SLI、SLO、SLA

驱动生产的三个字母

没有度量的可靠性只是表演。SRE 把可靠性变成一个事先约定、所有人都能验证的数字。

服务水平指标 (SLI)：对服务行为的度量。示例：请求延迟、错误率、吞吐量、队列深度。SLI 是你可以绘制成图表的数据。

服务水平目标 (SLO)：针对 SLI 的目标值或范围。示例：“在滚动 28 天窗口内，99.9% 的 HTTP 请求成功。”SLO 是你对自己和用户做出的关于可接受服务质量的承诺。

服务水平协议 (SLA)：具有法律约束力的合同承诺，通常包含违反时的财务处罚。示例：“如果月可用性低于 99.9%，我们将退款 10%。”SLA 是由律师强制执行的承诺。

关键区别：你的 SLA 必须始终比 SLO 更宽松。如果内部目标是 99.9%，而对外合同也是 99.9%，你就没有任何缓冲余地。SRE 通常将 SLO 设置得比 SLA 严格一个“9”：内部目标 99.95%，合同承诺 99.9%。这个差距可以吸收不可避免的糟糕周。

Error Budgets: The Inverse SLO

从可靠性目标到工程决策

An SLO sets a reliability target. The error budget is what is left over: the amount of failure you can spend before missing the target.

If your SLO promises 99.9% success over 28 days, your error budget is 0.1% of requests, or about 40 minutes of complete downtime per month. That budget is yours to spend however you want: on planned releases, on experimental features, on chaos engineering, on tolerating a misbehaving dependency.

Error budgets reframe the dev versus ops conflict. Without a budget, every outage starts an argument about who shipped the bad change and how to prevent the next one. With a budget:

- Budget remains: ship faster, take more risks, run experiments. The budget pays for it.

- Budget exhausted: stop launching new features, freeze risky changes, focus on reliability work until the budget rebuilds.

This converts reliability from an emotional argument into a measurable resource. Engineers can spend the budget deliberately, like any other production input.

[BLOCK_TYPE QUESTION slos/error_budget]

定义 Toil

什么是 Toil

并非所有运维任务都属于 toil。SRE 对 toil 的定义非常精确：手动、重复、可自动化、战术性、无长期价值、且随着服务规模增长而线性增加的工作。

以上六个属性必须全部满足才算 toil。一次性数据迁移虽然是手动的，但不重复，因此不属于 toil。高级工程师设计新服务架构虽然是战术决策，但能创造长期价值，因此也不属于 toil。

以下是属于 toil 的示例：

- 服务因内存泄漏崩溃后手动重启

- 事件排查时将日志片段粘贴到聊天频道

- 填写工单表单以配置新数据库

- 手动运行季度容量报告

- 逐一审批常规部署请求

50% 规则 将 toil 上限设定为 SRE 工作时间的一半。若超过 50%，团队必须将相应职责交还给产品团队或增加工程师，但核心目标始终不变：通过用工程化系统替代人工操作，将 toil 逐步降至零。

自动化不仅节省时间，还能彻底消除一类人为错误。一个用于配置数据库的脚本不会在长时间工作后遗漏步骤。

Toil 审计推理

你的团队记录了时间分配情况。上季度占比为：30% 部署、25% 事件响应、20% 容量工作、15% 特性开发、10% 产品团队的一次性请求。

On-Call 卫生

工程师，而非寻呼机

待命值班会带来真实成本。睡眠会被打断，周末会被占用，未知问题的压力也会不断累积。SRE 将待命视为一种有限资源，必须保持可持续，而非由最关心的人承担的英雄式负担。

健康的待命轮值遵循以下原则：

- 有偿时间：待命时长应换算为补休、额外薪酬或同等福利。无偿待命会耗尽团队。

- 合理的轮值深度：六人团队同时承担主备值班，意味着每位工程师每三周轮值一次。两人轮值会毁掉职业生涯。

- 告警量预算：Google SRE 手册建议每十二小时班次最多两次告警事件。超过此上限，团队必须投入工程时间降低告警量，而非单纯忍受。

- 仅保留可操作告警：每一次告警都必须需要人工介入。如果告警会被忽略、自动处理，或在正常运行期间反复触发，则不应存在。告警疲劳是一种可靠性缺陷。

- 跨时区交接：全球分布式团队在时区边界交接班次，确保除非系统确实无法等到早晨，否则无人会在凌晨三点收到告警。

Blameless Postmortems

故障如何转化为改进

每一次重大故障都会产出一份事后复盘（postmortem）：一份书面分析，记录发生了什么、原因、修复方式，以及为防止再次发生而做的改进。事后复盘是 SRE 版的复利：每一次复盘都会为系统带来永久的可靠性提升。

无责（Blameless） 意味着文档将故障归因于系统和流程，而非个人。如果工程师执行了错误的命令，复盘会追问：为什么系统允许执行该命令？为什么没有防护机制捕获它？对系统、文档或工具做哪些改动，才能防止下一位工程师犯同样的错误？

无责文化的存在只有一个原因：当人们害怕惩罚时，就会隐藏错误。隐藏的错误会成为下一次故障。与积累未披露缺陷的代价相比，无责文化的成本是低廉的。

事后复盘通常包含：

- 摘要：用一段话描述故障及其影响

- 时间线：按分钟重建的事件经过，附带时间戳

- 根本原因分析：导致故障的技术和流程因素

- 检测：团队如何发现事件，以及耗时多久

- 解决：恢复服务所采取的措施

- 经验教训：哪些有效，哪些无效

- 行动项：具体、明确责任人、有时限的工程任务

行动项记录在跟踪系统中。它们会像其他工程工作一样被优先级排序。没有行动项的事后复盘只是讲故事，工作不会带来任何改变。

四大黄金信号

每项服务都必须测量的指标

Google 的 SRE 书籍提出了每个面向用户的服务都必须暴露的四种信号：延迟、流量、错误和饱和度。它们共同从用户的角度描述了服务的健康状况。监控信号过少会留下盲区；监控数百个指标则会让团队陷入告警疲劳。

延迟：请求耗时。应跟踪分布而非平均值。p50（中位数）描述典型体验，p99 描述最差的 1% 用户。仅看平均值会掩盖长尾：一个中位数 50 ms、p99 5,000 ms 的服务在平均值上看起来正常，却会毁掉百分之一的用户体验。

流量：服务上的需求。对于 Web 服务，指每秒请求数；对于流媒体服务，指同时连接数；对于批处理作业，指每分钟处理的项目数。流量与容量决策相关，也能揭示工作负载异常。

错误：失败请求的比率。显式失败（HTTP 500）、隐式失败（HTTP 200 但返回损坏数据）以及策略失败（响应慢于 SLO）都应计入。区分这些错误很重要：一个携带错误负载的 200 响应往往比一个诚实的 500 更伤害用户。

饱和度：系统运行的满载程度。包括 CPU 利用率、队列深度、内存压力、连接池占用率。饱和度可预测未来的延迟：当系统 CPU 达到 95% 时，几乎没有余量应对用户可见的延迟激增。

大多数 SRE 告警都源自这四种信号。基于症状的告警（在用户会察觉时触发）优于基于原因的告警（在 CPU 超过 80% 时触发）。四黄金信号描述的是症状。

SRE 职业路径

SRE 技能的适用领域

SRE 职业路径会根据工程师最喜欢钻研的领域而分化：

基础设施 SRE：构建其他团队运行所依赖的平台。涉及 Kubernetes、服务网格、内部云。需要扎实的系统工程、分布式系统理论和平台设计能力。在大型公司薪资极高，因为这项工作具有规模效应：一名基础设施 SRE 可支持数百名产品工程师。

嵌入式 SRE：与产品工程团队紧密合作，提升特定服务的可靠性。既是工程师也是教练。强大的沟通能力和代码审查技能与技术深度同样重要。通常是喜欢教学的工程师的最佳路径。

可靠性工具开发：构建可观测性技术栈，包括监控、告警、仪表盘、事后分析工具和事件管理平台。涉及大量前端和数据工程工作。产出会被所有其他团队使用。

生产工程：Facebook/Meta 对 SRE 的称呼，专注于容量规划、部署和流量管理。涉及大量网络和系统工作。

值得持有的技术认证：Google Cloud Professional Cloud Architect、AWS Solutions Architect Professional，以及 CNCF 认证（Kubernetes Administrator、Kubernetes Application Developer）都标志着云原生能力。Linux Foundation 认证则体现系统深度。这些认证无法替代作品集，但有助于通过招聘筛选。

总结

你已掌握的内容

站点可靠性工程（SRE）最初是 Google 为解决规模化问题而提出的方案，如今已发展成为整个行业广泛采用的工程学科。你已学习：

- 从手动运维转向工程化可靠性

- SLI、SLO、SLA 以及 error budget（错误预算）的逆向 SLO 概念

- Toil 的定义、50% 规则以及通过工程手段降低 toil

- 可持续的 on-call 轮值与无责事后复盘实践

- 四大黄金信号（four golden signals）作为服务监控的起点

- SRE 职业发展路径及相关认证

最重要的两个理念。可靠性是一个事先约定的数字。 以及 运维负担是一种缺陷，而不是职位描述。 坚持这两个理念，其余的 SRE 实践便会自然而然地展开。

推荐阅读：Google SRE 书籍（免费在线阅读：sre.google/books/）、SRE 工作手册（提供实践练习），以及 Charity Majors 关于可观测性的文章。geometry-of 配套课程将深入探讨 SRE 实践背后的可视化结构：延迟分布、错误预算锥、依赖关系图以及仪表盘布局。