平均故障時間（MTTF）とは
平均故障時間（MTTF）は、修理不可能なシステムまたは資産（例：電球）が、障害により動作不可能または仕様外になるまでの平均時間です。
企業はこの信頼性に関する重要業績評価指標（KPI）を使用して、技術部品または機械部品の予想寿命を推定します。
DevOpsでは、MTTFは多くの場合、影響の大きい障害やダウンタイムが発生する前に、サービスがユーザーにとって利用可能である時間の長さを測定する指標となります。
MTTFが低いまたは低下している場合、それは開発者やサイト信頼性エンジニアにとって、インフラストラクチャーやコード、または依存関係が脆弱であり、信頼性を高めるために改善が必要であることの警告となります。MTTFが高いということは、本番環境が重大なインシデントやクラッシュの間で長期にわたって安定していることを意味し、したがってITチームが堅牢なITアーキテクチャーを実行し、ソフトウェア・アプリケーションを安全に提供していることを意味します。
MTTFメトリクスは、平均故障間隔（MTBF）などの他の保守メトリクスとともに、DevOpsチームがネットワーク・ノード、コンテナ、およびマネージド・サービスを含むさまざまなITコンポーネントの容量とライフサイクル計画を改善し、予期せぬ障害の可能性を減らす上で役立ちます。
これらのメトリクスにより、企業はリリース全体にわたる機器の信頼性も追跡できるため、コード、Infrastructure as Code（IaC）、構成の変更によって、単にシステムの出荷を迅速化するだけでなく、システムのレジリエンスが向上するかどうかを判断できます。
MTTFは、同一品目の母集団の故障までの平均稼働時間を表します。最も単純な形式では、MTTFはすべての資産の合計稼働時間を資産の故障の合計数で割ります。
「合計稼働時間」は各品目が故障するまで（または観測が停止するまで）の寿命の合計であり、「故障数」は実際に故障した品目の数です。
MTTF = 全品目の合計稼働時間 / 故障の合計数
コンテナ・クラスターを例にとってみましょう。
コンテナは、通常は修復されない一時的なインスタンスです。コンテナがクラッシュしたり、異常が発生した場合、コンテナ・オーケストレーション・ツール（Kubernetesなど）はそのコンテナを破棄し、新しいコンテナをスピン・アップします。
50個の同一のアプリケーション・コンテナでステートレスなWebサービスを実行しているITチームは、各コンテナの実行時間（作成から障害まで）を測定し、それを失敗したコンテナの数で割ることでMTTFを計算できます。アセスメントの結果、チームは50個のコンテナのグループが合計200時間実行され、その過程で5個のコンテナに障害が発生したことを発見しました。
MTTF = 200時間の稼働時間 / 5回の故障 = 40時間
このクラスターのコンテナのMTTFは40時間です。
MTTFは実際のユースケースにおいて完璧かつ正確な公式ではないため、DevOpsチームは一般的にコンポーネントの耐久性の近似として、また他のインシデント管理KPI（たとえば 平均修理時間（MTTR）やMTBF）の文脈で使用します。MTTFはこの場合、チームがコンテナ・クラスターに毎日何回の再起動が必要になるかを見積もる際の参考にすることができるため、クラスターのサイジングと自動スケーリングのリソースを適切に割り当てることができます。
ただし、故障データや運用データが正確であればあるほど、またチームがより多くのデータを含めるほど、MTTFの計算はより正確になります。
IBMニュースレター
The DX Leaders
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
ニュースレターは日本語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。
MTTFを追跡することで、チームはシステムの信頼性を定量化し、資産管理について情報に基づいた意思決定を下すことができるため、より適切な計画を立て、よりレジリエントな設計とプロセスを推進できます。これは、企業が以下を優先する上で役立ちます。
MTTFは、故障が発生するまでの資産の寿命を明確かつ数値的に把握するため、チームは事例に頼るのではなく、客観的に信頼性を評価することができます。
MTTFはまた、コンポーネントまたはサービスの固有の信頼性をMTTRから分離します。MTTRは、システムの問題が発生したときに、チームがどれだけの速さで修正できるかを測定します。あるサービスのMTTFが低下する場合、設計や依存関係におけるより深い問題（例：ライブラリの不良）を示すことがよくあります。チームはこれらのシグナルを使用して初期トラブルシューティングを開始し、システム障害の根本原因を特定できます。
障害メトリクスを長期にわたって追跡することで、チームは脆弱なサービスを特定し、改善事項に優先順位を付けて、将来のインシデントの頻度を減らすことができます。
MTTFモニタリングは、企業が保守管理の実践を最適化し、問題解決に対してより事前対応的なアプローチをとるのに役立ちます。
時間ベースまたはアドホックな保守作業（「毎週日曜日にサービスXを再起動」など）の代わりに、チームは観察されたMTTFを使用して、典型的な障害時間帯の前に保守をスケジュールできます（「一般的な障害発生時間の80%でポッドをリサイクルする」）。
実際、ITマネージャーと保守チームは、MTTFベースの明確なガイダンスに従ってランブック（ITタスクを完了するための詳細な指示セット）をエンコードできます。たとえば、「サービスXが通常のMTTFよりも長く稼働していて、早期警告シグナル（エラー、レイテンシー）が見られる場合は、重大な障害が発生するのを待つのではなく、事前にサービスを停止して再起動する」などのタスク・プロンプトを含めることができます。
インシデント管理において、MTTFは欠陥の検出から完全なシステム障害までの平均時間を表すことができ、システムが劣化した状態または安全でない状態で稼働し続ける可能性がある時間の長さを示します。この劣化期間を知ることで、チームはコンポーネントがシャットダウンする前に、修正プログラムを実装するまでに数分、数時間、または数日の猶予があるのかを判断できます。
また、インシデントの重大性を軽減する上でも役立ちます。ITスタッフは、予期しない障害が発生したときに混乱することなく、事前に計画、テスト、リソースを割り当てたスワップまたはフェイルオーバーを実行できます。
MTTFをDevOps KPIに組み込むと、ITチームは配信速度のみに重点を置くのではなく、信頼性と正常なデグラデーションに配慮した設計を行うように契機を得ることができます。チームはコンポーネント間でMTTFを比較して、パフォーマンスの低いコンポーネントの置き換えやサービスの再設計など、アーキテクチャー面での行動選択に役立つ情報を得ることができます。
MTTFを観察することで、ITアーキテクトは冗長性が必要な箇所を判断できます。たとえば、重要なサービスのMTTFが低い場合、正常に実行するには、レプリカ、フェイルオーバー・クラスター、または回路ブレーカー（サービスが失敗したオペレーションを繰り返さないようにする）が必要になる可能性があります。
MTTFは、サービスを組み合わせるためのガイダンスとなるメトリクスもアーキテクトに提供します。アプリケーションがMTTFの低い依存関係（障害の発生頻度が高い）に依存している場合、DevOpsチームはそれらを切り離すか、フォールバック・パスを追加することで、サービス全体で連鎖的な障害の発生を防ぐことができます。
MTTFは、「脆弱に感じる」というあいまいな不満を測定可能な信頼性リスクに変え、優先順位付けと対処を可能にすることで、DevOpsチームが技術的負債を優先順位付けできるよう支援します。MTTFデータを使用して、MTTFとインシデントの影響によって順序付けされた信頼性バックログを作成できるため、リファクタリング、再設計、依存関係のアップグレードは、システムの安定性を最も損なわせることが明らかな領域をターゲットにすることができます。
さらに、MTTFデータを使用すると、サービスが破損する頻度と、それが時間の経過とともにどの程度のダウンタイムやユーザーの混乱を引き起こすかを示すことで、企業は技術的負債をビジネス上の結果に結び付けることができます。これにより、エンジニアは技術的債務の解消についてエビデンスに基づいた議論を行えるようになります。直感に頼るのではなく、「このモジュールはN日ごとに故障し、インシデントのX％を引き起こしている」と言うことができ、リーダーシップや製品チームの共感を得やすくなります。
SLOは、特定のサービスに対して、特定の期間にわたって合意されたパフォーマンス目標です。これらは、サービスの期待される状態を定義し、システムの変更に関する意思決定を合理化する上で役立ちます。
可用性SLOは、サービスの許容可能なダウンタイム期間（エラー・バジェットと呼ばれる）を決定します。エラー・バジェットは、企業がイノベーションと安定性のバランスを取る上で役立つように設計されています。バジェットが健全であれば、チームは安全に機能の提供に優先順位を付けることができます。ほとんど使い果たされている場合は、信頼性に焦点を当てる必要があります。
MTTFの低いサービスはエラー・バジェットをすぐに消費し、SLOが現在の設計に対して非現実的であるか、ITチームがサービスの信頼性を向上させてMTTFを引き上げる必要があることを示しています。
MTTFとMTBFはどちらも、設備が動作する期間を表す信頼性メトリクスですが、適用される資産とライフサイクルの種類が異なります。MTTFはコンポーネントの最初の故障までの平均時間を表しますが、MTBFは故障サイクル間の平均時間を表します。
MTTFは、修復不可能な資産が永久的に故障（資産の交換が必要）するまでの平均稼働時間を推定します。1回の故障イベントでコンポーネントの有用寿命が終わると想定します。
MTTFは、ストレージ・ディスク、中央処理装置（CPU）やケーブルなど、完全に交換されるハードウェア・コンポーネントに適用されます。また、コンテナやマイクロサービスなどのソフトウェア・コンポーネントにも適用されます。これらのコンポーネントは、その場で修理されるのではなく、最終的には新しいバージョンや別のサービスに置き換えられます。
MTBFは、サーバー、ネットワーク・コンポーネント、ソフトウェア・コードなどの修理可能な資産の連続的な障害の間の平均時間を測定します。これらの資産は、故障後に修理され、サービスに復帰します。設備が故障し、修理され、その後再び故障すると想定するため、システムの有用寿命は複数の「故障→修理」サイクルで構成されます。
MTTFメトリクスとMTBFメトリクスを組み合わせることで、ITチームがインシデントとITサービス管理にアプローチする方法についての参考情報が得られます。
多くのアーキテクチャーでは、大規模、複雑かつ修復可能なシステム（MTTFで追跡）に修復不可能なコンポーネント（MTBFで追跡）が組み込まれているため、MTTFは、内部メカニズムによって大規模なシステムのMTBFの一因となる障害が発生する時期をチームが予測する上で役立ちます。
オブザーバビリティー・データから、小売アプリケーション内の支払い処理マイクロサービスのMTTFが1,000時間で、その後重大なメモリー・リークによって回復不能なクラッシュを引き起こすことが明らかになっていると仮定しましょう。DevOpsチームは、マイクロサービスの再起動を800時間でスケジュールして自動化し、アプリケーションのMTBFの急落を引き起こす連鎖的な障害を防ぐことができます。
したがって、修理不可能なマイクロサービスを先制的に交換することで、アプリケーション全体の信頼性が直接的に向上します。
どちらのメトリクスも、可用性と保守計画の基盤にもなります。MTTFは在庫管理と交換部品の在庫に関する決定をサポートし、MTBFは予防保守スケジュールと予想される中断頻度に関する決定をサポートします。
MTTR、MTTF、MTBFなどの修理時間メトリクスを併用することで、プランナーはシステムの稼働時間を見積もり、スペア・パーツの予算を立て、ITシステムを微調整して最適な信頼性を実現できます。
資産のMTTFを向上させるプロセスは、対象のシステム、その依存関係、それが運用されるより大きなDevOpsエコシステム、およびより広範なビジネス目標により大きく異なります。ただし、次のような特定のキー・プラクティスを伴う傾向があります。
- 継続的な監視。ITチームは、監視ツールとオブザーバビリティー・ツールを使用することで、性能と信頼性の逸脱をリアルタイムで追跡し、軽微な問題がシステム障害を加速させる事態を防ぐための対策をデプロイできます。
- 予防保全。定期的な検査を実施し、システムの保守を事前対応的にスケジュールすることで、チームは障害率を減らし、ITサービスの平均寿命を延ばすことができます。
- 堅牢なテスト・プロトコル。包括的で自動化されたテスト手法により、チームはデプロイメント前（そしてエンドユーザーに影響を及ぼす前）にソフトウェアの欠陥を発見できます。ほとんどの高品質な継続的インテグレーション/継続的デリバリー（CI/CD）パイプラインやツールは、ソフトウェア開発ライフサイクル全体を通じてテストを統合しています。
- 冗長性戦略。多くの企業は、単一障害点を排除し、チームが障害の影響を軽減できるように、負荷分散のためのレプリカ、マルチリージョンITアーキテクチャー、コンテナ・オーケストレーション・ツール、データ複製プロセスに依存しています。
参考情報
AIとオートメーションの力を活用することで、問題がアプリケーションスタック全体でプロアクティブに解決します。
DevOpsソフトウェアとツールを使用して、複数のデバイスや環境でクラウドネイティブ・アプリを構築、デプロイ、管理します。
ビジネスの俊敏性と成長を加速—IBMのクラウド・コンサルティング・サービスを利用して、あらゆるプラットフォーム上のアプリケーションを継続的にモダナイズしまします。