クラウド障害ライフサイクル

# クラウド障害ライフサイクル ## 定義クラウド障害ライフサイクル(fault life cycle)は、クラウドシステムで障害が発生してから解決されるまでの一連の段階を指す。[[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]] は 354 件のポストモーテムの分析を通じて、このライフサイクルを **4 段階の TTX(Time to X)指標**で定式化した。 ``` System → Fault Occurrence → [TTD] → Fault Detection → [TTI] → Fault Identification → [TTM] → Fault Mitigation → Running ←————————————————— TTR ——————————————————————→ ``` | 指標 | 定義 | 平均値 | |------|------|--------| | **TTD** (Time to Detect) | 障害発生から最初の検知まで | 16.9 分 | | **TTI** (Time to Identify) | 検知から根本原因特定まで | 77.8 分 | | **TTM** (Time to Mitigate) | 根本原因特定から緩和完了まで | 304.2 分 | | **TTR** (Time to Resolve) | 障害発生から完全解決まで | 572.8 分 | **可用性との関係**: $\text{Availability} = \frac{\text{TTF}}{\text{TTF} + \text{TTD} + \text{TTI} + \text{TTM}}$ 可用性向上には TTF の増大(障害間隔の延長)、または TTD・TTI・TTM のいずれかの短縮が必要となる。DevOps の理想目標は検知 1 分・箇所特定 5 分・緩和 10 分だが、354 件の実測値では達成率が TTD 15.7%・TTI 14.0%・TTM 1.9% にとどまる。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) TTX の各段階は、より基礎的な信頼性用語の連鎖の上に成り立つ。fault(error の推定原因)が error(将来 failure を招きうるシステムの内部状態)を経て failure(オンラインサービスが正しいサービスから逸脱する事象)に至り、failure が顧客に悪影響を与えると incident となる——このとき組織・オペレータの対応行動が要求される。TTD はこの failure(または incident への進行)の検知までの時間、TTI は failure から fault(根本原因)の特定までの時間、TTM は特定された fault への対応(緩和)完了までの時間、と読み替えられる。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 2 Background]] §2.2.1) ### 各段階の内容 - **障害発生(Fault Occurrence)**: 特定の場所・環境下での障害の誕生。根本原因が顕在化する段階。変更(アップグレード・メンテナンス)中が 58.8% を占める - **障害検知(Fault Detection)**: 障害の兆候が異常として検知されエンジニアの注意を引く。93.4% が自動監視ツールを使用 - **障害特定(Fault Identification)**: エンジニアが手がかりを関連付けて根本原因を割り出す。障害は平均 2.3 コンポーネントを伝搬 - **障害緩和(Fault Mitigation)**: 障害を緩和・除去するための手段が適用される段階。9 種類の緩和手段が観測された ## 横断的知見 - **緩和フェーズが TTR の 53% を占め、インシデント管理コストの律速因子となる**: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]] の実測では MTTR=572.8 分のうち MTTM=304.2 分(53.1%)が緩和フェーズ。検知(16.9 分, 3%)と特定(77.8 分, 14%)は相対的に小さい。[[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]] が Microsoft 4 年分データで「T3(最終担当チーム確定後の緩和フェーズ)が TTM の 70% を占める」と報告した構造的事実と整合し、**緩和段の短縮が最も影響の大きい改善ポイント**であることが独立した実証研究で収束している。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **変更(アップグレード・メンテナンス)が障害の主たる誘引であり、発生メカニズムに大きな非対称性がある**: Li+ 2022 は 354 件のうち 58.8% が変更中に発生し、そのうち 84.7% が内部原因(設定ミス・コード変更が主体)と報告。[[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]] が「変更起因インシデントのうちデプロイ中が 76.8%」と示した数値と整合し、**変更プロセス中が最もリスクが高い時間帯**という構造は独立データセットで一致する。通常運行中は外部原因(ハードウェア障害・過剰フロー)が 56.3% を占め、発生メカニズムが変化する。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **自動検知の主流化に関わらず、人手検知なしには半数超のインシデントに気付けない場合がある**: Li+ 2022 の 93.4% 自動検知という高率は、検知情報が記録されている事例に限定される(354 件中 38.7% のみ記録)。[[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]] は変更起因インシデントの 50.6% で利用者がモニターより先に検知したと報告し、[[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] は顧客報告インシデントで TTD が自動検知比 10.7 倍になると定量化した。Li+ 2022 の高い自動検知率は「検知情報を記録できた=自動検知が成功したケース」を反映しており、**検知に失敗したケースほど記録が残りにくいという観測バイアス**がある可能性に注意が必要。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **障害ライフサイクル研究の先行スコープ限定と本研究の全体カバーが異なる洞察を生む**: Gunawi+ 2016(SoCC)・Liu+ 2019(HotOS)・Chen+ 2020(FSE)等の先行研究は障害発生またはその一部の段階に焦点を当て、全ライフサイクルを一貫して追った研究は稀だった(Table I で確認)。Li+ 2022 は発生→検知→特定→緩和の全フェーズを一貫分析することで、「どのフェーズが最もコストがかかるか(TTM=304 分が支配的)」「各フェーズの障害因子がどう連動するか(変更中は内部原因主体、通常運行は外部原因主体)」という全体像を初めて定量化した。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **Li+ 2022 の 4 段階モデル(発生 → 検知 → 特定 → 緩和)を「自律化すべき対象」として個別システムに写像し直した最初のまとまった提案が現れた**: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 1 Introduction]] は、Li+ 2022 と同型のライフサイクル区分を踏まえたうえで、障害発生**以前**(pre-incident, 潜在バグの予防)に [[Rainmaker]] による障害注入テストを、障害特定(Fault Identification)に [[RCACopilot]] による根本原因分析を、障害緩和(Fault Mitigation)に [[Stratus|STRATUS]]・[[Transactional No-Regression]] による安全な緩和を対応づけ、[[AIOpsLab]] をこれら全段階を横断する評価基盤として位置づける。ただし Li+ 2022 のモデルにある「障害検知(Fault Detection)」だけは独立した貢献に対応せず、AIOpsLab のベンチマークタスク内の一評価項目として吸収される――ライフサイクル全体の自律化を掲げても、各段階に必ず 1:1 でシステムが対応づくわけではないことを示す。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]], [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 1 Introduction]]) - **ライフサイクル全体視点がAIOpsシステム設計の空白を明示する**: 検知(TTD短縮)→箇所特定(TTI短縮)→緩和(TTM短縮)という段階的改善はいずれも独立したAIOpsタスクとして研究されてきた([[異常検知]]・[[根本原因分析]]・[[障害緩和]])が、ライフサイクル全体の定量化により「緩和フェーズが最も時間的コストが高く、自動緩和の改善ROIが最大」という優先順位の根拠が実測データで与えられた。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **実務書は「特定」フェーズを独立させず、TTX を3指標(TTD/TTR/TBF)に圧縮する——TTR の終点を「緩和」に固定することで根本原因特定を明示的に切り離す**: [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]] は Li+ 2022 の TTD/TTI/TTM/TTR という4段階モデルに対し、TTD(検知)・TTR(修復=緩和完了まで)・TBF(障害間隔)の3指標に単純化する。本書の TTR は「コード修正が本番投入された時刻」ではなく「応答者が顧客影響を緩和した時刻」を終点と明記しており、これは Li+ 2022 の TTI(特定)+TTM(緩和)を合算しつつ、根本原因の完全な特定・修正(Li+ 2022 でいう修復手段としての「フィックス」)を意図的に指標の外へ追い出す設計である。実務家向けの単純化(3指標)と学術的な精密化(4段階への分解)が同じ現象を異なる粒度でモデル化しており、Li+ 2022 が「緩和フェーズ(TTM)が TTR の53%を占め律速因子」と定量化した知見は、Anatomy 本の TTR がまさにその TTI+TTM を包含する区間であることの裏付けとして読める。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]], [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]]) - **不信頼性の式は Li+ 2022 の可用性の式と構造的に同型だが、「影響(Impact)」という外生変数を明示的に乗じる点で異なる**: Li+ 2022 の Availability = TTF/(TTF+TTD+TTI+TTM) が純粋に時間の比だけで可用性を定義するのに対し、Anatomy 本の不信頼性の式(Unreliability ∝ Σ(TTD+TTR)/TBF × Impact)は同じ時間指標の比に「影響」という係数を明示的に加える。これは、同じ持続時間の障害でも影響の大きさ(ユーザー数・重大度・[[ブラスト半径]])が異なりうるという、時間だけでは捉えきれない次元を式に組み込む拡張であり、[[インシデント影響測定]] が扱う FCI(失敗した顧客とのやり取り数)のような手法が、この Impact 項を定量的に埋める候補になりうる。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]], [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]]) - **博士論文の5段階インシデント管理ライフサイクルは、Li+ 2022 の TTD/TTI/TTM/TTR に「トリアージ」という明示的な段階を割り込ませ、両モデルの粒度差を明らかにする**: 第2章§2.2.4 は、検知→トリアージ→障害箇所特定→緩和→解決の5段階モデルを提示する。Li+ 2022 の TTX は検知(TTD)・特定(TTI)・緩和(TTM)・解決(TTR)の4指標で構成され、両者は「検知」「特定」「緩和」「解決」の4段階では一致するが、博士論文の「トリアージ(重大度・影響度に基づく優先順位づけ)」は Li+ 2022 の時間指標には独立した区間として現れない——トリアージは実務上、検知直後から特定作業の開始までの間に埋め込まれており、TTI(検知→特定 77.8分)の内訳の一部を占めると解釈できる。教科書的な段階モデル(博士論文)が実務プロセスの構成要素を列挙するのに対し、実証研究(Li+ 2022)は測定可能な時間区間だけを指標化するため、プロセス上は存在するがコストとして計測されにくい段階(トリアージ)が実証データの粒度から抜け落ちる、という非対称性が生じる。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 2 Background]] §2.2.4, [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **博士論文は障害箇所特定を明示的にテレメトリデータへ依拠させ、TTX モデルが暗黙に前提としていたデータ依存性を明文化する**: 第2章§2.2.4 は「障害箇所特定は§2.3.1で述べるテレメトリデータを用いて根本原因を特定する」と述べ、インシデント管理ライフサイクルの各段階が[[テレメトリ]]の可用性に直接依存することを明示する。Li+ 2022 は「モニタリングデータの欠如」を検知困難要因の一つとして挙げるにとどまり(オブザーバビリティ概念ページの横断的知見「実本番354件分析」を参照)、TTI(特定)フェーズのデータ依存性までは明示していない。博士論文の記述は、テレメトリのスケーリング課題(計装・保持・分析ワークロードの増大、[[テレメトリ]]概念ページ参照)が TTX の各指標、特に TTI・TTM の実測値にどう影響しうるかという因果的な接続を与える——テレメトリワークロードの増大で分析(障害箇所特定)の計算負荷が上がれば TTI が伸び、逆にテレメトリ削減(特徴量削減等)が奏功すれば TTI が縮む、という関係が示唆される。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 2 Background]] §2.2.4, [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **AI エージェントの推薦品質は、TTX が測る所要時間とは逆方向に段階ごと変動する——検知段階は「速いが確信度が低い」、解決段階は「遅いが確信度が高い」という非対称性がライフサイクル全体を貫く**: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]] の TTX は各段階に要する**時間**を定量化する(TTD 16.9分・TTI 77.8分・TTM 304.2分)が、各段階でどれだけ**確信を持ってアクションを推薦できるか**は論じない。[[ActionNex]]([[@2026__arXiv__ActionNex - A Virtual Outage Manager for Cloud Computing]])は outage ライフサイクルを Detect・Assess・Investigate・Mitigate・Resolve の 5 段階に分けてアクション推薦の precision/recall を測定し、**recall は段階が進むほど上昇し、precision は段階が進むほど低下する**という一貫したパターンを報告した(Detect 段階で precision が最高値・recall が最低値をとり、Resolve 段階にかけて recall がほぼ最高値まで上昇する一方 precision は低下する、Figure 3)。これは、Li+ 2022 が示す「検知は短時間(TTD 16.9分)で完了するが自動化率が高い(93.4%が自動監視)」という所要時間の短さと、ActionNex が示す「検知段階は信号が乏しく確信を持った推薦が難しい(recall 低)」という推薦精度の低さが、**同じ初期段階について異なる軸(所要時間 vs 推薦確信度)で相補的な制約を明らかにしている**ことを示す。TTX が「どの段階を短縮すべきか」を教えるのに対し、ActionNex の段階別精度は「どの段階でAI推薦をどこまで信頼してよいか」を教える——両者を組み合わせると、緩和フェーズ(TTM が支配的でコスト最大)は同時に AI 推薦の precision/recall がともに中程度で安定する段階でもあり、自動化投資の優先順位づけに時間軸と精度軸の両方を使う根拠になる。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]], [[@2026__arXiv__ActionNex - A Virtual Outage Manager for Cloud Computing]]) ## 未解決の問い - DevOps の理想目標(TTD 1 分・TTI 5 分・TTM 10 分)に対して達成率が TTD 15.7%・TTI 14.0%・TTM 1.9% にとどまる原因はどこか。特に TTM の達成率が極端に低い理由は、緩和の種類によって大きく異なる TTM 分布(ロールバック中央値 91 分 vs フィックス中央値 220 分)に求められるか。 - AWS(14 件)・Azure(242 件)・Google Cloud(98 件)のクラウド間で TTX 指標に有意な差異はあるか。Li+ 2022 はクラウド間の比較は行っておらず、ベンダーの運用プロセス成熟度がライフサイクル各段階に与える影響は未定量化。 - TTX 指標は「インシデントが始まってから終わるまでの時間」を事後的に測定するが、「どのアクションがどのフェーズを律速しているか」という**相対的貢献度の分解**はポストモーテムの記述から得られるか。TTM の長さが緩和手段の難しさによるものか、手段の発見の遅れによるものかは分析されていない。 - 2011〜2021 年のデータを元にしているが、クラウドサービスの成熟と自動化の進化(2023〜2026 年)によって、特に TTI・TTM が短縮されているか。AIOps ツールの普及は実際の TTX 指標に現れているか。 - カオスエンジニアリングや障害注入テストへの投資が TTD・TTI・TTM の各段階にどの程度定量的に寄与するか。Li+ 2022 のデータは介入前後の比較ではなく横断的(cross-sectional)な観測であり、因果効果の推定は困難。 - Anatomy 本の不信頼性の式(Unreliability ∝ Σ(TTD+TTR)/TBF × Impact)の Impact 項を、[[インシデント影響測定]] の FCI のような実測ベースの手法で定量化した場合、Li+ 2022 の TTX 実測値(TTD 16.9分・TTI 77.8分・TTM 304.2分)とどのように組み合わさるか。3指標モデル(Anatomy)と4段階モデル(Li+ 2022)を統合した単一の定量フレームワークは構築できるか。 - ActionNex が報告する「段階が進むほど recall 上昇・precision 低下」というパターンは、Li+ 2022 の TTX(検知が最短・緩和が最長)とどう定量的に対応するか。両ソースは異なる outage データセット(Li+ 2022 は AWS/Azure/GCP 354件のポストモーテム横断分析、ActionNex は Azure 8 件の本番 outage)を用いており、同一データセットで TTX とアクション推薦精度を同時計測した研究はまだない。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]], [[@2026__arXiv__ActionNex - A Virtual Outage Manager for Cloud Computing]]) - 博士論文の5段階モデルにおける「トリアージ」は、Li+ 2022 の TTI(検知→特定 77.8分)の内訳のうちどの程度を占めるか。ポストモーテムの記述からトリアージに要した時間だけを分離抽出できるか、それとも実務上は特定作業と不可分に進行するため計測不能か。 - 障害箇所特定(TTI)の所要時間とテレメトリワークロード(計装・保持・分析の負荷、[[テレメトリ]]参照)の増減には因果関係があるか。特徴量削減等のテレメトリ削減手法の導入前後で TTI が実際に短縮したかを定量比較した実証研究はあるか。 - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 1 Introduction]] の 4 システム(Rainmaker・RCACopilot・STRATUS・AIOpsLab)を実運用に投入した場合、Li+ 2022 が実測した TTD 16.9 分・TTI 77.8 分・TTM 304.2 分という各段階の所要時間はどの程度短縮されるか。特に TTM の 53% を占める緩和フェーズに STRATUS の TNR がどれだけ寄与するかは、両ソースとも定量的な TTX 短縮効果としては測定していない。 ## 関連 - ソース: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]] / [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]] / [[@2026__arXiv__ActionNex - A Virtual Outage Manager for Cloud Computing]] / [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 2 Background]] / [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 1 Introduction]] - 概念: [[インシデント管理]] / [[運用障害分析]] / [[根本原因分析]] / [[障害緩和]] / [[障害注入]] / [[オブザーバビリティ]] / [[インシデントメトリクス]] / [[インシデント影響測定]] / [[ブラスト半径]] / [[次善アクション推薦]] / [[テレメトリ]] - エンティティ: [[Xiaoyun Li]] / [[Guangba Yu]] / [[Pengfei Chen]] / [[Sun Yat-sen University]] / [[Bizseer]] / [[ActionNex]] - 関連 MOC: [[SRE - MOC]] / [[AIOps - Failure Detection - MOC]] ## 出典 - [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]](§IV-A TTX 定義・Table III・Fig. 2/3、§IV-C RQ2 Finding 3/4・§IV-D RQ3 Finding 7) - [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]](「Calculating the Impact of Incidents」節、TTD/TTR/TBF の定義と不信頼性の式) - [[@2026__arXiv__ActionNex - A Virtual Outage Manager for Cloud Computing]](§5.3 Figure 3、outage 段階別の precision/recall) - [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 2 Background]](§2.2.1 failure/error/fault/incident の用語定義、§2.2.4 検知・トリアージ・障害箇所特定・緩和・解決の5段階インシデント管理ライフサイクル) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 1 Introduction]](§1 の4課題(予防・診断・緩和・評価)と§1.2 の4貢献(Rainmaker・RCACopilot・STRATUS・AIOpsLab)のライフサイクルへの写像)