监控不是摆设：把 SLA 写进监控后，SRE 的决策终于有了“方向盘”

大家好，我是 Echo_Wish。

很多团队做监控做了十几年，面板一个比一个花，Grafana 图一个比一个炫，但真正出问题时大家依旧一脸懵：
“到底算不算故障？”
“要不要触发应急？”
“这是不是要背锅？”

为什么？
因为监控没有和业务目标绑定，也就是 SLA 根本没写进去。

你看，监控和 SLA 的关系，就像仪表盘和限速标志：
只有速度和限速结合，你才能知道 “你是不是已经违章了”。

今天我想聊聊：SLA 写在监控上之后，SRE 的决策会发生什么质变？
我会给你实战思路、代码片段、业务案例，全都接地气，不整那些 PPT 话术。

一、监控没写 SLA，本质就是“只看数据，不看目标”

我看过太多团队的监控：

• CPU 80% 告警
• 内存 70% 告警
• Pod 重启告警
• QPS 下滑告警
• 错误率升高告警
• ……
  把每一个波动都当成“世界末日”。

但它们都漏了最关键的一件事——用户到底受到影响了吗？

举个例子：

• CPU 95%，但系统依旧稳如老狗
• 错误率 2%，但 SLA 容忍 5%
• QPS 下滑，但恰好夜间没人访问
• Kafka lag 升高，但下游不敏感

这些在 SLA 体系里都不叫“故障”，叫做：
不用惊动谁，但得记下来。

一个成熟的 SRE 决策应该基于 SLA，而不是 CPU 的心情波动。

二、SLA 要写在监控上，而不是写在文档里

很多公司号称有 SLA，结果我一看，是这样的：

系统 SLA：99.9%
月可用性：>= 43200 秒
容错范围：允许 43 秒不可用

问他们：“SLA 现在达标吗？”

他们回答：“不知道，看监控好像还行……”

SLA 写在 Confluence 里是没用的，得写进监控，挂到 Grafana 最明显的地方，给决策者一眼就能看到的东西。

比如这种：

• 错误预算剩余：92%
• 当前月可用性：99.902%
• 剩余可用时间：31 秒
• 预计风险：中
• 过去 24h 消耗：6%
• 是否触发变更冻结：是

这才是 SRE 能看懂的监控，而不是 CPU 曲线飘来飘去。

三、如何实现？我给你一个可落地的 SLA 监控框架

下面是典型的 SLA 监控指标：

下面给你一个 SLA 指标的 Prometheus 示例代码（Python）：

from prometheus_client import Gauge, Counter, start_http_server
import time, random

# 统计请求
total_req = Counter("api_total_requests", "Total API Requests")
err_req = Counter("api_error_requests", "API Error Requests")
slo_availability = Gauge("slo_availability", "SLO Availability (percentage)")

SLO_TARGET = 0.999  # 99.9%

def simulate_request():
    total_req.inc()
    fail = random.random() < 0.002  # 0.2% 错误率
    if fail:
        err_req.inc()
    # 计算 SLA 当前状态
    error_rate = err_req._value.get() / total_req._value.get()
    current_availability = 1 - error_rate
    slo_availability.set(current_availability)

start_http_server(9000)

while True:
    simulate_request()
    time.sleep(0.1)

你直接把这个 /metrics 给 Prometheus 抓，就能做 SLA 面板了。

四、SRE 的决策，必须由“错误预算”驱动

这是我一直强调的观念：

错误预算（Error Budget）才是真正决策 SRE 行为的依据，而不是告警。

举个例子：
你承诺 SLA = 99.9%，那么：

• 一个月允许 43.2 分钟不可用
• 如果你已经消耗 30 分钟了，那么：
  → 所有新功能 停止上线
  → 集中修复当前问题
  → 增加监控采样
• 如果一个月才消耗 2 分钟，甚至可以：
  → 放宽某些上线策略
  → 做一些性能试验
  → 允许业务做更激进的优化

这才是 SRE 驱动公司决策的真正价值。

不是维护监控，而是依据错误预算控制风险。

五、SLA 写在监控上的真实例子：

下面举一个实际场景，100% 会遇到。

场景：核心支付系统延迟升高

普通监控体系看到：

• P95 延迟从 80ms 升到 250ms
• 大家慌了：“要不要处理？要不启动应急？”

SLA 体系看到：

• SLA 允许 P95 <= 500ms
• error_budget_remaining = 96%
• 近 24h 错误预算消耗 < 1%

结论：

• 不触发应急
• 继续观察
• 给研发 2 小时排查，不打断业务

也就是说：
延迟升高 ≠ 故障。
超过 SLA ≠ 故障。
消耗完错误预算 = 故障，必须行动。

这就是 SRE 和传统运维的巨大区别。

六、SLA 真正改变的，不是监控，而是团队文化

我见过太多运维团队，每天忙死忙活，告警像过年一样响，但业务的反馈却是：

• “我们不知道系统到底好不好。”
• “你们说恢复了，但用户还是用不了。”
• “问题到底严重不严重啊？”

为什么？
因为监控和 SLA 没关系。

当你把 SLA 写入监控后，变化是这样的：

• SRE 不再处理无意义的小毛病
• 研发知道什么叫“真正的故障”
• 老板能一眼看懂系统健康
• 业务团队知道什么时候该 panic
• 变更上线不再靠拍脑袋

一句话：

SLA 是 SRE 的方向盘，监控是仪表盘，错误预算是油门。

只有三者连在一起，团队才不会开着开着翻车。

七、总结：SLA 写在监控上，是 SRE 的真正成熟点

文章最后总结一句话：

监控告诉你“发生了什么”，
SLA 告诉你“是否重要”，
错误预算告诉你“要不要干预”。

欠缺任何一个，都形成不了真正的 SRE 体系。

你要做的不是打造最复杂的监控，而是打造最有 决策能力 的监控。