把延迟数据做成产品

做 SRE 多年后我有个感受：监控面板是工程师的视角，业务看不懂。要让业务也关心"系统健康度"，必须把它做成产品——一个能让人看一眼就知道"今天稳不稳"的东西。本文整理我们怎么把延迟数据做成产品。

为什么要做成"产品"

报表的问题是"被动"——只有出事了才有人看。产品的逻辑是"主动"——它每天在用户面前，状态恶化立刻被感知。把延迟做成产品意味着：

• 业务方有自己的"健康度面板"。
• error budget 是可视的、可消耗的。
• 稳定性成为业务决策的一部分。

监控面板是工程师对自己负责。健康度产品是工程师对业务负责。两者都重要，但后者更稀缺。

SLO 是产品的"地基"

没有 SLO 就没有健康度产品。SLO 的核心要素：

• SLI（指标）：延迟 P99 < 300ms、可用性 > 99.9%。
• SLO（目标）：30 天内 SLI 达标比例 > 99%。
• error budget：30 天允许 7.2 小时不达标。
• burn rate：当前消耗速度，1x = 正好月末耗尽。

把这些数字做成可视化，业务就能直观看到"我们这个月的稳定性余额还有多少"。

产品的三个核心视图

视图 1：余额卡

最简单也最有效。一张卡显示"本月 error budget 剩余 X%"。绿色 = 健康，黄色 = 警戒，红色 = 已耗尽。配一句话："按当前速度，预算将在 X 天后耗尽"。

视图 2：burn rate 时间序列

burn rate 是"预算消耗速度"。1x 表示正好月末耗尽，2x 表示半月耗尽，10x 表示三天耗尽。看这个图比看延迟曲线更直观——它把"延迟"翻译成了"预算"。

视图 3：业务影响卡

把 SLO 翻译成业务语言："今天 P99 超过 500ms 的请求 12000 个，按 5% 转化率损失估算，约影响订单 X 单"。这个数字让产品同学立刻理解严重度。

error budget 的运营化

error budget 不只是看，还要"花"。我们定了几条规则：

1. 预算充足时：可以发新版本、做激进实验。
2. 预算 < 30% 时：发版需要 SRE review。
3. 预算耗尽时：暂停所有非紧急变更，全队投入可靠性。

这套规则让"稳定性"成为业务决策的一部分，不再是 SRE 的事。

multi-window multi-burn-rate 告警

Google SRE 实践里的经典：用多个时间窗口 + 多个 burn rate 阈值，做分级告警。

窗口	burn rate	级别
1h	14.4x	page（立即告警）
5m	14.4x	page
6h	6x	ticket（工单）
30m	6x	ticket
3d	1x	报告
6h	1x	报告

这套规则的好处：快速消耗（1h × 14.4x）立即告警，慢速消耗（3d × 1x）走报告。误报率低，召回率高。

把 SLO 写进开发流程

产品化的最后一步是把 SLO 嵌进开发流程：

• 每个新功能上线前标注"会影响哪个 SLO"。
• 每次发布后 24 小时内看对应 SLO 的 burn rate。
• 每周例会看 SLO 健康度，而不是"事故列表"。
• 每月发"SLO 报告"给业务方。

几个反直觉的经验

• SLO 设得严不是好事。太严的 SLO 让预算经常耗尽，团队疲劳。设到"刚好够用"才是对的。
• error budget 不是"用完就停"。它是"用完就要反思"——为什么消耗这么快，要不要调整 SLO 或投入。
• 不要给所有服务都上 SLO。只给"业务关键链路"上，其他用基础监控。

给团队的简短建议

• 先把 SLO 定下来，再谈产品化。
• 三张视图：余额卡 + burn rate + 业务影响。
• 用 multi-window告警替代单阈值告警。
• 把 SLO 嵌进开发流程，不只是给 SRE 看。

把延迟做成产品，本质上是"把工程语言翻译成业务语言"。这件事做好了，团队对稳定性的认知会从"技术问题"变成"业务问题"——而后者才有持续投入的动力。