MTTRの定義

平均修復時間 (MTTR) とは、インシデント発生後にシステムの機能を復元するために要した平均時間を表す主なパフォーマンス指標 (KPI) のことです。MTTRを他のインシデントメトリックとともに使用すると、DevOpsとITOpsのパフォーマンスを評価する、セキュリティプロセスの有効性を測定する、セキュリティソリューションの有効性を評価する、システムの保守性を測定する、といったことができます。

サードパーティプロバイダーとのサービスレベル契約では通常、MTTRの期待値を設定します。ただし、インシデントによっては複雑度が高いものもあるため、修復時間は保証されません。同じように、さまざまな組織のMTTRを比較してもあまり意味はありません。MTTRは、インフラストラクチャのサイズとタイプ、およびITOpsとDevOpsチームの規模とスキルに関する独自の要因に大きく依存するからです。どの企業も、どのメトリックが自社の目的に最も有用かを判断し、そのメトリックを独自の環境でどのように実務に反映するかを決定する必要があります。

よく使用される各種障害メトリックの違い

今日の企業のシステムは複雑で、障害をもたらす原因はさまざまです。そのため、どの企業の用途にも適した一連のインシデントメトリックというものはありません。選択肢は数多くあり、それぞれに微妙な違いがあります。

平均検知時間 (MTTD)

MTTDは平均検出時間とも呼ばれ、システム障害が始まってから検知されるまでの平均時間を表します。KPIとしての用途は、DevOpsチームが使用するツールとプロセスの有効性を測定することです。

MTTDを計算するには、まず月などの期間を選択し、システムの停止が始まってから検出されるまでの時間を追跡します。次に、時間を合計し、インシデントの数で除算して、平均を求めます。MTTDは低い必要があります。システム障害の検知または検出までにかかる時間が長くなり続ける（上昇傾向）場合は、インシデント対応管理の既存のツールとプロセスをすぐに見直すようにします。

平均識別時間 (MTTI)

アラートがトリガーされた瞬間からサイバーセキュリティチームがそのアラートの調査を開始する瞬間までの営業時間数を追跡する測定指標です。MTTIは、アラートシステムが効果的に機能しているかどうかや、必要な能力を備えた人材がサイバーセキュリティチームに配置されているかどうかを把握するために役立ちます。MTTIの値が高い場合や、MTTIの傾向が誤った方向に進んでいる場合は、サイバーセキュリティチームがアラート疲れに頭を抱えている兆候である可能性があります。

平均復旧時間 (MTTR)

平均復旧時間とは、インシデントが始まってから通常の運用に完全に復旧するまでに要する平均時間を営業時間で表したものです。このインシデントメトリックの用途は、DevOpsチームとITOpsチームの有効性を把握し、チームのプロセスの改善と能力の向上に向けた機会を見出すことです。

平均解決時間 (MTTR)

平均解決時間は、最初のアラート発生からインシデント後の分析までの平均時間で、今後障害が再発しないようにするまでの時間も含まれます。測定の単位は営業時間です。

平均故障間隔 (MTBF)

平均故障間隔は、システムの信頼性と可用性を測定する主なパフォーマンスメトリックです。ITOpsチームは、MTBFを使用して、システムやコンポーネントの中でパフォーマンスが良好なものがどれで、修復や交換の検討を要するものがどれかを把握します。MTBFを把握すると、予防的なメンテナンスを実施してリアクティブなメンテナンスを最小限に抑えること、ダウンタイムの合計時間を短縮すること、およびチームのワークロードに効果的に優先順位付けすることが可能になります。過去のMTBFデータを使用すると、計画メンテナンスに伴うダウンタイムとリソースの割り当てについて的確な意思決定ができます。

MTBFを算出するには、一定の期間にわたって通常どおり運用する過程で発生するシステム障害の間隔を時間数で追跡し、その平均を求めます。

平均故障時間 (MTTF)

平均故障時間は、稼働時間とダウンタイムを比較するための手段です。MTBFは修復可能かどうかに焦点を当てたインシデントメトリックであるのに対して、MTTFは修復できない障害に焦点を当てています。その用途は、システムの寿命を予測することです。MTTFは、どのシステムにも適しているわけではありません。例えば、コアとなるバンキングシステムや多くの産業用制御システムなど寿命の長いシステムは、MTTFメトリックに適した対象ではありません。あまりにも寿命が長いため、いざ交換が必要になったときに、技術の進歩によって交換先のシステムがまったくタイプの異なるものになるからです。そのような場合、MTTFは意味を持ちません。

一方、ごく一般的な寿命のシステムであれば、MTTFを追跡すると、どのブランドのパフォーマンスが最も優れ、どの環境要因が製品の耐久性に最も強く影響を与えるかに関して的確にインサイトを獲得できます。

DevOpsとITOpsにとってのMTTRの利点

MTTRの目的は、計画外のダウンタイムを削減し、ブレイクアウトタイムを短縮することです。その一方で、ITOpsチーム内の文化の質向上を支えるという用途もあります。

ユーザーが影響を受ける前にインシデントが修復されれば、DevOpsとITOpsは効率的かつ効果的に機能していると見なされます。レジリエンスを備えたシステム設計が推奨されるのは、DevOpsのパフォーマンスがMTTRによって測定されることになるとわかれば、DevOpsチームは迅速に修復できるアプリを構築しようとするからです。例えば、1つのサービスで障害が発生してもアプリ全体がクラッシュしないように、複数の個別のWebサービスから入力を受け付けるアプリを開発するなどです。MTTRには（適切に実施した場合）インシデント後の分析が含まれているため、その情報をフィードバックループに反映して、今後のソフトウェアビルドの品質を高め、SDLCプロセスの早い段階でバグを修正できるようにします。

平均修復時間の算出方法

MTTRの計算式は簡単です。単に、特定の時間枠内でシステムの計画外の修復にかかった時間を合計し、その結果を関連するインシデントの総数で除算します。

ただし、すべての障害が同等とは限りません。コンポーネントの障害や顧客向けシステムの停止がピーク時間帯に発生した場合、その修復にかかる時間は、夜中に発生した重大でない停止の修復にかかる時間よりも、売上損失や生産性低下、ブランド毀損という面で影響が大きくなります。組織として「エラー予算」といったものを組み、影響度が最も高いシステムの修復に費やす1分が、影響度の低いシステムの修復に費やす1時間の価値に相当することを明記できます。この粒度レベルにすると、ダウンタイムの真の意味でのコストを明らかにし、特定の組織にとってMTTRがどのような意味を持つのか理解を深めることができます。

MTTRを小さくする方法

MTTRを小さくするための要素が3つあります。

1. 1つ目は、解決プロセスを管理するための明確な戦略です。このプロセスには教訓を得るためのインシデント後の分析を含めるようにします。
2. テクノロジーは言うまでもなく重要な役割を果たします。ソリューションでベストと言えるのは、問題を根絶し、将来の攻撃に対する防御を構築するうえで役立つ可視性、モニタリング、是正メンテナンスを備えたものです。
3. 最後に、インシデントを軽減するために必要なスキルを身につける必要があります。

予算や人材を増やすことでMTTRを小さくできますが、それが常に現実的であるとは限りません。代わりに、人工知能 (AI) と機械学習 (ML) を展開して、修復プロセスのできる限り多くの部分を自動化します。その対象となるステップには迅速な検知、フォールスポジティブの最小化、スマートエスカレーション、自動修復などがあり、これらをワークフローに含めてMTTRが小さくなるようにします。

MTTRはダウンタイムの削減およびDevOpsチームとITOpsチームの合理化に役立つメトリックですが、その改善を最終目標にすべきではありません。結局のところ、メトリックを使用するポイントは単に数値を改善することではなく、システムの稼働を継続し、企業とその顧客を保護するという現実の問題を改善することです。チームが顧客を保護し、システム稼働時間を最適化できるよう、MTTRを活用します。

今日のログ管理ソリューションによるMTTRの改善

SIEMとログ管理のための最高水準のAIネイティブプラットフォーム、CrowdStrike Falcon®プラットフォームでサイバーセキュリティを強化しましょう。ペタバイト規模でのセキュリティログを体験してみてください。クラウドネイティブ型または自己ホスト型での展開が可能です。ボトルネックの生じない、強力でインデックスフリーのアーキテクチャを利用してデータをロギングすれば、1日あたり1PB以上のデータを取り込んで脅威ハンティングに役立てることができます。リアルタイムの検索機能により攻撃者をしのぐスピードで対策を実施できます。複雑なクエリを実行しても、そのレイテンシーは1秒未満です。360度の可視性によりデータを統合してサイロ化を解消し、セキュリティ、IT、DevOpsチームがシームレスに脅威のハンティング、パフォーマンスのモニタリング、コンプライアンスの確保を行うことができます。30億件ものイベントにわたる作業でも1秒未満で実施できます。