如果你的公司还没有走向平台化，当初依然能够是很大的飞跃。您依然能够通过解决公司的变更治理流程来放慢软件交付。在本章中，咱们将钻研咱们在公司外部所学的变更管理模式。咱们将向您展现什么是无效的，什么是有效的，以及如何利用 DevOps 准则将变更治理转化为无效的、使能的流程。
在过来的十年里，咱们曾经看到 DevOps 的实际颠覆了软件公布团队的工作形式。以下是最显著的变动。
“问题自身并不会扭转，因为扭转始终在产生；问题是在变动来长期无奈应答。”Kent Beck《解析极限编程：拥抱变动》
即便咱们看到交付团队胜利地转变了他们的思维和实际，但要在一个大型组织中扭转积重难返的构造和流程依然要艰难得多。变更治理就是最难扭转的过程之一。
转向一种新的做事形式须要领导反对、组织纪律和跨组织各层的大量单干和合作。然而，在大多数大型组织中倒退起来的大型遗留环境并不容易被拆分和从新设计。它们通常由许多不同的团队保护，每个团队都领有技术堆栈的一部分。了解工作的团队通常不足批准本人所提变更的权限；相同，变更批准常常被调配给脱离实际工作、理解不够深切的委员会。
所有这些层面的存在是因为大型遗留环境是组织的次要业务所在。因而，任何变动都会让人感觉有危险，而且有大量的流程和官僚作风，让人感觉是在爱护企业的平安。
可怜的是，所有这些过程都妨碍了组织的倒退。他们根本无法疾速公布软件——无论是面向内部客户还是外部客户——以满足业务需要。同时，那些使他们的变更治理更无效的竞争对手可能疾速而重复地公布，使他们排在后面。
DevOps 演进和变更治理有效性
咱们想看看变更治理的有效性是否与 DevOps 的倒退相干。为了掂量改革治理的有效性，咱们从以下三个维度察看：
施行成功率。咱们察看了变更失败率和部署频率。现实状况下，企业应该可能更频繁地进行改革，从失败中迅速复原，并从中吸取教训。
效率程度。咱们想晓得扭转的效率有多高治理过程基于以下内容：
•不到两周的强制期待期
•更改只需一次批准
•更改被正确实现，不须要撤销
•由具备适当技能的人批准，从而做出正确评估
•记录更改所需的工夫很少
绩效情绪。作为对每个受访者所在组织的主观评估的代理，咱们制订了该指标。咱们询问受访者他们公司的变更管理程序是否：
•升高危险
•缩小与服务事件相干的停机工夫
•提供对组织有用的信息
•确保与适当的利益相关者共享常识和信息
•放慢业务需要的变动速度
•依据评估的变更危险等级，提供适当级别的审查和批准
这三个维度——施行成功率，效率程度和绩效情绪——形成咱们的变更治理有效性的度量。
咱们发现随着组织倒退他们的 DevOps 实际，变更治理的有效性减少了。尽管差别不是很大，但在统计上的体现是显著的。
变更治理的办法
为了考察改革治理，咱们向受访者询问了他们在工作场合的一些不同做法。这些能够分为两个局部：变更审批流程和变更实现的自动化水平。可分为四种群体：
运维成熟。高水平的过程和自动化。
工程驱动。高度重视自动化。
以治理为核心。高度重视人工审批，而不器重自动化。
长期型。不器重过程和自动化。
是什么驱动着改革治理的有效性？
当从总体上看改革治理的有效性时，会发现工程驱动的公司具备最高程度的变更治理有效性，长期型公司因不足流程而成功率居于第二，剩下的两组重大依赖正统的认可，在有效性上得分不高。
咱们的数据揭示了一些对于影响变更治理的有效性和效率：
正统的批准会升高效率；
自动化使团队对变更治理充满信心；
授予权限会带来更高的效率。