MTTR (平均修復時間)：定義、ヒント、課題

Observability January 08, 2025 Muhammad Raza

どのITサービスでも、可用性と信頼性は最終的にエンドユーザーエクスペリエンスとサービスパフォーマンスの優劣を左右し、その結果、ビジネスに大きな影響を及ぼします。

可用性と信頼性の2つの指標は、このクラウドコンピューティングの時代に特に重要です。クラウドコンピューティングではソフトウェアがビジネスの運営を支えていますが、それらのソフトウェアの多くがサードパーティのベンダーによってサービスとして管理および提供されています。つまり、可用性と信頼性は、ITサービスを提供する上で特に重要なメトリクスとしてその価値が大きく高まっているのです。

では、可用性と信頼性はどのように評価すればよいでしょうか？

サービスの安定性を示すこれらの指標を評価するために重要なメトリクスの1つがMTTRです。このブログ記事では、MTTRメトリクスの概要、計算方法、短縮方法、MTTRを最適化するうえで直面しがちな課題について詳しく説明します。

/ja_jp/blog/fragments/body-xf/it-service-intelligence

MTTRとは

MTTRは、障害メトリクスの1つで、「Mean Time To Repair (平均修復時間)」の略です。システム、機器、プロセスで問題や障害が発生してから修復または復旧するまでの平均時間を示します。「Mean Time To Resolve (平均解決時間)」、「Mean Time To Respond (平均対応時間)」、「Mean Time To Recover (平均復旧時間)」の略として使われることもありますが、特に区別はされません。さらに「Mean Time」の代わりに「Average Time」が使われることもありますが、これも同じ意味で使われます。

MTTRは、組織のITインフラ、システム、機器のパフォーマンスや、ITチームが重大なインシデントに対応する際の効率と効果を評価するための、非常にわかりやすくて便利なメトリクスの1つです。

具体的には、MTTRの値が小さいほど、サービスや本番環境の可用性に影響を及ぼすインシデントに組織がすばやく対応して復旧できていることを示します。MTTRは、障害が起きている状態から障害発生前の許容可能な運用状態に戻すまでの時間に影響する内部機能と外部要因の両方に基づいて変化します。

(MTTRは、インシデント対応について評価するための多数のメトリクスの1つにすぎません。)

MTTRの厳密な違い

MTTRは通常、「R」が何を指すかに関係なく、同じ意味のメトリクスとして使われます。しかし実際には、4つの異なる測定値を含む場合があります。「R」が「Repair (修復)」、「Resolve (解決)」、「Respond (対応)」、「Recovery (復旧)」のいずれでもいくつかの共通項がありますが、厳密には意味が多少異なります。

Mean Time To Resolve：チケットがオープンされてからクローズされる(問題が解決する)までの平均時間を指します。
Mean Time To Respond：新たにオープンされたチケットにITチームが応答するまでの平均時間を指します。
Mean Time To Recover (またはRecovery)：問題の検出から、緩和、解決までにかかった平均時間を指します。このメトリクスはDevOpsプラクティスにおいて特に重要で、DORA (DevOps Research and Assessment)研究プログラムが推奨しているように、DevOpsチームの安定性を測る指標として使われます。

MTTRの重要性

MTTRは、さまざまな状況で使用できる便利なメトリクスです。最も一般的な用途はサービス管理で、契約書で保証されたとおりにサービスがエンドユーザーに提供されているかどうかを評価できます。また、ソフトウェア開発でも役立ち、たとえば、DevOpsの継続的開発のプラクティスでは、ソフトウェア開発の成熟度が高くなるとMTTRが短くなる傾向にあります。

MTTRの計測は、障害が検出された時点から始まります。MTTRには、問題の診断、修復、修復後のテストなど、サービスを復旧して正常な運用状態に戻すまでに必要なすべてのプロセスにかかる時間が含まれます。そのため、MTTRは長いよりも短い方が明らかに望ましい状態です。

MTTRが短いということは、システムの停止が比較的短時間だったことを示します。
逆にMTTRが長いと、ユーザーや顧客がサービスを使えない状態がそれだけ長く続いたことを示します。

顧客とサービスプロバイダー/ベンダーとの間で交わされるほとんどのサービスレベル契約(SLA)には、性能保証の一環として何らかの形でMTTRが規定され、それを超えると重いペナルティが発生する場合があります。ここで重要なのは、MTTRは標準的な修復時間を示すものであり、保証された修復時間ではないという点です。たとえば、MTTRが24時間と記載されている場合、修復が完了するまでに通常それだけの時間がかかるということであり、実際のインシデントは、それより長いことも短いこともあります。

MTTRの計算方法

MTTRの目的は、ビジネスクリティカルなシステムを利用できなかった時間を記録することです。この指標は、ITインシデントの全体的な重大度や影響を分析するために重要です。MTTRの計算式は次のように定義されます。

MTTR = ダウンタイムが発生していた時間/インシデント件数

または

MTTR = メンテナンスにかかった時間/修復件数

影響があったすべてのコンポーネントについて、MTTRには、インシデントが発生した瞬間から運用や可用性が正常な状態に戻った瞬間までの時間が含まれます。

MTTRによる可用性と信頼性の評価

ここでは、可用性は、サービスが正常な状態で運用されている時間の割合を指します。その計算式は次のようになります。

可用性 = (経過時間の合計 - ダウンタイムの合計) / 経過時間の合計

可用性とMTTRは反比例の関係にあります。つまり、システムの信頼性が低下してMTTRが長くなると、サービスが正常に機能している時間が短くなります。

ここでは、信頼性は、サービスが運用状態において期待されるパフォーマンス基準を維持している割合を指します。

信頼性は可用性の属性として使用でき、事前定義したパフォーマンスメトリクスに基づいて、サービスが利用可能な状態と障害が発生している状態を繰り返す中でサービスのパフォーマンスがどのくらい維持されているかを示します。一般的に、サービスの信頼性はそのライフサイクルを通じて低下していき、MTTRの値は上がっていきます。

可用性や信頼性にはさまざまな要因が影響するため、MTTRはコンポーネントによって大きく異なります。故障率は個々のハードウェアやソフトウェアに対して定義された定数項である場合がありますが、可用性を正常な状態に戻せるかどうかは、システム内部の依存関係や、交換部品、代替ツール、代替サービスを確保できるかといった外部的な事情など、さまざまな要因に左右されます。

そのため、MTTRの評価基準は一定ではないことに注意してください。たとえばeコマースの場合、ホリデーシーズンなどの繁忙期に発生するダウンタイムは、閑散期に発生するダウンタイムよりも、機会コストが大幅に上がります。この場合、さまざまなモジュール冗長化を取り入れることで、MTTRを最小限に短縮し、障害発生をほとんど気づかれない規模に抑えることができます。

(関連記事：サイトリライアビリティエンジニアによるシステムの信頼性向上)

MTTRを記録および測定すべき理由

MTTRは、ビジネスパフォーマンスと強い相関関係があります。MTTRとビジネスの運営や成果との関連についていくつか例をご紹介します。

ユーザーエクスペリエンス

予定外のサービス停止はエンドユーザーエクスペリエンスに重大な影響を及ぼします。クラウドを活用する企業にとっては、障害発生の頻度と障害からの復旧時間がダウンタイムの機会コストに直接つながるため、MTTRを把握することが特に重要です。

ユーザーエクスペリエンスとMTTRは反比例の関係にあります。サービス障害からの復旧時間が長くなるほど、エンドユーザーエクスペリエンスへの悪影響が大きくなります。

ダウンタイムコスト

障害の修復やそこからの復旧が長引くほど、ダウンタイムが長くなります。ダウンタイムは以下のような損失につながります。

生産性の低下
収益の低下
顧客満足度の低下

MTTRを短縮すれば、ダウンタイムが短くなり、財務上の悪影響を最小限に抑えられます。

運用の効率

MTTRは、修復と復旧のプロセスがどのくらい効率的であるかを示します。この効率は、ダウンタイムコストに直結します。効率が向上すれば、ダウンタイムが短くなるだけでなく、リソースを有効活用して、運用全体の効率をさらに改善することもできます。

従業員の生産性

ITが中心になっている今日のビジネスでは、MTTRを短縮することが社内のシステムやサービスのパフォーマンスを維持するのと同じくらい重要になります。主要なツールでサービスが中断すれば、従業員の業務効率が低下するか、場合によっては業務を中断せざるを得なくなり、生産性の低下、従業員の不満、収益の損失につながります。

SLAの遵守

今日、顧客とサービスレベル契約(SLA)を結び、その中で最小限のMTTR目標を定める企業は少なくありません。合意したMTTRを維持できなかった場合は、ペナルティを科せられたり、契約違反を問われたりする可能性があります。

MTTRを短縮する方法

MTTRメトリクスの改善は「一度やれば終わり」のプロジェクトではなく、多くのITイニシアチブがそうであるように、反復と見直しが求められる継続的なプロセスです。

優れたMTTRを維持するために継続的に行うべき取り組みをいくつかご紹介します。

監視とアラート

問題を修正するには、その内容、発生箇所、タイミングを知る必要があります。高度なIT監視ソリューションがあれば、リアルタイムのデータを継続的に収集して、システムのパフォーマンスを詳細に理解し、障害に関連するすべてのデータを分析できます。

MTTRは、問題への対応力を示すメトリクスです。そのため、MTTRを短縮するには、アラートの精度と効果を高めることで、重大な問題をチームができるだけ早い段階で察知して、ビジネスに対する影響を最小限に抑える必要があります。

根本原因分析

MTTR改善の第一歩は、その対象となるインシデントを理解することです。重大なインシデントの根本原因分析を徹底することがMTTRを最小化するための鍵です。システムやコンポーネントの障害の原因を理解し、適切な対策の実施、部品の交換、修正プログラムの適用などを通じて問題の再発を防止します。

インシデント対応計画の策定

インシデント対応手順を念入りに作成している組織は、問題に迅速かつ効果的に対応できる可能性が非常に高く、MTTRの短縮につなげることができます。そのためにお勧めなのが、ITサービス管理(ITSM)のアプローチです。全面的なデジタルトランスフォーメーションを済ませた企業であればもっと柔軟に、部門間コラボレーションツールを使用して、インシデントごとに個別の対応を構築したり、具体的なチェックリストを作成したりするといった手法をとることもできるでしょう。

また、多くの組織に役立つのが、インシデント管理の自動化システムです。たとえば、インシデント対応チームの全メンバーに複数のチャネル(電話、テキストメッセージ、メールなど)でアラートを送信して、通知にかかる時間を短縮できます。いずれにしても、インシデント計画を作成するときは、インシデントを誰に通知するか、どのように記録するか、どのような修正手順を実行すべきかを明確にすることが重要です。

ナレッジベース管理

過去のインシデントは単なる可用性グラフ上の落ち込みではなく、今後に向けた教訓を学び、対策を考える機会でもあります。これらのインシデントを正確に記録し、文書に残して、将来同じようなインシデントが発生したときにすばやく参照できるようにすることで、MTTRの短縮につなげることができます。

(関連記事：Splunkを使った超速インシデントレスポンス)

システムの冗長化とフェイルオーバー

クラウドベースのシステムでは、サービスの信頼性と可用性についてSLAで合意した要件を満たすためにレジリエンス強化に取り組んでいる組織も多いでしょう。単一のネットワークノードでは、冗長化がMTTRの短縮につながります。

単一ノードのコンポーネントは信頼性に問題がありますが、モジュール冗長化によって個々のコンポーネントレベルで対策を行えば、さほどコストはかかりません。

モジュール冗長化の導入時には、MTTRとMTTF (平均障害/故障時間)の両方を検討する必要があります。

つまり、信頼性の高いシステムとは、できるだけMTTFが長くMTTRが短くなるように最適化されたシステムと言えます。

MTTRの最適化で直面する課題

MTTRの短縮は継続的に行う必要がありますが、取り組みを進めるほど難易度が上がります。新たな脅威の登場やシステムの複雑化により、サイバーセキュリティは常に適応を迫られ、システムの潜在的な障害点も増えていきます。

しかも、それは氷山の一角にすぎません。MTTRを評価する際に考慮すべき重要な課題をいくつかご紹介します。

複雑さと依存関係

クラウド環境の課題の1つが、クラウドインフラの可視性が低下して管理が行き届かなくなることです。十分なリアルタイム監視データがないと、IT障害の真の根本原因を特定できないこともあります。その場合、MTTRはIT環境の複雑さや依存関係に左右されることになります。

この課題の解決策の1つは、AIを活用したハイパーオートメーションのインテリジェンステクノロジーを導入することです。これにより、監視データの中からプロセスレベルの関連データを抽出するとともに、エンドツーエンドのマルチクラウド環境全体で、システムのパフォーマンスを評価して依存関係を明確にできます。

サードパーティへの依存

サードパーティツールを購入したのには理由があるはずです。しかし、機能の強化、拡張性の向上、内部の人材やリソース不足への対応など、いずれの理由であっても、サードパーティツールが関わる障害はMTTRに大きく影響しがちです。少なくともある程度は外部のサポートチームに頼らざるを得ないことが多く、また、システムやコンポーネントの可視性が大幅に低下するため、サードパーティのコンポーネントで障害が発生すると、必然的にMTTRが大幅に長くなります。

自動化の遅れ

手動での検出とトリアージは、MTTRが大幅に長くなる原因になります。システムに検出と対応の自動化ツールを取り入れて、インシデントをできるだけ早期に解決できるようにすることが重要です。

ユーザーとのコミュニケーション

システム障害を解決している間、顧客は障害の影響を受け続けることになります。障害が発生したサービスやツールによっては、顧客に大きな不便を強いることもあります。障害の発生時に十分な情報が得られないと、顧客はフラストレーションや不満を感じます。根本原因分析に想定以上の時間がかかると、障害の内容や復旧の見込みについて通知するのが難しくなります。

MTTRの評価基準は一定ではなく、大規模な障害が発生したときにユーザーとのコミュニケーションに失敗すると、ビジネスにまで大きな影響を及ぼすことがあります。