MTTR 已不再適合當今工程團隊

隨着人工智能在軟件開發中的廣泛應用，代碼生成和部署速度顯著提升，但傳統的保障措施尚未跟上這一變化。MTTR（平均恢復時間）曾被視為衡量工程團隊應對故障能力的關鍵指標，然而在AI時代，這一指標已暴露出諸多侷限性。

MTTR起源於DORA和SRE方法論，旨在通過快速恢復來減輕故障影響。然而，隨着AI生成代碼的規模和速度不斷增長，MTTR無法有效捕捉AI時代的故障模式，也無法應對自主代理可能帶來的大範圍影響。這促使業界重新思考度量標準：MTTF（平均無故障時間）正成為一個更有價值的替代方案。

MTTF最初用於硬件領域，衡量組件在故障前的平均運行時間。將其引入軟件領域，焦點應轉向客户體驗——即確保客户儘可能少地遭遇負面體驗。文章指出，MTTR的廣泛使用導致了古德哈特定律的典型問題：當指標成為目標，它就不再是好指標。即使團隊誠實追求MTTR的降低，也可能在無意中容忍客户承受故障，將其視為業務成本的一部分。

在AI加速變革的背景下，這一風險更為突出。研究表明，AI工具的採用伴隨了交付穩定性下降7.2%和bug率上升41%。代碼審查成為瓶頸——代碼量激增但審查能力未同步提升，導致大量未審查代碼積壓。與此同時，自主AI代理的任務完成能力每7個月翻倍，潛在bug和故障波及範圍隨之擴大。

文章強調，工程團隊應將度量重點從“恢復速度”轉向“預防故障”，通過預部署審查和運行時分析來確保客户體驗。長期來看，這要求團隊在加速開發的同時，不犧牲代碼質量，並建立能夠反映真實客户影響的指標。唯有如此，才能避免陷入“快速修復但用户體驗持續受損”的循環。