运维不是救火队

——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 的路上了。