运维不是救火队
——Google 的 SRE 工程文化，到底高明在哪？
很多朋友一提“运维”，第一反应是啥？
半夜报警
电话被打爆
SSH 一路敲到手抖
祈祷“这次千万别是我”
说实话，我以前也是这么干运维的。
直到后来系统越来越复杂、规模越来越大，我才慢慢意识到一件事：
把运维当“救火队”，本身就是一种失败的工程文化。
而 Google 的 SRE（Site Reliability Engineering），本质上就是对这件事的“彻底反叛”。
一、先说一句大实话：SRE 不是岗位，是一种工程思想
很多人一上来就问：
“Echo，SRE 是不是就是高级运维？”
“是不是运维 + Python + 自动化？”
我一般都会摇头。
在 Google 内部，SRE 的定义非常直接：
SRE 是用软件工程的方法，来解决运维问题。
注意关键词不是“值班”，而是工程。
所以你会发现，Google 的 SRE 并不以“多抗事故”为荣，而是以：
- 事故越来越少
- 人越来越不需要救火
- 系统越来越“自己能活”
为目标。
二、Google 做运维的第一原则：别追求 100% 稳定
这点很多人一听就懵了。
“啥？不追求 100% 稳定？那还运维个啥？”
但 Google 非常清醒：
100% 稳定 = 无限成本 = 不现实。
于是他们提出了一个非常经典的概念：
👉 SLO / SLI / SLA 三件套
先用人话解释：
- SLI：怎么量稳定性（比如成功率、延迟）
- SLO：我们接受的目标值
- SLA：对外承诺（违约要赔钱的那种）
举个非常接地气的例子：
SLI：请求成功率
SLO：99.9%
这意味着什么？
一年 0.1% 的失败，是“被允许的”。
而这 0.1%，就是 Google 非常著名的——
三、Error Budget：SRE 文化的灵魂
如果你只记住 Google SRE 的一个东西，
那我强烈建议你记住：Error Budget（错误预算）。
1️⃣ 什么是 Error Budget？
假设：
- SLO = 99.9%
- 一年总请求 = 1000 万
那就意味着：
允许失败 1 万次请求
这 1 万次，就是你的“错误预算”。
2️⃣ 错误预算用来干嘛？
重点来了。
在 Google：
- 有错误预算 → 可以大胆发布
- 错误预算用完 → 停止发布，只做稳定性
这句话，真的非常反直觉。
很多公司是：
“业务要快！先上线再说！”
“出问题了运维顶上！”
而 Google 是：
稳定性不好，业务开发必须停下来。
注意，是开发停，不是 SRE 加班。
3️⃣ 这才是 Dev 和 Ops 真正的平衡
Error Budget 的高明之处在于：
- 不靠吵架
- 不靠拍脑袋
- 用数据说话
稳定性不是“感觉”，而是量化指标。
四、SRE 的日常工作，远不止“看监控”
很多人以为 SRE 就是：
Prometheus + Grafana + PagerDuty
但在 Google，SRE 有一个非常硬核的规定：
SRE 用于“救火”的时间，不能超过 50%。
剩下的时间，必须干什么？
1️⃣ 把“人肉操作”变成代码
比如，自动扩容。
def autoscale(instances, qps):
if qps > 1000:
instances += 2
elif qps < 300:
instances -= 1
return max(instances, 1)
不是这个代码有多牛，
而是这个思路非常 SRE：
任何需要反复人工干预的事情，都是技术债。
2️⃣ 事故复盘不是追责，而是“反思系统”
Google 的事故复盘（Postmortem）有一个铁律：
Blameless（无责复盘）
复盘关注的是：
- 哪个机制失效了
- 哪个假设不成立
- 哪个监控没报警
而不是：
“是谁点了这个按钮？”
五、监控不是为了“看”，而是为了“行动”
SRE 文化下的监控，有一个非常重要的标准：
没有明确行动的告警，都是耍流氓。
举个例子。
❌ 错误的告警：
CPU 使用率 > 80%
因为你不知道该干嘛。
✅ SRE 风格的告警：
请求错误率 > 1%，持续 5 分钟
这意味着：
- 用户已经感知
- 必须采取行动
监控不是“仪表盘好看”，
而是触发决策的信号。
六、我自己的感受：SRE 是“反人性”的，但非常值得
说点个人感受。
SRE 有几个点，在国内落地时特别难：
- 不追求 100% 稳定
- 出问题不追人
- 用数据约束业务节奏
这些都非常反人性，也反“职场习惯”。
但一旦你真的跑通了，会发现：
- 人没那么累了
- 系统反而更稳
- 团队不再天天内耗
七、写在最后：SRE 的终极目标，是让自己“没那么重要”
这句话，是我越来越认同的一点。
一个成熟的 SRE 团队，应该是“可有可无”的。
不是因为他们不重要，
而是因为他们把系统设计成：
- 不依赖英雄
- 不靠熬夜
- 不怕人离职
如果你今天开始思考：
- 怎么量稳定性
- 怎么减少人肉操作
- 怎么让系统“自愈”
那你已经走在 SRE 的路上了。
