第1章引言

从理念到实践

章节导读

2003 年，Google 做出一个在当时看起来颇为激进的决定：把一群软件工程师从产品开发线上抽调出来，组建一个专门负责生产环境的团队。这个团队的使命不是「运维」，而是「用软件工程的方法解决运维问题」。Benjamin Treynor Sloss 被任命为这个团队的负责人，他给这个新学科起了一个名字——Site Reliability Engineering，站点可靠性工程，简称 SRE。SRE 的诞生有其深刻的历史背景。在 Google 之前，互联网行业的标准做法是把「开发」和「运维」割裂开来：开发人员写代码、追求新功能，运维人员守机器、追求稳定。这两个角色的激励天然对立——开发想快速发布，运维想少动生产环境。这种对立导致了著名的「DevOps 之墙」：代码写完扔过墙，出了问题互相指责。随着 Google 的服务规模以指数级增长，这种割裂模式的代价越来越高。一次糟糕的发布可能影响数亿用户，一次配置错误可能导致全球服务中断。Google 意识到，传统的「人肉运维」根本无法支撑这种规模，必须用工程师的方式重构整个生产体系。SRE 的核心命题可以概括为一句话：SRE 就是让软件工程师来设计运维职能。SRE 团队里的人本质上都是软件工程师，他们花费大量时间编写代码来自动化运维流程、构建监控系统、开发容量规划工具，而不是手工敲命令。Google 有一条著名的规则：SRE 花在「琐事」（toil）上的时间不得超过 50%。所谓琐事，是指那些手动的、重复的、可自动化的、没有持久工程价值的、随规模线性增长的操作工作。如果一个 SRE 团队发现自己 80% 的时间都在处理工单和手工重启服务，那么这个团队正在滑向传统运维的深渊，必须通过自动化和流程改造把时间夺回来。2016 年，Google 出版了《Site Reliability Engineering: How Google Runs Production Systems》，也就是俗称的「黑皮书」，系统阐述了 SRE 的理念、原则和方法论。这本书在业界引起了巨大反响，「SRE」从一个 Google 内部职位变成了全行业的标准角色。但读者很快发现一个问题：黑皮书讲清楚了「为什么」和「是什么」，却没有足够篇幅讲「具体怎么做」。比如，书里说应该设定服务等级目标（SLO），但一个真实团队坐下来设定 SLO 时，会遇到一连串棘手的问题：SLI 应该基于什么数据源计算？窗口选多长？SLO 定多少合适？错误预算耗尽了怎么办？如何说服产品团队接受这套机制？2018 年出版的《The Site Reliability Workbook》，也就是这本「蓝皮书」，正是为了回答这些问题而生。它是黑皮书的实践手册，全书围绕一个个具体主题展开：SLO 的设定与实施、告警体系设计、值班机制、防止过载、数据管道可靠性、负载均衡、混沌工程、需求预测、变更管理与灾难响应。每一章都包含 Google 内部的真实做法、可复用的框架、检查清单和决策树，以及来自其他公司的案例研究。理解蓝皮书的定位，可以用一个类比：黑皮书像是医学院的教科书，告诉你人体如何运作、疾病的原理是什么；蓝皮书则像是临床操作手册，告诉你面对一个具体病人时，该做哪些检查、按什么顺序、如何解读结果、什么情况下该采取什么措施。两本书合在一起，才构成完整的 SRE 知识体系。本章作为全书的引言，将带你回顾 SRE 的核心理念，为后续各章的实践内容打下概念基础。我们会重点讨论几个贯穿全书的关键思想：拥抱风险（可靠性不是越高越好，100% 是错误的目标）、错误预算（用数据驱动的方式平衡可靠性投入与功能迭代）、消除琐事（自动化一切可自动化的工作）、以及监控与告警的正确姿势（基于症状而非原因）。这些理念看似抽象，但蓝皮书的每一章都在把它们变成可执行的工程实践。比如「拥抱风险」这个理念，在第 3 章会变成具体的 SLO 设定方法；在第 4 章会变成多窗口多燃烧率告警；在第 10 章会变成混沌工程的爆炸半径控制。理念只有落地为实践才有价值，这正是本书存在的意义。另一个值得强调的点是 SRE 的组织模式。不同公司、不同团队引入 SRE 的方式差异很大。Google 内部主要有几种模式：嵌入式 SRE（Embedded SRE），SRE 工程师直接加入产品团队，与开发人员并肩工作；咨询式 SRE（Consulting SRE），SRE 团队作为顾问帮助产品团队建立可靠性实践，但不直接承担生产责任；框架 SRE（Framework SRE），为其他 SRE 团队提供工具和平台，比如监控系统、发布工具、容量规划框架。第 2 章和第 8 章会详细讨论这些模式的适用场景和演进路径。对于刚接触 SRE 的读者，建议的阅读路径是：先通读本章建立整体认知，然后直接跳到第 3 章（SLO）和第 4 章（告警），因为这两章是绝大多数团队落地 SRE 的第一步；之后再按需阅读值班、过载保护、数据管道等专题章节。如果你正在推动团队转型，第 2 章和第 8 章关于参与模式和跨团队协作的内容会对你特别有价值。最后要说明的是，SRE 不是银弹，也不是必须照搬的教条。Google 的做法根植于其独特的工程文化、超大规模的基础设施和人才密度。蓝皮书反复强调：这些实践是「我们发现的可行方法」，而不是「唯一正确的方法」。每个团队都应该根据自身的服务特性、团队规模和组织文化，对这些实践进行裁剪和适配。SRE 的本质精神是：用工程思维对待可靠性，用数据驱动决策，用自动化消灭重复劳动。抓住这个精神，比记住任何具体数字或配置都重要。

核心概念

SRE
错误预算
SLO
消除琐事

要点精析

SRE 的起源与使命：用软件工程方法解决运维问题。SRE 诞生于 2003 年的 Google，当时整个团队只有 7 个人，负责支撑迅速增长的 Google 服务。Benjamin Treynor Sloss 对 SRE 的经典定义是「SRE is what happens when you ask a software engineer to design an operations function」——当你让软件工程师来设计运维职能时，就产生了 SRE。这句话的深意在于：传统运维的核心工作是「操作」，而 SRE 的核心工作是「构建」。SRE 工程师面对重复性运维任务时的第一反应不是把它做得更快，而是写一个系统让它不再需要人来做。Google 对 SRE 团队有一条硬性规定：至少 50% 的时间必须用于工程项目（开发工具、构建平台、改进系统），而不是运维响应。这条规则的意义在于防止 SRE 团队退化成传统运维团队——一旦琐事占满全部时间，团队就失去了改进系统的能力，陷入「越忙越乱、越乱越忙」的恶性循环。理解这一点是理解全书的前提：SRE 的所有实践（SLO、告警、值班、自动化）都服务于同一个目标——让生产系统在规模持续增长的同时，人力投入保持亚线性增长。

拥抱风险：为什么 100% 是错误的可靠性目标。这是 SRE 最反直觉也最重要的理念之一。直觉上，服务越可靠越好，但 SRE 认为 100% 的可靠性目标不仅是错误的，而且是有害的。原因有三：第一，用户端的现实决定了 100% 毫无意义——家庭宽带、移动网络、用户设备本身的可用性通常低于 99.9%，你的服务做到 99.999% 用户也感知不到差异；第二，可靠性是有成本的，从 99.9% 提升到 99.99% 的成本可能是十倍甚至百倍，包括冗余硬件、多活架构、更严格的发布流程，这些成本最终会拖慢创新速度；第三，追求 100% 会让团队变得极度保守，任何变更都被视为风险，系统反而会因为缺乏演进而变得脆弱。正确的做法是：把可靠性目标设定在「略高于用户期望」的水平，然后把剩余的「不可靠额度」——也就是错误预算——主动花掉，用于快速实验、发布新功能、做混沌测试。Google 的许多服务甚至会有计划地利用错误预算做破坏性实验，这正是第 10 章混沌工程的理念基础。

错误预算：平衡可靠性与迭代速度的核心机制。错误预算（Error Budget）是 SRE 最具原创性的管理工具，它把「可靠性 vs 速度」这个看似无解的矛盾转化成了一个可计算、可执行的机制。定义很简单：错误预算 = 1 - SLO。如果 SLO 是 99.9%，那么错误预算就是 0.1%，在 30 天窗口内约等于 43 分钟的不可用时间或等比例的失败请求。这个机制的妙处在于它改变了开发与运维的对话方式：过去，开发说「我要发布新功能」，运维说「不行，太危险」，双方各执一词、靠嗓门和职级决胜负；现在，双方看着同一个数字说话——预算还有剩余，就大胆发布、快速迭代；预算快耗尽了，就冻结变更、专注可靠性。错误预算把主观争论变成了客观决策。实践中需要注意几个细节：预算窗口通常选 28 天或 30 天（4 周的整数倍便于对齐周期）；预算耗尽后的「冻结」应该有明确的豁免规则（安全补丁、修复可靠性本身的变更不受限）；预算的消耗速度（burn rate）比剩余量更重要，它决定了告警的紧急程度，这是第 4 章多窗口多燃烧率告警的理论基础。

消除琐事：SRE 时间的保卫战。琐事（Toil）在 SRE 语境中有精确定义：手动的、重复的、可自动化的、没有持久工程价值的、随服务规模线性增长的工作。典型的琐事包括：手工重启服务、人工处理例行工单、手动扩容、复制粘贴式的发布操作、例行数据修复。琐事本身不可怕，可怕的是它的累积效应——它挤占工程时间、消磨团队士气、让最有能力的工程师沦为「人肉脚本」。Google 的对策是把琐事占比控制在 50% 以下，并且从多个层面系统性地消灭它：产品层面，改进服务设计让故障更少发生；流程层面，用自动化取代手工步骤；组织层面，把例行操作下放给自助工具。识别琐事有个实用技巧：记录一周内所有被打断的工作，问自己「这件事明年还需要人来做吗？」如果答案是肯定的，它就是自动化候选。消除琐事的优先级排序可以用「频率 × 单次耗时 × 自动化难度」来评估，先摘低垂的果实，快速积累自动化红利。蓝皮书后续章节中的值班手册、发布自动化、容量规划工具，本质上都是消除琐事的工程实践。

监控与告警的正确姿势：基于症状而非原因。传统运维监控的思路是「把所有能采的指标都采上来，所有异常都告警」：CPU 高了告警、内存高了告警、磁盘满了告警、进程挂了告警。这种「原因导向」的监控在系统规模小的时候尚可维持，规模一大就会陷入告警风暴——一次故障触发几百条告警，值班工程师淹没在噪音里，反而找不到真正的问题。SRE 的监控哲学是「症状导向」：监控用户可感知的症状（请求失败率、延迟、服务不可用），而不是系统内部的原因（CPU、内存）。原因指标不是不要，而是它们的角色是「诊断辅助」而非「告警触发器」。Google 把监控系统的输出分为四类：紧急告警（需要人立即行动）、工单（需要人尽快处理但非紧急）、日志与诊断信息（供排查用）、仪表盘（供人观察趋势）。判断一条告警是否合格的标准是：它是否代表用户正在受损？收到告警的人是否需要立即采取智能行动？如果一条告警连续一个月都没有导致任何行动，它就应该被删除或降级。这套哲学在第 4 章会展开为完整的基于 SLO 的告警体系设计方法。

黑皮书与蓝皮书的分工：理念篇与实践篇。理解这两本书的关系，有助于建立正确的学习路径。黑皮书（2016）回答的是「SRE 是什么、为什么有效」：它阐述了 SRE 的诞生背景、核心理念（拥抱风险、消除琐事、简单化）、关键实践框架（SLO、监控、发布工程、事后分析），以及 Google 的基础设施概览（Borg、Chubby、Colossus 等）。黑皮书更像一部「思想宣言」，它让全世界知道了 SRE 这个学科的存在。蓝皮书（2018，即本书）回答的是「具体怎么做」：每一章聚焦一个实践主题，提供可直接套用的方法论。例如第 3 章不仅告诉你「要设定 SLO」，还给出了 SLI 选择的决策树、SLO 设定的具体步骤、错误预算策略的模板；第 4 章给出了多窗口多燃烧率告警的完整 PromQL 实现；第 5 章给出了操作负载的量化计算方法。蓝皮书还引入了大量非 Google 的案例研究，展示了不同规模、不同行业的组织如何适配 SRE 实践。推荐的阅读方式是：先读黑皮书的第 1、2、3、4、5、6 章建立理念框架，然后用蓝皮书作为操作手册逐章落地。两本书都在 sre.google 免费在线阅读，Google 还配套发布了 The Site Reliability Workbook 的中文版《SRE 工作手册》。

SRE 的组织模式：嵌入式、咨询式与框架团队。SRE 不是一个必须整齐划一的角色，Google 内部演化出了多种参与模式，各有适用场景。嵌入式 SRE（Embedded SRE）：SRE 工程师作为产品团队的一员，与开发人员坐在一起（或在同一个团队编制内），共同承担服务的生产责任。这种模式协作最紧密、响应最快，适合关键业务服务，但对 SRE 人力消耗大。咨询式 SRE（Consulting SRE）：SRE 团队作为内部顾问，帮助产品团队评估生产就绪度、设计可靠性方案、培训值班技能，但不长期承担生产责任。这种模式杠杆率高，一个 SRE 可以影响多个团队，适合 SRE 人力有限或产品团队工程能力较强的场景，风险是建议可能不被执行。框架 SRE（Framework SRE）：不直接服务某个产品，而是构建所有 SRE 团队共用的工具和平台——监控系统、告警框架、发布工具、容量规划平台。框架团队的价值在于把可靠性能力「平台化」，让每个嵌入式 SRE 都站在巨人肩膀上。实际组织中这三种模式往往并存并随时间演化：早期人力少时用咨询式打样，成熟后对关键服务转嵌入式，同时沉淀出框架团队。第 2 章和第 8 章将详细讨论如何选择和演进这些模式，包括 SRE 介入的前提条件、退出机制和常见陷阱。

发布工程：把变更风险变成可控变量。Google 的经验数据表明，约 70% 的生产事故由某种变更触发——代码发布、配置修改、基础设施调整。因此发布工程（Release Engineering）是 SRE 的核心职能之一。SRE 视角下的发布工程有几大原则：自助式发布，开发团队不需要求着运维帮忙发布，而是通过标准化流水线自己完成，发布从「高危仪式」变成「日常操作」；追求速度，发布流程越慢，每次发布积累的变更越多，风险越大，小步快跑比大步慢走安全；密闭的构建与部署，构建产物在任何环境都一致，杜绝「在我机器上能跑」；强调配置管理，所有环境差异通过配置声明式描述，而不是靠人记忆。渐进式发布是控制爆炸半径的关键手段：金丝雀发布（先发一台机器观察）、灰度发布（按用户比例逐步放量）、蓝绿部署（新旧环境快速切换）。每种策略都在「发布速度」和「风险控制」之间做不同的权衡。第 12 章将深入讨论变更管理与灾难响应，包括如何设计快速回滚、如何组织事故响应。发布工程的终极目标是让发布变得「无聊」——当发布不再令人紧张时，说明系统已经足够健壮、流程已经足够成熟。

简单化：可靠性的隐形基石。软件系统天然趋向复杂，而复杂性是可靠性的头号敌人。Google 把「简单化」列为 SRE 的持续工程实践：每个季度，SRE 团队都会审视所负责的系统，找出可以删除的代码、可以合并的服务、可以下线的功能。这里要区分两种复杂性：本质复杂性（essential complexity）来自问题域本身，无法消除，比如分布式系统必须处理网络分区；偶然复杂性（accidental complexity）是设计和实现过程中引入的，可以通过工程手段消除，比如为了「将来可能需要」而预留的抽象层、复制粘贴产生的重复代码、没人敢删的历史遗留模块。SRE 对简单化的执着有一个务实的理由：紧急时刻，人只能处理简单的系统。凌晨三点被叫醒的值班工程师，面对一个他不完全理解的复杂系统，做出错误决策的概率大大增加。简单化不仅是美学追求，更是降低操作负载、提升故障响应质量的工程手段。蓝皮书第 2 章专门讨论了「简单化框架」：如何通过删除死代码、减少依赖、收敛接口、明确所有权来系统性降低复杂度。一个实用的自检问题是：如果这个组件明天消失了，用户会注意到吗？如果答案是否定的，它可能就是删除候选。

本书的使用方法：如何把阅读转化为落地。蓝皮书不是一本从头读到尾的小说，而是一本按需查阅的实践手册。不同角色的读者应该有不同的使用策略。如果你是团队负责人或架构师：重点阅读第 2 章（参与模式）、第 3 章（SLO）、第 8 章（跨团队协作），这三章决定了 SRE 转型的组织路径；先在一个试点服务上完整走通「SLI 定义 → SLO 设定 → 错误预算策略 → 基于 SLO 的告警」的闭环，再逐步推广。如果你是一线 SRE 或运维工程师：第 4 章（告警）、第 5 章（值班）、第 6 章（过载保护）是你的日常武器库，可以直接套用其中的 PromQL 模板、值班手册结构和限流配置。如果你负责数据系统：第 7 章（数据管道）提供了针对性的可靠性框架。如果你在做基础设施：第 9 章（负载均衡）、第 11 章（容量规划）有深入的工程细节。无论哪种角色，都建议把每章末尾的实践练习真正做一遍——SRE 是实践学科，只读不练等于没读。落地时最常见的失败模式是「全盘照搬」：把 Google 的所有实践一次性引入，结果团队消化不良。正确的节奏是：一次引入一个实践，跑通闭环，度量效果，再引入下一个。记住 SRE 转型是以年为单位的旅程，而不是一个季度的项目。

代码示例

/* 示例 1：错误预算的基本计算（TypeScript） */
function computeErrorBudget(slo: number, windowDays: number) {
  /* 错误预算比例 = 1 - SLO */
  const budgetRatio = 1 - slo;
  const windowMinutes = windowDays * 24 * 60;
  const budgetMinutes = windowMinutes * budgetRatio;
  return {
    slo,
    budgetRatio,
    windowDays,
    budgetMinutes: Number(budgetMinutes.toFixed(2)),
  };
}
/* 常见 SLO 对应的 30 天错误预算 */
const budgets = [0.99, 0.999, 0.9995, 0.9999].map((s) => computeErrorBudget(s, 30));
/* 结果：99% -> 432 分钟(7.2小时)；99.9% -> 43.2 分钟；
   99.95% -> 21.6 分钟；99.99% -> 4.32 分钟 */

这段代码演示了错误预算的核心计算：预算 = (1 - SLO) × 窗口时长。注意 30 天窗口下，SLO 每提高一个 9，可用预算就缩小到十分之一——99.9% 的服务一个月只允许 43 分钟不可用，而 99.99% 只允许 4.3 分钟。这个数量级差异直观解释了为什么「追求更高的 SLO」代价巨大：它意味着发布窗口更窄、容错空间更小、对基础设施的要求呈指数上升。实践中团队常犯的错误是拍脑袋定一个「听起来很厉害」的 99.99%，结果预算频繁耗尽、发布长期冻结，最终被迫偷偷放宽标准，SLO 失去公信力。正确的做法是从用户实际感知出发：用户真的能区分 99.9% 和 99.99% 吗？如果不能，多花的成本就是纯浪费。

/* 示例 2：用 PromQL 计算基于请求的可用性 SLI */
/* 过去 30 天的成功请求比例（滚动窗口） */
sum(rate(http_requests_total{job="my-service",code!~"5.."}[30d]))
/
sum(rate(http_requests_total{job="my-service"}[30d]))

这是最经典的可用性 SLI 查询：分子是非 5xx 请求的速率总和，分母是全部请求的速率总和，两者相除得到成功比例。几个实践细节值得注意：第一，用 rate 而不是 increase，因为 rate 对计数器重置（如进程重启）更鲁棒；第二，5xx 的定义要与业务对齐——有些服务把 429（限流）也算作失败，因为从用户视角看请求确实没成功，而有些服务把 404 排除在外，因为那是客户端错误；第三，30d 的滚动窗口计算成本较高，生产中通常用 recording rule 预先聚合，或者采用「长窗口 + 短窗口」组合来平衡精度与开销。这个查询的结果直接与 SLO 比较：如果 SLO 是 0.999，查询结果低于 0.999 就意味着错误预算已耗尽。

/* 示例 3：错误预算剩余比例的 PromQL */
/* 已消耗预算比例：1 减去当前成功率，再除以预算比例 */
(
  1 - (
    sum(rate(http_requests_total{job="my-service",code!~"5.."}[30d]))
    /
    sum(rate(http_requests_total{job="my-service"}[30d]))
  )
)
/ (1 - 0.999)  /* SLO = 99.9%，预算比例 = 0.001 */

这个查询计算的是「错误预算消耗比例」：当前错误率除以允许的错误率。结果为 0.5 表示预算用掉一半，结果为 1.0 表示预算耗尽，结果大于 1 表示已超标。这个指标是错误预算策略的触发器：团队可以基于它设置仪表盘和通知——消耗超过 50% 时在周会上提示，超过 80% 时收紧发布节奏，达到 100% 时启动变更冻结。注意分母 (1 - SLO) 是硬编码的，实践中应该用变量或配置管理，避免 SLO 调整后忘记同步修改查询。另外，30 天滚动窗口的特点是「记忆衰减」：一次大事故的影响会随着时间推移逐渐滑出窗口，预算自动恢复，这既符合直觉（过去的错误不应永久惩罚团队），也给了团队明确的「恢复时间点」预期。

/* 示例 4：琐事评分脚本（Python 风格伪代码） */
def toil_score(task):
    """琐事分数 = 手动度 * 频率 * 可自动化度 / 工程价值"""
    manual = task["manual_level"]        /* 1-5，越高越手动 */
    freq = task["frequency_per_month"]   /* 每月发生次数 */
    automatable = task["automatable"]    /* 1-5，越高越容易自动化 */
    value = max(task["engineering_value"], 1)  /* 1-5，避免除零 */
    return manual * freq * automatable / value

tasks = load_ops_log("last_month.json")
ranked = sorted(tasks, key=toil_score, reverse=True)
for t in ranked[:5]:
    print(t["name"], round(toil_score(t), 1))

这个脚本把「消除琐事」从口号变成了可排序的待办清单。评分模型的四个维度各有含义：手动度衡量人的参与程度，频率衡量累积成本，可自动化度衡量改造的可行性，工程价值作为分母确保我们优先自动化「低价值高重复」的工作而不是误伤有创造性价值的任务。每月运行一次这个脚本，取分数最高的前几项作为自动化项目的候选，是控制琐事占比的实用手段。Google 的经验是，琐事审计最大的难点不是计算，而是诚实记录——工程师倾向于低估自己花在琐事上的时间，或者觉得某些琐事「不值得记录」。建议用一周时间做精确的时间打点，其结果往往令人震惊：许多团队发现自己 60% 以上的时间被琐事占据。

/* 示例 5：简单的错误预算策略配置（YAML） */
error_budget_policy:
  service: checkout-api
  slo: 0.999
  window_days: 30
  thresholds:
    - consumed_ratio: 0.5
      action: "在团队周会上通报，评估近期变更风险"
    - consumed_ratio: 0.8
      action: "暂停非关键发布，仅允许低风险变更"
    - consumed_ratio: 1.0
      action: "冻结所有功能发布，全力投入可靠性修复"
  exemptions:
    - "安全漏洞修复"
    - "旨在恢复 SLO 的可靠性变更"
    - "经 SRE 与产品负责人共同批准的紧急业务变更"
  review_cadence: "每周一自动计算并推送报告"

这份 YAML 是错误预算策略的最小可用模板。它的价值不在于格式，而在于「事先约定」：在事故发生之前、在情绪和利益冲突出现之前，团队已经白纸黑字地写好了不同预算水位下的行为规则。三个关键设计点：第一，阈值分级（50%、80%、100%）让响应是渐进的，避免从「一切正常」直接跳到「全面冻结」的悬崖式决策；第二，豁免条款必不可少——安全补丁和可靠性修复本身永远不能被预算冻结挡住，否则机制会自我矛盾；第三，明确审批人（SRE 与产品负责人共同批准），避免豁免变成随意绕过的后门。策略生效后，开发与运维的争论从「该不该发布」变成「预算还剩多少」，这正是错误预算机制的精髓：用共享的客观数据取代立场之争。

实验笔记

本实验的目标是让你亲身体验 SRE 的核心工作循环：识别琐事、定义服务等级指标、计算错误预算、并制定初步的可靠性改进计划。实验分为五个部分，预计总时长 4 到 6 小时，适合以 2 到 3 人的小组形式完成。第一部分：服务画像与琐事审计（约 1 小时）。选择你所在团队负责的一个真实服务（如果没有，可以选择一个开源项目如 WordPress 或 GitLab 作为假想对象）。为这个服务绘制一张简单的架构图，标注所有外部依赖：数据库、缓存、消息队列、第三方 API 等。然后进行琐事审计：列出过去一个月中团队处理的所有运维工作，按「手动程度」「重复频率」「可自动化性」「工程价值」四个维度打分（每项 1 到 5 分）。计算每项工作的琐事分数 = 手动程度 × 重复频率 × 可自动化性 ÷ 工程价值。分数最高的三项就是你最应该优先自动化的目标。检查清单：架构图是否覆盖了所有强依赖？琐事清单是否至少有 10 项？是否区分了「一次性工作」和「重复性工作」？第二部分：SLI 定义工作坊（约 1 小时）。针对所选服务，从用户视角出发定义 SLI。问自己三个问题：用户如何感知这个服务？什么样的响应算「好」？用户能容忍多慢？基于这三个问题，至少定义两类 SLI：可用性类（成功请求数 ÷ 总请求数）和延迟类（快于某阈值的请求数 ÷ 总请求数）。为每个 SLI 写出精确的数学定义，明确分子、分母、数据来源和聚合窗口。常见误区提醒：不要把「服务器 CPU 使用率」这类原因指标当作 SLI，SLI 必须是用户可感知的症状指标；不要一开始就追求完美的 SLI 定义，先跑起来再迭代。第三部分：SLO 设定与错误预算计算（约 1 小时）。基于历史数据（或合理假设）为每个 SLI 设定 SLO。使用决策树：这个服务是面向终端用户还是内部系统？用户能否容忍短暂不可用？是否有合同约束？竞品或行业基准是什么？据此在 99%、99.9%、99.95%、99.99% 中选择。然后计算错误预算：如果 SLO 是 99.9%，30 天窗口内的错误预算 = 30 × 24 × 60 × 0.1% = 43.2 分钟。用电子表格建立一个简单的错误预算追踪器，输入过去 30 天的模拟数据，观察预算的消耗曲线。思考题：如果预算在第 10 天就消耗了 80%，团队应该做什么？第四部分：错误预算策略草案（约 1 小时）。为你的服务起草一份错误预算策略文档，内容包括：预算消耗的监控方式（谁看、多久看一次）；不同消耗速度下的响应动作（正常、加速消耗、即将耗尽、已耗尽四档）；预算耗尽时的冻结规则（冻结哪些活动、豁免哪些情况）；策略的决策者和升级路径。写完后与同伴互相评审：策略是否可执行？触发条件是否明确？有没有模糊地带？第五部分：汇报与反思（约 30 分钟）。准备一份 10 分钟的汇报，内容包括：服务画像、琐事审计结果、SLI/SLO 定义、错误预算策略。汇报后回答反思问题：整个过程中最难的决定是什么？如果重来一次会怎么做？哪些 SRE 理念在实践中最容易走样？通过这五个部分，你将完整走过一遍「从理念到实践」的循环，这正是蓝皮书全书的缩影。

第1章 引言