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

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

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

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

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

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