杜颖君-巡航太平洋，运维平台实施的苦与乐

刘策

作者简介：

杜颖君
中国太平洋保险信息技术中心运维研发团队负责人，目前负责运维平台的整体规划及架构设计，14年IT行业从业经验，6年大型项目运维经验，曾负责太平洋保险95500呼叫中心和产、寿险电销系统等项目运维工作。

我的个人发展经历一开始做了一段时间开发，后来转太保的运维部门，最后成立了一个运维研发的团队，我现在担任运维研发团队的负责人，主要负责自主架构的设计与团队建设，包括整个项目的上线和实施。

我今天的分享分为四个部分：

• 第一，介绍一下太保内部的运维体系。

• 第二，介绍一下这套运维平台的组成。

• 第三，平台上线后以及实施过程中遇到的问题和成效。

• 第四，未来的展望。说的是展望，其实是一些问题的探讨，也就是明年做的一些事情。

一、太平洋保险的内部的运维体系

太保的运维部门分为三块：

• 我本身来自应用运维支持部，我们部门的主要工作是对于系统的物理架构的设计和系统的部署、发布上线，和通常的处置。主要大的一部分就是说支持业务部门使用所有系统中跟IT相关的任何问题。这也是我们跟外界交流的话，一直说我们部门人非常多，为什么这么多？我这里介绍一下，我们70%的人力投入在业务系统的使用支持上，不光是系统坏了要维护，还是系统操作怎么去使用，这些也是我们这边的工作职责之一。

• 基础设施部划分不是从中间件开始，它安装完交付系统，以及中间件、数据库，随后我们去部署原生的应用和相关一些东西。

• 安全内控我本人不太懂，跟它们交流不太多，只是我们的一个部门。它们的职责我个人比较倾向于认为，把它们理解成锦衣卫。

二、运维平台的组成

2.1、运维平台的组成

这张图是我们平台，上面浅色的部分是团队研发的，从2015年开始研发的一些功能组件。神色的部分是技术监控、流程平台，以及对一些业务数据的采集。基础监控研究目前还在用BMC的产品。流程平台现在用的自主研发的流程平台，不原来买的给替换掉的。现在应用产生的数据已经作了汇总，我称之为运营数据。我们基于这一套整个数据结合我的流程监控以及业务，我们在延展出来一些可视化的东西，包括决策预警和智能客服。智能客服这块做得比较基础，还是基于人工维护的知识库，加上一些语音识别做一些场景式的应答。可视化这块后面会详细介绍，用于重大业务保障的大屏展示的东西，也是可以分担运维同学平时做的巡检工作。决策预警也做得比较简单。
　　

2.2、平台 Agent 介绍

　　
　　
这块是平台Agent介绍，上面是主体，负责插件的管理，还有自身的升级和插件升级，以及Agent运行状态的上报。为什么这样考虑呢？保证这块的业务实施尽可能让它少和简单，不容易挂，保证我对机器能够有绝对的控制权。后面是CMDB的插件以及日志插件和自定义插件。CMDB插件是独立团队做的，今年我们做了整合，做成一个大的主体。

2.3、平台坚持的路线

我们平台坚持自主可控的路线，拥抱开源技术，量身打造全方位、大功能的运维平台巡洋舰。这个路上是我们用的一些组件，其实我们选择这样的技术组件也是下了非常大的决心，因为我们的业务系统大多数还是基于传统框架，包括用的数据库绝大多数是Oracle。这里重点说一下MyKQL和Oracle，我个人当时认为当初选 MyKQL我是不太情愿。一个是我没技术积累，这两个东西比起来好处差距很大。现在说它唯一的好处是对于开发能力的提升，可能性能上面要关注数据量的点，我就要比Oracle低很多。可能Oracle的库在百万级、千万级，我都不需要对它有太大的关注。但MaSQL现在可能十万级就要去关注它的数据量，是不是要进行一些封库封表。
　　
整个平台运行一些交易记录和一些流水信息，包括我和Agent交互的内容。
其他是开发语言和消息队列，因为平台和Agent的交互处于异步模式。我们选择它，主要是因为它是强力执行的东西。Kafka我们用在日志平台上用作收集。这两个东西虽然功能相类似，但是使场景有明显的界限。Kafka相对来说高的吞吐量，Rabbit更倾向于长一致性，保证消息不丢。

2.4、CMDB

为什么我们把这块进行了重做呢？单独的CMDB给人工运维去做，其实功能也有，也不是不好用，最多也就是卖点。但是它的API支持相对来说比较薄弱，而且我没有可定制化的空间，就是我去找人开发也没有这样的人支持我。我要接我的运维平台，我要把CMDB作为标准的输出就很困难。自主研发就把这个弊端彻底解决掉，我可以随意定制API接口。另外从展示层面我们比BMC做了一些，基于日常维护中的痛点，也就是各个环境机器原来是看不太清晰的，现在我们做了各个环境的服务器比对。可以看到环境是不是一致，在这个图上可以比较清晰地看出来。这块是一个内部的拓扑，因为旁边的数也是静态的，我们制定的我们最关注的关键路径。这块如果单个系统去看这张图，只能说有效果。总体来说对于这些数据的分析，是非常有用的。对于我们故障的分析，在一个节点出现问题，可以清晰地看到这个是不是处于同一台物理机或者使用同一个数据库，这样我们对于这个价值。包括这个系统有关单点故障的风险，可以比较清晰对后台的数据做一个分析，然后得出一个结论。

2.5、自动化运维

这是我们自动化运维平台，我们部门现在日常运维的工作基本上都是基于这个平台，因为今年上半年是把大多数运维人员的后台账号全部收起来了，基本上不给用了。就是日常的变更、系统发布、异常处置都通过这个平台去做。这个界面是一个发布流程的执行过程。这块是日常配置的一些工具，包括它的起停和一些清理、日常动作都会配置成这样的工具，这样可以把人员的能力给彻底地分开。懂系统的人可以白天把一些事情固化下来做好，在晚间操作的时候，可以留给一些简单的人去处理一些需要花时间的工作。

每个节点我们选择不同的IP，去编制整个操作流程，然后在前面看的界面上做执行。

2.6、日志分析

这块是日志分析的平台，现在的数据量大概是每天增长1个T，基本上现在接入了60个重要的应用系统，这块还在推广中，基本上400多个系统。上面的图是针对我的关键字，在每个时点出现的次数，这样的分析对我的故障分析也是有一定作用的。就是我可以做一些比较，这个错误在哪个时间点出现得相对比较高。后面错误关键字，或者我想要关键字，在每台机器上的分布。我们的纬度是从系统出发的，肯定比较多。我们做这样的一个分析。从目前来说这两个是做客制化开发的，主要对我们常用的东西做了统一检索和初步的分析。
　　
讲到ES我这边分享一个在实施过程中遇到的解决过的一个问题，我们ES搭建的一个集群当中隔一段时间就会发现某一台机器不停地做垃圾收集，导致它脱离机群，反正有多台，一台一台的掉，最后要重启机群。我们分析原因，对于系统性拆分，比如对于拓扑24，最关键的24系统，我也是建单独的索引。索引产生了ES有一个sgenment（音）的单位，每个索引上面随着数据的加载，这个东西会越记越多。最后这个东西多了，导致内存溢出。最后我定期对前一天的索引，等于静态不会加载数据的索引，做了一个Fsmozhe（音）的操作，其实是ES本身提供的一个方法。这个动作一做，就把Sgment单个索引降成24个，这是固化的数字。这个问题如果大家以后碰到可以看一下这个方法，或者已经用的可以提前做一下。
　　

2.7、可视化看板

这块是我前面提的可视化的动作，这是基于寿险的全链路交易，包括核心系统服务外面的一些出单、神行太保整个链路的交易。我们前段时间“开门红”的时候，也是用到了这个大屏展示。一个是系统巡检可以方案省下来，另外在保障期间，这些领导或者运维部门的小伙伴都可以看这些屏，能够知道一些系统的状况。这是出单量，我们也是做了一个地图，使它一些关键的业务数据我们都采集在这上面，并且做了一定的显示。后面也是基于某个系统的一些技术指标，这等于是辅助基础监控的一些不足，基础监控不涵盖的东西我们也做了一些弥补，就是中间件的数据，以及数字化的链接数，你配置的中间件会不会超过这个最大链接数的数字，在这个看板上是可以显示出来的。
　　

三、平台上线后以及实施过程中遇到的问题和成效。

3.1、自动化运营平台的流程编排　　

　　
　
　　
系统介绍完了，后面是系统的全效。刚才看到自动化运营平台的是一个流程的编排。这边简单介绍一下编排的大致过程吧。原子脚本对于我来说，脚本要执行的内容。加上一些我事先定义好的参数，这个脚本需要有那么参数来做，后面是方案，方案是根据每个系统的不同，把脚本定制的参数值给填满。最下面一层是工具，工具就是方案与IP的结合，这些方案可以在哪些IP上执行，最后通过一个流程把工具串起来。工具也可以单个直接生成下面的任务的，这样有效把人员的操作职责给分开了，白天可以把一些发布的流程或者方案任务创建好、配置好，等到晚上有另外一波人来执行，看着这些东西，包括验证的东西都在这个里面。

3.2、运营平台的成效

这张图是运营平台的成效，首先纳管有1.2万台服务器，一次会支持200多个系统的发布，平均耗时每个系统27分钟，最快的4分钟就可以完成发布。现在晚上一个人可以通过操作6个系统，在之前纯手工的情况这个数字是反过来，大的系统是6个人进行操作。

3.3、平台流程图

这块开发交付到自动平台一直实施发布的流程图，平台会解决什么问题呢？原来是基于TBF服务器的，开发对TBF服务器也有一定的操作权限，是可以把程序包换掉的。给不给换，就看开发和运维的关系好不好。现在必须把测试部的意见接进这个系统，整个流程把系统固化下来了，至少是有一个记录，也不是说完全不能换。可以把这些完全线下的人为风险给控制住。

3.4、新增设备流程图

这块一个新设备的投产过程，一个机器分IP的时候，IP手工的登记到CMDB当中。然后装机家长部署监控，就是操作系统以及中间件、数据库，加上监控服务。这块是基础步骤，后面是部门做一些应用部署，然后再次登记CMDB，把一些部署的应用、节点、端口再次登记到CMDB当中，最后是服务器的投产使用。我们用了这个平台以后，这三块的东西全部可以自动化地实施。部署应用是通过平台，可以是定义好任务自动去执行或者人工触发也可以。

3.5、人员结构的调整

中间也不是不能做，但是因为是跨部门，因为一些部门之间的壁垒造成了一些问题。它们通过我们提供的原生PaaS主线做了一些流程，用它们的工具去实现部署。平台上线以后对于运维人员的调整做了比较大的变动，这是原来的架构部署，对于架构设计、系统部署这块都是要做的。可能一组少数三四个或者四五个人，去服务于两三个系统，是这样的架构模式。

现在通过平台，我是把架构部署的人员给独立出来的，这个全部是由系统去固化。这个好处，一个是通过这个系统我的执行效率提高了。可能这个团队现在维护5台机器50台机器、5000台机器效率不是线性地下降。可能最终实现的目标是5000台和50台速度是差不多的。另外对于内部的标准化是差不多了原来三五个人管三五个系统，看不到别人的东西，自然设计出来的东西是五花八门的。这样每一个人负责的系统多了以后，对于推动这个标准化是非常有利的。我看到一个人要负责20个，对于我的自动化配置的一些工作来说，我也可以减少。如果标准的话我可能要配20遍，如果是统一的东西都一样的，一个个复制就搞定了。下面的业务支持没有太好的办法把工作量减下来，还是要投相应的人力进去，占了部门70%的资源。

3.6、实施过程中的问题

接下来是几个问题。
　　
- 第一，标准化程度差，现在120000台机器，我们简单统计了一下，Linux的版本至少有64。所以我们部署这套系统的时候，也是相当痛苦。
　　
- 第二，缺少专业团队支持。技术部的Oracle有一些自己的在里面。
　　
- 第三，团队定位比较尴尬，毕竟是运维部门，开发也觉得这块东西是我们作为需求方让他们来做。我们的运维团队觉得凭什么你们这个团队可以做研发，他们也是挺不服气，肯定有这种情况在里面。
　　
- 第四，系统提高效率的同时，一定会带来批量执行风险。可能原来操作的时候有思考空间，现在可能一下会导致毁灭性的灾难。
　　
- 第五，系统产生了之后并不是说拿出来就是享受，中间还有配置的过程。上面一部分负责架构部署的人员就需要往系统配置标准的方案和流程，这一部分我们推动的阻碍也是比较大的。因为他们的工作压力确实也并不小，也是日夜颠倒，这是经常的事情。再加上这块东西，阻碍是非常大的。我们今年上半年对系统的易用性也是投入了相当大的精力的，去年年初的时候整个系统的功能已经差不多做完了。今年大概用了三四个月，就是考虑让它怎么配置简单一点。

四、对未来的展望　

最后说一下未来的展望 AIOps。

第一、是继续完善数据运维平台，现在做的工作把数据产生出来了。其实我们怎么把数据用好，让它产生更好的价值，来进一步减少人力投入和故障发现和恢复的速度，这是我后面要重点去考虑的东西。
　　
第二，结合一些机器学习的技术，强化故障诊断和分析。这块我们会尝试建立一些决策数据，包括刚才CMDB已经采集到的数据，去做一些分析。比如说5台服务器挂了，我先看一下它是不是属于同一个应用，或者是不是处于同一组物理机上，对于故障的分析会有比较好的帮助。
　　
第三，业务之间的关联关系，调用的自动识别。这块在保险行业业务系统之间的互相调用是相当复杂的。我们之前也是看过一些产品，投入网络包帮我们抓取一些数据，抓出来的图确实不能说它不全，但是人是没法看的。这个问题对于我们来说，我们要改造现有的业务系统这是不可能的。从我的角度想的话，我通过日志，结合一下网络抓包，再结合一些相对的机器学习的一些技术，能够把它作为一个收敛，来生成一个比较完整的，而且又是能够自动发现识别的业务关系的调用图。这个对我的发布当中的一个影响评估也是会有帮助的。就我现在发布当中发了一个系统，我可能不知道我会关联哪个系统。我要回退的话，也没发通知，要组织很多人来评估。这样的话这个图能够比较高效地出来的话，对于这块是非常有帮助的。

第四，强化机器学习技术。强化智能客服，想办法减轻减少70%的人力投入，至少能够让它少量增长甚至不增长。因为从目前的技术水平来看，我估计减少人是不太可能的。

第五，运营分析，我们之前做过业务的出单量预测。但实际的应用场景和价值并不是太好，也不是不准，也准，就是没有想到太好的地方去用。后面还考虑怎么把和发布之后产生的数据关联起来，做一个整体的分析。
　　
　　

最后是一个愿景，这张照片是我2014年的时候拍的，我是在等一个悲催的批处理执行完。这个事情彻彻底底人耗在那里，必须看着。因为这个东西如果不跑完，第二天业务部门可以放假回家了。后面是通过打造我们这套自动化运维平台，能够在不同的环境下面比较方便做我们的一些运维动作。理想是好的，但还是很遥远，想想就可以了。刚才提到的安全部有一个职责，就是检查你关键操作在不在现场。所以梦想还比较遥远，我的分享就到这里。