译者：刘征
为完善本报告中的观点，我们与来自不同行业的三位 SRE 领导者进行了交谈，他们在过去几年中以各种形式采用了 SRE。每个人都有关于采用 SRE 的独特故事以及他们可能会做出不同选择的见解，此外还有关于在他们的行业或组织中使 SRE 工作的洞见。
医疗保健 // Joseph
Joseph Bironas 自从担任 Google SRE 领导者后，一直在多个医疗保健组织中领导 SRE 的采用。因此，他能够提供一个行业层面的观点，说明在这一领域实施 SRE 如何与其他技术和初创文化不同。由于其生命攸关的工作流程的性质，可靠性通常是首要考虑的问题。然而，医疗保健行业面临着组织模式、文化、预算和监管要求方面的特定挑战。
在与一家专注于利润空间极窄的医疗设备制造及 FDA 监管领域的公司合作后，Joseph 观察到，虽然可靠性被视为一种需求，但在该行业中 SRE 的成本效益却未被充分理解。因此，SRE 和基础设施团队可能会发现自己成为“全能工程”，被纳入 IT 成本中心，职责范围大幅增加。
你可能会问，将 SRE 团队归属在 IT 成本中心下有什么问题？当企业习惯于通过广泛的 IT 框架（如 ITIL）进行管理时，很难对 SRE 做出价值判断，而 SRE 只是 ITIL 的一部分——ITIL 还处理像硬件采购等 SRE 不涉及的事情。更重要的是，管理所有公司和生产 IT 的 CIO 并不是做出软件系统可靠性判断的最佳人选。相反，归属于专注于软件的领导者（例如工程高级副总裁（SVP）或 CTO）更为合理。
该领域的组织往往面临着希望采用 SRE 而尚未采用 DevOps 实践的陡峭曲线。例如，由于涉及法规和全组织合规控制的复杂性，他们每月只发布一次软件，并且几乎没有 CI/CD 自动化。许多医疗保健组织根本不愿快速部署：对于某些客户来说，快速部署意味着测试不足或安全性不足。
实施变革（如转向 SRE）的意愿在整个行业中差异很大，可能是由于领导优先事项和风格的不同。Joseph 描述了一个团队能够派遣设计师到现场收集需求，建立新工作流程，通过更好的产品革新护理的场景。在另一个场景中，一个不同的团队只被激励比现任者做得更好，这不需要同样的投资水平。在第三个场景中，一个团队被惯性困扰，在做出任何变革或投资之前等待自上而下的命令。根据 Joseph 的经验，更进步的领导往往对客户对可靠性的需求更敏感。
与初创文化相比，这些团队的一些变革非常缓慢。一个团队质疑他们是否能在 18 个月内完成“任何事情”（如采用 SRE）——对于初创企业来说，这段时间几乎是永恒的。在考虑这种节奏的组织中的重大变革时，你必须有模型来帮助理解计划的投资回报。了解 J 曲线（见屋顶射击与登月计划（roofshots versus moonshots））在这里很重要，以避免在低谷中放弃努力，错过真正的回报。Joseph 建议每季度与团队进行检查，以保持进展的稳定节奏。他建议在专注于 SLO 之前，从事件响应开始转向 SRE，并通过事件评审（例如，持续六个月）建立持续学习的循环。为了进行“真正的投资”而不是无声地失败，你可能需要寻求高管的赞助，实施顶层 OKR，或专注于使努力在你的组织中“真实”的任何事情。关键不仅是从这个循环中学习，还要将所学付诸实践。
另一个在医疗保健行业中常见的错误是忽视 SRE 的“软件方面”，当团队习惯于专注于传统运维工作时，认为“通过软件可以大幅减少 IT 支出”这种核心价值通常是领导者所陌生的概念，甚至可能被一些根深蒂固的系统管理员和操作人员故意抵制或破坏。忽视这一方面会使 SRE 显得非常无效。软件工程也很困难且昂贵。即使你购买了商业 SRE 相关工具（尽管有多年的大量贡献者，但这些工具仍不完美），你也无法逃避集成工作，这在很大程度上是一项软件工程工作。
为可靠性制定预算也可能是一个问题。Joseph 指出，“这个行业没有 [Google 在建立 SRE 时拥有的] 广告收入曲线。” 这影响了他们像 Google 那样专业化和投资的能力，导致他们更多地依赖商业解决方案。业务预算和规划通常仍然采用瀑布模式，这对 SRE 工作来说是一个挑战——探索、理解和设计新解决方案所需的时间不适合瀑布式工作方式。
从中得到的启示是，这些问题可以适用于所有行业。Joseph 分享了一个故事，说明即使是不完美的尝试也可以是一个有价值的起点。在他曾合作的一家公司中，领导层希望有一个极其简单的错误预算版本。他们没有选择适合其关键用户旅程 (CUJ) 的 SLO，而是为所有内容设定了一个单一的 SLO（99.95% 可用）。这个目标虽然简单易懂，但却削弱了整个工程团队对 SLO 概念的信心。状态和无状态应用程序、批处理和实时应用程序都采用相同的 SLO，这最终是无用的，并削弱了对该技术的信心。这也导致了毫无意义的错误预算，因此这些预算同样被削弱，任何试图使用这些错误预算的过程也被削弱。
零售业 // Kip 和 Randy
The Home Depot（THD）的 Commodore “Kip” Primous 和 Randall Lee 分享了这家大型零售商如何采用 SRE 的经验、成功之处以及面临的一些挑战。THD 是 Google Cloud Platform（GCP）的早期大型零售客户之一，在采用云服务的过程中，他们也遵循最近出版的 SRE 书中的原则采用了 SRE。六年后，他们当初期望构建的与现在存在的截然不同。
Kip 最初是“点商”业务部门的可靠性工程（RE）经理，负责 THD 电子商务网站“浏览堆栈”的工作。Randy 比 Kip 早加入 THD，他们分享了一个共同的 SRE 目标：通过更好的平台提高弹性。他们最初考虑建立自己的云和数据中心，但后来评估了各种云服务提供商，并最终选择了 GCP。在向云迁移的过程中，唯一成功的方法是同时改变他们的工作方式，采用类似 SRE 或“DevOps 2.0”的方法。
最初，THD 的目标是摆脱庞大的单体商业服务。Aurora 项目由副总裁资助并推动，目的是实现规模经济，减少运营团队的规模，将团队从数百名承包商转变为显著减少的全职员工。还有一个普遍的意图是提高可靠性，减少对组织内部其他可能不完全一致的团队的依赖。点商团队希望能够以“互联网速度”运作。
对齐非常重要。在迁移到云之前，每次部署都“像发射航天飞机：需要多年努力的协调”。团队觉得目前的 DevOps 模式在 THD/点商内部已经走到了尽头。通过引入 RE，团队能够在新平台和新的职责下采用新的工作模式，并有能力解决任何与可靠性相关的问题。他们雇佣了很多云原生工程师，并尽可能地实现自动化。他们能够突破限制现有 DevOps 团队的边界。
从 2015 年到 2017 年，SRE 团队能够快速独立地行动，因为他们在新的云基础设施上使用现代工具和硬件工作。然后在 2018 年，企业团队赶上了步伐——SRE 不再是唯一在 GCP 上工作的团队。令人欣慰的是，双方在企业团队更新传统模型时实现了融合——例如，承认在新的短暂虚拟机环境中不应再跟踪单个机器的补丁。通过一系列建设性的对话将团队聚集在一起，点商 RE 团队能够与新成立的集中企业团队合作，帮助建立更符合企业需求的流程和更好的安全准则。此外，他们能够将 GCP 平台的大部分管理工作（如计费、权限、配额等）从 RE 团队转移到企业团队。
在 THD 进行 SRE 之旅的过程中，Kip 和 Randy 观察到了一些模式和经验，这些经验和模式可能适用于其他行业。让其他团队采用 SRE 概念的过程花了几年时间，并且是循环进行的：推动合规自动化、成本改进、访问控制和网络安全的改进。每次互动都需要大量讨论和教育。在故障或停机很少的平静时期，紧迫感可能来自外部事件。Equifax 故障或 Akamai 或 Facebook 的 DNS 问题可能会引发新一轮的可靠性改进。
高管的支持对 SRE 在 THD 内部的成功采用至关重要。在点商团队通过使用 SRE 模型成功迁移到云后，SRE 角色在公司内变得与高绩效同义。许多其他团队希望复制这一模型，有些团队即使没有明确的 SLO 要求也被迫实施 SRE。然而，并不是所有团队都像点商团队那样幸运，可以从零开始并采用云原生。这导致一些团队难以认识到 RE 团队所带来的价值，有时会误解角色和责任的期望。当一个团队与组织中的“非官方” RE 互动时，这种模糊性可能会导致问题，因为这些 RE 可能无法在同一水平上工作或使用与原始团队相同的原则。例如，有些人“只是按按钮”，而没有真正的自动化琐事计划。这样的经历会让团队对未来与其他 RE 团队的合作失去兴趣。
Kip 还警告说，如果每隔几年没有新的 SRE 启发的努力，可靠性标准会退化。RE 团队打破了壁垒，但这些壁垒正在重新建立。团队认为，“可靠性不是我的问题，这是 RE 的问题！”这传递了错误的信号。Randy 补充说，一个运行良好的 RE 团队如果没有不断强化和教育 RE 的实践和原则，以及明确的角色和责任定义，就会倒退。
目前，THD 正在“加倍”投入 RE，但如果变革没有坚持 SRE 的原则，这实际上可能是一种反模式。SRE 不是解决所有问题的万能药，但当一个团队看到 SRE 的成功时，很难不想将 SRE 应用于各个方面。最近，Kip 被要求在分销中心和供应商支持的物理硬件上运行 RE，这并不适合 SRE。虽然总是有机会提高这些系统的可靠性，但在非云原生环境中应用许多 RE 实践更具挑战性。对于某些业务领域，可能更好的前进路径不是 SRE，而是价值流图（Value Stream Mapping）或精益（Lean）等实践。为了避免这些问题，更有意义的是将 SRE 作为“拉动”模型，而不是“推送”模型：不要强迫团队使用 SRE，而是将其作为一种服务提供，让团队自主选择。
Kip 和 Randy 的最大建议是专注于高管教育，并认识到拥护者的价值。如果没有自上而下的支持，很难为任何有意义的变革筹集资金。通过产品开发团队获得资金会导致这些团队“从不想支付这笔税”的现象。每当他们支付这笔税时，只希望 SRE 直接为他们的产品工作并朝着他们的产品目标努力。
在 THD，最初有一位高级领导倡导创建和发展点商 RE 团队以及其他领域的 RE 团队。THD 现在处于一个尴尬的境地，有许多 RE 团队在不同的项目上工作，应用 SRE 原则的能力各不相同。Randy 和 Kip 认为，拥有一个更高级的领导者可能会改善 THD 的状况。一个负责所有 RE 角色的可靠性副总裁（VP of Reliability）可以提供规模经济。没有中央 RE 组织，SRE 角色可能会演变成不同组织中的 SRE 完全做着不同的事情，并遵循不同的标准和原则。
结论
我们希望这份报告能够为企业如何采用 SRE 以及可能面临的挑战提供一些见解。我们认为，如果您清晰地定义 SRE 原则，将这些原则映射到具体的实践和能力，并优先培养团队内的成长，成功的机会会更高。我们还展示了一些团队在企业内部启动 SRE 实践的过程中所经历的例子，以及他们所面临和克服的具体挑战。
我们相信这份报告将有助于您采用 SRE，带来更可靠的技术体验。希望通过这种采用，运营团队可以变得更可持续，服务更具扩展性，开发速度得到提升。
“愿所有请求顺利，警报永不响起。”
关于作者
James Brookbank 是 Google 的一名云解决方案架构师。解决方案架构师通过解决复杂的技术问题并提供专业的架构指导，帮助 Google 的客户更轻松地使用云服务。在加入 Google 之前，James 曾在多家大型企业工作，专注于 IT 基础设施和金融服务。
Steve McGhee 是一位可靠性倡导者，帮助团队了解如何最佳地构建和运营世界级的可靠服务。在此之前，他在 Google 担任了超过 10 年的 SRE，学习如何在搜索、YouTube、Android 和云中扩展全球系统。他曾在加利福尼亚、日本和英国管理多个工程团队。Steve 还曾在一家加利福尼亚的企业工作，帮助他们向云迁移。
Feature picture ❤️ Anete Lusina: https://www.pexels.com/photo/miniature-toy-car-on-top-of-monopoly-board-game-4792380/