00:00:00
国内 SRE 的一线经验，都写在了这本白皮书里 原创
做运维和 SRE 这些年，我读过不少「方法论」：有从 Google 直接翻译过来的，有咨询公司出的框架图，也有各种大会 PPT。读完最大的感受是——道理都对，但落不到自己的机房里。
直到翻完《SRE 实践白皮书》。这本书不太一样：它不是讲「应该怎么做」，而是把腾讯、阿里、蚂蚁、B 站、小红书、携程、小米、中国联通、广发证券这些公司的 SRE 团队真实做过的事，摊开给你看。
本文不是书评，是一份导读。如果你时间不多，看完这一篇大概知道这本书值不值得你花时间。
一、这本书是谁写的
2022 年，赵成等人牵头，把互联网、运营商、金融等行业里一批 SRE 团队负责人聚在一起，组了个研讨社区。所谓「研讨」，就是每周二晚上开例会，各家公司轮流讲自己踩过的坑、做过的改造。这些分享沉淀下来，就成了白皮书。
几个关键节点：
- 2023 年，信通院云大所「稳定性保障实验室」的专家加入，并为白皮书编写提供专业指导
- 2023 年，实验室牵头编制《服务韧性工程（SRE）成熟度模型》标准
- 2025 年，SRE-Elite 整体并入信通院云大所稳定性保障实验室，成立 SRE 工作组，成员扩到 40+
所以它不是个人作品，也不属于某一家公司。它本质上是一份「国内 SRE 现状的横截面」，这是它最稀缺的地方——你在任何一家公司内部都看不到别人的全貌。
二、从 1.0.1 到 1.0.7，它在长什么样
白皮书从 2024 年 2 月首发 1.0.1，到 2026 年 3 月的 1.0.7，一路是「按章迭代」的：
| 版本 | 时间 | 主要变化 |
|---|---|---|
| v1.0.1 | 2024-02 | 首个正式版，搭起整体框架 |
| v1.0.2 | 2024-03 | 补版权声明（CC BY-ND 4.0）、修目录 |
| v1.0.3 | 2024-06 | 第四章大重构，约 4 万字，聚焦变更管理，新增 6 个案例 |
| v1.0.4 | 2024-09 | 研发保障 + 故障应急两章，7.2 万字，新增 7 个案例 |
| v1.0.5 | 2024-12 | 故障应急深化，补 B 站、蚂蚁、OPPO 案例 |
| v1.0.6 | 2025-07 | 新增约 6 万字，首次出现「第四章 SRE 进阶」 |
| v1.0.7 | 2026-03 | 新增约 13 万字，算力调度 + 混沌工程/全链路压测 |
两年多、累计几十万字。这个体量的更新，靠的不是约稿，是一线的人在持续交作业。
三、结构：四个部分，面向四类人
白皮书现在的骨架大概是这样的：
第一章 SRE 整体介绍 —— 发展历程、目标、组织架构。适合拿去给领导解释「我们这岗位是干嘛的」。
第二章 SRE 的基础 —— 面向新人和在校学生的基础理论，标注「1.0.8 发布」，目前还是空的。
第三章 SRE 的职能 —— 全书最重的一章，也是最有价值的一章。
第四章 SRE 的进阶 —— 面向带团队的管理者，讨论生存、算力、AI、从止损到增收。
其中最值得先读的是第三章，它把 SRE 的职能拆成了七个部分：
- 可靠性架构设计 —— 分布式、解耦、冗余、熔断、限流、降级、可观测七种设计
- 研发保障 —— 代码、代码仓库、构建、制品的可靠性，以及 CI、容器平台、编译加速
- 入网控制 —— 运行环境适配、交付、测试策略、变更评审
- 变更管理 —— 发布与变更的关系、流程与工程体系设计
- 故障应急 —— 故障定义分级、应急体系设计、工程体系
- 上线后持续优化 —— 用户体验、运维琐事、成本、持续改进
- 平台工程 —— 标准应用平台与异构应用平台
看到「七种设计」「四类可靠性」这种分层，你就知道它不是随笔集，是有意做过的抽象。每个小节下面挂的案例，才是肉的所在。
四、几个真正值得抠的细节
4.1 变更：70% 的故障是自己搞出来的
白皮书里反复出现一个数字：业界经验认为 70% 左右的故障由变更引起。这个数字 Google 的书里也有，但白皮书给的是国内版本的答案。
v1.0.3 整章重构就是为了这件事。里面提到 B 站的做法我印象很深：利用 trace 和 CMDB 的资源拓扑，把应用服务的变更关联起来，追踪一次变更对整个服务生态的潜在影响。这解决了一个很实际的问题——公司内部往往有好几套发布系统，短期内不可能统一重建，所以从「变更防控」的视角补一个平台，用统一模型和熔断控制做自动化的集中管控。
携程的思路则是基础设施侧的全栈 IaC：用 SaltStack 和 StackStorm 管配置变更，用 Kustomize + Git Workflow 管多集群多环境的基础组件配置，公有云资源用 Terraform。
而某银行的案例做到了量化风控——定义应用和基础设施的变更风险评分模型和积分制度，结合评审控制准入。这在强监管行业几乎是必选项。
三种路径，对应三种组织形态。你可以直接对号入座。
4.2 故障应急：把专家的隐性知识变成平台能力
故障应急这一章是全书案例最密集的地方，光是 v1.0.5 到 v1.0.6 就补了 B 站、蚂蚁、OPPO、XX 银行、腾讯 IEG、小米米家、广发证券一堆。
其中「1-5-10」这个提法很值得记一下：
- 1 分钟监控感知
- 5 分钟节点级定界
- 10 分钟应急处置
配合「纵横三层技术支持」和「应急六板斧」，形成端到端闭环。再往前一步，是把专家脑子里的处置经验自动化——建「可预见故障场景库」和一键应急平台，让故障诊断从「找人」变成「查表」。
腾讯 IEG 的案例则展示了平台工程的威力：依托蓝鲸基座整合监控、CMDB、权限，形成「告警 → 响应 → 诊断 → 恢复 → 复盘」全链闭环；APM + eBPF 做零侵入全栈观测，再叠 LLM Agent 做根因定位，把诊断压缩到分钟级。
小米米家的数字更直观：8.6 亿设备、1 亿月活、日 PV 200 亿。一次失误波及千万用户，所以他们搞了「三句话」多活容灾——层层防护、多机房、多版本快照回滚。2022 年跨机房专线中断和 2024 年机房火灾两次实战，验收了 79 项改进。
这些不是 PPT 里的架构图，是出过事之后改出来的东西。
4.3 v1.0.7 新增：算力调度和混沌工程
最新版加的两块内容，正好踩在这两年的行业风口上。
综合算力调度（第四章第 2 节）的定义写得很准：
将公司购买的私有设备，和租用的物理及虚拟设备，用统一的技术方案进行资源管控，并转化为可以随时使用的弹性算力池，根据各业务系统的需要进行自动化调度，承载业务稳定运行，平衡质量与成本，并精确计算各业务成本费用的能力。
一句话：把资源变成算力，把算力变成可交易的商品。它还明确对应了工信部 2025 年 5 月印发的《算力互联互通行动计划》，落地路径是四条——筑牢算力互联基础、优化设施互联、促进资源互用、创新业务互通。
里面有几个技术细节我读得比较仔细：
- 基础资源管控：管理（生命周期、属性、关系、成本）+ 控制（批量命令、文件传输、数据采集）两条腿
- 管控通道的 Agent / 无 Agent 之争：Ansible 那种 SSH 模式千台并发命令要 10s 以上，文件分发 500MB 要 40–60 分钟；蓝鲸的 Agent 模式千台并发 2s 内，1GB 文件 200s 内，P2P 带宽节省率超 80%
- One Agent 模式：用一个统一 Agent 覆盖运维、混沌、安全等场景，避免多 Agent 的资源浪费
- 算力市场：精准匹配、无差异体验、可信交易三个核心能力
混沌工程与全链路压测（第五章第 5.4 节）那一节，开头那段比喻我很喜欢：流感年年都会来，我们无法预知它何时爆发，但可以确定它迟早会来。与其被动挨打，不如主动出击，检验系统的「免疫系统」。
它还点破了传统压测的「三个谎言」：
- 环境等价的谎言 —— 测试环境永远不等于生产环境，机器规格、数据规模、网络拓扑都有差异
- 用户真实的谎言 —— 固定比例的流量模型还原不了真实用户行为。游戏场景里，玩家前 5 分钟还在大厅没开枪，进对局后才大量移动射击，不同协议在不同时段的占比是波动的
- 链路完整的谎言 —— 单集群单服务压测碰不到第三方依赖、负载均衡、核心网络这些「看着边缘、实际最先崩」的组件
这段写得很实在。压测报告好看但线上照样崩，回头看基本都能归到这三点。
五、如果你是不同角色，该怎么读
刚入行的运维 / 在转 SRE 先看第一章和第三章第 1 节（可靠性架构设计）。七种设计是通用语言，看完至少能听懂架构评审在说什么。第二章虽然还没发布，但可以蹲。
一线 SRE / 平台工程师 重点啃第三章第 2、3、7 节——研发保障、入网控制、平台工程。这部分最「工程」，能直接抄作业，尤其是 CI 流水线、制品可靠性、编译加速这些具体场景。
SRE 团队负责人 第四章第 1 节《SRE 团队的生存与持续发展》值得反复读。里面有些话不太好听但很真实：
没有这个岗位，公司还能否运转，答案是，可以。
蜜月期过后（大致一年左右），如果可靠性未有明显改善，同时又出现负面评价，例如成本过高、引发矛盾、拖慢业务等，SRE 岗位将被缩减；如果可靠性有明显改善，而 SRE 岗位没有扩展出例行服务，SRE 岗位也将被缩减。
然后给出了三种预算来源（业务闭环 / 集中划拨 / 货币化支付），以及一条生存法则总结：
以高于同行或业务自建的 ROI，保障基础可靠性，不断降本增效创新，伴随及辅助业务发展
还有一句我很认同的判断——SRE 应该把工作重心左移，因为代码 bug 导致的可靠性损失大致在 20%~40% 之间，极端情况可能超过一半。只管线上，等于只管了一半的可靠性。
管理者 / 架构师 第四章整章 + 第三章第 5 节案例。看别的公司怎么组织、怎么算账、怎么在故障之后做治理。
六、一点个人看法
这本书也有它的局限，得说清楚：
一是章节完成度不齐。 第二章（SRE 的基础）标注「1.0.8 发布」，至今是空的；第四章第 4 节（基础监控与应用观测）同样在「编写中」。想系统学监控的同学，这里还得自己补。
二是案例以头部公司为主。 腾讯、阿里、蚂蚁、B 站这个级别的场景，中小团队直接照搬会水土不服。比如全链路压测的「影子库表 + 独立压测集群 + 影子 MQ」三层隔离，投入不是一般团队扛得住的。读的时候得自己做减法。
三是它的深度靠案例撑，抽象部分偏薄。 好在案例足够多，40+ 家企业、跨互联网/运营商/银行/证券/游戏，总能找到和自己形状相似的。
即便如此，它依然是目前中文世界里最接近「国内 SRE 实践全景图」的一份材料。Google 的书告诉你 SRE 的理想形态，这本告诉你理想在现实里被磨成了什么样。
七、怎么拿到
- 公告与版本说明：https://www.sre-elite.com/notice/
- 最新版下载（v1.0.7）：http://docs.sre-elite.com/SRE-White-Paper-v1.0.7.pdf
- GitHub 反馈与讨论：https://github.com/sre-elite/whitepaper
另外，SRE 工作组每周二晚上有例会，也会在 QCon、GOPS 等大会开专场。有兴趣的话可以去提交案例，这书就是这么做出来的。
最后引用一句书里的话收尾。它讲的是 SRE 团队心态，但我觉得对所有做稳定性的人都适用：
「弱小和无知不是生存的障碍，傲慢才是。」