作者简介
桂林
中国人寿上海数据中心，服务处经理
带领团队独立自主开发了中国人寿自动化运维平台，基于开源平台自开发，建立了自主监控、自主流程、移动运维的一体化智能运维体系。
前言
本文主要讲的是中国人寿自主研发自动化运维平台成功要素。写了中国人寿自动化运维平台从无到有这样的过程，并这有一些关键的要点，给大家做一些介绍。
上图中的照片来自网络，我曾经是个快乐的码农，以前是做一些保险业务平台开发，比如车站码头乘客意外险出单系统等，后来开始做运维，真是一入运维深四海，没有做开发那么痛快，因为有很多苦逼的经历。
1、运维之疼
疼点一：系统繁多
以前我们分公司的机房可能没有那么规范，我们做光纤布线的时候没有跳线架，拿一根PP管把光纤插进去，揭开机房地板直接从地板下面把PP水管捅过去，用这种方式来搭光纤连接服务器和存储，很粗放。
集中到数据中心运维之后，主要的产品线比较多，特别是像我们这种情况，因为我们现在集中主要还是物理集中其没有逻辑，就是一个系统就是只有36个分公司，一样的数据库可能就是36个，所以我们产品线比较多，这个就导致我们应用的实例和数据库的实例也比较多，我们批作业量也是比较大。
这个前期我们在没有上线自动化平台之前，我们是发动了全国分公司的信息部的人力一起干，为此我们还要拨出一部分费用，每一年给他们一点奖励。
疼点二：设备繁杂
我们的设备是比较繁杂的，大家看这张图片，很多分公司的机房就是这样子的，当然总部数据中心要规范多了。
疼点三：标准杂乱
到目前为止实际上我们已经在逐步的去改善这个情况，但是现在我们还是有一部分的大部分核心数据是在小机上面跑。标准比较杂乱，我们刚刚做的时候，标准是比较混乱的，操作系统也是有32位的有64位的，redhat 有5.4的，有5.8的，我们数据库版本有也有很多种。
疼点四：操作无序
这个是一个最大的问题，就是我们的操作，手工操作这个是比如说我们做数据库转换的时候，或者是很大的一些数据迁移的时候，我们可能会大量抽调全国做临时的补充。人手不够是因为你没有相应的自动化平台，平时我们操作的时候也是按照一个操作手册来做的，而且变更也没有做一个有序的管理。
这个也是一个很严重的问题，基本上节是出了事情我们开始做变更。没有一个完善的规划，这个也是一个比较严重的问题。一个事件导致一个变更，因为是没有计划和组织，没有经过严格的一个计划安排，所以说往往有可能导致新的事件，被动地变成一系列的变更。
那么怎么办？这个会导致，我们需要有一个蜕变。从传统的企业来讲，我们其实蜕变的这个程度还是比较痛苦的。
2、化茧成蝶
蜕变一：标准化
我们的第一个目标就是将大量的开始做X86和U2L转换，把我们本来是在小机上跑的应用程序转移到X86平台上去，进一步转移到虚拟机的 Linux。
这个应用改造是第一步，我们通过这个改造我们节约了大量的小机。现在我们除了核心的数据库在这小机上面，我们基本上所有的应用服务器都是基于 Virtual Linux，当然虚拟机也有一部分是 win 的。而且现在除了 vmware 之外我们还有建立了我们一个 OpenStack 集群。
我们做 OpenStack 给我们的研发团队使用，同时我们还在做我们的一个基于 Docker 的一个 PaaS 平台的研发。我们通过这些方式为后期的标准化打下基础。
基础平台标准化
我们开始做一个标准化，首先是统一一个设备的采购标准，我们统一了一个操作系统、数据库、中间件版本以及我们很多的开源的平台我们也是做标准的统一化，就是有统一的规范，以便我们运维有一个统一的管理。
应用架构标准化
这个是我们根据以往的教训对研发上线的应用系统我们做出了一些架构上的规避，比如说我们对非集群的系统我们不允许上线，或者说你这个是单点的，你没有采用集群架构我们是不允许上线的。
你用什么手段保证你的数据库实现一个热切换，可以有一个更快的恢复，规定我们一个抽取的标准，你数据怎么抽取也要有一个规范。
我们和研发就达成了一个君子协定相应对于你推过来的版本不符合规范我们是不允许上线的。我们应用架构标准化这一块是就是推动到研发当中去发挥出我们的影响力。
运维流程的标准化
这一块我们新从新开始做出梳理，先是从有设备来的时候配置资源上线和下线的流程，到把我们这个设备的管理规范起来，然后我们再设立我们计划变更的流程。
现在我们基本上规定在周三有一个小变更，周五一个大变更，其他时间是不允许做变更的。这样我们如果说有变更的话，我们都要提前一周做一个变更计划，通过评审才可以在下周做一个大变更。
我们对于一些影响比较小的，范围比较小的小系统，或者是特别紧急的系统，我们可以做紧急的变更，我们紧急变更我们也有一个审批流程，这样就把我们整个的变更的管理让他有序，让他形成一个安全可控的一个状态。
我们同时也建立安全事件的管理流程，以及我们变更的手段，都把它做到有据可依，有据可查，有法可依。
操作流程规范化
操作规范的标准化，这个也是我们做标准梳理的一个重要的动作，我们把我们的知识建立了一个文档库，我们把操作手册集中起来，首先要做的是文档管理，所以文档版本要统一。
统一以后我们的变更的时间建立在周三到周五的八点钟以后，做到定期维护。
蜕变二：工具化
下一步就是要建立我们的工具，我们把标准化做好了以后就要建立我们自己的工具体系，我们的管理工具，这个我们现在还在用
流程管理工具
统一的流程管理，通过一些流程观点的通知，来做到我们的一个所有的流程的统一管理，就是相应流程包括我们这个权限申请的流程，通过这个平台走。
我们用的监控工具也是基于一款商业软件，能够解决大多数的基础平台状态监控问题，而应用监控这一块是比较薄弱的也都有一个共同的通电在里面，因为你是依赖厂商，新的需求就一定要定制化开发。
蜕变三：自主化
然后操作自动化工具是缺失，这个应该是在12年、13年的时候，我受到领导的委托做一些商业的自动化操作软件的一些POC。
你们看我们考察了很多的商业软件，我们用了大量的精力来考察这些商业软件平台。
然后总的来看，我得出这样的结论，第一个就是软件过于庞大，就是这里面很多的功能，有我想要的功能，但是有很多也是不想要的，但是这个东西因为是一个成熟的商业软件，所以不管怎么样你都得要。
这个报价预算这个就不具体说了，因为我们目的也是不仅仅想试一试，而是想选择一个产品线，我们未来两地三中心整个生产系统，我都想要通过这一个产品线管理起来，所以说因为我们这个预期比较大，他们的胃口也比较大，所以报价是超出我们的预算的。
POC 效果是勉强的，这个很难把个个都测到点，而且很多的功能想做并不是想做就可以做，比如说我当时有一个很简单的功能需求，云平台是面向用户的申请，而我们这里的管理员还有一个需求，就是我把虚拟机配置清单形成 Excel 文件导入进系统，系统就自动帮我把虚拟机全部建好。
但是当时我们跟厂商接触的反馈就是说，这个功能需要另外开发因为他们的产品是没有这个功能，需要另外再开发，类似这种定制化开发还有很多，所以这个开发量是很大的。
什么意思呢？比如我们现在人寿的有一个云助理平台有一个消息推送功能和我们想要引进的商业平台整合起来，或者是短信整合起来做推送，总之这些都是非常困难的都是需要开发的，每一个点上都钱都是需求都是投入，因为这些种种原因实际上我们这个采购平台的需求是迟迟得不到领导的批准。所以这是很痛苦的一个事情。
后来我们最后决定做自主开发，因为当时正好是14年九月份的时候，银监会出了一个文，就是要求实现我们国内金融行业的一个信息系统安全可控的文件，这个文件下来以后，领导态度就变了，领导就是说鼓励你们做自主研发，我们同时也存在规模瓶颈，大家可以看这是几个图。
<img src="http://www.greatops.net/zb_users/upload/2017/04/20170417203534149243253414572.jpeg" data-w="1280" original="http://www.greatops.net/zb_users/upload/2017/04/="img-responsive" style="box-sizing: border-box; border: 0px; vertical-align: middle; display: inline-block; max-width: 100%; height: auto;"/>
这个是我们以前在上海集电港的一个机房，随着规模上面以后，成本是越来越高的。而且我们在这边我们有很多也还是有大量的技术的沉淀，我们现在就是 OCM 有七个，CCIE 也有五六个，是能够干一点事的。
其实作为一个没有这种经验的一个传统公司，要来做这些事情是很难的，因为你特别是走出第一步，非常难。因为之前我们都觉得要做这些东西，要自己来做简直是不可思议的，后来我们也是做了大量的POC验证，去选择一个开源的框架做这个事情。
根据我们现有的情况，实际上我们有一部分是开源的东西，这个是我们研发平台，我们用这个 openstack 来做。还好就是 vmware 的 vsphere API 是全开放的，他每一个版本的SDK都是可以下载的，可以给你做指导，我们基于这个做定制化的工作，我们应用监控是做了大量的日志挖掘。
然后基础平台监控我们是基于开源做完全的重新企划，我们这个是已经达到每天一个亿的监控信息采集规模。大概是有十个 zabbix proxy，就可以扛住了。
我们的主界面我们用了比较有意思的框架就是 primefaces，快速的一个 WEB 组件开发的一个框架我们移动端是用的 JQuery。我们在流程方面我们还是用了一个开源的平台就是 Activiti，自动化我们主要是用 zabbix 的API来实现命令统一推送和配置采集。
实际上自动化我们用了两块，一个是通过 rundeck 做批作业，还有一些基于ssh的一个推送，我们还用一个 zabbix 带有一个告警自动修复功能有一个API，我们利用这个做了一个脚本推送功能。
我们是自主研发整合不同开源和不开源工具，融合现有的生态环境，尽量节省开发人力，现在大概是20万行代码，这个写了一年多写出来，这个量也不小，有数十个功能模块。
现在我们基本上目前我们是 zabbix，已经是全面覆盖掉商业监控软件的所有的监控点。Activiti 这边我们的紧急变更，还有资源的上线都来走 Activiti，而不是用原来的商业流程软件了，我们走逐步的替换的这种方式。
组件我们就是使用了 Primefaces，我们后面的框架主要是基于 JSF 和 spring。我们开发的速度是很快的，功能上线基本上一个新功能一周就可以上去。
这是一个简单的架构，我们现在这一个平台是基于 JQuery Mobile 的界面，就是我们这个界面就是自适应的，不管是什么终端访问都可以自动的适应你的屏幕。
我们前端是 Nginx 做附载均衡，后面是有 Redis 是高速缓存的。几个组的 Tomcat 是做我们的任务的调度脚本的分发以及虚机的管控，云平台的管控，这后面是我们的 vsphere API 和 openstack API。下面有 zabbix proxy 这里画少了，我们现在 proxy 已经有十多个。
这是我们的自己编写的云平台的界面，我们内部使用资源币控制资源消费，你用一个月还是用半年价钱是不一样的，然后因为通过这个环境管理起来，我们研发环境他们在也不敢浪费了。
都是内部的客户，其实这个价格也不好我们算，但是我们有这么一个机制以后，研发在使用资源的时候就不会扔在那过了一年两年还在跑没人管。
这个是我们做运维分发的工具库，而且我们每一个推送的脚本都是做了详细的日志，而且我们通过这些脚本的贡献者，可以去考核我们每一个系统管理员在我们知识库里面的贡献度。
现在我们实现的功能，不只是这些，最高效的是去年我们有一个X86机房都是比较热，需要关机，这个我们作用发挥了非常大的作用，我们一个按钮下去200多台机器就搞定了。
现在看到的这个是我们移动版的功能，这是我们的主机变更的流程，你只需要把你的流程图在 Activiti 里面画出来，很少的编程就可以把这个流程跑起来，非常轻量级的这么一个机制。现在我们的紧急变更基本上都是通过手机申请的。
这个是我们项目在2015去年获得了保险行业协会一个奖——“2015年保险行业信息化杰出项目奖”。
3、未来方向：自主开发一体化DCOS
下面讲一下未来的考虑，我们做了一些小东西，未来通过这个框架不断的拓展去自主研发继续深化，做出一个自主开发的一体化的 DCOS。
我们可以通过执行我们的运维命令，比如说我们在移动端就可以做虚机的一个资源情况的查询，以及虚机的一些服务器的重启，扩展我们数据库的空间，包括我们建立或扩展文件系统，这些标准化的操作都可以做的。
另外我们可以做到智能修复。如果说一些管的不是很规范的地方，觉得这个很简单，发现了以后修复就可以了，但是不行你必须要留下变更的轨迹，所以我们要通过 zabbix 自动发现了以后，就是把这个自动修复了，然后通过 Activiti 留下一个紧急变更的轨迹，在我们的流程管理里面，以后是有据可查的。
然后我们计划还是要面向现在这种容器技术做我们云 PaaS 平台的交互，目前我们新一代 PaaS 平台是通过调我们自动化运维的 API 来找我们索取虚拟机环境，目前是这样的接口，未来我们想通过自动化运维平台来管理我的镜像和 PaaS 环境。
这是我们的一个设想，用开源代替封闭，用自建代替购买，用整合代替孤立。我们尝到了一些甜头但是前面还有很多坑需要我们踏。因为我们 zabbix 可以自动的把这些配置信息推过去，所以我们现在 CMDB 是很准的。
然后我们在刚才的移动版里面，我们又把 CMDB 的查询做进去了，因为我们希望所有的领导包括系统管理员都可以在手机上面通过 CMDB 查到这个设备的信息。比如位置信息在哪个机房哪个机柜，全部都可以查到。
所以我们 CMDB 实际上一个是源头是活水。因为从自动化发现里面出来的，消费是频繁的，因为每一次找服务器都是会用到他。我们以前的封闭的 CMDB 已经完全不用了，下面我们通过 CMDB 把我们现在有的工作流全部结合起来。
未来是什么样的情况，领导审批以后，系统管理员只需要点一下鼠标 Activiti 就会调我们的自动流标准件完成后续的工作，工作流和自动化完美融合，对外提供云服务菜单，这个就是我们未来的国寿云平台。