MTTR不是復雜軟件系統可靠性和安全性的可行標準

平均解決時間（MTTR）不是衡量復雜軟件系統可靠性或安全性的可行標準，應該被其他更可信的選項取代。以上結論出自Verica近期發布的一份報告，報告辯稱，使用MTTR衡量軟件網絡故障和宕機并不合適，部分原因在于事件持續時間數據的分布，因為此類系統中的故障并不是隨時間均勻出現的。因此，站點可靠性工程（SRE）團隊及其他類似角色應當不再將MTTR用作關鍵指標，應轉而考慮服務水平目標（SLO）和事后數據審查等其他策略。

MTTR指標無法描述系統可靠性

Verica的報告指出，MTTR源自制造業，用于測量修復故障實體組件或設備所需的平均時間。然而，此類設備的運行損耗比較簡單可測，可以采用標準化的MTTR統一評估。“隨著時間流逝，MTTR逐漸用到了軟件系統上，軟件公司將之視為系統可靠性和團隊敏捷性/有效性的指標。”

Verica研究人員預計，MTTR不是復雜軟件系統的恰當指標。“不同于實體制造設備，軟件系統的故障千奇百怪。現代軟件系統運營商經常投入提升其系統的可靠性，卻往往被非預期的意外故障搞得措手不及。”

“MTTR挺有吸引力，因為它似乎能明確標示無法簡單總結的混亂情況，但MTTR的底層數據差異太大，并不能充做系統可靠性的衡量指標。”Verica首席研究員Courtney Nash解釋道，“MTTR也無法告訴我們事件對公司的真正影響，在所涉人員和團隊數量、壓力水平、修復所需技術和組織工作，以及團隊可獲得的經驗教訓方面，每起事件之間差異巨大。”可想而知，取決于響應人員所知或不知，及其風險胃納和內部壓力，同樣的技術環境可能會有很多不同的走向。

基于報告中收集的事件數據，Verica聲稱MTTR無法描述復雜軟件系統的可靠性，并根據?těpán Davidovi?之前發布的SRE事件指標研究成果進行了兩次實驗來測試MTTR的可靠性。結果表明，無論樣本量（如事件總數）如何，減少10%的事件持續時間未必能相應縮短算出的MTTR。“我們的結果還凸顯了事件持續時間數據的極大差異會對MTTR計算結果產生多么顯著的影響。”

MTTR指標的替代方案

報告指出，本就不應該用一個平均數來衡量或代表復雜軟件系統的可靠性。“無論你那（不可靠的）MTTR看起來指征了什么，你仍舊需要對事件展開調查，了解自己的系統到底真正發生了什么。而且，放棄MTTR不僅僅是從一個指標轉向另一個指標，而是一整套思維方式的轉換。”Nash表示，“正如早期的DevOps運動既是技術變革也是文化變革，迎接數據驅動決策并授權員工在必要時付諸變革的企業，會考慮到這種沒用的指標并加以調整。”

Verica在報告中列出了可供替代MTTR的一組指標（大多基于事件分析）：

● SLO/客戶反饋：SLO是服務提供商做出的承諾，承諾自己為用戶提供充分的服務（并在需要時投入增強可靠性以達到這些承諾）。SLO有助于彌合技術系統指標和業務目標，使之成為更有用的可靠性框架。然而，SLO與MTTR存在同樣的弱點，比如缺乏前瞻性、未包含已知風險的相關信息，以及忽略不影響SLO的未遂事件。

● 社會技術事件數據：現代復雜系統是社會技術性的，由代碼、機器和構建并維護這些東西的人組成。但是，團隊往往歷來僅收集技術數據來評估這些系統的表現。報告指出：“社會技術數據的一大豐富來源是Laura Maguire博士研究的協調成本概念。這些數據類型包括事件所涉人員數量、使用的工具、各支團隊，以及并發事件。在你開始收集此類信息之前，你不會知道企業如何實際應對事件（不同于你認知中的做法）。”

● 事后審查數據：評估企業內部/整個企業事件分析有效性的另一方式是跟蹤事后審查信息的參與、共享和傳播程度，包括閱讀簡評和資源參加事后審查會議的人數。

● 未遂事件：重視從未遂事件和實際影響客戶/用戶的事件中汲取經驗教訓是軟件行業又一新做法。“我們從航空業了解到，關注未遂事件可以加深對知識空白、思維模式失調和其他形式的組織與技術盲點的理解。”不過，確定未遂事件的構成因素絕非易事。Verica給出的示例場景包括：“X系統宕機了，但由于Y系統在事件持續或宕機期間提供了緩存或通用內容，用戶并沒有注意到出現了什么差錯。這還算是一起事件嗎？此外，備份故障了，但團隊一個月都沒發現，客戶也沒注意到。這又是不是事件呢？”

“轉變絕非一朝一夕之功，但最終，我們要誠實面對促成因素和人員在提出解決方案上發揮的作用。”Nash表示，“這聽起來很簡單，但需要時間，而這些都是可以建立更好指標的具體活動。”