万众期待的《加速度：2019 DevOps全球状态报告》上周刚刚发布。这个系列报告拥有极高的专业度和客观性，使用数据驱动的洞察方法，对来自全球不同类型企业的DevOps实践经验和需具备的能力进行提炼总结。作为追随其多年的DevOps实践者，我在2017、2018年曾经做过多次针对该报告内容的线上、线下解读和分享。
今年的报告依然非常有料，内容丰富饱满，并且有很多创新。今天我们就来分享最新报告中的一些精华内容。
你的研发效能在业界属于什么水平？
延续历年报告中一贯使用的研发效能度量指标和聚类分析法，可以把企业归类为低效能、中等效能、高效能和精英效能组织。具体的度量指标如下，你不妨与业界对标一下，看看达到了业界的什么水平？
四个关键研发效能度量指标
我们来仔细看一下上表中的内容：如果你的部署频率是按需（可以每天多次）、变更前置时间是小时级（从代码提交到上线）、故障恢复时间（MTTR）低于一个小时，变更失败率小于15%（变更失败即服务受损或中断，需要进行热修复、打补丁或者回滚），那么恭喜你，你属于精英效能组织，在2019年可以排到全球效能最高企业的前20%！
如何改进才能成为精英效能组织？
很多朋友也许在想，如何才能成为报告中的精英效能组织呢？有没有一个通用的DevOps实践全集？有没有跨行业、跨组织类型、跨企业规模的DevOps实践标准，照搬或者套用就能实现效能提升呢？
今年的报告非常明确地指出：DevOps转型和研发效能提升不存在“One Size Fits All”，即没有所谓的一招鲜吃遍天。
每个企业面临的实际情况不同，企业环境上下文不同，需要解决的痛点问题也不同，技术、文化、流程千差万别，不可能有统一的方案或者标准。另外，这个行业是快速动态发展的，今年精英效能组织的比例是去年的三倍，去年自我感觉良好的，一年时间就可能被很多同行所超越。
提升研发效能的必由之路：
1、找到当前最亟需解决的问题。比如最容易导致的Delay的阶段、最多发生问题的部分、最让你感到头疼的事情
2、以效能改进模型为指导，选取特定的实践，消除约束和瓶颈、找到协作点，避免不必要的工作
3、安排三五个专职的专家资源，在特定的时间范围内着手解决这些问题
4、始终聚焦在最大的问题上，不用担心还有其他问题
5、当每一个约束和瓶颈被解决，从第1步开始重复这个过程
正可谓“菩萨畏因，众生畏果”，想要提升软件研发效能，需要从其根因上入手。
那么重点来了，今年的报告提供了两种关键的效能改进模型：
1、软件研发与运维效能模型
2、工程生产力模型
上图中的软件研发与运维效能模型是从2014年以来一直延续并持续强化的，而工程生产力模型是今年报告中首次加入。两个模型所反映出的因果关系，共同指导并助力软件研发效能的提升。图中的所有的连线，其箭头方向，可以理解为驱动、影响、促进，比如技术实践的提升和变更管理流程的提升会促进软件研发和运维效能的提升。
软件研发与运维效能模型
数字化转型的一个关键目标就是要优化软件交付效能，通过技术的改进加强对用户和利益相关者的价值交付。根据报告中基于证据的诸多分析，我们聚焦到一系列能够加速转型的能力和实践，如下图所示：
往年的报告重点分析了自动化测试、自动化部署、监控、松耦合的架构、云的使用、持续集成、持续交付等内容，大家可以翻阅以前的报告。今年重点加入了变更管理流程、故障恢复测试、代码可维护性、心理安全的文化等多个实践要素。
值得注意的是，一些能力和实践可以在团队级别开展，而另外一些则需要在组织级进行，尤其是那些大型组织和有很多层级的组织。团队级实践和组织级实践可以并行推进，很多时候二者互为补充，如下图所示:
变更管理流程
受到篇幅限制，我们今天只探讨其中一个实践：变更管理流程。
很多朋友经常向我反馈，他们公司的软件变更管理流程非常复杂和官僚，开展DevOps阻力重重。其实有两个因素决定了这个流程的复杂性：
1、对于跨团队协作的需求
2、来自监管控制的要求，尤其是金融服务、健康、政府项目等。
在DevOps转型过程中，对于重型变更管理流程，我们要选择合适的方式进行处理。比如，我们经常碰到“职责分离”的要求，即变更必须由变更发起人之外的人或者组织进行批准，比如支付卡安全标准PCI-DSS中就存在类似的规范，通常这导致重型的变更管理流程，以及不同部门之间很厚的部门墙。
我们赞同某个开发者个人不能拥有对流程端到端的整体控制以控制风险，但是其实这里有更 轻量级、安全的方法可以达到这一目标，而不需大量协调工作和重量级方法。
我们建议的方式是：每一个变更，在代码提交到版本控制库之前或者合并到主干之前，需要由团队的另外一个人进行代码评审。这种方式还可以结合自动化的检查来约束变更，比如可以检查开发者提交的变更是否导致计算或存储资源成本阈值的超出。这种轻量级、直接的流程提供给实践者清晰的优化的空间。
可能有朋友指出：类似ITSM框架中等正式变更审批流程可以带来更多的稳定性，而且行业中几十年以来一直就是这样做的！轻量级变更流程靠谱么？为了解决这个疑虑，今年的调查报告专门做了一组实验：测试重量级变更管理流程对软件交付效能的影响。
报告的结论也许出乎你的意料：正式的变更管理流程（比如需要Change Advisory Borad，即CAB审批或者高级经理审批）对软件交付效能有负面影响！
调查指出，重量级变更管理流程的组织相比其他组织，有2.6倍可能性属于低效能组织。这个结论与2014年调查报告相吻合。在调查中，我们发现正式的变更管理流程与发布失败率的降低没有关联，甚至因加入了更多的审批过程而降低了发布效率，导致大批量和高风险，变更失败率反而增加。很多组织在发生错误后，第一反应是增加额外的流程和重量级的审批，分析得出这样的做法也许是错误的。
上图反映出基于统计数据，变更管理流程和同行评审与研发效能的对应关系，可见右侧使用同行评审形式的研发效能更高。
所以，我们建议组织将重量级的变更管理流程“左移”到开发过程中的同行评审，并且增加自动化的检测机制，在软件交付周期的早期预防和修复错误的变更。持续测试、持续集成、完善的监控和可观测性可以提供更早的检测、可视化和更快的反馈。使用这种方式，错误可以立即发现并解决而不是等到正式的审批流程。
那么问题来了，在DevOps中，变更控制委员会（CAB）的作用是什么呢？答案是CAB依然重要，随着组织越来越复杂、协作越来越多样化，CAB的职责是帮助团队改进工作流程并优化软件交付效能。CAB的工作还包括权衡和签署高阶业务决定和业务风险应对措施。是的，CAB的工作从细节的变更控制转向更为战略级的管理工作。
工程生产力模型
我们经常听人提起谷歌的工程效率部门叫做“Engineering Productivity”，即工程生产力。大家都认同生产力很重要，它可以让工程师工作更高效，给他们更多的时间用于对工作再投资，比如重构、精进技术、开发更多的功能、完善文档等。
但是，究竟什么是生产力，如何度量它呢？
生产力不是简单的度量指标，比如代码行、故事点数、缺陷关闭数，考核这样的片面指标不利于团队发展及达到业务目标。比如，团队可以拒绝给其他人帮助，因为这样会降低自身的研发速率，即使这样的帮助对整个组织是非常重要的。
生产力是一种能力，将复杂、消耗时间的任务，以最少干扰和打断的方式完成。这个定义也与Facebook研发效能的重要原则之一”不要阻塞开发人员”非常吻合。
我们看到很多公司在谈“人效”即人员效率，考核很多工程师的工作产出作为度量指标，其实更应该做的，就是想尽一切办法为工程师服务，最大限度的提升他们对工作顺畅度、减少工作打断。
模型中给出了提升生产力的实践，分别是：
1、可用、易用的工具
2、内部和外部搜索
3、减少技术债务，具体手段包括：提升代码可维护性、解耦的架构、监控
4、心理安全的文化
减少技术债务
在当今的复杂系统，技术债务存在于很多角落：应用代码、脚本、配置文件、基础设施等等，代码和系统的技术债一般包括：
1、已知的未修复缺陷
2、不充分的测试覆盖
3、低代码质量和不良设计导致的问题
4、不再使用的代码或制品没有清理
5、团队缺乏领域知识，无法高效调试和维护
6、未完成的迁移
7、废弃的技术
8、未完成或过期的文档或缺失注释
技术债会显著降低生产力，那么我们如何解决？Martin Fowler曾经说过：重构应该是日常工作的一部分。事实上，很多大型组织都在代码重构上进行投资，其中有些开发了对应的工具，比如Facebook的开源工具fastmod，以及谷歌的开源工具ClangMR，这些工具在Github上都能够找到详细信息。
最后，我们应该持续关注和监控代码的可维护性，如下图所示：
总结
今年的DevOps全球状态报告共有82页，以上是其中一部分精华速读。
每个时代都有自己的软件研发方法论。有些看起来不错，但是历史会证明其价值。多年的状态报告表明，DevOps的能力和实践可以帮助组织显著提升软件交付效能、提升工程生产力。DevOps不是一个趋势，而是事实上都应该采用的软件研发和交付方法，它能给每个人带来更高的产出，给企业带来更大的价值。
推荐你实践上文中给出的两个效能提升模型，持续发现和优化流程中的瓶颈，愿你早日成为精英效能组织！
