平均復旧時間（平均修復時間と呼ばれることもあります）、または MTTR は、障害が発生したデプロイメント、インシデント、またはサービス停止からのリカバリの平均時間を表します。インシデントや停止の検出から、システムの完全な機能がリストアされるまでの時間を測定します。
MTTR は、リカバリ・プロセスの速度を測定し、システムが障害からどれだけ迅速にリカバリできるかを示す高レベルの指標です。一般的に、MTTR は、サービスリクエストではなく、計画外のインシデントに関連しています。
平均復旧時間と平均解決時間：平均復旧時間と平均解決時間の違い
平均復旧時間とは、製品またはサービスの障害から復旧するのにかかる平均時間のことです。ただし、インシデントが再発しないようにするためにかかる追加時間は含まれません。
一方、平均解決時間は、システムを完全にリストアするために必要な平均時間です。これには、問題を解決し、問題の再発を防ぐために必要な追加作業を完了するための時間が含まれます。これには、障害の検出、診断、リストア、および将来同様の障害に対してシステムを強化するために講じられる積極的な手順が含まれます。
その結果、平均解決時間は、実際のダウンタイムを超えて問題を解決するために必要な全範囲についての洞察を提供し、問題解決だけでなく、システムの長期的なパフォーマンスの向上にもチームの責任を拡大します。
平均復旧時間の計算方法
平均復旧時間は、特定の期間のダウンタイムの合計を、その期間のインシデントの合計数で割って計算されます。
MTTR = 期間／インシデント数を解決するまでの時間の合計
例えば、システムが 2 週間以内に 3 回ダウンするとします。最初のインシデントの復旧に 2 時間かかり、2 回目のインシデントには 4 時間かかり、3 回目のインシデントには合計 12 時間かかりました。その 2 週間の MTTR は、次のようになります。
MTTR = 合計 12 時間のダウンタイム/3件のインシデント
MTTR = 4 時間
平均的な復旧時間とはどの程度が適切なのでしょうか？
システムの停止やダウンタイムは、顧客体験に大きな影響を与えます。そのため、MTTR をできるだけ短くすることが重要です。MTTR が高いほど、組織とその顧客は、重大で頻繁なダウンタイムを経験する可能性が高く、苦情、キャンセル、非更新につながる可能性があります。
優れた MTTR は、問題の根本原因（平均検出時間、MTTD）をいかに迅速に検出し、特定できるかに直接関係します。問題の特定にかかる時間が長ければ長いほど、システムをフル稼働にリストアする時間が長くなります。
低 MTTD は、MTTR を削減し、他の信頼性指標を改善する鍵となります。また、問題の検出に要する時間を短縮することで、問題が解決するまでの時間を短縮できます。オブザーバビリティと継続的な監視は、チームに問題を警告し、MTTD を迅速に削減する上で重要な役割を果たします。
監視の他に、MTTR を削減する方法をいくつかご紹介します。
- 最初のアラートからシステムがフル稼働を再開する時点まで、インシデントの管理方法をチームに知らせる、明確に文書化されたインシデント管理計画を作成します。
- 自動化されたツールを使用して、責任の割り当て、ドキュメントの作成、分析のキャプチャ、構成の管理を行います。
- チームの役割と責任を明確に定義し、割り当てることで、インシデント発生時に何をすべきかを全員が理解できるようにします。
- 過去のインシデントを事後調査し、各問題の詳細、その発生方法、今後の防止方法などを調査し、文書化します。
平均解決時間の計算方法
平均解決時間（MTTR）は、同様の問題が将来発生するのを防ぐために費やされる追加の時間が含まれているため、平均復旧時間とは異なります。
MTTR を計算するには、システムのリストアに要する合計時間を追加します。これには、問題が再発しないようにするための追加時間が含まれ、この数をインシデントの合計数で除算します。次のように考えてみてください。
MTTR = 総インシデントリストア時間 + 問題が再発しないようにするための追加時間 / インシデント数
48 時間で 2 回システムがダウンするとします。最初のインシデントは 1 時間、2 回目のインシデントは 2 時間続きます。その後、チームは、問題の再発を防ぐためにさらに3時間のシステム強化費を費やし、合計 6 時間を要します。
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 が小さいほどよい。Accelerate State of DevOps 2021 レポートでは、DevOps チームの 4 つのパフォーマンス・カテゴリーを特定しています。
- エリート：1 時間未満
- 高：24 時間未満
- 中：1 週間未満
- 低：1 週間以上
MTTR の高速化は、障害率の低下、配信の高速化、ユーザー満足度の向上につながります。DevOps の成熟度が高まるにつれ、MTTR は低下するはずです。
MTTR の監視に必要なツール
MTTR を改善するには、システム障害を迅速に検出できる必要があります。Prometheus や Grafana などの継続的な監視ツール、Datadog、Splunk、Dynatrace などの一般的なアプリケーション・パフォーマンス監視ツールは、MTTR メトリクスの収集に役立ちます。
これらのシステムは、大量のリアルタイムおよび履歴データを使用して、問題をより迅速に診断および分析するのに役立ちます。しかし、複雑なクエリやリアルタイムの処理をサポートするには、オールフラッシュ・ストレージが提供する超高速の性能が必要です。
ピュア・ストレージは、大規模なスループットと一貫した性能を提供する、複数のオールフラッシュ・データ・ストレージ・ソリューションを提供します。FlashBlade は、高速な MTTD と MTTR をサポートするアプリケーションと監視ツールに必要な速度と性能を提供する高性能のファイル/オブジェクト・ストレージ・プラットフォームです。
MTTR に続く次の指標は何ですか？
MTTR は、問題に迅速に対応できることを示す強力な指標ですが、他にも監視すべき重要な信頼性指標があります。もう 1 つの重要な計算方法、すなわち、平均故障間隔（MTBF）について詳しく説明します。
