千万级用户运维事件管理之路

一、背景介绍

本文主要包含以下几块，首先看一下背景介绍。

1.1、互联网转型

传统的研发团队已经满足不了当时业务的发展，所以我们也紧急的建设了互联网的研发团队。从图上可以看到从91年到2014年底的时候我们的存量用户只有150多万，但是近几年来随着业务的发展，到2016年底我们的存量用户达到了1000万。

在用户量不断地增加，给我们整个研发团队带来了什么问题？我们发生了怎样的故事？

1.2、暴增下的影响

下面我们来看一下用户暴增下的影响？2014年业务量趋势增加，用户上报的事件数也开始慢慢的上升起来。所以各个业务部门的投诉也开始多了起来。

直到2015年4月份的时候就形成了运维背的黑锅，收到事件后不会做过多的分析，就会把事件转给我们的研发，研发也是在这种被强干扰的模式下完成其他需求的开发。他们这个时候就开始抱怨需求太多，没有时间查生产问题。所以我们的生产事件得不到很好的处理。

我们当时的局面很不理想，我们的用户体验也是急剧下降。我们遇到这种难堪的局面怎么解决呢？平安证券事件处理组同样也是在这种情况下成立的，我们在成立之前我们也调研过其他的公司，比如说携程和饿了么，以及平安集团的电话客服中心。

1.3、事件处理组成立

我们首先来看一下他们的工作模式，我们先看一下95511这一块，他们是以纯业务的思想去帮助用户解决问题，只需要查询一些简单的信息，主要的工作是收集问题和分发问题，大部分的问题是需要我们研发团队进行协助才能够完成的。

但是携程和饿了么这两家公司不太一样，是以技术为主，需要查询服务器日志，只有一小部分比较复杂的问题才会流转到研发团队。随着整个研发团队后续不断地扩大下对事件处理的影响，我们最后考虑以技术为主，业务为辅的思想成立事件处理组，我们的组成部分是以开发和测试，需要具备一定的技术要求。

我们首先处理的是平安证券的开户业务，随着我们对这个系统不断地进行总结和归纳，我们极少的问题会流转到我们的研发团队，这个时候其他的系统也同样遇到了比较难堪的局面，所以我们也陆续承接了其他的系统。

到目前为止生产事件处理小组总共8个人，分别在上海、深圳，我们现在处理了十大核心系统，包括平安证券的帐户系统，主要对事件的分析、跟踪以及提供解决方案。

1.4、事件处理流程

下面看一下事件处理组处理事件的流程。首先是接受事件，当我们的用户发生问题之后就会找相应渠道经理和财富经理，我们统称为客户经理，他们会进行简单的分析之后会把问题上报给事件处理组。我们收到后会做一系列的分析，查询ELK的日志系统，以及app埋点信息和数据库判断问题。

当我们发现兼容性的问题，或者根本查询不到用户日志，这个时候我们会转给测试人员重现生产问题。如果我们遇到一些解决不了的事情，我们也会转给研发团队让他们进行协助。如果发现历史数据的问题，我们会把脚本整理好给到运维同事审查和执行。

如果发现是一些产品配置的问题，会找产品经理和运营的同事，把相应的产品信息修改正确。最后我们处理完事件后就会形成一个知识库，主要包含的是问题发生的描述以及问题的解决步骤。我们的目的是当其他的同事如果遇到相同的问题，来查看知识库就可以很容易的把这个事件解决掉。

我们还会根据事件的数量和严重程度考虑是否需要加入到我们的监控平台去。下面分享的一些课题主要包含在我们处理事件的流程中遇到了什么困难，我们需要通过技术为主的方式来把这个问题解决掉。

二、上报通道

下面我们来看一下上报的通道。

2.1、原有上报渠道

这些客户经理遇到问题之后肯定也需要通过一个系统把事件报到事件处理组，平安的事件管理遵循的规范，有一套超过十年的ITSM，同样也对接了我们集团的OA系统。到目前为止已经承接了10多家专业子公司，任务通道达到800多个，年运营量超过几百万单。

但是有一个渠道打破了我们原有上报方式，我们上面说到了，在2016年底的时候我们的存量用户达到了1000万，开户日均200到20000，开户量剧增了100倍，交易量也是直线上升，事件数也是成倍增加。导致这些客户经理提交ITSM不是特别流畅，处理事件也不是特别的及时，投诉就开始多了起来。

我们平安是一家综合金融集团，它有保险、银行和证券的业务，2015年、2016年诸多的存量用户是保险业务员带来的业务开拓。当他们遇到问题之后也同样需要把问题提交到ITSM上面来，我们的保险业务员大部分的时间在客户的现场，不在办公区域，所以他们提交上来比较困难。

2.2、微信渠道

当然我们为了解决我们的渠道不太流畅的问题也紧急的建设了微信渠道。现在微信渠道总共有两个海量获客群，每个群里有500个客户经理。

2.3、微信群问题

首先让他们通过微信的方式把问题反馈给事件处理组。但是经过运行一段时间之后我们发现微信渠道有很大的问题，上报的成本比较低，质量比较差，往往是一句话，股票交易不了。这样一句话给事件处理组不太好处理，因为我们需要根据用户的信息查询用户的日志才能判断，所以来来回回沟通成本比较大。

第二块，由于微信群里的人数比较多，信息交叉比较错乱，滚动刷屏的概率比较大，所以我们的遗漏率也是比较高的。

第三块通过微信群跟踪处理问题比较麻烦，不太好维护，不太好统计数据分析。

并且我们没有人力一一回复这些微信群里的信息，所以我们的效率也是比较低下。

2.4、移动端的反馈系统MSS

与此同时我们深刻认识到这些保险业务员通过移动端反馈系统是他们的需要。很多保险的同事在我们客户的现场，不在办公区域。就为他们建设了移动端的反馈系统MSS，让他们通过系统自助的进行提交和反馈。

MSS并不是特别的复杂，只是提供了一套简单的H5的前后台。上报起来也是比较方便的，只需要输入用户的信息和用户发生问题的描述，以及用户发生问题的截图，就可以把问题上报到事件处理组。

我们收到问题之后也会通过MSS后台把这个问题进行处理掉，处理掉之后他们也可以根据前台查询自己提交问题处理的进度。当MSS系统运行一段时间之后我们也做了很多的问卷调查，有很多客户经理他们认为我们回答了一些问题还想对这个问题进行继续提问。

所以我们加入到第二张图就是交互式的聊天功能，他们如果对事件还有疑问可以发离线消息，我们会在MSS后台给他们一一进行答复，直到他们明白为止。

所以我们就这样解除掉了我们对微信的捆绑，不过这个过程也是比较痛苦的，因为我们需要反复的和这些客户经理进行宣导。我们为了解决事件及时率的问题，我们也引用到了微信企业号，上报人把这些问题上报出来之后让他们第一时间知道有新的事件上报过来，需要利马处理。

当我们通过MSS后台处理掉之后也会给我们的上报人推送一条消息，让他们知道我们处理的解决方案需要他们紧急帮用户把这个问题解决掉。通过移动端的反馈系统解决掉了消息比较杂乱、渠道不太流畅，以及处理效率比较低下的问题。

2.5、实施效果

下面看一下MSS推动的走势图。大部分是通过微信的渠道把这个问题上报给我们事件处理组。经过我们不断地对系统进行完善，不断的宣导，90%的问题是通过MSS这个系统把问题提交上来的。

三、数据构造

下面我们来看一下第三块，数据构造。

3.1、重现数据

我们发现一些兼容性的问题，或者根本查不到用户的日志，我们需要转给我们的测试同事重现我们的生产问题。可是我们往往发现我们的测试同事在我们的测试环境下面构造测试数据的时候是比较困难的，原本的方式是我们和测试人员总结了一些大量的 sql 脚本，需要什么帐号的时候对数据库进行一系列的操作就可以得到我们想要的帐号。

第一块准确性比较差的问题。因为我们有大量的sql脚本和大量的存储过程依赖的关系比较强，很容易出错。

第二块维护成本比较大，当开发修改了业务的场景，导致我们构造出来的测试数据的正确性不够，所以来来回回和他们的沟通成本比较大。

第三块数据源比较多。

第四块，如果对数据库来回切换操作，比较耗时，也是比较费力的过程。

3.2、功能特点

下面我们看一下我们需要一个什么样的平台？我们需要能够准确、快速的在测试环境下能把测试数据构造出来，需要构造常规的数据和复杂的数据来支持多场景、多业务，需要提供可视化的界面给我们，操作起来比较容易，并不是大量的sql脚本。

3.3、UTA数据构造平台

所以我们提出需要一个平台化的概念，这个时候就和测试人员共同建设了数据构造平台，他们提供业务逻辑，我们来实施代码工作。UAT数据构造平台功能并不是特别多，我们只需要常规数据、复杂数据和报表的功能。

下面是常规的数据构造，构造起来比较容易，只需要输入用户的姓名和身份证号码。输入完之后就可以把我们想要的帐号信息构造出来。大家看到界面比较简单，复杂的数据构造的界面没有贴出来，只是界面上的元素多了许多，比如是否需要加入可用、可取，是否需要设置我们的风险评测的等级。

下面我们来看一下具体的实施情况。我们原本是想通过代码来调用总结的脚本达到我们想要的帐号，可是为了避免我们的研发团队频繁的修改业务场景，我们维护代码工作量比较大。最后改用调他们的接口业务逻辑，构造常规的数据需要调用35个接口，可想而知数据构造的后台是多么的复杂。

3.4、数据构造体系

构造数据平台完成我们的三大体系：

第一个是帐户体系，设置用户资料的相关操作。

第二块是三方体系，需要绑定三方存管，多方存管。

第三块需要给我们的帐号加入一些协议来完成我们的交易体系。

3.5、数据构造平台使用情况

下面我们来看一下使用的情况。我们的数据构造平台是今年6月份开始建设起来的，建设起来之后首先给的是事件处理组的人员和测试人员进行试用。试用完之后需要反馈修改信息给我们，从而来完善我们的系统。到目前为止我们每天在这个平台上构造80—90条测试数据，不仅仅是为了测试生产事件，更多的数据是测试版本需要的测试帐号。

然后是结果的分布，分为成功和失败，以及正在处理中的数据。大家可以看到10%的失败率，是因为开发在部署版本的时候导致环境不可用带来了失败。

最后是个人使用的统计。这一块也统计过，通过传统手工的方式构造出一条测试数据，就算脚本极为丰富，对数据库的表结构足够熟悉的情况下，通过平台来构造出来的效率足足比手工的效率提高了8倍左右。

四、服务中心

4.1、数据分析

下面我们来看一下第四块，我们的服务中心。下面是数据分析，是数据化可视平台。我们需要分析各个系统的运行情况，如果让我们统计每周或者每月的数据走势对我们来说比较困难，我们就在想能不能把每天处理的事件沉淀下来，定期进行分析。

所以我们把一些离散的数据汇聚起来，让整体的数据有一定的逻辑。所以把上面ITSM以及MSS数据收集起来，放到数据仓库里边去，通过数据化可视平台展示出来。今天主要看一下周报，遇到了什么困难。

4.2、事件分析

上面就是事件处理组的周报，这块只是去掉了事件解决率和及时解决率的走势线。我们需要把各个小类的问题综合成几大类：数据类、程序类、咨询类。咨询类的走势就代表着产品的交互问题，或者新的业务规则，或者我们业务规则发生改变之后带来的这些咨询。

可以从上面这个图表看到近两个月的数据走势，平均咨询类的走势占比每期总量的80%以上。所以这么庞大的数据对于我们事件处理组来说是比较头痛的一个问题，因为这些咨询类的问题比较多，对我们的工作量产生比较大的影响。

这个时候就和运营的同事商讨，如何把咨询类的占比降下去。首先产品的交互需要设计的更加人性化一点，其次把我们总结出来的知识库形成文档发给客户经理，让他们知道一些简单的解决方案，让他们知道怎么处理它，但是效果并不是特别好。

这个时候有个大胆的想法，我们能不能把这些同事和客户经理汇聚在一起，我们通过互动交流进行知识的分享。

4.3、直播平台

最后我们选择了平安集团的知鸟直播平台进行知识的分享。我们作为主讲嘉宾把一些疑难杂症的问题通过主动的方式传递给他们，让他们知道这些常见咨询问题的处理方法。做法也比较简单，到目前为止每个星期二的晚上八点钟做知识的直播，每一期是一个小时，30分钟的主讲和10分钟的做题，15分钟互动交流环节。

我们的直播主要分为四期，第一期是事件流程分享，告诉他们如何正确的把事件上报到我们的事件处理组，事件处理组处理事件的优先级别是什么，都需要告诉他们。其余的几期是把我们上报问题比较多的问题拿出来一一讲解，让他们知道怎么去帮助用户解决。

4.4、直播数据

下面看一下直播这一块的数据，主要分为总观众人数和总浏览人数，总观众人数是直播同时在线的人数，总浏览人数需要加上回看的数据。因为我们帮他们进行直播分享之后，这个时候我们也会同样给他们发送一些消息，让没有来看的一些同事来回看我们的视频。

同样也会定期的分析，不管是周报还是月报，如果发现他们有问题我们也会进行知识的直播。其实做法相对比较容易，成本也不是特别大，但是效果还不错，只是说敢不敢于去尝试的问题。

4.5、QA服务中心

通过每周总结热点问题形成知识库，给到这些客户经理进行培训，进行知识的分享。

在我们直播的互动交流环节中，我们有很多客户经理他们提到，他们想通过一个系统来查询我们的解决方案，并不是我们提供给他们的文档。

其实我们每个系统都有他们自己的帮助中心，但是对于这些客户经理而言查询起来比较困难，我们就为他们建设QA的服务中心，专门针对于客户经理的帮助中心。

通过帮助中心达到服务台的自助服务，主要是业务的流程和已知问题，和各个系统的热点问题都会放进来。

4.6、AQ服务中心展示

下面我们来看一下QA服务中心，主要包含的是首页、列表页以及内容展示页。我们先看一下首页，包含的是各个系统的模块可以根据关键来查询我们问题的解决方案。

下面是我们的热点问题，我们需要把最近经常处理的问题总结出来，放到我们的QA服务中心里面去。

下面是我们的内容展示页，有很多流程图是事件处理组提供的，但是我们提供之前也给到产品经理确认，每周如果没有特殊的情况下我们会进行维护一次，会在我们的事件处理组的周会上面把热点问题讨论出来。

五、监控

下面我们看一下我们的第五块监控。

5.1、被动转主动

其实往往大批量的用户发生之后我们都需要通过用户上报之后我们才知道什么地方出了问题，我们需要解决它。没有达到提前告警的功能，或者说当用户想把这个问题提交上来的时候我们已经知道，或者我们已经在解决中，或者已经解决掉了。所以我们深刻认识到问题的所在。

所以需要把被动的方式转化成一个主动的过程，我们需要提醒告警，处理大批量的问题，来提高我们用户的体验。

其实在平安证券大大小小的监控比较多，CPU、流量，空间，重大的监控比较多，这些对事件处理组而言并不是那么重要，因为我们需要根据我们的规则做我们自己的监控。

下面是我们在处理开户业务的时候总结的一些规则，我们主要对每日申请的开户量和开户的详情以及开户渠道的分布做的一系列监控。

5.2、监控实施

上面我们说到了在我们处理事件的过程中我们通过事件的数量和处理事件的严重级别来考虑是否需要加入到监控的需求里面去。定期的观察事件的走势，然后来做一系列监控。

上面这一块举了一个具体的例子，我们的帐户系统和交易系统状态不太一致的情况做了监控，这个项目上线的时间并不是特别长。主要的原因是用户投诉起来，处理非常麻烦。

我们首先说一下项目的背景，每天交易系统和帐户系统会拿到清算文件做一些清算，修改数据库的股东卡的状态信息。但是往往我们发现有些用户的状态不太一致，所以我们做了监控。

5.3、监控成效

下面看一下我们监控的成效，主要是正常数据和异常数据的分布图，其次是异常数据的个数，可以点击列表详细页看到具体用户数据。

第三块是我们告警的方式，到目前为止我们现在主要是以邮件的方式告警，我们收到邮件之后就会把这些问题解决掉。最后我们看一下指标的参数，通过监控之后，近期没有收到用户的投诉，不过根本问题的原因还需要研发检查自己的代码，把根本的问题解决掉。

所以我们通过把被动转化成主动的过程，处理批量用户的问题来提升用户的体验。

六、总结

下面看一下总结，总结主要分为以下三块。

第一，需要关注处理事件的每个环节，如果发生问题需要通过技术为主的方式处理掉。

第二，尽量通过 工具 平台化提升效率。

第三，需要在方法方式上进行不断地创新，给予一线同事最好的支持。