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