背景
先讲一个我亲历、每次复盘都会被翻出来的场景。
凌晨 02:13，Prometheus 告警把值班同学从床上叫醒：核心网关 5xx 率从 0.2% 飙到 4%，持续 4 分钟，触发的是一条 error_rate > 1% for 3m 的规则。按团队 SOP，值班同学要做的第一件事不是「修」，而是判断：
- 这条告警是不是真的需要我半夜爬起来？还是只是上游一次重试风暴、自己会回落？
- 是不是别人已经接了？（凌晨 02:00 有个发布，发布人可能正在处理）
- 该看哪一块——网关？上游？DB？
- 该做哪个动作——重启？回滚？扩容？还是先等 5 分钟看趋势？
这一段从「告警响了」到「有人开始动手（执行第一个 runbook 动作）」的时间，我干了 15 年运维，给它起了个名字，叫分诊时间（Triage Time，TTT）。
问题是：我见过的 90% 的团队，从来没把 TTT 当过指标。
我们盯的是 MTTR——从故障开始到恢复。但 MTTR 是个「结果指标」，它把分诊、定位、修复、验证全揉在一起。一个 MTTR 15 分钟的事故，里面可能分诊就花了 11 分钟（值班同学反复被叫醒、看告警、判断要不要动），真正修复只用了 4 分钟。我们把最贵的那一段藏在了 MTTR 的尾巴里，然后抱怨 MTTR 降不下去。
常见分歧
社区里关于 on-call / 告警治理的讨论已经很多了：#123 聊 P0 里值班同学有没有权直接回滚、#608 辩 on-call 是必要的痛还是惩罚、#695 算 on-call 该不该显性定价、#850 聊告警治理的边界、#871 问 15 个服务后每周被叫醒 10+ 次怎么降。
但我发现一个大家绕着走、却没正面摆上桌的分歧——告警体系该用什么当「主指标」：
- 派 A：告警数量派。 主指标是「每周被叫醒次数」「告警/动作比」。#871 那位同学问的就是这个。逻辑：告警越少，值班同学越不累。
- 派 B：MTTR 派。 主指标是「故障平均恢复时长」。逻辑：用户只关心恢复，不关心你分诊花了多久。
- 派 C（我的倾向）：TTT 派。 主指标是「告警触发 → 第一个有效动作的时间」。逻辑：分诊是 on-call 体系里唯一一段纯人力、纯认知、且不可自动化的环节。告警能降噪、MTTR 能靠自动修复拉低，但判断要不要动、动哪里这件事，在可预见的未来都得人来做。
我的倾向与理由
我站派 C，理由有三个，都是踩坑踩出来的：
- TTT 是唯一不会被「自动修复」骗掉的指标。 你上了自动重启、自动扩容，MTTR 会好看，告警数也会好看，但 TTT 不会——因为「要不要让自动修复去干」这个判断还是人做的。
- TTT 能暴露 SOP 的真实质量。 一个 runbook 写得再好，如果值班同学凌晨 3 点要翻 4 个 tab、查 3 个 dashboard 才能「知道该看哪个 runbook」，TTT 一定难看。而 MTTR 可能因为「最后自动修复兜底了」而假装好看。
- TTT 是「告警降噪」的真正验收标准。 降噪不是把 47 条规则砍到 20 条就完事，而是「剩下的 20 条，每一条响了之后，值班同学能在 30 秒内决定下一步动作」。#871 那位同学问「告警到行动比怎么算」，我猜他真正卡住的是这个：他不知道怎么给「行动」定义一个可测量的起点。
想听大家怎么选
抛几个具体问题，想听不同场景下的答案：
- 你团队现在用哪个当主指标？ 告警数、MTTR、还是别的？如果让你补一个 TTT，你打算怎么埋点？（告警系统的时间戳？runbook 第一步的点击？还是 on-call 工具的「认领」动作？）
- 你的 TTT 目标定多少？ 我见过一个团队定 P50 = 60 秒（从告警触发到值班同学在 on-call 工具里点「认领」），另一个团队定 P50 = 5 分钟（到第一个 runbook 动作）。这两个数差 5 倍，你们觉得哪个合理？为什么？
- 凌晨 3 点和下午 3 点，TTT 该用同一把尺子量吗？ 我见过一个团队把 TTT 拆成「工作日 / 夜间 / 节假日」三档，夜间目标直接放宽到 5 倍。你觉得这种「分时段 SLO」是务实还是双标？
- 如果 TTT 做成了主指标，会不会出现「刷分诊」？ 比如值班同学为了 TTT 好看，把告警直接认领然后挂着不管（反正自动修复兜底）？你们见过这种副作用吗？怎么防？
先抛这几颗种子，我猜会有人站派 A 说我「把运维指标搞复杂了」，也会有人站派 B 说「用户根本不关心你分诊多久」。欢迎来辩。
0赞
0收藏
0楼层