平均還原時間（有時稱為平均復原時間），又稱為 MTTR，是指從故障部署、事件或服務中斷中復原的平均時間。它可測量從偵測事件或中斷到恢復完整系統功能的時間。
MTTR 是高階指標，可協助您測量復原過程的速度，並指出系統從故障中復原的速度。一般而言，MTTR 通常與意外事件相關，而非服務要求。
平均還原時間 vs. 解決時間：有何不同？
平均還原時間是指從產品或服務故障中恢復所需的平均時間，但不包括確保事件不再發生所需的額外時間。
另一方面，解決的平均時間是完全還原系統所需的平均時間，包括解決問題所需的時間，以及完成防止問題再次發生所需的任何額外工作。這可能包括故障偵測、診斷、恢復，以及未來為了強化系統，以對抗類似故障而採取的主動措施。
因此，平均解決時間可全面了解問題解決所需的範圍，超越實際停機時間，將團隊的責任延伸到只解決問題，以改善系統的長期效能。
如何計算平均還原時間
平均還原時間的計算方式是增加特定期間內的總停機時間，然後除以該期間內的總事件數。
MTTR = 解決期間/事件數量的所有時間總和
例如，想像您的系統在兩週內故障三次。如果第一個事件需要兩小時才能恢復，第二個事件需要四小時，而第三個事件總共需要六小時，共 12 小時，則該兩週期間的 MTTR 將為：
MTTR = 總停機時間 12 小時 / 3 起事件
MTTR = 4 小時
什麼是復原的好平均時間？
系統中斷和停機時間對客戶體驗有很大的影響，因此 MTTR 越短越好。更高的 MTTR 意味著組織及其客戶更有可能經歷重大且頻繁的停機時間，這可能導致投訴、取消和不續訂。
良好的 MTTR 與偵測和辨識問題的根本原因（偵測的平均時間，或 MTTD）的速度有直接關係。識別問題所需的時間越長，系統恢復到完整運作所需的時間就越長。
MTTD 較低是降低 MTTR 並改善其他可靠性指標的關鍵。如果您縮短了偵測問題所需的時間，也可以縮短問題解決的時間。觀察性和持續監控在提醒團隊問題並快速減少 MTTD 方面扮演重要角色。
除了監控之外，還有幾種其他方法可以降低 MTTR：
- 制定清楚記錄的事件管理計畫，讓團隊知道如何管理事件，從第一個警示到系統恢復完整運作為止。
- 使用自動化工具指派職責、建立文件、擷取分析和管理配置。
- 明確定義並指派團隊角色與責任，讓每個人都知道事件發生時該怎麼做。
- 對過去的事件進行事後調查，並記錄每個問題的具體細節、問題如何發生，以及未來如何預防。
如何計算平均解決時間
平均解決時間（MTTR）與平均還原時間不同，因為它包含了防止未來發生類似問題所花費的額外時間。
若要計算 MTTR，請新增還原系統所需的總時間，包括額外時間，以確保問題不再發生，並將此數字除以總事件數。想一想：
MTTR = 事件復原總時間 + 額外花費的時間，確保問題不會再次發生/事件數
想像一下，您的系統在 48 小時的時間內會停機兩次。第一個事件持續一個小時，第二個事件持續兩個小時。然後，團隊再多花三小時強化系統，防止問題再次發生，總共造成六小時。
MTTR =（1 + 2 + 3）小時 / 2 起事件
MTTR = 3 小時
什麼是解決的好平均時間？
由於減少 MTTD 可縮短平均還原時間，因此相同的動作也會影響完成解決的時間（平均解決時間）。
重點也可以改善團隊實施預防措施的速度。舉例來說，復原流程的平均時間後驗會特別有幫助，因為深入分析問題可以顯示有用的深度資訊，並應用於後續活動。
誰應該使用 MTTR？何時使用？
整體而言，MTTR 是評估數個技術領域中復原流程速度的良好指標。當您想要改善團隊維修資產的平均時間時，應使用 MTTR。
如何在網路安全中使用 MTTR
網路安全的 MTTR 是指團隊在發生網路安全漏洞後，需要花費多少時間才能恢復系統運作。如此一來，您的資安團隊就能以多快的速度將系統退回，並影響客戶恢復正常營運。
在網路安全團隊中，MTTR 時脈通常從團隊因網路攻擊而收到系統故障警示時開始。
恢復過程可能涉及幾個步驟，包括遏制（阻止威脅擴散）、實際消除威脅，以及對系統恢復正常所需的組件和資源進行消毒。所有步驟完成後，系統即視為完全還原。
如何在事件回應中使用 MTTR
MTTR 是事件回應的關鍵指標，因為它能深入了解影響的嚴重性，並協助組織評估停機時間事件是否迅速解決。
在事件回應中，MTTR 是問題回報與解決時間戳之間的平均時間。自動化工具不僅能警示團隊事件，還能協助他們更輕鬆地進行協作和溝通，進而改善 MTTR。
服務層級目標（SLO）和服務層級指標（SLI）也可用於衡量系統可靠性和可用性，以及客戶對產品或服務的大致滿意度。違反 SLO 時，還原服務的平均時間是偵測、減輕和解決問題的總時間，直到再次符合 SLO 規定為止。
如何在 DevOps 中使用 MTTR
在 DevOps 中，MTTR 可以代表生產故障後還原應用程式所需的平均時間。測量 MTTR 有助於團隊確保系統彈性和穩定性，以及判斷可改善回應流程的位置。
在 DevOps 中，測量 MTTR 通常涉及使用監控系統來記錄事件的開始，以及事件的解決時間（例如，在事件到達生產階段後復原變更或釋出的時間）。
MTTR 也可以評估 DevOps 團隊的效能。DevOps 團隊的 MTTR 越低越好。2021 年 DevOps 加速狀態報告為 DevOps 團隊找出四種效能類別：
- 精英：不到一小時
- 高：不到 24 小時
- 中：不到一週
- 低：超過或等於一週
更快的 MTTR 可降低故障率、加快交付速度，並提升使用者滿意度。隨著 DevOps 成熟度的成長，MTTR 應該會越來越低。
您需要哪些工具來監控 MTTR？
為了改善 MTTR，您需要能夠快速偵測系統故障。Prometheus 和 Grafana 等持續監控工具，以及 Datadog 、Splunk 和 Dynatrace 等熱門應用程式效能監控工具，可協助您收集 MTTR 指標。
這些系統使用大量的即時和歷史資料，幫助您更快速地診斷和分析問題。然而，為了支援複雜的查詢和即時處理，您需要全快閃儲存系統能提供的超高速效能。
Pure Storage 提供數個全快閃雲端資料儲存方案：，可提供龐大的傳輸量與一致的效能。FlashBlade® 是高效能的檔案暨物件式資料儲存平台，可提供應用程式與監控工具所需的速度與效能，以支援更快速的 MTTD 與 MTTR。
MTTR 之後的下一個指標是什麼？
雖然 MTTR 是您快速應對問題的能力的強大指標，但您還需要監控其他重要的可靠性指標。深入了解另一項關鍵計算：平均故障前時間（MTBF）。
