大多数声称采用了[SRE0]的公司实际上只是重新命名了运营团队。他们将“系统管理员”的头衔更改为“站点可靠性工程师”，保持流程不变，然后惊讶地发现事件以同样的速度继续发生，并且开发人员和运营人员之间的紧张关系没有缓解。 SRE 不是一个职位。这是一种思考责任、风险和速度的特定方式——如果不改变团队的实际运作方式，这个头衔就毫无价值。问题不在于意图，而在于假设术语的变化足以改变工程和运营之间的关系文化。
SRE 的真正含义是什么
站点可靠性工程诞生于 Google，其前提很简单：如果您希望软件能够大规模可靠地工作，就让软件工程师负责它。核心理念不是让人们“照顾服务器”，而是让工程师应用软件开发原理来解决运营问题。
这从根本上改变了函数的轮廓。 SRE 编写代码来自动执行重复的操作工作。 Google 的原书定义，SRE 最多 50% 的时间应该花在工程上——自动化、工具、基础设施改进。当这个百分比低于此值时，就表明该团队正在以新名称的传统运维团队的身份运营，而不是真正的 SRE。
SLO 和错误预算：可协商的可靠性
使 SRE 操作一致的机制是服务级别目标和错误预算的结合。 SLO 定义服务需要提供多少可靠性 - 例如，在 30 天的窗口内测量的可用性为 99.9%。错误预算是补充：剩余的 0.1% 代表团队在不违反与用户合同的情况下犯错误、部署、测试更改的空间。
这种机制将可靠性变成了可以协商的而不是绝对的。当错误预算已满时，团队可以更加积极地进行部署和实验。当耗尽时，释放速度会减慢，直到窗口恢复。这消除了风险决策的任意性：不是运营经理说“我们现在无法部署”——而是预算用数据说的。产品和工程之间的对话基于可衡量的东西，这完全改变了谈判动态。然而，定义不明确的 SLO 比不存在的 SLO 更糟糕：它们在衡量不反映真实用户体验的事物时产生了错误的控制感。
结构性问题：嵌入式 SRE 或平台团队
在采用 SRE 时，组织需要做出的最具体的决策之一是关于结构：SRE 是嵌入在产品团队中工作，还是组成一个集中的平台团队？没有通用的答案——并且要警惕任何在不询问组织规模、技术成熟度水平和相关服务概况的情况下提供答案的人。
每个模型都有真正的权衡。嵌入式 SRE 密切关注服务环境、了解产品决策并与团队开发人员建立信任。风险在于分散：SRE 最终为本地团队解决了紧急问题，并浪费了时间来构建共享基础设施。此外，很难保持不同团队之间实践的一致性。
该平台模型集中了专业知识，并允许您构建可扩展的工具。风险是相反的：远离服务的真实环境，倾向于提供不太适合日常使用的解决方案，以及“内部客户”动态有时会产生更多的官僚主义而不是敏捷性。成熟的 SRE 组织通常同时使用这两种模型：负责基础设施的平台团队和嵌入高风险产品团队的 SRE。
从内部看过渡是什么样的
对于来自运营方面的人员来说，采用 SRE 通常会感到不舒服。期望工作将从“解决事件”转向“通过代码和自动化防止事件再次发生”。这需要改变身份：因灭火能力而受到重视的专业人员现在负责降低火灾发生率。并不是每个人都想要或能够实现这种转变，假装这很简单会让人感到沮丧。
对于开发方来说，调整是不同的。产品团队需要接受这样一个事实：他们现在对所提供服务的可靠性负有共同责任。 SRE 引入了这样的理念：运营不是“另一个领域的问题”——它是工程工作的一部分。这与开发人员编写代码并“将其扔到墙上”以供操作来处理的文化相冲突。这里的文化变革与任何工具或流程一样重要。
采用率往往会下降的地方
最常见的 SRE 失败遵循可识别的模式。第一种是采用词汇而不采用实质内容：定义 SLO 但没有在错误预算耗尽时采取行动的机制的团队只是记录期望，而不是管理风险。第二个常见错误是将可靠性完全外包给 SRE 团队，从而免除产品团队的任何责任。这恰恰重建了 SRE 旨在消除的筒仓。
第三个失败点是低估了自动化投资。只有系统地减少操作性体力劳动，SRE 才能成为一种理念。如果没有专门的时间和资源，团队就会陷入劳累之中——重复性、被动性的工作不会产生累积的价值。诚实的 SRE 采用需要领导层积极保护团队的工程时间以满足短期运营需求。如果没有这种明确的承诺，SRE 就只是一次昂贵的品牌重塑。
另请阅读
- [站点可靠性工程指标：定义和监控 SLI、SLO 和 SLA1
- [现代事件响应：从侦查到无戏剧性的事后剖析2
- [测试覆盖率：完整指南3
- [自动化测试：架构和基础4
- [负载测试：它们是什么以及为什么您的系统应该在客户之前进行这些测试5
- [负载测试-小型团队的商业模式6