Google SRE 如何定义他们的 OKR

SRE（Site Reliability Engineering，站点可靠性工程）这一理念最早由 Google 于 2003 年提出，并在 2016 年通过《Site Reliability Engineering》一书在全球范围内广泛传播。

SRE 概念大约在 2017 年前后开始进入中国大陆的技术社区和互联网企业视野。

随着国内云计算、微服务和大规模分布式系统的发展，越来越多的中国互联网公司（如 阿里巴巴、腾讯、字节跳动 等）开始关注并引入 SRE 实践。

2018 年以后，SRE 相关的书籍、社区、技术大会和岗位招聘在中国大陆逐渐增多，SRE 已成为国内大型互联网公司提升系统可靠性和自动化运维能力的重要方法论之一。

那么，Google 为什么会提出 SRE？Google 运维工程师如何转型成 SRE？ Google SRE 工程师的 OKR 是什么样的呢？

2 什么是 SRE？

SRE（Site Reliability Engineering，站点可靠性工程）是 Google 于 2003 年首次提出的一种工程实践和文化理念，旨在通过软件工程的方法来管理和运维大规模系统。SRE 团队的核心目标是提升服务的可靠性、可用性和可扩展性，同时保持开发创新的速度。

SRE 的核心思想是将传统的运维工作自动化、工程化，把『运维』变成『软件问题』，用代码和自动化工具解决系统的可用性、容量、变更管理等挑战。SRE 通常与 DevOps 理念相辅相成，但更强调工程化和量化目标（如 SLI、SLO、SLA）。

3 SRE 的发展简史

—— 2003 年

Google 首次组建 SRE 团队，由 Ben Treynor Sloss 领导，目标是用软件工程师的方法来管理生产系统。

—— 2016 年

Google 出版了《SRE：Google 运维解密》一书，系统总结了 SRE 的理念、方法和最佳实践，推动了 SRE 在全球范围的普及。

—— 2017 年

进入中国大陆的技术社区和互联网企业视野。

—— 2018 年

随着云计算和微服务架构的兴起，SRE 的理念被越来越多的互联网公司和大型企业采纳，成为现代 IT 运维和服务管理的重要方法论。

—— 现在

SRE 已经成为全球范围内提升系统可靠性和运维效率的主流工程实践。

许多公司都设有专门的 SRE 团队，负责服务的可用性、自动化运维、容量规划、故障响应等工作。

4 SRE 的核心理念

SRE 不仅仅是一套技术方法，它更是一种文化变革，强调 工程师对服务可靠性的共同责任，以及 通过数据驱动和自动化持续改进系统。

5 谷歌如何定义事件（Incident）

事件（Incident） 是生产环境的一类故障。并不等同于生产事故。

一个事故可能是一个事件，但一个事件并不一定是一个事故。

事件的创建

基于 Google 强大的监控体系，『大多数事件是被自动发现和创建出来的』。会通过电子表格记录所有事件及其缓解时间。

在创建事件的同时，还会『自动分析并记录一些事件的相关信息』，以备后续作为定位分析的输入。

事件的附着点是产品（Product）

在 Google SRE 的实践中，事件（Incident） 是以 Google 产品（Product） 为单位来记录的，而不是其内部的某个服务组件。

例如，如果 App Engine 发生故障，会为 App Engine 这个产品声明一个 事件(Incident)，而不是为其内部的某个服务或团队单独声明该事件。

一个事件的多产品附着

一个事件是根据其影响，可能会被记录到多个 产品（Product） 上，但最终会有一个 "父" 事件。

例如，某个基础设施服务（如 认证服务）宕机，因其所有受影响的产品都会声明各自的这次事件，但这些事件会有一个『父』事件（即 认证服务 的产品事件）。

6 事件影响分级

Google SRE 对事件的影响有明确的分级标准：

• Negligible（可忽略），对用户无可见影响
• Minor（轻微）
• Medium（中等）
• Major（严重）
• Huge（极严重），涉及多服务、多区域的故障

影响分级的变量 包括：

• 故障持续时间
• 受影响用户数量
• 受影响事件的百分比
• 受影响功能的重要性等

每个事件都需要声明自己在其附着点的影响级别，可以不同。

例如，认证服务 可能声明为『极严重』事件，但如果对用户的影响较小的话，Google App Engine 可能只声明为『轻微』。

7 目标设定与标准化

Google 建议各团队根据自身及客户当前面临的问题设定目标，而不是设定全局统一目标。

但是拥有标准化的影响定义、缓解时间等指标非常有用。

Google 的事件管理工具会自动捕获所有这些元数据，并在报告中提供，便于数据分析和目标追踪。对于所有影响为 Medium 及以上的事件，都会进行事后复盘（Postmortem），并检查所有元数据的准确性。

8 事件元数据采集

• 部分元数据自动采集（如事件创建时间、缓解时间、解决时间）
• 部分元数据需人工补充（如影响级别等）
• 自动生成的数据如果有误，也可以手动覆盖（例如，用户影响实际早于事件创建时间）

9 举例说明（TTM vs TTR）

我们以缓解时间（TTM，Time to Mitigation）和 恢复时间（TTR，Time To Recovery）为例。

关于 MTTR 等概念，请参考文章：度量：MTTR，MTBF，MTTF，你分得清楚么？ 在 SRE 团队内部，其在 2022 年前后，关注的并不是传统的恢复时间（Time To Recovery），而是『缓解时间（Time to Mitigation）』。

TTM 是指：用户不再感知到问题的时间点，而不是事件完全『解决』且不再需要 SRE 介入的时间（后者有时会更长）。

笔者认为，软件工程师 SDE 可能就会关注 TTR。

不同级别的 SRE，其 OKR 的关注点可能也不同。

例如，一个 Principle SRE 可能更关注那些影响为 Medium 及以上的事件。

由于事件的 TTR 时间分布不是正态分布，所以，并不使用 MTTR（平均值），而是采用 75 分位数（P75）作为衡量标准。

例如，某个 Principle SRE 的半年 OKR 目标是：

『对于 Medium 及以上事件，2022 H2 的 TTR(P75) 值要比 H1 降低 50%』

10 小结

以上内容涵盖了 Google SRE 在事件管理、影响分级、MTTR 计算、目标设定和元数据采集等方面的实际做法和经验。

作者注：由于信息获取并非 Google 官方发布的内容，而是通过非官方渠道了解，可能会有偏差，仅供参考。

11 概念复习

SRE（Site Reliability Engineering，站点可靠性工程）是由谷歌提出的一套将软件工程方法应用于基础设施和服务可靠性管理的体系。

其核心理念围绕“用工程思维解决可靠性问题”，打破传统运维与开发的边界，以数据和量化指标为驱动，平衡业务快速迭代与系统稳定性。以下是 SRE 的核心思想提炼：

一、可靠性与工程思维的融合

• 告别“人肉运维”传统运维依赖人工经验和应急响应，而 SRE 强调用软件工程方法（如自动化、模块化、代码化）管理基础设施，将可靠性需求转化为可实现的技术方案（如用代码定义监控、部署流程）。
• 将可靠性视为“可迭代的产品”：像开发软件一样设计可靠性架构，通过持续优化（如混沌工程、故障演练）提升系统韧性，而非仅靠事后救火。

二、数据驱动的量化管理：SLO 与错误预算

• SLO（服务水平目标）为核心用具体指标（如请求成功率 ≥99.9%、响应时间 ≤500ms）定义“什么是可靠”，而非模糊的“系统不能挂”。例如，设定 API 接口的 SLO 为“月可用性 99.9%”，对应每月允许的不可用时间约 43 分钟。
• 错误预算（Error Budget）机制：将 SLO 的“缺口”转化为“可接受的错误额度”。例如，99.9%的 SLO 对应 0.1%的错误预算（即每月可“浪费”43 分钟故障时间）。开发团队可在预算内快速迭代（如发布新功能），一旦预算耗尽，则优先修复问题而非上线新功能，实现“可靠性与迭代速度的平衡”。

三、自动化优先：减少人为干预

• 自动化是 SRE 的“基础设施”：通过工具（如配置管理、CI/CD 流水线、自动扩缩容）替代手动操作，降低人为失误概率（如误删文件、配置错误），同时提升效率（如分钟级部署、自动故障恢复）。
• “不可自动化的流程不是好流程”：例如，将日常运维任务（如日志分析、资源监控）封装为自动化脚本，让团队聚焦于优化架构而非重复劳动。

四、从“被动响应”到“主动预防”

• 监控与预测先行：通过全链路监控（如 Prometheus、Grafana）实时追踪系统状态，结合机器学习预测潜在风险（如资源瓶颈、流量突增），在故障发生前介入。
• 混沌工程（Chaos Engineering）：主动注入故障（如模拟服务器宕机、网络延迟），验证系统韧性，提前发现隐藏的单点故障，而非等到真实故障时措手不及。

五、跨团队协作与文化转型

• 打破“开发 vs 运维”的壁垒：SRE 团队通常由开发、运维、测试等角色组成，强调“共同对服务可靠性负责”。开发团队需理解运维痛点（如部署风险），运维团队需参与架构设计（如可观测性规划）。
• “错误是改进的机会”：采用无 blame 文化分析故障（如事后复盘），重点挖掘系统设计缺陷（如缺乏熔断机制），而非追究个人责任，通过流程和工具改进避免重复错误。

六、业务价值导向：可靠性服务于业务目标

• 拒绝“绝对可靠”的误区：SRE 不追求 100%可用性（成本极高），而是根据业务优先级制定差异化 SLO。例如，核心交易系统需 99.99%可用性，而边缘功能可能只需 99%。
• 用可靠性反哺业务：通过稳定的服务体验提升用户信任（如电商平台的支付流程），同时通过错误预算机制允许创新试错，助力业务快速迭代（如 A/B 测试、新功能发布）。

总结：SRE 的本质是“用工程方法量化和管理风险”

它将可靠性从“运维的责任”转化为“整个团队的技术目标”，通过数据量化、自动化、跨学科协作，在快速变化的业务需求中找到稳定性的平衡点。核心不是“不出错”，而是“知道哪里可能出错、能承受多少错误，并通过技术手段持续优化”。