MTTR、MTBF、MTTA是什麼意思：公式與算例

先說結論： MTTR 是故障發生後平均要多久修好或恢復；MTBF 是系統兩次故障之間平均能穩定運行多久；MTTA 是事件出現後平均要多久有人接手。MTTR 和 MTTA 衡量的是支援團隊行動快不快，MTBF 衡量的是系統本身牢不牢靠。寫進合約之前，務必先寫清楚你說的 MTTR 裡的「R」到底是哪一個。

只要看過月度 IT 支援報告，多半見過這三個縮寫排在一起。它們長得像，常被一起引用，也常被用錯。這篇文章逐個說明含義和公式，每個指標配一個小算例，最後講哪些指標適合寫進服務等級協議（SLA），哪些只適合放在報告裡。

定義和公式參考了 Atlassian 的常用事件指標指南，該文給出了各指標的公式，並指出 MTTR 有四種不同含義。我們於 2026 年 10 月 28 日閱讀該文（查證日期：2026-10-28）。下文算例中的數字均為虛構，僅用於說明，並非博迅的實際數據。

MTTR、MTBF、MTTA 分別代表什麼？

三者都是「平均時間」：總時長除以次數，回答的都是「平均下來要多久」，只是各自量的是一次故障生命週期中的不同一段。

MTTA（平均確認時間）： 從告警或工單產生，到有人開始處理為止。
MTTR（平均修復、恢復、響應或解決時間）： 從故障開始（或工單創建）到服務恢復正常為止。問題出在這個「R」上，下一節展開說。
MTBF（平均無故障間隔時間）： 可修復的系統，平均每隔多久出一次故障。

把一次故障想成一條時間線：故障發生、告警觸發、有人確認、有人修復，然後系統一直正常運行到下一次故障。MTTA 量第一段空檔，MTTR 量從故障到修好，MTBF 量兩次故障之間那一長段穩定期。

MTTR 到底是什麼意思？為什麼有四種說法？

MTTR 是三個指標裡被引用最多、定義卻最不統一的一個。Atlassian 指出，這個 R 可以是 repair（修理）、recovery（恢復）、respond（響應）或 resolve（解決），四者互有重疊，但並不是同一種測量。我們的理解如下。

平均修理時間（repair）： 動手修故障花的時間，一般從開始修到修完，包括測試直到系統完全恢復正常，不含發現故障和排隊等待的時間。
平均恢復時間（recovery）： 從故障開始，到用戶重新能用服務為止的整段時間，包含發現、確認、診斷、修復和測試。老闆關心的就是這個版本，因為它等於停機時長。
平均響應時間（respond）： 從第一次告警到系統完全恢復的平均時間，不含告警系統本身的延遲。這是 Atlassian 的定義。
平均解決時間（resolve）： 從工單創建到工單被標記為已解決，含永久性修復和後續跟進。服務檯系統裡報表上的 MTTR 通常指這個。

這四種都不算錯，錯在把含義不同的數字拿來比較。服務商報告「平均 40 分鐘修好」，客戶卻經歷了三小時停機，兩邊說的可能都是真的，只是量的東西不一樣。

實用做法是：數字旁邊一定寫上定義，即從哪個時間點開始計時、到哪個時間點停止，等待客戶回覆的時間算不算。

MTTR 怎麼算？一個算例

公式很簡單：

MTTR = 所有事件耗時之和 ÷ 事件數量

假設一個支援團隊本月處理了五起事件，從工單創建到服務恢復的耗時分別為：

事件 A：45 分鐘
事件 B：90 分鐘
事件 C：30 分鐘
事件 D：240 分鐘
事件 E：15 分鐘

總耗時為 45 + 90 + 30 + 240 + 15 = 420 分鐘，除以 5 起事件，MTTR 為 84 分鐘。

換個角度看同一組數據。按從小到大排序：15、30、45、90、240，中位數是 45 分鐘。五起事件中有四起在 90 分鐘內解決，只是事件 D 拖得特別久，把平均值拉到了 84 分鐘。這個平均值算得沒錯，但容易讓人誤解，因為實際上沒有任何一起事件恰好花了 84 分鐘。

所以我們建議在平均值旁邊同時報告中位數和耗時最長的那起事件。只報平均值的話，一個糟糕的夜晚就能讓整個月看起來很差，一批很快搞定的密碼重置也可能掩蓋一台伺服器的嚴重故障。

MTBF 是什麼意思？怎麼計算？

MTBF 用來衡量可以修復並重新投入使用的設備或系統的可靠性，比如伺服器、防火牆、專線、業務應用。公式：

MTBF = 總運行時間 ÷ 故障次數

算例：監控一台文件伺服器 30 天，即 720 小時，期間故障三次，累計停機 6 小時。

運行時間 = 720 − 6 = 714 小時
故障次數 = 3
MTBF = 714 ÷ 3 = 238 小時

也就是說，這台伺服器平均每運行 238 小時（不到十天）出一次故障。

有兩點要注意。第一，MTBF 需要足夠長的歷史數據，一個月三次故障說明不了未來一年的情況。第二，MTBF 適用於可修復的系統；對更換而不修理的部件，對應的指標是 MTTF（平均失效前時間），Atlassian 也說明了非可修復對象應該用 MTTF。

另外，MTBF 是對一批設備或一段時期的平均，不能預測某一台具體設備何時出故障。別把「238 小時」當成這台伺服器一定能撐 238 小時的承諾。

MTTA 是什麼意思？怎麼計算？

MTTA 衡量響應是否及時。公式：

MTTA = 從告警到確認的總時間 ÷ 事件數量

算例：產生五起事件，工程師接手所用的時間分別是 4、6、10、3、12 分鐘，總計 35 分鐘，MTTA = 35 ÷ 5 = 7 分鐘。

MTTA 低，說明告警能很快送到人手上，而且這個人確實會行動。MTTA 逐漸升高，則是預警信號：隊列過載、告警被忽略，或者值班路由設定有問題。但它不能說明修好要多久。

MTTA 和 SLA 裡的「首次響應時間」很接近，但不完全相同。首次響應是針對每張工單的承諾（例如「每張緊急工單 15 分鐘內響應」），MTTA 則是實際耗時的平均數。團隊可以平均數很漂亮，同時個別工單仍然超時。關於各優先級的首次響應目標是怎麼定的，可以看我們的P1 至 P4 優先級說明。

MTTR 和 MTBF 的區別，以及兩者的關係

兩者是同一枚硬幣的兩面，放在一起可以算出可用性。

MTBF 說明多久壞一次。
MTTR（取「恢復」的含義）說明每次壞多久。

可用性是服務處於正常狀態的時間佔比：

可用性 = MTBF ÷ （MTBF + MTTR）

沿用前面的文件伺服器：MTBF 為 238 小時；3 次故障共停機 6 小時，所以 MTTR = 6 ÷ 3 = 2 小時。可用性 = 238 ÷ （238 + 2）= 238 ÷ 240 ≈ 0.9917，約 99.2%。反過來驗證：720 小時裏正常運行 714 小時，同樣是 99.2%。

由此可以看出兩條改進路徑：讓故障變少，即提高 MTBF，通常靠更好的硬件、補丁、監控和變更管控；或者讓恢復變快，即降低 MTTR，靠更完善的運維手冊、備件、升級路徑和自動化。對中小企業來說，第二條路往往更便宜，也更容易馬上動手。

哪些指標適合寫進 SLA，哪些只放在報告裡？

合約條款和管理報告的用途不同。我們的看法：

逐張工單的響應和解決目標適合寫進 SLA。 它們可以按工單逐一核對，例如每個優先級的首次響應時間和解決時間。博迅在 SLA 頁面公開了這些數字：緊急（P1）工單首次響應 15 分鐘，解決目標 8 個工作小時，尊享服務窗口另提供 24×7 覆蓋。SLA 是什麼一文講了怎麼讀這類數字。
MTTA 和 MTTR 適合放在月報裡。 它們反映趨勢。它們是平均數，只靠一個平均數去設違約條款並不合適。
MTBF 適合放在可靠性或容量評審裡。 它用於基礎設施：哪台防火牆、哪條線路、哪台伺服器總出問題，該不該換。

如果合約確實要用平均數，例如「平均解決時間低於四小時」，就要寫清四件事：計時起點、計時終點、暫停規則（例如等待客戶回覆），以及重大事件是否剔除。缺了這四條，這個數字就無法審計。

開始統計之前，如何先統一定義？

與任何服務商或內部團隊建立報告時，可以按下面的清單來。

說明你所指的 MTTR 是修理、恢復、響應還是解決。
寫明起點時間戳（告警產生、工單創建或故障開始）和終點時間戳（服務恢復、工單解決或工單關閉）。
約定等待客戶、等待供應商或等待已批准變更窗口的時間怎麼處理。
約定按事件還是按工單統計，重複工單和誤報是否剔除。
按優先級分別報告，不要只給一個混合數字，免得 P4 的小請求稀釋 P1 的重大故障。
在平均值旁邊同時給出中位數和最慢的一例。
把定義和數字放在同一份文件裡。

想把這些報告和背後的優先級定義對應起來，可讀嚴重程度與優先級的區別。當故障大到需要單獨流程時，請看重大事件管理流程。關於可用性規劃中的恢復環節，可參考RTO 與 RPO。

在哪裡可以看到博迅公開的服務等級？

我們對各優先級承諾的響應目標在 SLA 頁面公開，頁面上也說明了 8×5 和 24×7 兩種服務窗口。管理型IT外判服務方案與按用戶收費展示了管理型IT外判服務的公開價目，並標明合約訂明的服務時段內緊急事件 15 分鐘首次響應，方便你在聯絡我們之前先做比較。如果想了解哪種服務等級和報告方式適合你的業務，歡迎聯絡我們。