本文共 4363 字，大约阅读时间需要 14 分钟。
\\\看新闻很累？看技术新闻更累？试试，每天上下班路上听新闻，有趣还有料！
\
经济学有个概念称为“看不见的手”，即市场机制能够驱动市场内每个人自发向上从而使整体更有效率发展，但其中有个核心要求是充分竞争，如何让互联网企业内不同业务线的运维工作人员自发将风险控制到最低？滴滴用“看不见的手”提供了一个全新的解决思路。
\\4月20-24日，QCon全球软件开发大会将在北京国际会议中心举行。本次大会设置了《DevOps Top案例》专题来深入探讨新运维时代下研发、交付、运维模式等环节的创新方案，其中邀请了滴滴出行运维架构师华明前来分享。
\\我们借此机会采访了华明老师，他为我们讲解滴滴风险量化体系的相关实践细节，如果读者想了解更多滴滴如何克服运维工作中无法执行标准的困难，欢迎报名参加QCon北京站并与华明老师进一步交流。
\\华明，滴滴出行运维架构师，曾供职于百度运维部，七年百度SRE运维和架构经验，主要负责百度搜索广告和地图、糯米等服务的一线运维和运维体系建设。2016年底加入了滴滴运维部，担任滴滴运维架构师，主要负责滴滴服务稳定性建设和滴滴运维平台的研发工作。
\\我在百度和滴滴都是在运维部工作，主体工作也都是负责服务的稳定性建设、运维效率建设等等。主要的区别在于在百度时我的角色是技术负责人，并没有明确的团队管理职责，在滴滴我作为技术负责人的同时还有管理者的职责。
\\在百度通常可以看到一个团队有管理者加技术负责人这样的组合，大家都对团队和团队的目标负责，但工作职责的侧重会略有不同，技术负责人专注技术规划和实现，管理者侧重目标设定、人员管理、资源协调、对外沟通等，而在滴滴这两个角色通常是合二为一的，这两种方式各有优劣。
\\实际上滴滴有很多的运维人员都有过百度的工作经历，所以总体来讲两者的运维文化有很多相似之处。除了前面提到的管理者和技术负责人的角色区别外，在稳定性等重要工作的分工机制上也略有差别，例如在百度通常是运维部作为主体在推动服务的稳定性建设，这个做法是百度运维部长期历史积累形成的有效机制，让很多稳定性的平台、经验快速落地到各个业务线，适合百度业务线众多且发展阶段各异的特点。
\\滴滴运维部也是服务稳定性建设的总体负责部门，但前面还有一个有效的保障，即相关机制的制定、职责的分摊等是由全技术部门的“星辰花”稳定性委员会来推进，在执行过程中还有裁判（效能平台部门）来随时组织，这有效地保证了稳定性各方的有效参与和相关工作的快速推进。
\\滴滴的服务稳定性建设重要内容之一是运维平台的建设，稳定性建设包括的工作内容很多，比如流程规范建设、风险量化、标准化和自动化、架构高可用、容量管理、变更管理、服务监控、预案管理等等。几乎每项工作要得到有效的落地和长期的执行最好都是由平台来保证，监控、变更、容量管理、预案管理这些需要平台来支撑比较容易理解，也是滴滴运维的主要工作之一。
\\但我们将流程规范建设、风险量化等也和平台建设关联起来，比如我们发布了“服务变更五条军规”，其中包括灰度变更原则、double-check原则、高峰期不变更原则等等，这些原则最后都落地到变更平台来保证执行。
\\再比如风险量化，我们针对变更的风险建立了评估标准，并进行自动的计算量化，形成了变更信用分平台，可以有效的总结和量化各个团队的变更在稳定性上的风险。
\\滴滴的各项工作非常推崇数据量化的作用，任何工作最后都要落地到指标上，滴滴内部几项重要的工作会以竞赛的机制来推进，比如：
\\把目标、效果进行量化是这些竞赛机制能够发挥作用的基础。在这种机制下，无论工作的大小，我们都会首先考虑量化机制的建设。
\\在稳定性建设过程中，我们发现有很多工作一直以来还没有被说得太清楚，比如变更一直以来都是影响服务稳定性的重要因素，但变更应该做到什么程度才是安全的？很多人并不知道要做好哪些准备工作、过程中要遵守哪些流程。平时虽然有针对变更数据的一些分析，比如回滚率等，但都不系统不全面，也严重依赖人工的执行，这导致团队的管理者层面看不到自己团队变更风险的全貌和严重程度，执行者也通常没有意识到自己做的不够好。
\\另一方面，虽然我们发布了变更的流程规范，这些流程规范很多也都落地到了变更平台，但流程规范的执行仍然有很多需要人为拿捏的地方，比如灰度检查通常暂停的时间越长越有可能发现问题，但平台只能约束至少有暂停或暂停一个固定时间，更长的暂停时间则由执行者把握。
\\再比如流程规定高峰期不能上线，平台可以强制不在这个时间上线，但一定会有紧急的需求需要在高峰期操作，平台还必须放开这个口子，这类操作带来的风险也是确确实实存在的，它不应该被经常执行。
\\诸如这些问题我们希望通过结合标准制定一个量化机制，叫变更信用分机制，变更信用分标准规定，比如暂停时间越长分数越高，高峰期如有操作则需要扣分，同时不同优先级的模块采用不同的标准，最高优先级的模块有强制double-check的要求，需要两个人才能在平台完成上线，如果没有在平台执行这个要求也需要扣分。
\\我们对每周2000个左右的上线单做这些问题的系统分析，并按团队做汇总、量化和排名，让大家能从全局的角度看到问题的总体情况和各自的严重程度，并能够从上往下索引到各个团队具体的变更单、变更人和变更参数，甚至直到具体的变更模块配置界面，以此促进各个团队有针对性的发现变更风险并清晰的知道如何进行完善。
\\滴滴的数据量化文化催生了变更信用分机制，但这种机制的实施具有很大的普适性，其他公司如有需要，是完全可以复制并做一些适合自己业务特点的调整把它运行起来的。
\\量化首先要有一个标准，这之前我们发布了“线上变更五条军规”和“服务变更窗口规定”等等变更流程，这些流程和标准是经过评审得到各业务的共同认可的。风险量化的机制基于这些标准产生，我们把这些风险划分为几个大的维度，比如变更暂停、回滚、上线窗口等。
\\各个大的维度再细分到具体的维度，比如变更暂停维度，变更暂停10min该单子80分、暂停20min该单子90分，如相应的变更有预发环境100分，没有预发环境0分具体维度的分值聚合计算出大维度的分值，大维度的分值再聚合计算出一个团队总体的分值。
\\这些计算规则也要经过评审，当然评审只能使最后的数值更趋于合理更符合真实的风险情况，但这还是不够的，我们需要针对各团队计算出的分值结合实际情况进行一段时间的观察和Review，并对规则做出一些调整，这样逐步迭代一段时间后基本可以较准确的反映分险的情况。
\\而信用分机制更重要的价值不在于100%准确的反映风险，而是能够在大家认可的标准下，方便大家看到问题的严重程度和具体要改进的工作并进行完善。比如每周排行榜上会有各个团队的得分排名，每个团队可以点击进入查看各个维度的得分详情，这周的得分较差是因为一直就没有完善好上线的配置，还是这周的发布回滚过多，在系统里面可以一目了然的看清。
\\建设风险量化体系有技术难点和非技术难点，技术难点主要有两个。
\\一是底层的操作单要有详细的信息输出，才能支持对操作单做各种维度的分析，比如操作暂停时间计算、是否在高峰期中有过执行、是在哪个阶段执行的回滚，为此我们对部署系统进行了升级，支持这些信息的记录并离线分析。
\\二是我们希望对所有变更都做风险量化，除部署外还有数据配送、配置开关等，但各个系统的差异较大，很难达成统一的计算方式，为此我们首先在最重要的上线部署上试点，再考虑逐步适配各类变更，后续线上实现统一的变更中台后将进一步方便数据的采集。
\\非技术的难点是要让大家真的认可这些数据及它反映的问题，否则量化将没有价值。这方面有些团队会自发的高度重视并积极发现和改进，有些团队可能相对被动，我们从三个方面来提高大家的重视度：
\\建设风险量化体系并没有非常大的技术复杂度，关键在于底层数据的标准化和规范化，能够将各个数据映射到各个业务线和团队。
\\目前我们主要建设了变更的风险量化、预案的健康量化，现在正在建设监控的完善分机制，原理都一样：标准-》打分机制-》采集-》计算-》排名。只要涉及到稳定性风险的地方理论上都可以用这种量化的方式来推动完善，这也是我们继续努力的方向。
\\不同维度的运维数据与之相应的计算我们会从规范和标准出发并逐步迭代完善，针对特别的情况还会对业务线、模块设定不同的优先级，给予不同的评分权重，总体的原则是业务线越重要、模块越核心，要求也越高。
\\关于性能方面，目前我们的指标是每周输出一次，对性能和实时性的要求还不那么高。这些风险量化的数据从变更或预案执行的单子中来，本身是有滞后性的，但未来可以考虑做得更为实时。
\\如果实时性提高也有可能可以做更多的事情，比如一个构想是如果变更信用分低于某个阈值，则会控制该团队后续的变更在一定的频率内或提高该团队变更的审核要求，以降低变更的风险。
\\总体来说风险量化体系会逐步覆盖运维中各方面的风险，把风险的高低大小通过量化和排名的方式呈现出来以支持运维稳定性的决策。如前面提到进一步的可能也包括提高量化数据的实时性，把风险的控制做得更为实时。
\\关于在分值竞赛评定上，是否会面对“优化空间已经不大”的情况？在推进过程中很多团队会积极的根据量化情况来进行完善和改进，并严格遵守相应的标准和流程要求，这确实可以把信用分保持在很高的水平，把风险控制得很好，这种情况是我们乐于看见的，也希望长期得到保持，并有更多团队来效仿，大家一起降低运维稳定性的风险。
\\InfoQ：感谢华明老师接受我们的采访，期待华明老师在QCon分享的《从标准到落地：数据驱动的风险防范体系建设》，读者可关注了解更多DevOps Top案例。
转载地址：http://ctjtx.baihongyu.com/