团队经常谈论生产错误，就好像成本包含在缺陷中一样。发货条件不好。迁移错过了边缘情况。队列使用者重试过于激进。修复代码，成本就结束了。
这个视野太小了。
生产错误的成本不仅仅是导致它的代码行。这是组织围绕它度过的时间。
等待改变了事件的面貌
五分钟内修复的错误通常是代码问题。等待一个小时的 bug 就变成了协调问题。等待一天的错误就会成为信任问题。
相同的潜在缺陷可能会造成截然不同的损害，具体取决于其存在的时间长短：
- 顾客反复走同样的路。
- 支持团队在没有自信答案的情况下收集票证。
- 销售或成功团队开始撰写临时解释。
- 工程师暂停附近的部署，因为他们不确定什么是安全的。
- 更多数据以错误或部分处理的状态进入系统。
- 最初的部署上下文从拥有它的人身上消失了。
这些成本都不是奇特的。它们是正常的生产阻力。
MTTR 会错过一些昂贵的分钟
平均恢复时间很有用，但它可能隐藏了造成最多浪费的时刻。
时钟通常在检测到问题时启动，并在认为服务已恢复时停止。这说明了可靠性的一些重要内容。它不会告诉您事件花费了多少时间来了解故障、寻找所有者、收集证据或等待可审查的更改。
对于修复工作流程，昂贵的差距通常如下所示：
alert -> evidence -> code path -> owner -> patch -> review -> deploy如果团队可以压缩前四个步骤，代码审查就会更早开始，最终的修复也会变得更容易评估。
上下文衰减是真正的成本
最近的代码更容易推理。作者记得为什么会发生这种变化。审稿人记得讨论。功能标志、推出计划和测试假设仍然新鲜。
随着时间的推移，调查变得越来越重。工程师们重新审视他们几个小时前做出的决定。他们重建了部署窗口。他们重新打开仪表板。他们询问该问题是否与另一事件有关。修复可能仍然很小，但合并它所需的信心变得更难建立。
快速修复不仅仅涉及速度。这是为了在团队仍然拥有背景的情况下保留背景。
成本并不总是在工程仪表板中可见
一些生产问题在遥测中看起来并不严重，但仍然损害了业务。
权限错误可能会影响少数高价值帐户。在创建手动财务工作时，计费状态错误可能会显示为低容量边缘情况。结帐问题可能只影响一个地区的一种付款方式，但支持影响可能是立竿见影的。
工程仪表板是必要的，但它们很少捕获整个恢复负担。正确的事件简介应包括客户路径、帐户或租户影响（如果有）、支持信号、代码所有权以及跟踪和日志。
是什么降低了等待成本
当团队在同一循环中进行调查和审查时，可以减少等待成本。
这意味着：
- 警报与相关跟踪和日志相关联
- 失败窗口与部署进行比较
- 可疑的代码路径被命名为
- 所有权自动解决
- 提议的补丁足够小以供审查
- 不确定性是可见的，而不是隐藏在自信的措辞背后
这就是人工智能辅助修复的用处。它不应该秘密改变生产。它应该准备证据，起草最小的合理修复方案，并向所有者提交可以接受、编辑或拒绝的拉取请求。
真正的衡量标准是做出正确决定的时间
一个团队不会因为机器人快速产生差异而获胜。当正确的审稿人能够更快地做出正确的决定时，它就会获胜。
有时这个决定是“合并修复”。有时是“回滚”。有时是“这是上游事件”。有时是“我们需要人工调查，而不是补丁”。
等待的代价是昂贵的，因为它会延迟所有这些决定。目标不是疯狂的自动化。目标是缩短从生产信号到有证据支持的行动的路径。
