在第一本SRE手册的介绍中，Ben Treynor Sloss将SRE团队描述为“以快速创新和大量接受变革为特征”，并将组织变革管理作为SRE团队的核心职责。本章探讨理论如何在实践中应用于SRE团队。在回顾了一些关键的变革管理理论之后，我们探索了两个案例研究，它们展示了在Google中不同的变更管理风格是如何以具体的方式表现出来的。
请注意，变更管理一词有两种解释：组织变更管理和变更控制。本章将变更管理作为所有方法的集合术语，用于准备和支持个人，团队和业务单位进行组织变革。我们不会在项目管理环境中讨论这个术语，它可以用来指代变更控制流程，例如变更审核或版本控制。
SRE拥抱变化
2000多年前，希腊哲学家Heraclitus宣称变化是唯一不变的。这个公理今天仍然适用——特别是在技术方面，尤其是在快速发展的互联网和云计算领域。
产品团队的存在是为了构建产品、发布功能和满足客户需求。在Google，大多数变化是快节奏的，遵循“启动和迭代”的方法。执行此类更改通常需要跨系统、产品和全球分布的团队进行协调。网站可靠性工程师经常处于这个复杂且快速变化的环境中，负责平衡变更中固有的风险与产品可靠性和可用性。错误预算（参见第2章）是实现这种平衡的主要机制。
变更管理简介
自上世纪40年代Kurt Lewin在该领域的基础性工作以来，变更管理作为一个研究和实践领域不断发展。理论主要侧重于开发管理组织变革的框架。对特定理论的深入分析超出了本书的范围，但是为了在SRE领域内对它们进行语境化，我们简要介绍了一些常见理论以及每种理论如何适用于SRE类型的组织。虽然这些理论框架中隐含的正式流程尚未被SRE应用于Google，但通过这些框架的镜头考虑SRE活动有助于我们改进管理变革的方法。在讨论之后，我们将介绍一些案例研究，展示其中一些理论的元素如何适用于Google SRE领导的变更管理活动。
Lewin的三阶段模型
Kurt Lewin用于管理变革的“不冻结—改变—冻结”模型是该领域中最古老的相关理论。这个简单的三阶段模型是一个管理过程审查的工具，以及由此产生的群体动态变化。阶段1需要说服一个需要改变的团体。一旦他们接受了改变的想法，第2阶段就会执行这一改变。最后，当变化大致完成时，第3阶段将新的行为和思想模式制度化。该模型的核心原则将该群体作为主要的动态工具，认为当群体计划、执行和完成任何变革期时，应将个人和群体互动作为一个系统来进行检验。因此，Lewin的工作对于在宏观层面规划组织变革最有用。
McKinsey的7-S模型
McKinsey的七个S代表结构、战略、系统、技能、风格、员工和共同价值观。 与Lewin的工作类似，该框架也是计划组织变革的工具集。 虽然Lewin的框架是通用的，但7-S的明确目标是提高组织效率。 两种理论的应用始于对当前目的和过程的分析。 但是，7-S还明确涵盖了业务要素（结构、战略、系统）和人员管理要素（共享价值观、技能、风格、员工）。 对于考虑从传统系统管理重点转向更全面的网络可靠性工程方法的团队，此模型可能非常有用。
Kotter领导变革的八步流程
《时代》杂志将John P. Kotter于1996年出版的《引领变革》（Leading Change, Harvard Business School Press）一书评为有史以来最具影响力的25大商业管理书籍之一。 图21-1描述了Kotter变更管理流程中的八个步骤。
Kotter的流程尤其与SRE团队和组织相关，只有一个小例外：在许多情况下（例如，即将推出的Waze案例研究），没有必要产生紧迫感。支持快速增长的产品和系统的SRE团队经常面临紧急的扩展、可靠性和运维挑战。组件系统通常由多个开发团队拥有，可能跨越多个组织单元; 扩展问题可能还需要与从物理基础架构到产品管理的团队进行协调。 由于SRE通常在出现问题时处于第一线，因此他们具有独特的动机来领导所需的更改，以确保产品24/7/365全天候可用。大部分SRE工作（隐含地）都采用了Kotter的流程来确保支持产品的持续可用性。
Prosci ADKAR模型
Prosci ADKAR模型侧重于平衡变更管理的业务和人员两个方面。 ADKAR是个人为成功组织变革必须达到的目标的首字母缩写：意识、愿望、知识、能力和强化。
原则上，ADKAR提供了一个有用的，深思熟虑的，以人为中心的框架。但是，它对SRE的适用性是有限的，因为业务责任通常会带来相当大的时间限制。通过ADKAR的阶段反复进行并提供必要的培训或指导需要在通信方面进行调整和投资，这在全球分布的，以业务为重点的团队的背景下难以实施。也就是说，Google已成功使用ADKAR风格的流程来引入和构建对高级别更改的支持——例如，将全局组织变更引入SRE管理团队，同时保留本地实现细节的自主权。
基于情感的模型
桥梁过渡模型描述了人们对变化的情感反应。虽然它是人员管理者的有用管理工具，但它不是变更管理的框架或流程。同样，Kübler-Ross变化曲线描述了人们在面对变化时可能会感受到的情感范围。根据Elisabeth Kübler-Ross关于死亡和垂死的研究，它已被用于理解和预测员工对组织变革的反应。这两种模型都可以在变更期间保持高员工生产率，因为不快乐的人很少有生产力。
戴明循环
也称为Plan-Do-Check-Act（或PDCA）循环，统计学家Edward W. Deming的这一过程通常用于DevOps环境中以改进流程——例如，采用持续集成/持续交付技术。它不适合组织变革管理，因为它不包括变革的人性方面，包括动机和领导风格。戴明的重点是采用现有流程（机械的，自动化的或工作流的）并循环应用持续改进。我们在本章中提到的案例研究涉及更大的组织变革，其中迭代会适得其反：频繁、痛苦的组织结构变化会削弱员工的信心并对公司文化产生负面影响。
这些理论如何应用于SRE
没有一种变更管理模式适用于所有情况，因此Google SRE并未专门针对一种模式进行标准化也就不足为奇了。也就是说，这就是我们如何考虑将这些模型应用于SRE中的常见变更管理方案：
- Kotter的八步流程是SRE团队的变革管理模式，他们必须将变革视为核心责任
- Prosci ADKAR模型是SRE管理层可能需要考虑的框架，用于协调全球分布式团队的变更。
- 所有单独的SRE经理都将受益于熟悉Bridges Transition Model和 Kübler-Ross Change Curve，它们提供了在组织变革时为员工提供支持的工具。
既然我们已经介绍了这些理论，让我们看看两个案例研究，它们展示了变革管理在Google上的表现。
案例研究1：从临时变更到计划变更的缓和规模
背景
Waze是Google于2013年收购的基于社区的导航应用程序。收购完成后，Waze进入了活跃用户、工程人员和计算基础架构的显著增长期，但在Google内部继续相对独立的运行。这种增长带来了许多技术和组织方面的挑战。
Waze的自主权和创新精神使他们通过小组工程师的基层技术响应来应对这些挑战，而不是前一节讨论的正式模型所暗示的管理性，结构化的组织变革。然而，他们在整个组织和基础设施中传播变更的方法与Kotter的变更管理模型非常相似。本案例研究探讨了Kotter的流程（我们追溯应用）如何恰当地描述了Waze在收购后增长所面临的一系列技术和组织挑战。
消息队列：在保持可靠性的同时更换系统
Kotter的模型以一种紧迫感开始了变革的周期。Waze的SRE团队需要在Waze的消息队列系统的可靠性严重退化，导致日益频繁和严重的停机时迅速而果断地采取行动。如图21-2所示，消息队列系统对于操作至关重要，因为Waze的每个组件（实时、地理编码、路由等）都使用它来与内部的其他组件进行通信。
随着消息队列上的吞吐量显着增长，系统根本无法应对不断增长的需求。SRE需要手动干预以在越来越短的时间间隔内保持系统稳定性。在最糟糕的情况下，整个Waze SRE团队每周7天，每天24小时大部分时间在进行排障，最终每小时重新启动消息队列的一些组件，以保持消息流动，数千万用户满意。
由于SRE还负责构建和发布所有Waze软件，因此这种操作负载对特性速度有明显影响——当SRE花费所有时间处理故障时，他们几乎没有时间支持新功能推出。通过强调情况的严重性，工程师说服Waze领导重新评估优先级并将一些工程师的时间用于可靠性工作。两个SRE和一名高级工程师的指导联盟聚集在一起形成了一个未来的战略愿景，SRE辛劳不再是保持信息流动所必需的。这个小团队评估了现成的消息队列产品，但很快就决定他们只能通过定制解决方案满足Waze的扩展和可靠性要求。
如果没有某种方法在此期间维持操作，在内部开发此消息队列是不可能的。联盟从使用当前消息传递队列的团队中招募了一批志愿者开发人员，从而消除了这一障碍。每个团队都检查了他们的服务代码库，以确定减少他们发布的消息数量的方法。删除不必要的消息，并在旧队列的顶部扩展压缩层，可以减少系统上的一些负载。该团队还通过为一个特定组件构建专用消息队列来获得更多的操作空间，该组件负责超过30％的系统流量。这些措施产生了足够的临时操作缓冲，允许在两个月内组装和测试新消息传递系统的原型。
即使没有迫在眉睫的服务崩溃的压力，迁移每秒处理数万条消息的消息队列系统也是一项艰巨的任务。但逐渐减少旧系统的负载可以减轻一些压力，为团队提供更长的时间窗口来完成迁移。为此，Waze SRE重建了消息队列的客户端库，以便他们可以使用其中一个或两个系统发布和接收消息，使用集中控制界面来切换流量。
一旦新系统被证明有效，SRE就开始了迁移的第一阶段：他们发现了一些低流量，高重要性的消息流，消息传递中断对这些消息流来说是灾难性的。对于这些流，向两个消息传递系统写入将提供一个备份路径。有几次差点失败，当旧系统摇摇欲坠时，备用路径保持核心Waze服务的运行，提供了短期的胜利，证明了最初的投资是合理的。
大规模迁移到新系统需要SRE与使用它的团队密切合作。该团队需要弄清楚如何最好地支持他们的用例以及如何协调流量切换。由于SRE团队自动化了迁移流量的过程，并且新系统默认支持更多用例，因此迁移率显著加快。
Kotter的变革管理流程以实施变革而告终。最终，在采用新系统背后有足够的动力，SRE团队可以声明旧系统已弃用且不再受支持。几个季度后他们迁移了最后的一批消息队列。如今，新系统处理的负载超过前一个系统的1000倍，并且几乎不需要SRE的人工干预即可持续提供支持和维护。
下一个变更周期：改进部署过程
作为一个周期的变化过程是Kotter的关键见解之一。当涉及到SRE面临的技术变化类型时，有意义变化的周期性特征尤其明显。消除系统中的一个瓶颈常常会突出显示另一个瓶颈。随着每个变更周期的完成，由此产生的改进、标准化和自动化可以节省工程时间。工程团队现在有空间更仔细地检查他们的系统并识别更多的痛点，从而触发下一个变化周期。
当Waze SRE最终能够从与消息传递系统相关的问题中退出时，一个新的瓶颈出现了，随之而来的是一种新的紧迫感：SRE对发行版本的唯一所有权明显地、严重地阻碍了开发速度。发布的手动性质需要大量的SRE投入时间。为了加剧已经不理想的情况，系统组件很大，而且由于发布成本很高，它们的频率相对较低。因此，每个版本都代表一个大的增量，这大大增加了一个重大缺陷需要回滚的可能性。
由于Waze SRE没有一个方案的总体规划，因此逐步改进为更好的发布流程。为了精简系统组件，以便团队能够更快地迭代每个组件，Waze的一位高级开发人员创建了一个构建微服务的框架。这提供了一个标准的“电池包含”平台，使得工程组织可以很容易地将其组件分开。SRE与该开发人员一起工作，以包含一些重点关注可靠性的特性——例如，一个通用的控制界面和一组易于自动化的行为。因此，SRE可以开发一套工具来管理发布过程中以前昂贵的部分。其中一种工具通过将创建一个新的微服务所需的所有步骤与框架捆绑在一起来鼓励采用。
这些工具一开始很简单，最初的原型是由一个SRE在几天内完成的。随着团队从它们的父组件中分离出更多的微服务，SRE开发的工具的价值在更广泛的组织中很快变得明显起来。SRE将精简后的组件投入生产的时间减少了，而单独发布新的微服务的成本要低得多。
虽然发布过程已经有了很大的改进，但新微服务的激增意味着SRE的总体负担仍然令人担忧。工程领导不愿意承担发布过程的责任，直到发布不再那么繁重。
作为回应，一个由SREs和开发人员组成的小联盟勾勒出了一个战略愿景，使用Spinnaker(一个开源、多云、持续交付平台，用于构建和执行部署工作流)转向持续部署策略。通过引导工具节省的时间，团队现在能够设计这个新系统，以支持一键构建和部署成百上千的微服务。新系统在各个方面都优于以前的系统，但是SRE仍然无法说服开发团队进行转换。这种不情愿是由两个因素驱动的：必须将自己的发行版推向生产的明显的抑制因素，加上对发布过程的可见性不强所导致的变更厌恶。
Waze SRE通过展示新流程如何增加价值来消除这些采用障碍。该团队构建了一个集中式仪表盘，显示二进制文件的发布状态以及微服务框架导出的一些标准指标。开发团队可以很轻松地将他们的发布与这些指标中的变化联系起来，这使他们相信部署是成功的。SRE与一些面向系统的志愿者开发团队密切合作，将服务转移到Spinnaker。
这些胜利证明了新的系统不仅能够满足它的需求，而且能够在原有的发布过程之外增加价值。此时，工程领导为所有团队设定了一个目标，即使用新的Spinnaker部署管道来执行发布。为了促进迁移，Waze SRE为具有复杂需求的团队提供了组织范围内的Spinnaker培训和咨询会议。当早期采用者熟悉新系统后，他们的积极经历引发了加速采用的连锁反应。他们发现，与等待SRE推送他们的版本相比，这个新的流程更快，痛苦也更少。现在，工程师开始对没有移动的依赖项施加压力，因为他们是加快开发速度的障碍——而不是SRE团队!
如今，超过95%的Waze的服务使用Spinnaker进行持续部署，并且可以在极少人工参与的情况下将更改推到生产环境中。虽然Spinnaker并不是一种万能的解决方案，但是如果使用微服务框架构建了一个新的服务，那么配置一个发布管道是很简单的，因此新的服务有强烈的动机对这个解决方案进行标准化。
经验总结
Waze在消除技术变更瓶颈方面的经验，对于其他尝试工程主导技术或组织变更的团队来说，包含了许多有用的经验。首先，改变管理理论不是浪费时间！通过Kotter过程的镜头来观察这个开发和迁移过程可以证明模型的适用性。当时，Kotter模型更正式的应用可能有助于简化和指导变更的过程。
从基层发起的变更需要SRE和研发团队之间的密切合作，以及行政领导的支持。创建一个小的、集中的团队，成员来自组织的各个部分——sre、开发人员和管理人员——是团队成功的关键。类似的合作对实现这一变更至关重要。随着时间的推移，这些特设小组能够而且应该发展成更正式和更结构化的合作，在这种合作中，SREs自动参与设计讨论，并能够就在整个产品生命周期中在生产环境中构建和部署健壮的应用程序的最佳实践提供建议。
增量更改更容易管理。直接跳到“完美”的解决方案是一个非常大的步骤，不能一下子全部执行（如果你的系统即将崩溃，更不用说可能是不可行的），而且“完美”的概念可能会随着更改过程中新信息的出现而演进。迭代方法可以演示早期的胜利，帮助组织接受变更的远景 并证明进一步的投资是合理的。另一方面，如果早期的迭代没有显示出价值，那么当你不可避免地放弃变更时，你将浪费更少的时间和资源。因为增量式的改变不是一下子就能发生的，所以有一个总体计划是非常宝贵的。用宽泛的术语描述目标，要灵活，并确保每次迭代都朝着目标前进。
最后，有时你当前的解决方案不能支持你的战略远景的需求。构建新事物需要大量的工程成本，但如果项目将你推离了局部的最大值，并且能够实现长期的增长，那么这是值得的。作为一个思想实验，随着业务和组织在未来几年的增长，找出系统和工具中可能出现的瓶颈。如果你怀疑任何元素没有横向扩展，或者对于核心业务度量（如每日活跃用户）具有超线性（或者更糟，是指数增长），那么你可能需要考虑重新设计或替换它们。
Waze开发的一种新的内部消息队列系统表明，一小群有决心的工程师有可能进行变革，从而提高服务可靠性。将Kotter的模型映射到变更上表明，对变更管理策略的一些考虑可以帮助提供成功的公式，即使是在小型的、工程主导的组织中。而且，正如下一个案例研究也表明的那样，当变革促进标准化技术和过程时，整个组织可以获得相当大的效率收益。
案例研究2：SRE中的通用工具采用
背景
SREs对于他们可以用来管理生产的软件持有不同的看法。多年的经验，观察什么做得好，什么做得不好，以及通过事后分析的视角来审视过去，让SREs有了深刻的背景和强烈的直觉。在SRE中，指定、构建和试实施软件以自动化今年的工作是核心价值。特别是，Google SRE最近将我们的工作重点放在了横向软件上。大量用户和开发人员采用了相同的解决方案，这就形成了一个良性循环，减少了重新开发。否则可能不进行交互的团队将共享使用相同软件自动化的实践和策略。
这个案例研究基于组织的发展，而不是对系统扩展或可靠性问题的响应（如Waze案例研究中所讨论的）。因此，Prosci ADKAR模型（如图21-3所示）比Kotter的模型更适合，因为它识别了在变更期间显式的组织/人员管理特征和技术考虑。
问题陈述
几年前，Google SRE发现自己使用了多个独立的软件解决方案，可以在多个问题空间中解决大致相同的问题：监控、发布和部署、事件响应、容量管理等等。
这种最终状态出现的部分原因是为SRE构建工具的人员与他们的用户及其需求是分离的。工具开发人员并不总是对问题陈述或整个生产环境有一个当前的视图——生产环境以新的方式以非常快的速度变化，因为新的软件、硬件和用例几乎每天都被引入到生活中。此外，工具的使用者是多种多样的，有时还存在正交需求（“这种推出必须是快速的；近似是正确的，相对而言，这个展示必须是100%正确的；可以慢慢进行”）。
因此，这些长期项目都没有完全满足任何人的需求，每个项目的特点都是不同级别的开发工作、功能完整性和持续的支持。那些等待大用例的人——一个非特定的、全能的未来解决方案——等了很长时间，感到沮丧，并使用他们自己的软件工程技术来创建他们自己的利基解决方案。那些有更小、更具体需求的人不愿意采用一种更广泛的、不适合他们的解决方案。更通用的解决方案的长期、技术和组织效益是显而易见的，但是客户、服务和团队并没有因为等待而得到人员配备或奖励。为了是这种情况更加复杂，大客户团队和小客户团队的需求会随着时间而改变。
我们决定做什么
为了将此场景扩展为一个具体的问题空间，我们问自己：如果所有Google SREs都可以使用一个通用的监控引擎和一组仪表盘，这些仪表盘易于使用，并且支持各种各样的用例，而不需要自定义，那会怎么样?
同样，我们可以将这种思维模型扩展到发布和推广、事件响应、容量管理等等。如果一个产品的初始配置捕获了大量的方法来满足我们的大部分功能需求，那么随着时间的推移，我们一般的和高深的解决方案将变得不可避免。在某种程度上，与生产交互的工程师的临界数量将超过他们使用的任何解决方案，并自行选择迁移到一组通用的、受良好支持的工具和自动化中，放弃他们定制的工具和相关的维护成本。
Google的SRE很幸运，它的许多工程师都有软件工程背景和经验。他们是专家，对具体问题有自己的看法——从负载均衡到发布工具到事件管理和响应——以虚拟团队的形式工作，由共同的长期愿景自行选择。这些工程师将把他们的愿景转化为实际的软件，最终被所有的SRE和所有的Google所采用，作为生产的基本功能。
为了回到ADKAR的变更管理模型，到目前为止所讨论的步骤——识别问题和确认机会——是ADKAR启动意识步骤的典型例子。Google SRE领导团队同意需求（愿望），并有足够的知识和能力来快速设计解决方案。
设计
我们的首要任务是集中讨论一些我们认为是核心的主题，这将极大地受益于一致的愿景：交付适合大多数用例的解决方案和采用计划。从65个以上的项目列表开始，我们花了几个月的时间收集客户需求，验证路线图，进行市场分析，最终将我们的工作范围确定在少数经过审查的主题。
我们最初的设计围绕这些主题创建了一个虚拟的SRE专家团队。这个虚拟团队将为这些横向项目贡献很大比例的时间，大约80%。80%的时间和一个虚拟团队背后的想法是，确保我们在没有与生产持续接触的情况下，不设计或构建解决方案。然而，我们（也许可以预见）发现了这种方法的一些痛点:
- 协调一个虚拟团队是非常困难的，这个团队的重点是在多个时间区域内定期随叫随到。在运行一个服务和构建一个软件之间，有很多状态需要交换。
- 从收集共识到代码审查的所有内容都受到缺乏中心位置和公共时间的影响。
- 横向项目的人员最初必须来自现有的团队，他们现在处理自己项目的工程资源更少了。即使在Google，委派员工来支持系统与委派员工来构建面向未来的基础设施之间也存在矛盾。
有了足够的数据，我们意识到我们需要重新设计我们的方法，并选择更熟悉的集中式模型。最重要的是，我们取消了团队成员在项目工作和值班职责之间分配80/20时间的要求。大多数SRE软件开发现在都是由拥有大量on-call经验的高级工程师组成的小组来完成的，但他们都是专注于基于这些经验构建软件的。我们也通过招募或调动工程师来集中这些团队。小组（6-10人）的开发在一个房间内更有效率（然而，这个论点并不适用于所有的小组——例如，远程SRE团队）。我们仍然可以通过视频会议、电子邮件和传统的出差来达到收集整个Google工程组织的需求和观点的目标。
所以我们的设计演变实际上出现在一个熟悉的地方——小型、灵活、大多是本地、快速发展的团队——但更加强调选择和构建自动化和工具，以供60%的Google工程师采用（我们确定这个数字是对“几乎每个人都在Google”的目标）。成功意味着Google大部分人都在使用SRE为管理其生产环境而构建的工具。
ADKAR模型在以人为中心的知识和能力阶段之间映射了变更项目的实现阶段。这个案例研究证实了这种映射。我们有许多敬业、才华横溢、知识渊博的工程师，但我们通过关注客户需求，产品路线图和交付承诺，要求那些专注于SRE问题的人员像产品软件开发工程师一样行事。我们需要重新考虑这个更改的实现，以使工程师能够展示他们关于这些新属性的能力。
实现：监控
为了回到上一节中提到的监控空间，第一本SRE手册中的第31章描述了Viceroy-Google SRE如何创建一个适合所有人的监控仪表盘解决方案，解决了完全不同的定制解决方案的问题。几个SRE团队一起创建并运行最初的迭代，随着Viceroy成长为Google的实际监控和仪表盘解决方案，一个专门的集中式SRE开发团队承担了项目的所有权。
但是，即使Viceroy框架将SRE统一在一个共同的框架下，由于团队构建了特定于其服务的复杂自定义仪表盘，因此需要进行大量重复工作。虽然Viceroy提供了一种标准的托管方法来设计和构建数据的可视化显示，但仍然需要每个团队决定显示哪些数据以及如何组织这些数据。
现在集中化的软件开发团队开始了第二个并行工作，提供通用仪表板，在较低级别的“自定义”系统之上构建了一个固定的零配置系统。这个零配置系统提供了一套标准的综合监控显示，它基于一个给定的服务被组织为少数流行的样式之一的假设。随着时间的推移，大多数服务都迁移到使用这些标准仪表板，而不是投资于自定义布局。如果需要，非常大的、独特的或其他特殊的服务仍然可以在托管系统中部署自定义视图。
回到ADKAR模型，Google监控工具的整合始于基层工作，由此带来的运营效率提升提供了可量化的基础（意识和愿望），以启动更广泛的努力：SRE自筹资金的软件开发团队为所有Google构建生产管理工具。
经验总结
设计相互依赖的部件的迁移通常比空白页设计更复杂。但在现实生活中，最困难的工程工作最终是将许多小型/受限系统演变成更少、更通用的系统——而不会干扰许多客户所依赖的已经在运行的服务。与此同时，除了现有的系统之外，新的小型系统也在不断增加——其中一些系统最终发展成为大型系统而让我们感到惊讶。大型设计重新开始，只有支持真正必要的约束，才有吸引力，但系统和团队的迁移是迄今为止最困难的工作。
设计横向软件需要大量听取潜在最终用户的意见，在许多方面，构建和采用的任务看起来很像产品经理的角色。为了使这一努力取得成功，我们必须确保我们吸收并优先考虑优先事项。满足客户需求——SREs和其他生产用户的需求——也是成功的关键因素。必须承认，向通用工具的转移仍然是一项正在进行的工作。我们对构建共享技术的团队的结构和人员进行了迭代，以更好地满足客户需求，我们还增加了产品管理和用户体验人才(解决了缺失的知识)。
在过去的一两年里，我们在Google的许多团队中看到了这些SRE设计和构建的产品。我们已经了解到，要想取得成功，迁移（从旧的、碎片化的、专门的解决方案）的成本相对于新的通用解决方案的净收益而言较小。否则，迁移本身就会成为采用的障碍。我们继续与构建这些产品的单个团队合作，以加强团队交付的通用解决方案满足客户所需的行为。
我们在横向软件开发项目中发现的一个共同主题是，无论新软件和产品有多好，从已经在工作的东西迁移到新东西的迁移成本总是被认为非常高。尽管有更容易管理和不太具体的深入知识的诱惑，从熟悉的地方迁移（尽管有缺点和辛苦）的成本通常是一个障碍。此外，个别工程师也经常有类似的内部独白：“我没有改进或改变系统；我把一个工件换成另一个工件。ADKAR将这种阻力描述为“知识——能力差距”。在人性方面，为了认识和接受变革，人们需要时间、指导和新工具和技能方面的培训。在技术方面，实现变更需要理解采用成本，并包括将这些成本最小化的工作作为启动过程的一部分。
因此，对于团队、个人和公司来说，迁移成本必须接近于零（“只需重新编译，您就可以获得新的东西”），而好处也必须明确（“现在你可以免受$foo漏洞的伤害”）。
SRE通常用于以“尽力而为”的方式构建我们承诺的产品，这意味着我们给产品的时间量适合我们正在做的其他事情之间的裂缝（管理主要服务，容量规划，处理中断，等等）。因此，我们的执行不是很可靠；无法预测什么时候可以使用某个特性或服务。延伸开来，我们产品的消费者对最终结果的信任度就降低了，因为我们的产品总是会被推迟，并且有一个轮流的产品经理和个体工程师组成。当各个SREs或SRE团队为自己的使用构建工具时，重点是解决个别问题，以降低为支持的系统维护SLOs的成本。为了在Google中为大多数用例构建通用工具，我们需要将重点转移到衡量这项工作在产品采用方面的成功与否。
由于我们的组织文化和丰富的资源，我们以自下而上而不是自上而下的方式来处理这个项目。我们没有强制用户迁移到我们的新监控系统，而是通过证明我们的新产品比现有的解决方案更好来赢得用户。
随着时间的推移，我们了解到我们如何执行我们的开发过程将告知潜在的内部用户如何感知最终结果。只有当生产经验丰富的工程师100%致力于构建软件时，这些项目才能获得真正的吸引力，其计划和支持与Google的其他软件开发相同。透明地构建通用软件，像clockwork一样，具有良好的通信（“我们将在Y 日期之前完成X”），极大地提高了迁移到新系统的速度。人们已经信任这个新系统，因为他们可以观察到它是如何从早期发展起来的。从一开始，人们对香肠制作过程的理解就比我们预想的更加重要。我们最初的想法是“如果你创造出伟大的东西，人们会自然而然地涌向它”，但这并不是真的。相反，这些项目必须明确定义，事先做好宣传，针对大量的用户案例（首先针对最暴躁的采用者）进行评估，比现有的选择有更好的跳跃式发展，并且可以毫不费力地采用。
普通工具采用的消费者越多，除了编写代码之外，你实际花费的时间就越多。回想起来，这听起来可能很明显，但是清晰的最终目标、可信的日期、定期的更新以及与消费者的持续接触是至关重要的。通常持怀疑态度的消费者会问：“如果我当前的一次性shell脚本运行良好，我真的需要这个吗?”采用通用软件或流程类似于可靠性作为一项特性——你可以构建世界上最好的东西，但是如果人们不采用它（或者如果它不可靠就不能使用它），那么它对任何人都没有用处。当涉及到构建和采用通用工具和实践时，制定一个采用计划——从拥护者到beta测试人员，从执行发起人到专门的工程师，他们都明白最小化采用障碍的重要性——既是最终目标，也是起点。
这是因为采用会带来网络效应：随着普通软件工具的规模和范围的扩大，对这些工具的逐步改进对组织来说更有价值。随着工具价值的增加，致力于它们的开发工作也会增加。这些开发工作中的一部分自然用于进一步降低迁移成本，鼓励更多的采用。广泛采用鼓励以一致的、类似于产品的方式构建组织范围内的改进，并证明配备完整的团队以支持长期的工具是合理的。这些工具应该具有快速开发、特性稳定性、通用控制界面和可自动化api的特点。
在衡量此类工作的影响时，我们可以提出类似以下问题：
- 新产品开发人员能够以多快的速度构建和管理世界级服务？
- 通过常见的工具和实践启用，一个领域中的SRE可以多容易地转移到另一个领域?
- 使用相同的原语可以管理多少服务，如端到端用户体验与单独服务？
这些都是度量影响的可能且非常有价值的方法，但是我们的第一个度量必须是采用。
结论
正如Waze和横向软件案例研究所展示的那样，即使在一家公司内，SRE变更管理也可能需要处理各种问题空间和组织环境。因此，可能没有任何一种正式的变更管理模型可以巧妙地应用于任何给定组织可能处理的变更范围。然而，这些框架，特别是Kotter的八步过程和Prosci ADKAR模型，可以为即将发生的变化提供有用的见解。在像SRE这样动态的环境中，任何必要的更改都有一个共同点，那就是不断的重新评估和迭代。虽然许多变化可能以基层的方式有机地开始，但随着变化的成熟，大多数变化可以从结构化的协调和计划中获益。