平均修復時間(MTTR)とは？- MTBFとの違いや計算方法

障害メトリクスとは？

障害メトリクスとは、機器やシステムの信頼性を追跡するためのパフォーマンス指標です。一般的なパソコン関連のサービスリクエスト(ノートパソコンや接続のトラブルシューティング)においても、サーバー障害のように重大な影響を及ぼす可能性のあるコンポーネント動作不良においても使用されます。「障害」という言葉が意味するのは、デバイスやシステムの機能停止(ファイルサーバーのクラッシュなど)だけではありません。システムは動作しているものの、パフォーマンスが低下したので意図的にオフラインにしてあるという場合も含まれます。システムが目的を果たしていない場合はすべて「障害」と呼びます。

よく使用される障害メトリクスは以下のとおりです。

• 平均修復時間(MTTR：Mean Time To Repair)：障害が起きたシステムを修復して回復させるためにかかる平均時間。MTTRは修復可能なコンポーネントやサービスの保守性を示す評価基準です。対象デバイスと問題の複雑度によって、MTTRは分、時間、または日数単位の値になります。(MTTRは平均復旧時間(Mean Time To Recovery)や平均解決時間(Mean Time To Resolve/Resolution)を意味することもあります。)
• 平均障害間隔または平均故障間隔(MTBF：Mean Time Between Failures)：デバイスやシステムの障害が1度発生してから次に発生するまでの平均稼働時間。システムやコンポーネントの信頼性と可用性を予測するために使用されます。システムやコンポーネントの障害と障害の間の正常稼働している時間を追跡することで算出します。
• 平均障害時間または平均故障時間(MTTF：Mean Time To Failure)：MTTFとは、デバイスやシステムに障害が発生するまで予想稼働時間の平均。ITチームは一般的に、このデータを収集するためにシステムコンポーネントを数日または数週間かけて観察します。MTBFと似ていますが、MTTFは通常、バックアップアレイのテープドライブのように交換可能な物に対して使用されます。一方でMTBFは、修復可能な物にも交換可能な物にも使用されます。
• 平均検出時間(MTTD：Mean Time To Detect)：問題が発生してから検出されるまでの平均時間。MTTDが示す期間はITチームがトラブルチケットを受領する時点までであり、この時点からMTTRの計測が始まります。
• 平均調査時間(MTTI：Mean Time To Investigate)：ITインシデントが検出されてから、組織が原因と解決策の調査を始めるまでの平均時間。MTTDからMTTR初期までの期間です。
• 平均サービス回復時間(MTRS：Mean Time to Restore Service)：インシデントが検出されてから、対象システムまたはコンポーネントをユーザーが再び利用できるようになるまでの平均経過時間。MTRSとMTTRの違いは、MTTRが対象物の修復にかかる時間を示すのに対し、MTRSはその対象物が修復された後でサービスが回復するまでにかかる時間を示すという点です。
• 平均システムインシデント間隔(MTBSI：Mean Time Between System Incidents)：連続した2件のインシデント間の平均経過時間。MTBFとMTRSを足すことで算出できます(MTBSI = MTBF + MTRS)。
• 障害発生率または故障発生率：これもよく使用されるメトリクスです。コンポーネントやシステムが障害を起こす頻度の評価基準です。単位時間あたりの障害件数で表されます。

ダウンタイムと、ダウンタイムがビジネスに与える悪影響の可能性に対処するためには、障害メトリクスが不可欠です。障害メトリクスにより、どうしても避けられないシステム障害に対してITチームがより良い計画を立てて対応するために必要な定量および定性的データが得られます。

障害メトリクスを有効活用するためには、具体的で正確なデータを大量に収集しなければなりません。それを人力で行うのは手間も時間もかかりますが、最新のエンタープライズ向けソフトウェアを使用すれば、数回のクリック操作だけで、多様なソースから必要なデータを簡単に収集し、これらのメトリクスを算出できます。

RAM(信頼性、可用性、保守性)とは？

RAMと略される信頼性(Reliability)、可用性(Availability)、保守性(Maintainability)はシステム設計の属性であり、システムのライフサイクルコストと目的達成能力に影響を与えます。そのためRAMは、組織のハードウェア、ソフトウェア、ネットワークに対する安心度を示す評価基準となります。

これらの属性により、システムの強みと弱点が浮き彫りになるだけでなく、その強みや弱点が生産性、顧客満足、さらには組織の最終損益に与える影響も明らかになります。

• 信頼性は、あるシステムが一定期間において障害なく所定の機能を安定して発揮できる確度を意味します。信頼性は製品品質にある程度依存するため、システムの各種コンポーネント(とその設計)に本来備わる特性と言えます。ただし、どのハードウェアやソフトウェアにも障害が起きる可能性はあるので、コンポーネントやシステムの信頼性を測定および予測する場合は、MTBF、MTTF、障害発生率などの障害メトリクスがよく使用されます。
• 可用性とは、システムが必要なときに使用できるよう、設計どおり稼働している確度です。したがって、可用性は信頼性と保守性に依存するものであり、MTBFとMTTRの合計でMTBFを割ることにより算出できます(A = MTBF / (MTBF + MTTR)。
• 保守性は、障害の発生後にシステムやその構成コンポーネントを修復または交換して完全稼働状態に回復させる際の容易さとスピードを表します。システムの保守性はさまざまな要素に依存します。例としては、機器やその設置の品質、IT担当者のスキルや対応可能性、保守および修復手順の適切さと効率などが挙げられます。コンポーネントやシステムの保守性を見極めるために、ベンチマークメトリクスの1つとしてMTTRが使用されます。MTTRが短ければ、保守性が高いと言えます。

RAMを組み合わせることで、システムのアップタイム(信頼性)とダウンタイム(保守性)のパターンや、一定期間におけるアップタイムの割合(可用性)を見極められます。

MTTR(平均修復時間)はなぜ重要か？

MTTRはその名のとおり、ビジネスクリティカルなシステムが使用できない時間を測定するものなので、ITインシデントが組織の最終損益に及ぼす影響を予想する強力な手段となります。ITチームのMTTRが長いほど、ITインシデントが発生した場合に大幅なダウンタイムにつながるリスクが高くなり、ビジネスの中断、顧客の不満、収益の喪失を招くおそれが生じます。

テクノロジーに障害はつきものです。MTTRを把握することで、どれだけ速く効率的に障害に対処して業務を通常に戻せるか予想がつくようになります。一般的に、MTTRの値が低ければ、コンピューティング環境が健全であり、IT業務が良好に行われていると言えます。

MTTRとMTBFの違い

基本的に、MTBFはシステムや機器が障害を起こす頻度を表すのに対し、MTTRは再稼働させるまでのスピードを表します。MTTRとMTBF、これらのメトリクスを組み合わせて使用することで、システムのアップタイム、すなわち可用性を算出できます。予期しないダウンタイムを最小化もしくは回避するには、MTTRの短縮とMTBFの延長の両方を目標にする必要があります。

MTTRの算出(計算)方法

MTTRを算出するには、障害によって発生した合計ダウンタイムを障害の合計件数で割り、計算します。たとえば、あるシステムが1か月に障害を3回起こし、これらの障害によって合計6時間のダウンタイムが発生した場合、MTTRは2時間となります。

MTTR = 6時間 / 障害3件 = 2時間

障害の程度によって、修復は数分で済むことも数日かかることもありますが、ITシステムのMTTRは一般的に時間単位で表されます。

ITILにおけるMTTRとは？

ITIL (IT Infrastructure Library)において、MTTRは主要メトリクスの1つとなっています。ITILとは、ビジネスニーズに整合したITSM (ITサービス管理)を行うためのベストプラクティスを解説した書籍群です。現在はコアとなる5つの書籍があり、ITILのサービスライフサイクルに対応しています。ITILライセンスを現在所有しているAxelos社は、このライフサイクルを「顧客のニーズとIT要件のドライバの特定に始まり、サービスの設計および実施、サービスの監視および改善フェーズに至るまで」としています。

ITILでは、IT業務が複数の測定可能なプロセスに分解されています。プロセスには、サービスカタログ管理、サービスレベル管理、リスク管理、キャパシティ管理、可用性管理、ITサービス継続性管理、コンプライアンス管理、ITアーキテクチャ管理、サプライヤ管理などがあります。

MTTRは可用性管理プロセスに含まれており、このプロセスは「すべてのITインフラ、プロセス、ツール、役割などを合意済みの可用性目標にふさわしいものにすること」を目指しています。多くの場合、MTTRはインシデントおよび問題管理の評価基準として、MTBF、MTBSI、MTRSとともにSLA (サービスレベル契約)に記載されます。

DevOpsにおけるMTTRとは？

DevOpsにおいてMTTRは通常、平均修復時間ではなく、平均復旧時間(Mean Time To Recovery)を意味し、実稼働環境の障害から復旧するまでにDevOpsチームが費やす時間の評価基準として使用されます。DevOpsでは一般的に、ダウンタイムが発生した直近10件のインシデントにおける実稼働環境のダウンタイムの平均として、MTTRを算出します。

DevOpsが成功を収めるため、そして成功を定量化するために、メトリクスは常に不可欠です。MTTRは、アプリケーションに追加された新機能の量、コードの複雑さ、実稼働環境における変動要素の影響を受けることがあるものの、一般的にはチームの能力を示す正確な評価基準となります。DevOpsの導入が進むにつれてMTTRが短くなると理想的です。

DevOpsがビジネスにもたらす好影響を経営陣などのビジネスリーダーに伝える際にも、MTTRが役立ちます。たとえば、生産性の向上やダウンタイムの縮小によって節約できるコストとして示すことができます。

継続的開発におけるMTTRとは？

MTTRは、組織における継続的開発プロセスの安定性の評価基準として使用される値の1つです。

多くの組織にとって、ソフトウェア開発とデリバリーのスピードは、成功を収めるために非常に重要な要因です。強力な継続的デリバリープロセスを実現するには、「構築、測定、学習」というフィードバックループを採り入れることで、たゆまぬ改善とビジネス目標の達成を図ります。

スピードと安定性は継続的開発の基礎となるため、これらを評価して改善するためのメトリクスが不可欠です。継続的開発を監視するための標準化されたメトリクスは存在しません。したがって、どのメトリクスが目標に適しているかを各組織が判断しなければなりません。ただし、継続的デリバリーのパイプラインにおいては、障害に対処するスピードを評価するためにMTTRがよく使用されており、安定性を向上させるための指針となります。

MTTRを短縮する方法

MTTRが長い場合、その要因となる問題の多くは組織によって異なりますが(実際のITプロセスと手続きを詳細に評価することが必要)、MTTRを短縮するために、あらゆるビジネスに有効と思われる一般的な6つのステップがあります。

1. 実際のインシデントを理解：MTTRを短縮するために最初にすべきことは、実際のインシデントと障害をよく理解することです。最新のエンタープライズ向けソフトウェアを使用すれば、サイロ化されたデータを自動的に集約して信頼できるMTTRを計算し、この重要なメトリクスの原因や要因に関する価値あるインサイトを得ることができます。
2. 監視を徹底：問題を解決するためには、まずその問題を特定する必要があります。早ければ早いほど効果的です。適切な監視ソリューションを使用すれば、システムのパフォーマンスに関するリアルタイムデータが常に途切れなく得られ、通常はわかりやすいダッシュボードインターフェイスで一括して表示されます。そして問題が進展した場合にはアラートで通知されます。
3. アクションプランを策定：リソースが十分にない小規模な組織では臨機応変の対応が必要になることも多いですが、大企業ではより厳格な手順や規約に沿って対応すべきです。そのため、多くの場合、従来のITSMの手法を用いて役割と対応を明確に定める必要があります。全面的なデジタルトランスフォーメーションを済ませた企業であればもっと柔軟に、部門間コラボレーションツールを使用して、インシデントごとに個別の対応を構築するといった手法をとることもできるでしょう。どのような計画であっても、インシデントが発生したら誰に通知するか、インシデントをどのように記録するか、解決に向けてITチームが作業を始める際にどのようなステップを踏むかを明確に定める必要があります。
4. インシデント管理の仕組みを自動化：MTTRを短縮するため、インシデントに迅速に対応するためにはまず、問題に関する正確な情報を適切な人員がすばやく得られるようにする必要があります。業務時間中に優先度の低いインシデントが起きた場合は、担当者に電話で知らせれば済むかもしれません。しかし、金曜日の午後8時にWebサイトがオフラインになったら、どうなるでしょうか？各担当者の所在を確認し、手作業で1人ずつ連絡するのは、時間がかかり過ぎます。自動化されたインシデント管理システムならば、電話、ショートメール、電子メールなど、マルチチャネルで、指定しておいた受信者全員にあてて一斉にアラートを送出できるため、時間を大幅に節約可能です。
5. 対応チームと役割を指定：効果的にインシデント管理を行い、MTTRを短縮するためには、役割と責任を明確に定義することがきわめて重要です。サポート組織の編成はビジネスニーズに応じて決まるものですが、ITILでは以下の役割からなるフレームワークが提示されています。
   • インシデント管理者：インシデント管理プロセスを推進し、必要に応じて調整や改善を行う役割です。ITILでは、中小規模の組織の場合は基本的にサービスデスクマネージャーにこの役割を割り当て、大企業の場合は別の役割として定めてもよいとしています。インシデント管理者は、インシデント管理システムの管理とインシデント管理プロセスの実施の主要な責任者です。その他、対応チームのリーダーを務め、KPI (主要業績評価指標)を経営陣に報告し、一次サポートと二次サポートの管理を行います。
   • 一次(レベル1)サポート：この役割は、エンドユーザーがサービス中断を報告する際の単一窓口となります。インシデントを分類し、障害を起こしたサービスをできる限り迅速に回復させるよう努める責任があります。一次サポートで解決できなかったインシデントは、一次サポートグループから適切な二次サポート担当者に転送し、修復アクティビティを監視し、インシデントの状況をユーザーへ随時伝えなければなりません。
   • 二次(レベル2)サポート：二次サポートの技術者は通常、一次サポートよりも高度な知識を持っています。そのため、一次サポートで解決できなかったインシデントの対応に協力することになります。二次サポートの対応者は、通常のサービスを迅速に回復させるために、ソフトウェアやハードウェアのサードパーティベンダーとやり取りする責任もあります。きわめて大規模な環境、複雑な環境、慎重な扱いを要する環境では、さらに高度なスキルと知識を持つ三次(レベル3)サポートグループも必要になる場合があります。
   インシデント対応チームがこのとおりである必要はありません。しかし、どのようにチームを編成する場合でも、インシデント対応を監督しながら、チーム内外の関係者と緊密なコミュニケーションを図るリーダーを指名することと、チームメンバー全員が責任を明確に理解していることが必要です。
6. チームメンバーに複数の役割のクロストレーニングを実施：インシデントチームには、専門的知識を持つスペシャリストの存在がきわめて重要です。とはいえ、比較的軽易な問題までこうしたスペシャリストだけに頼っていると、負担がかかり過ぎます。スペシャリストたちは本来の責務でパフォーマンスが低下し、最終的には燃え尽きてしまうでしょう。インシデントが起きたときにスペシャリストがいなければ、対応チームにとっても痛手になります。

こうした問題を軽減し、ひいてはMTTRを短縮する方法があります。それは、チームメンバー全員がシステムについて深く理解し、複数の職務やインシデント対応の役割を務められるトレーニングを受けておくことです。そうすれば問題が発生したときに誰が電話をとったとしても、今までより効率的に対応できるでしょう。

以上のようなインフラに対する可視性は、より迅速かつ正確に問題を診断するために役立ちます。たとえば、サーバーが受け取るクエリの量とクエリに応答する速度に関するリアルタイムデータがあれば、そのサーバーに障害が起きたとき、すぐにトラブルシューティングを行えます。また、データがあれば、システムコンポーネントの修復作業がシステムのパフォーマンスにどのような影響を与えるか知ることも可能になります。そのため、最適な解決策をより迅速に策定できます。

大企業のITチームは、サービスレベルを上げながらコストを削減することを要求されており、インシデントへの対応時間がきわめて重要になりつつあります。MTTRは魔法の数字ではありませんが、コストがかさむ可能性のある問題に対し、対応と修復を迅速に行えることを示す強力な指標となります。システムのダウンタイムは、生産性、収益性、顧客の信用に直接的な影響を与えます。技術を重視する組織にとっては、MTTRとその効用をしっかり理解することが不可欠です。