滴滴 来炜 - 《从标准到落地:数据驱动的风险防范体系建设》_部分3

运维工作中,通常会通过制定标准来预防风险、沉淀经验以及和周边团队形成共识。但常出现的情况是标准的影响会随着时间而减小,甚至被遗忘抛弃。一个较好的解决办法是将标准落地到各个平台,由平台来保证标准的执行。但这也有一些难以解决的问题: 标准有控制不了的部分:有一部分风险是标准无法控制的,比如一个业务线频繁的出现上线回滚,但标准并不能规定上线不能回滚或回滚的比例,这样的业务线我们如何驱动他们自省? 标准有弹性的部分:标准中通常也有一些需要人为拿捏的部分,比如变更在灰度阶段的暂停检查时长,通常是越长越安全,但平台通常只能约束到一个固定值。如何驱动大家做更充分的检查呢? 标准有被打破的特殊情况:比如标准规定禁止在业务高峰期变更,但由于紧急的问题修复或业务需要,又必须临时批准部分操作,这样的操作风险如何控制? 缺少风险的全局视图:通常SRE在push业务线做标准改进和控制的时候都只能针对一些局部进行推进,同时业务线的负责人也看不到全局的情况和风险的严重程度,因此推动较为困难,如何破解? 基于以上问题,滴滴建立了一套完善的风险量化体系,通过自动采集用户的平台操作数据、运维数据并自动计算量化出每个业务线的运维风险,落地到一个具体的分数,最终形成排名和竞赛机制,以达到促进标准长效执行的目的。本主题将重点介绍滴滴如何建设这套运维风险量化体系并成功运转长期有效降低业务运维风险的实践,同时还将分享建设和落地这套风险量化体系的实践心得。
展开查看详情

1.系统实现 规则配置 操作单记录/模块信息 过滤清洗 规则引擎 团队/业务配置 操作信用分元数据 聚合计算 周期:每周1次 呈现:web前端+邮件报告 团队/全平台信用分 前端展示 邮件报告

2.变更信用分评价体系产品

3.落地执行方式 部分业务⾼度认可自发执⾏ 排名对比 分析结果邮件发送 联合例会上Review

4.变更信用分执行:效果趋势向好,但需要长期观察 2017年7月发布线上变更五条军规,10月推出变更信用分平台 变更信用分值变化 变更导致的故障变化 • 等级良好产品线数量:3->8(11个核⼼产品线) 3->12 • 未遵守变更流程或流程执⾏不到位导致的故障数变化 (全部产品线40+) 超80分产品线数量 违反流程或流程执行不到位导致的异常case数 14 6 12 5 10 8 4 6 3 4 2 2 0 1 0 7月 8月 9月 10月 11月 12月 1月 2月 3月 4月 核心产品线 全部产品线 注:部分时间突降是处于假期封线期间 注:还需要更长时间的跟进和观察

5.关键问题:计分标准对真实风险反映的准确度 持续迭代修正 区分业务成熟度 区分模块等级

6.注意事项 变更信用分是对引发异常风险⼤小的评估,不能绝对说分 值⾼就不会出问题,它反映的是概率,我们追求的是降低 出问题的概率

7.下一步构想:以信用分为中心的变更风险防范 流程规范 考试系统 资格准⼊ 个⼈/团队长期不合格 细分到个⼈的信用分 变更信用分 线上操作 个⼈/团队短期不合格 提⾼变更的审核级别

8.风险量化体系 变更信用分 预案健康分 监控成熟度 运维安全风险

9.