从标准到落地：数据驱动的风险防范体系建设

简介

本次分享是由滴滴的SRE总监来炜分享，主要内容覆盖了滴滴内部的业务特点，以及相应的运维发布体系。我们知道，成立于2012年的滴滴最近几年也是发展很快，公司发展快就会导致一个问题就是业务迭代快，运维的难度就会很大，为了减少运维成本滴滴引入了数据量化的方法，同时以竞赛的方式加速内部各部门的成长。目前有如下一些竞赛：

太阳花：用户体验竞赛
星辰花：稳定性竞赛
蓝莲花：运营竞赛
风铃花：安全竞赛
别乱花：效率竞赛

以SRE最为关注的稳定性星辰花为例，该竞赛由滴滴效能平台部作为裁判，所有服务稳定性相关团队作为参赛方的方式进行，以下是滴滴的稳定性目标：

2016： 99.9% 不可用时长小于40min/月
2017： 99.95% 不可用时长小于21.9min/月
2018： 99.98% 不可用时长小于8.76min/月

值得一提的是，在滴滴内部不可用时长的计算方式并不是广义上大家所认为的服务的宕机时间，而是通过如下的方式计算得出的：

参赛业务线任一核心指标（呼叫量、应答量、支付量）下降超过10%的时间（T）
以此故障中的全平台不可用时长消耗 = T x 受影响业务上周的单量占比

可以看到这里引入的衡量标准是核心指标低于90%就开始算作故障，更加严苛也更加黑盒

然而人非圣贤孰能无过，一味地要求所有团队100%的服务可用性并不现实，因此年初会给每个团队分配一定的不可用时长，分配方式通过参照各个团队历史的表现情况、所负责服务稳定性的维护难度、变更量等因素协商分配。同时对各个团队的不可用时长的消耗以及剩余占比进行展示。

光有数据肯定是不够的，因此滴滴每个年度、季度都会根据历史数据从多个维度进行数据复盘来完善现有的体系规范。

奖惩

滴滴的故障等级氛围p1-p5 总共5个等级，最高的p1事故会对管理者收取罚金，同时还会办法团队金榴莲奖（该奖项是颁发给稳定性表现最差的团队），相应的表现优秀的团队可以获得基金奖励+荣誉勋章，并且会以大会的形式定期总结颁奖，程维也会亲自给表现好的团队颁奖。

滴滴SRE的主要工作

滴滴SRE主要关注以下三个指标：可用性、单均成本、体验，这些涵盖了平台研发、流程规范、监控预案等各方面的工作，在滴滴推动数据量化的过程中同时也遇到了一些问题，例如刚刚推出某项流程规范短期内对大家的意识能起到比较好的效果，但是随着时间的推移约束就会渐渐被弱化，在来炜的分享中他提到了两点关键原因：一个是容易被遗忘，同时新人不易理解和掌握。另一个是缺少达成程度的度量，不能随时了解风险的变化。第一点很好理解也比较好解决，经常提醒加新人培训能一定程度上解决，我觉得第二点才是问题的关键，首先一项制度规范制定出来之后对现有的业务以及场景会比较实用，但是随着时间推移越来越多问题出现那么当初的规范就会渐渐显得力不从心了。还是以稳定性为例，我们来看看滴滴是怎么做的。

首先滴滴参考了芝麻信用分，引入了风险量化参考信用分。例如，由于变更是导致稳定性问题的最大来源，2016-2017年有55%的故障都是和变更相关的，同时在滴滴，每周有超过2000次迭代变更。这个时候有一个统一的变更平台就位标准化的数据采集提供了良好的基础。

在变更风险防范中利用统一平台的约束以及支持结合风险量化不断完善。

我们来看一下滴滴的变更规范：

线上变更五条军规
1. 提前通报要记得
2. 变更步骤要完备
3. 分级发布要遵守
4. 高峰窗口要避免
5. 服务检查要执行
上线变更窗口约定

对于发布来说，分为两部分来看，一部分是可以技术支持的及必须要求的部分，这一块儿由变更平台提供支持，部分要求强制落地。另外一部分是可拿捏的和紧急情况下确实需要打破流程的部分，这一部分就需要引入风险量化来进行解决。

##变更信用分实现思路

每次操作经过五大维度进行评估后直接影响团队得分和全平台得分，五大维度分别包括：配置规范、审核规范、回滚规范、敞口规范、过程规范。

系统实现包括：操作单记录/模块信息->过滤清洗->规则引擎（支持配置规则）->操作信用分元数据->聚合计算（团队业务配置）->团队/全平台信用分->前端展示/邮件报告。

需要注意的是在前端显示页面展示了很详尽的信用分信息，包括个人、团队的分数的历史变换以及排名和各个维度的统计，同时会展示top10和tail10的排名进行激励和鞭策。

##落地执行的方式

在落地执行阶段部分业务高度认可并自发执行，通过邮件发送结果以及排名对比的方式进行反馈，并且有联合例会进行Review。

执行以来，等级良好的产品线从3个变成了8个（总共11个核心产品线）

同时对于系统和规则进行持续的迭代和修正，例如区分业务成熟度，将模块分位总共四个等级：

模块等级	对应服务类型	对应变更操作单信用分权重
一级	核心服务，非常重要	1.44
二级	重要服务，比较重要	1.2
三级	自运维服务，重要性不高	1
四级	离线服务、测试服务等	0

这里需要指出的是变更信用分只是对于引发异常风险大小的评估，并不是说信用分值高就不会有问题，它反应的是概率，而我们所追求的就是降低出问题的概率。

当信用分建立起来之后，到现在并没有完全结束，对于低分用户会进行相应的处理，例如需要leader审批他的上线，当分数过低时甚至需要进行考试系统的考核才能获取资质。

除此之外，滴滴内部还有预案健康分、监控成熟度、运维安全风险这几个量化体系。

通过提取来炜的分享，我也有如下几个感触，首先我们SRE应该是规范的制定者和完善者，并不是严格意义上的执行者如果我们过多的参与其中，公司这么多的业务线和流程会把我们的时间一代弄点耗尽，因此滴滴引入了量化的标准以此来规范和引导其他开发来遵守和自发执行，你分低就是做的不好就需要改正，ok你觉得我的量化有问题不完善，那我们就根据情况来修改规则。通过这种方式来让各个部门尽可能的把问题在内部进行消化和解决。

转载请注明来源链接 http://just4fun.im/2018/05/13/Qcon/ 尊重知识,谢谢:)