谷歌把故障当教材用了20年，其他公司还在写检讨书

2003年，谷歌一个搜索集群宕机47分钟，直接损失约350万美元。工程师本·特雷纳（Ben Treynor）没有写事故报告，而是带着团队算了一笔账：如果每季度都花0.1%的时间搞"故意破坏"，能提前发现多少隐患？这笔账算出了后来市值万亿的SRE体系，也让"可靠性工程"从运维背锅位变成了产品决策层。

特雷纳当时的原话是：「运维团队不应该只是灭火队，他们应该有权拒绝发布不可靠的代码。」这句话在20年前几乎反动——开发只管功能上线，运维只管擦屁股，是硅谷的默认分工。谷歌的解法是把两拨人拧成同一拨：SRE（站点可靠性工程师，Site Reliability Engineer）。

从"救火"到"防火"：SRE改了什么

传统运维的KPI是MTTR（平均修复时间，Mean Time To Repair），越快恢复越好。SRE的KPI是MTBF（平均故障间隔时间，Mean Time Between Failures），越晚出事越好。指标一变，动作全变。

谷歌给SRE团队配了一个硬规则：50%的时间必须花在工程工作上——写自动化工具、优化部署流程、拆单体架构。剩下50%才处理on-call（值班告警）。如果运维琐事挤占了工程时间，SRE有权把新功能打回给开发团队重写。

这个机制有个名字：「错误预算」（Error Budget）。产品团队想要99.99%的可用性？可以，但一年只有52分钟的故障额度。用完即止，新功能冻结。产品经理和SRE坐在同一张桌上谈判，可靠性成了和"用户增长"并列的硬约束。

Netflix把这个逻辑玩得更极端。他们的「混沌工程」（Chaos Engineering）团队专职搞破坏：随机关服务器、拔网线、模拟整个区域瘫痪。2011年他们开源了Chaos Monkey，现在这套工具每天在生产环境"作案"数千次。Netflix工程副总裁亚伦·布莱斯（Yaron Blies）说过：「我们宁愿在周二下午2点自己搞崩服务，也不愿在周五晚8点被用户骂上推特。」

事故管理的四个阶段，谷歌怎么填的

SRE把一次故障拆成四个动作：检测（Detection）、响应（Response）、复盘（Postmortem）、预防（Prevention）。每个环节都有具体的工具和方法，不是喊口号。

检测环节，谷歌用「服务水平指标」（SLI，Service Level Indicator）量化用户体验。不是看"服务器CPU多少"，而是看"搜索请求返回首字节的时间"。SLI达标率就是「服务水平目标」（SLO，Service Level Objective），SLO的违约阈值触发告警。这套指标把"系统健康"翻译成了业务语言。

响应环节有个细节：on-call工程师必须能在15分钟内介入，且不需要懂全部代码。谷歌的做法是强制要求所有服务附带「运行手册」（Runbook），故障场景按症状分类，处理步骤写到第几步该 escalation（升级）给哪个团队。2014年他们内部统计，72%的P0级故障（最高优先级）在运行手册里有现成解法，工程师只需要执行，不需要现场推理。

复盘环节是SRE最具辨识度的文化输出。谷歌的「事后复盘」（Postmortem）文档模板有固定格式：时间线精确到秒、影响范围用数据量化、根因分析用「5个为什么」深挖、改进项必须有owner和deadline。最关键的是一条纪律：复盘文档禁止出现"人为失误"作为根因。如果某人点错了按钮，问题出在为什么系统允许这个按钮被点错。

2017年谷歌云的一次重大 outage，根因是配置推送工具的一个边界条件没覆盖。复盘文档公开后，社区发现这个工具的开源版本同样有漏洞，一周内收到了17个外部PR修复同类问题。故障成了公共教材。

国内公司的SRE实践，卡在哪个环节

阿里2015年设立SRE团队，学的是谷歌的形：也搞错误预算，也写SLO。但一位前阿里SRE告诉我，真正的阻力在"冻结发布"的执行。双十一前代码冻结是铁律，但日常迭代中，产品经理的OKR压力经常压过错误预算。SRE的否决权写在PPT里，死在钉钉群里。

字节跳动的解法更技术流。他们的SRE团队开发了「全链路压测」平台，用线上流量镜像模拟峰值，提前爆破瓶颈。2021年抖音春晚红包活动，压测平台提前48小时发现了一个数据库分片热点，工程师临时改了路由策略。活动当天零故障，但这个案例的代价是：压测平台本身占用了相当于3000台服务器的计算资源。

小红书的SRE负责人张宇在一次分享中提到，他们最难推的是「运行手册」文化。工程师觉得写文档不如写代码，故障来了现场debug更快。直到2022年一次凌晨故障，on-call同学花了40分钟定位，发现解法就在去年某次复盘写的运行手册里，但那份文档躺在Confluence角落没人更新。现在他们的机制是：运行手册和代码同仓库，CI/CD（持续集成/持续部署）流程中强制检查文档更新。

SRE的边界：什么时候该说"不"

谷歌SRE手册里有个反直觉的建议：如果某个服务太老、太乱、文档缺失，SRE应该拒绝接手。不是摆烂，而是逼业务团队先做技术债偿还。接手烂摊子只会让SRE陷入无限on-call，50%工程时间的承诺变成笑话。

这个原则在国内很难落地。一位腾讯IEG（互动娱乐事业群）的SRE说，游戏上线前三个月是"不可能拒绝"的窗口期，哪怕代码质量堪忧。他们的妥协方案是「分级SRE」：核心支付链路配全职SRE，边缘功能配"半职"——开发兼on-call，SRE只负责培训和工具。

2023年，谷歌把SRE手册更新到了第三版，新增了一章：「AI时代的可靠性」。大模型服务的延迟波动比传统服务高一个数量级，SLO怎么设？推理集群的弹性伸缩策略和训练任务抢资源，怎么仲裁？这些问题还没有标准答案。

特雷纳2022年离开谷歌时，内部论坛最高赞的留言是：「你教会我们最好的事，是让可靠性变得可谈判、可量化、可改进。」

现在的问题是：当AI让系统复杂度再上一个台阶，SRE的下一个20年，该把"错误预算"花在什么地方？