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

# クラウド障害ライフサイクル ## 定義クラウド障害ライフサイクル(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]]) ### 各段階の内容 - **障害発生(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]]) - **ライフサイクル全体視点がAIOpsシステム設計の空白を明示する**: 検知(TTD短縮)→箇所特定(TTI短縮)→緩和(TTM短縮)という段階的改善はいずれも独立したAIOpsタスクとして研究されてきた([[異常検知]]・[[根本原因分析]]・[[障害緩和]])が、ライフサイクル全体の定量化により「緩和フェーズが最も時間的コストが高く、自動緩和の改善ROIが最大」という優先順位の根拠が実測データで与えられた。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) ## 未解決の問い - 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)な観測であり、因果効果の推定は困難。 ## 関連 - ソース: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]] - 概念: [[インシデント管理]] / [[運用障害分析]] / [[根本原因分析]] / [[障害緩和]] / [[障害注入]] / [[オブザーバビリティ]] - エンティティ: [[Xiaoyun Li]] / [[Guangba Yu]] / [[Pengfei Chen]] / [[Sun Yat-sen University]] / [[Bizseer]] - 関連 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)