译者：刘征
一旦你决定 SRE 值得在你的组织中推行并决心投资于它，确保你的投资取得成功至关重要。在系统中引入变革总是困难的，但要让这种变革持续下去则更难。以下是一些关于如何在你的组织中保持 SRE 运作的建议。
思考要大，行动要小
“如果你不能衡量它，你就不能管理它”这句话经常与 Edwards Deming 联系在一起。然而，完整的引用是“认为你不能衡量它就不能管理它，这是一个代价高昂的谬论。”SRE 的核心是一种以指标驱动的方法。然而，无论有多少 SLO 或 SLI，都无法帮助你理解你的 SRE 实践是否有效并与企业战略一致。你必须通过持续的实验和学习来发现这一点。
在前面的章节中，我们要求你“思考要大”，但在培养成功方面，你应该“行动要小”。任何形式的大规模变革都需要通过迭代和渐进的方式实现，SRE 也不例外。但有一个明显的警告——如果你的时间线太短，你将无法取得有意义的改变，所以要准备好找到平衡。
Google 内部使用目标和关键结果 (OKR) 来共享目标和对齐团队，即使在实现这些目标的方法不总是明确时。你的组织可能有自己的流程来实现这一点，但必须扩展到包括明确的迭代和定期审查 SRE 团队的各项指标（如琐事、警报、软件工程影响、容量计划等）。由于采用的非线性特性，你的进展总会有挫折，因此这也应该视为过程中的正常部分。
文化比战略更重要
Google 的一个假设，即 SRE 故事中的一个关键未书写部分，是内在的创新性 Google 文化。Google 还分享了我们进行的研究来描述这些属性。事实证明，团队成员是谁远不如团队成员如何互动、安排工作和看待他们的贡献重要。
我们了解到，有五个关键动态使成功团队在 Google 中与其他团队区分开来：
- 心理安全 : 我们是否能够在团队中冒险而不感到不安全或尴尬？
- 可靠性 : 我们是否可以指望彼此按时完成高质量的工作？
- 结构和清晰度 : 我们团队的目标、角色和执行计划是否清晰？
- 工作的意义 : 我们是否在做对每个人来说都非常重要的事情？
- 工作的影响 : 我们是否从根本上相信我们正在做的工作很重要？
我们看到的许多关于 SRE 采用的典型问题，如成本影响、特定行业关注、技术债务等。然而，这一发现的最好之处在于，像所有好的事物一样，这五个动态基本上是免费的！无论你的行业或情况如何，都可以优先考虑这些因素。Google 的高绩效团队依赖这些文化规范使 SRE 成功，使 SRE 成为这种文化基础上的自然行为。
忽视文化不会有帮助；等待也无济于事
听我们谈论文化对成功采用 SRE 至关重要，通常令人沮丧，这暗示你应该等到文化达到一定程度后才能采用 SRE。套用一句流行的谚语，最好的改变文化的时间可能是 20 年前，但第二好的时间是现在。除了可靠性问题，不让你的文化对可靠性反馈做出响应还有其他重大后果。
培养 SRE 的含义是什么？
要培养和发展 SRE，需要考虑一些关键活动。
- 次线性扩展 : 我们之前提到过这一点，但需要澄清，这不是“用更少的资源做更多的事”，而是通过自动化和持续改进的文化来改变我们处理可靠性问题的方式。SRE 明确设计不是通过增加人数来扩展的，因此要抵制在现有软件流水线中增加更多人的诱惑，而是用 SRE 来自动化或省略这些步骤。
- 建立和保留可持续的、快乐的团队 : 尽管科技行业已经从项目导向转向产品导向，但仍然很常见的是将个体视为可以随意在不同活动之间调动的可替换资源。这直接冲突于我们的文化建议。不要指望这样做还能在 SRE 上取得成功。
- 承认 SRE 不是静态的——它本质上是一个动态角色，会随着时间成长 : 减少琐事和实施自动化的演变过程的一部分意味着 SRE 会在你的组织中发展。你仍然可以为此预算和计划，但目标是结果而不是具体任务和固定的团队规模。这一开始会感觉很奇怪，因为它与很多自上而下的计划活动相冲突。然而，当 SRE 动态地重新组建团队时，这通常是你正在取得成功的标志。
- 评估你在组织内的可靠性思维水平和目标 : 达到高水平的 SRE 采用需要比预期更长的时间。在 Google 内部，我们认为达到产品战略级别的可靠性可能需要 3 到 5 年的时间。鉴于保持这一水平需要持续努力，恢复旧习惯也很常见。因此，花时间和精力不断评估和调整这种新的思维方式。
SRE 的关怀与培育
一旦启动 SRE，你需要照顾并培育你新生的组织。随着 SRE 实践的发展，你需要考虑以下几点。
将一个立足点团队发展成更大的组织
不要从你最大的难题或每个人都不敢碰触的核心巨型单体应用开始。你需要在一个支持性的环境中通过一些快速的成功来起步，建立你的团队、原则和实践。相反，也不要从一个玩具服务开始。SRE 只有在有重要可靠性需求的地方才有价值。一旦你有了立足点，你需要不断学习，安全地扩展。处理大量不太重要的服务可能看起来很有吸引力，但要抵制这种诱惑。SRE 的价值在于高可靠性服务。其他服务应该遵循“你构建它，你运行它”的模型。
SRE 组织结构：独立的 SRE 组织与嵌入式团队
自成立以来，Google 一直有一个专门的 SRE 组织，我们认为这样做有很多好处，例如可靠性文化、发布优先级、招聘等等。我们经常被要求将其与 DevOps 的“打破孤岛”方法进行比较。理解独立的 SRE 管理链不应该成为孤岛是至关重要的。SRE 有多种与开发团队合作的方式，从嵌入个体到轻度咨询。尽管如此，没有专门的组织结构也可能成功地部署 SRE，但需要广泛的高级领导支持。
晋升、培训和补偿
SRE 是开发人员，应该期望获得至少与组织中其他开发人员相等的补偿和激励。晋升率也是衡量是否与其他团队平等的一个重要指标。你应该定期比较薪酬和晋升率，以消除任何差距。防止任何认为这种薪酬水平允许你虐待 SRE 的假设（例如，长时间工作）。注意，SRE 对进行有意义和有影响力的工作的期望会更高。
值班是一项令人恐惧和疲惫的活动，需要仔细的准备和培训。还必须以有意义的方式补偿值班团队。如果你对直接补偿有限制，那么可以通过采用创意的方式（例如调休）来实现。
沟通和社区建设
SRE 使能涵盖了各种活动，例如正式培训课程、技术讲座、读书小组等。大部分工作是间接完成的，通过提供时间和资源进行实验（例如 20% 工作时间）。自主权和授权是建设社区的关键，这需要通过积极的领导方式来实现。这意味着设定明确的领导愿景或北极星，并在组织内显著地树立授权的榜样。在任何形式的变革中，沟通的量很容易被低估，而 SRE 也特别擅长检测不真实的信息。
评估你的 SRE 采用是否有效
在采用 SRE 的过程中，获得大量的 SRE 工件是很常见的，例如 SLO、SLI、错误预算、仪表板等。这些都是组织的代理指标，但它们不会总是给你一个全面的可靠性变化的图景。为此，你可能需要考虑一些更非常规的视角。如果事情确实进展顺利，良性循环会随着时间的推移显得更加平静。与其仅仅在事故与事故之间救火，不如有一种主动预防火灾的感觉。这可能会让人不安，特别是如果你的组织习惯于通过忙碌来展示其价值。在这一点上，抵制进行战术优化以重新获得忙碌感觉的诱惑。你的 SRE 会在经历失败并提升能力时自然地改进 SLO 和错误预算。
航向
采用更主动的方法可以让你有更多时间专注于战略愿景。你会开始更清楚地了解组织中不同服务实际需要的可靠性水平。利用这些数据并设定新的预期结果来决定优化的重点。也许你的一些内部系统被标记为业务关键，但你的 SRE 们现在知道它们只需要 99.9% 的服务水平目标（SLO）。其他系统可能现在需要更高的可靠性水平，而判断你是否成功的一个可靠方法是当你开始看到其他团队对获得 SRE 好处的兴趣。
Feature picture ❤️ Anete Lusina: https://www.pexels.com/photo/miniature-toy-car-on-top-of-monopoly-board-game-4792380/