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

本文整理自 GOPS2017·上海站演讲《面向千万级互联网证券用户的事件运维之路》

作者简介

作者简介：袁友高，一名IT男，2013年加入了平安证券，参与和见证了生产事件组的组建和发展。

前言：

本文的主题是《面向千万级互联网证券用户的事件运维之路》。

一、背景介绍

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

1.1、互联网转型

我们首先看一下公司的历史，我们平安证券在91年的时候就开始开展我们的证券业务，随着2013年、2014年政策的开放，再加上行情利好，业务强势转型。再结合平安集团金融综合优势我们成立了海量获客计划。

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

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

1.2、暴增下的影响

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

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

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

1.3、事件处理组成立

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

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

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

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

1.4、事件处理流程

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

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

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

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

二、上报通道

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

2.1、原有上报渠道