系统三智能运维实践之总篇——智能运维转型与7e平台设计

系统三智能运维实践之总篇——智能运维转型与7e平台设计

系统三团队主要负责中国银行x86平台的运维工作，也是中心在开源互联网技术领域的先行者和实践者。x86平台技术的特点和传统基于IBM小型机、大型机及其上运行的商业软件，无论在架构、运维模式、管理模式上都具有非常大的差别，甚至可以说是完全不同。中国银行的IT系统的最大特点是x86平台和开放平台两头大，两边在分区个数、系统复杂性等方面上比重相当，开放平台承担更多地重要性系统，但自2017年起将会从主机、开放平台下移部分查询交易，且未来运行于x86平台的网络银行类系统的比重将逐渐增加，因此x86平台的运维工作将更加重要、更加复杂。

使用传统模式进行x86平台运维的现状与问题：

随着系统交付规模越来越大、时效要求越来越高，业务的快速上线、敏捷投产和批量变更对运维工作提出了更高的要求分布式架构下海量服务器的集中监控、分析与操作要求运维具有高度的自动化、平台化能力传统的运维方式偏重系统组件级分析监控，应用与业务层面分析监控能力不足，对于复杂场景系统的应急状况，无法进行交易的自动化关联分析传统的运维模式遵循ITIL标准，运维工作多停留在部署、变更、应急、隔离、重启等保障系统可用性层面，运维产生的大量数据未能有效利用，难以为业务提供有效的运营价值

面对上述问题，系统三团队从2016年开始了智能化运维转型之路，转型过程中，传统的“监管控”的运维模式已经不能满足现代化运维需求，需要逐步由原来的“事件驱动型”向“数据驱动型”转变。2016年Gartner提出了如下IT运维发展历程图。

当前IT运维正快速由ITOM向ITOA转变，并进一步向AIOPS发展。在ITOM（IT运维管理）阶段，运维工作主要集中在容量、性能、事件、故障管理、配置管理等方面。在ITOA（IT运营分析）阶段，要求运维在保障服务可用性基础之上，能够通过大数据分析技术，从海量数据中提取出有价值的内容，为业务提供运营决策支持。当IT运维发展到AIOPS阶段时，运维能够在数据分析的基础上，通过机器学习与人工智能技术，使IT系统对自身运行状况进行自我学习，自主决策，并通过自动化的手段，代替人脑决策和手工操作，达到智能化运维。

系统三在智能运维转型的路线上提倡以开源技术为主，方针上尽量满足自主可控，在某些领域，例如监控、自动化配置部署、大数据方面，力求做到完全基于开源自主研发；而对商业软件依赖比较严重的领域，例如微软、VMWare、防病毒、云平台等，我们要求厂商的产品必须提供API，我们基于这些产品的API进行二次开发和定制化修改；对于完全封闭、不提供任何API的产品，我们会考虑用开源软件进行替换。

在上述路线方针指引下，针对系统三日常运维所涵盖的各方面内容，系统三从2016年开始研究规划“7e”智能运维平台。目标是通过2-3年时间，整合现有x86平台的工具、脚本和系统，挖掘运维需求，打造以“7e”为主的智能运维体系，实现x86平台自动化、智能化的运维目标。“7e”建设之初，整个平台只包含5个子平台：EIRMS、EOPS、ECOPS、EWOPS、EVIMS，后来随着IT运维的发展，系统三对智能运维的逐步深入研究，以及整个中心层面的工作需求，又补充进入了ECMS和EIDAS。时至今日，系统三自主或半自主开发的平台已经不止7个，但仍沿用了“7e”的简称，这些平台的简要介绍如下：

EIRMS：x86平台的CMDB，包括基础资源信息管理、工作流、团队综合管理等EOPS：x86平台分布式自动化运维平台，主要针对Linux运维，包括监控、告警、配置部署、健康检查、日志查询等，同时为大数据分析提供展现页面ECOPS：全辖业务、办公终端自动化管理平台EWOPS：基于Winows的自动化运维管理系统，包括部署配置、性能监控、健康检查等EVIMS：x86平台服务器及终端的防病毒一体化运维管理系统ECMS：云化资源管理平台，目前以青云为主，包括分行托管云，以及未来西安合肥云数据中心IaaS层的资源管理EIDAS：运维大数据平台，收集全中心的系统、应用日志，提供准实时、实时、离线三种分析模式DBOPS：x86平台统一的数据库管理平台，涵盖Oracle、Mysql、MongoDB等，包括监控、巡检、变更操作等BOCSYS3：虚拟化管理平台，包括虚拟化信息的收集、管理，以及通过VMware接口进行虚拟化管理操作

随着各个平台陆续建成并投入使用，又引入了新的问题：

各平台有数据上的重复，最简单的一个就是服务器列表，EOPS、DBOPS等平台都需要用，如果每个平台都各自维护一份，就面临着如何同步的问题，如果只维护一份，那么该以谁为主？各平台有基础功能上的重复，比如登录、发送邮件、告警、自动化配置变更等，重复开发的话会浪费人力精力

我们在做“7e”设计的时候，最开始只是把它当成一个个独立平台或者工具去用，还没有一个服务的概念，也没有构建整体框架的想法。当平台越做越多的时候，实现有些功能就没必要重复开发了，比如开发C平台的时候发现有些功能A平台能提供，有些功能B平台能提供，但是AB平台开发语言不同，接口标准也不统一，调用方法也不一样，这就比较麻烦。有段时间几个e平台之间的关联关系非常混乱，代码臃肿，逻辑也不清晰。

在后来的规划设计中，我们引入了SOA面向服务的理念，在平台和开源/商业软件的API之间加了一层微服务，并且借助2017年发展火热的容器技术来承载微服务。这一层微服务主要作用和好处如下：

屏蔽底层不同组件的接口差异，微服务对上层提供规范化、标准化的REST接口，标准由我们来定义，输入输出参数、接口语义必须固定打通基础数据和基础功能服务，基础数据只存一份，不区分是来自哪个平台的数据，统一都称为系统三的资源，并提供标准化的微服务接口。一些基础功能，例如单点登录、发送邮件、Websocket消息通知、上传下载导出文件等，都统一由微服务提供，各平台不再重复开发，直接调用即可微服务可以通过容器非常方便的进行横向扩展、负载均衡、故障隔离等，高可用和高效率同时兼顾使用容器在开发测试部署的持续集成方面非常方便。以前做版本更新，必须停服务，停业很久，现在可以在保证业务不间断的情况下做灰度发布加了一层微服务后，各平台只需专注于自身的功能逻辑，无需操心底层功能怎么实现，直白地说，想要啥功能先去微服务找找，没准就可以直接调了微服务也可以为其它团队提供服务，现在中心已经有越来越多其它团队向我们要数据时可以通过微服务提供了，不用再像以前一样导出成excel或者文本文件发出去，还要定时更新

增加了微服务以后，以前的平台代码需要做重构，把原来直接调用开源组件的API变成调用微服务，目前这个工作EOPS和EIRMS已经完成，其它平台后续视情况逐步改造。

系统三智能运维转型除了需要扎实的方法论做理论基础外，其实践还是要依托于“7e”体系，后续文章会逐一介绍“7e”是如何实现x86平台的智能化运维，敬请期待。