MTTR 还是有用的。它告诉团队生产是否足够快地恢复到健康状态。
但这不再是唯一重要的时钟了。
当修复工作流程可以连接可观察性、部署历史记录、代码所有权和人工智能生成的补丁时，一个新的指标就变得实用：审查 PR 的时间。
该指标的含义是什么
PR 审查时间衡量从生产信号到代码所有者可以认真评估的拉取请求的路径。
不是随机生成的差异。不是一个含糊的事件总结。可审查的公关。
这意味着拉取请求包括：
- 引发调查的生产信号
- 可疑的服务、文件、函数或代码路径
- 最近可能相关的部署或更改集
- 集中补丁
- 已运行或应该运行的测试
- 假设和置信度
- 合适的审稿人或所有者
当 PR 准备好做出有意义的工程决策时，该指标结束。
为什么这与 MTTR 不同
MTTR 以结果为导向。公关审查时间是以工作流程为导向的。
MTTR 询问：“我们什么时候恢复的？”
审查时间公关询问：“我们多快达到高质量决策点？”
这种区别很重要，因为许多事件在代码更改发生之前就被延迟了。工程师仍在收集证据、寻找所有权、比较部署或确定问题是否属于另一个系统。
如果团队能够缩短这个阶段，恢复通常会自然改善。即使最终的答案是回滚或升级，决策也会有更好的证据和更少的混乱。
质量吧
该指标仅在“经过审查的公关”意味着严格的情况下才有效。
该指标的不良版本将奖励那些快速打开嘈杂拉取请求的工具。这会造成审查疲劳，并使工程师不信任自动化。
一个好的版本会奖励那些准备充分、范围明确、有证据支持的工作。
PR 应该足够小以供审查，足够清晰以拒绝，并且与生产证据足够相关，以便审查者不必从头开始重建事件。
有用的同伴指标
公关审核时间不应单独存在。将其与质量信号配对：
- 公关接受率
- 审稿人编辑率
- 误诊率
- AI辅助修复后的回滚率
- 合并后重复事件率
- 从 PR 开放到审稿人决定的时间
这些指标共同表明自动化是否节省了时间，或者只是将工作移交给审查。
这对领导者有帮助
工程领导者需要知道事件工具是否可以减少操作阻力。一张显示恢复速度更快的图表很有帮助，但它并不能解释时间都花在哪里了。
PR 审查时间使交接变得可见。它显示了团队是否可以从警报到证据、从证据到代码、从代码到所有权，而无需手动拼接。
它还暴露了薄弱环节。如果 PR 很快开放但未经审查，则问题出在所有权或人员配置上。如果证据花费的时间太长，问题就出在整合上。如果很多 PR 被拒绝，问题就出在诊断质量上。
重点不在于更多的指标
我们的目标不是发明另一个让工程师忽视的仪表板。
目标是使修复质量可见。
当警报触发时，生产错误不会得到解决，当模型编写代码时，它们也不会得到解决。当正确的人能够在正确的证据面前做出自信的决定时，他们就会走向解决方案。
这就是审查公关时间的衡量标准。
