MTTR 已不再适合当今工程团队

随着人工智能在软件开发中的广泛应用，代码生成和部署速度显著提升，但传统的保障措施尚未跟上这一变化。MTTR（平均恢复时间）曾被视为衡量工程团队应对故障能力的关键指标，然而在AI时代，这一指标已暴露出诸多局限性。

MTTR起源于DORA和SRE方法论，旨在通过快速恢复来减轻故障影响。然而，随着AI生成代码的规模和速度不断增长，MTTR无法有效捕捉AI时代的故障模式，也无法应对自主代理可能带来的大范围影响。这促使业界重新思考度量标准：MTTF（平均无故障时间）正成为一个更有价值的替代方案。

MTTF最初用于硬件领域，衡量组件在故障前的平均运行时间。将其引入软件领域，焦点应转向客户体验——即确保客户尽可能少地遭遇负面体验。文章指出，MTTR的广泛使用导致了古德哈特定律的典型问题：当指标成为目标，它就不再是好指标。即使团队诚实追求MTTR的降低，也可能在无意中容忍客户承受故障，将其视为业务成本的一部分。

在AI加速变革的背景下，这一风险更为突出。研究表明，AI工具的采用伴随了交付稳定性下降7.2%和bug率上升41%。代码审查成为瓶颈——代码量激增但审查能力未同步提升，导致大量未审查代码积压。与此同时，自主AI代理的任务完成能力每7个月翻倍，潜在bug和故障波及范围随之扩大。

文章强调，工程团队应将度量重点从“恢复速度”转向“预防故障”，通过预部署审查和运行时分析来确保客户体验。长期来看，这要求团队在加速开发的同时，不牺牲代码质量，并建立能够反映真实客户影响的指标。唯有如此，才能避免陷入“快速修复但用户体验持续受损”的循环。