导读：

今年是电信 O3 设计编排、移动 O4 二级编排(以下统称为业务编排中心)的大规模交付年；业务编排中心系统采用了云化的微服务架构，服务之间的调用链长，依赖关系错综复杂，让运维复杂度陡增。当系统出现异常时，几乎都是依赖人工运维，运维压力大增，人力成本很高，给各地办事处带来了沉重的运维负担。

这与公司今年推行的降本增效总体方针背道而驰。急迫需要一种工具能够把人力从运维中解放出来，降低运维成本，运维子系统这种自动化运维产品套件因孕而生。

客户现场的运维压力

“为什么我的手机到现在还没有开通？”客户因等待业务开通时间过长产生不满而询问营业员时，营业员面对这种情况除了一边劝客户耐心等待，一边向后端支撑人员求援以外也是毫无它法。为了尽量少的影响客户感知，现场运维人员不得不全力以赴解决此异常，给运维人员带来的压力可想而知。除了前端给运维人员带来的压力，异常的定位、修复效率也让运维人员异常头疼。

云化的微服务架构，让异常定位难

业务编排中心为了高扩展性，采用分布式云化微服务架构，既需要高性能又需要进行微服务集群化部署。这样做产生的副作用就是让服务间的依赖关系越来越复杂，系统间的交互节点越来越多，调用链越来越长。目前业务编排中心对业务端到端全流程没有做到全方位监控，当异常发生时需要通过查看各种日志来还原异常发生的原因，让异常定位比以前的单服务架构困难了很多倍。

异常单点处理，无法形成有效可共享的经验库

运维人员在平常处理异常的过程中，都能够总结出一定的经验和方法，下次再遇到同类问题时，处理效率能够提高很多。但因为没有相关工具来支撑，这些经验和方法无法及时共享。换一个人或省份再遇到同类异常时，又得从头再来，这无形中让异常修复效率降低了很多。

缺少运维工具，让异常处理时效性难保障

对于同一类异常，就算有丰富的处理经验，但因为缺少运维工具的支撑，异常的修复完全依赖人工操作。少量出现时还能应付，但当发生大面积异常时，就会让运维人员应接不暇、焦头烂额了，异常的处理时效性也难以得到有效保障。

如何能够帮助前端运维人员减轻压力，同时响应公司降本增效的号召，将人力从繁琐的日常运维中解脱出来，增加端到端人效，是我们必须要思考并解决的一个问题。

运维套件因此孕育而生。

降本增效神器--运维套件

运维套件就是把运维人员日常解决问题的经验和方法通过脚本转换成可动态运行的一个个组件，再通过运维编排将这些组件按照一定的顺序自动执行，最终实现异常的自动化处理。要想知道运维套件是如何实现异常自动化运维的，需要对运维套件的工作原理、功能以及运行方式有一个深入的了解。

运维套件自动化运维原理

运维套件的功能体系和运行模式与业务编排中心是一致的，运维套件能够实现自动化运维，离不开业务设计编排的赋能，业务设计编排将异常查询能力、业务数据的查询能力、业务数据的修复能力、流程引擎的调度能力等开放给运维套件使用；运维套件利用业务编排中心赋予的能力，通过设置一定的监控策略，能够主动监控业务编排中心发生的异常。当异常发生时，运维套件根据策略自动匹配异常处理组件，启动异常修复程序。对于修复成功的，运维套件通知业务编排中心让流程继续流转下去。对于修复失败的，则通过消息推送功能，将处理失败的结果告知运维人员，转为人工处理。具体的处理过程如下图所示：

从运维套件异常修复流程来看，运维套件要能够良好运行、实现自动化运维，必须做到主动发现、自动修复、修复失败后能够转人工处理并通知相关运维人员。基于这个功能需求，就可以设计出运维套件的功能架构。

运维套件功能架构

从运维套件功能需求来看，运维套件包含运维监控、运维编排、异常修复、消息管理四大核心模块。为了管理运维套件，还需增加基础管理模块。具体功能架构如下：

• 基础管理

实现运维套件的基础管理功能，包括运维人员管理、组织权限管理、日志管理以及修复指令脚本管理。

• 运维监控

主动监控业务编排中心整个运行过程以及业务编排中心依赖的 PAAS 平台。包括订单监控、流程监控、API 监控、PAAS 平台监控。

• 运维编排

对监控发现的异常，启动流程实现修复流程调度。包括组件管理、运维流程编排、运维任务管理、运维调度管理。

• 异常修复

实现异常的自动修复或生成人工修复工单。包括自动修复管理、人工修复管理、异常修复统计。

• 消息管理

对于自动修复失败的异常通过邮件或短信等方式通知运维人员，包括消息模板管理、消息推送管理、消息降噪规则管理。

从功能架构可以看出运维套件与业务设计编排是相辅相成的。业务设计编排为运维套件赋能，运维套件协助业务设计编排完成异常修复，运维套件可以与业务设计编排无缝衔接。运维套件除了实现异常的监控和修复两大核心能力外，还附带了其它两大好处。

• 一省定制、多省共享

试点省份定制化运维组件，上线稳定运行后，可共享给其它各省份。其它省份出现类似异常时，可以直接加载使用，无需再次投入人力重复开发组件。

• 图表监控、一目了然

运维套件自带图表统计分析功能，包括异常组件数量统计、运维任务统计、异常修复率统计等，让运维套件的运行情况一目了然。

运维套件一项核心的能力就是实现异常的自动修复，而自动修复是通过异常修复组件实现的。这里的组件是基于 Groovy 脚本将平常的运维经验和方法进行固化，可以根据需要实时动态定义。

下面通过实例来看看是如何将异常处理方法和经验封装成组件的。

组件封装实例

某省 O3 设计编排上线初期，异常单相对比较多，花费了运维人员极大的精力。通过对异常进行分析、总结、归类发现，其中异常率最高的一类异常为编排中心调用流程引擎创建工单时，因为网络不稳定，调用超时造成工单创建失败。根据以往的处理经验，我们很容易分析出处理这类异常需要分两步走。

第一步：获取工单创建失败的消息 ID。

第二步：根据消息 ID 判断工单是否真的创建失败，如果实际是创建成功的，则将该消息修改为创建成功，如果创建失败，则重发该消息。

根据以上两步，我们可以分析出业务编排中心需要开放异常消息查询能力、工单实例查询能力、消息重置成功能力以及消息重发能力。根据业务编排中心提供的能力，基于 Groovy 脚本，我们可以定义两个组件来修复该异常。

第一个组件为异常消息查询组件，通过调用业务编排中心开放的异常消息查询能力查询工单创建失败的消息 ID，根据运维套件的组件规范要求，所有的处理组件都必须实现 IGroovyExecutorExt 接口，逻辑代码如下：

第二个异常修复组件，首先调用业务编排中心开放的工单实例查询能力判断工单是否真的创建失败，再根据判断结果分别调用消息重置成功能力或消息重发能力，实现异常修复。其逻辑代码如下：

这里之所以拆分成两个原子组件是基于组件能力复用来考虑的。组件编写完成后，可以即时加载到运维套件系统中，通过运维编排，将查询组件的输出结果作为异常修复组件的输入条件。前期为了验证组件的执行效果，可以通过手工执行的方式进行验证。当验证成功后，可以将该组件设定为自动调度运行。运维套件下次再监控到该类异常时，就可以自动修复了，该组件稳定后可以共享给其它省份使用。

运维套件价值成效

在运维套件的建设之初，我们就为它设定一『低』三『快』的目标。

一低即能够低成本部署，应用部署时间约为 1 人天左右，不需要高配置，并且套件本身消耗较小，可以与设计编排中心共享机器。如果需要额外申请机器，申请最小配置即可。

三快即快速自动发现异常、快速自动定位异常、快速自动修复异常。三快给我们带了效能的极大提高，主要体现为：

释放人力，降低运维成本

异常处理全自动化，只有在极少数自动化处理失败的情况下，才需要人工介入，极大地释放了运维人力，降低了运维成本。

降低运维门槛，减少对高级人员的依赖

产品线将各种异常组件封装后供各省共享使用，极大的减少了各省的运维门槛，减少了各省对高级运维人员的依赖，可以投入更多的资源服务于客户。

节约时间成本

在未上线运维套件以前，遇到异常需要手工一个一个的修复，有了运维件套件以后，系统能够一次性批量处理一类异常，大大节约了异常修复时间。

保障业务系统稳定高效运转

许多常见的异常都通过运维套件快速自动处理了，保障了业务系统稳定高效运行。

以某省电信 O3 系统为例，运维套件上线前，异常率占比约为 0.08%。运维套件上线后，初期根据业务需要定制了 5 类处理组件，经过 2 周左右的时间运行，异常率减少到了约 0.03%。在无需人工参与的情况下，异常率整整减少了约 62%。

通过数据可以分析出，通过分类处理后，真正需要人工介入的异常相对比较少，大部分异常都可以通过运维套件自动化处理。因此不难看出自动化的运维套件是一个低成本高收益的降本增效神器！

总结

自动运维套件自建设以来已经加载了上百个运维组件，运维套件的建设对外能够自动监控异常的发生，先于造成客户影响前发现问题；自动化异常处理技术，实现异常自动化修复，先于客户投诉前解决问题；处理失败的异常告警能力，能够将自动修复失败的异常推送给相应运维人员，防止异常丢失，提高运维人员的认同感和满意度；对内积极响应公司的降本增效号召，降低公司的运维成本，一举四得。自从有了运维套件，运营业务再也不必担心会遇到客户的不满投诉了。

运维套件目前只对接了业务设计编排中心，像资源、采控、调度等系统平常也会遇到同样的运维问题，后续根据需要也可以对接资源、采控、调度等其它系统，运维套件必将发挥它应有的光芒。