色控传媒

平均還原時間（有時稱為平均復原時間），又稱為 MTTR，是指從故障部署、事件或服務中斷中復原的平均時間。它可測量從偵測事件或中斷到恢復完整系統功能的時間。

MTTR 是高階指標，可協助您測量復原過程的速度，並指出系統從故障中復原的速度。一般而言，MTTR 通常與意外事件相關，而非服務要求。

平均還原時間 vs. 解決時間：有何不同？

平均還原時間是指從产物或服務故障中恢復所需的平均時間，但不包括確保事件不再發生所需的額外時間。

另一方面，解决的平均时间是完全还原系统所需的平均时间，包括解决问题所需的时间，以及完成防止问题再次发生所需的任何额外工作。这可能包括故障侦测、诊断、恢復，以及未来為了强化系统，以对抗类似故障而採取的主动措施。

因此，平均解决时间可全面了解问题解决所需的范围，超越实际停机时间，将团队的责任延伸到只解决问题，以改善系统的长期效能。

如何计算平均还原时间

平均还原时间的计算方式是增加特定期间内的总停机时间，然后除以该期间内的总事件数。

MTTR = 解決期間/事件數量的所有時間總和

例如，想像您的系統在兩週內故障三次。如果第一個事件需要兩小時才能恢復，第二個事件需要四小時，而第三個事件總共需要六小時，共 12 小時，則該兩週期間的 MTTR 將為：

MTTR = 總停機時間 12 小時 / 3 起事件

MTTR = 4 小時

什麼是復原的好平均时间？

系統中斷和停機時間對客戶體驗有很大的影響，因此 MTTR 越短越好。更高的 MTTR 意味著組織及其客戶更有可能經歷重大且頻繁的停機時間，這可能導致投訴、取消和不續訂。

良好的 MTTR 與偵測和辨識問題的根本原因（偵測的平均時間，或 MTTD）的速度有直接關係。識別問題所需的時間越長，系統恢復到完整運作所需的時間就越長。

MTTD 較低是降低 MTTR 並改善其他可靠性指標的關鍵。如果您縮短了偵測問題所需的時間，也可以縮短問題解決的時間。觀察性和持續監控在提醒團隊問題並快速減少 MTTD 方面扮演重要角色。

除了監控之外，還有幾種其他方法可以降低 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 越低越好。為 DevOps 團隊找出四種效能類別：

• 精英：不到一小时
• 高：不到 24 小時
• 中：不到一週
• 低：超过或等於一週

更快的 MTTR 可降低故障率、加快交付速度，並提升使用者滿意度。隨著 DevOps 成熟度的成長，MTTR 應該會越來越低。

您需要哪些工具來監控 MTTR？

為了改善 MTTR，您需要能夠快速偵測系統故障。Prometheus 和 Grafana 等持續監控工具，以及 Datadog 、Splunk 和 Dynatrace 等熱門應用程式效能監控工具，可協助您收集 MTTR 指標。

这些系统使用大量的即时和歷史资料，帮助您更快速地诊断和分析问题。然而，為了支援复杂的查询和即时处理，您需要全快闪储存系统能提供的超高速效能。

色控传媒 提供數個全快閃云端資料儲存方案：，可提供龐大的傳輸量與一致的效能。FlashBlade? 是高效能的檔案暨物件式資料儲存平台，可提供應用程式與監控工具所需的速度與效能，以支援更快速的 MTTD 與 MTTR。

MTTR 之後的下一個指標是什麼？

雖然 MTTR 是您快速應對問題的能力的強大指標，但您還需要監控其他重要的可靠性指標。深入了解另一项关键计算：平均故障前时间（惭罢叠贵）。