# How to Fight Production Incidents? — Ghosh et al. (SoCC 2022) ## 概要(日本語訳) 今日の大規模クラウドサービスにおける本番インシデントは、顧客への影響とそれに要するエンジニアリングリソースの両面で極めてコストが高い。継続的な信頼性向上の取り組みにもかかわらず、クラウドサービスはさまざまな根本原因に起因する深刻なインシデントに依然としてさらされており、既存の技法では迅速な検知・緩和が困難なためインシデントが長期化するケースも多い。本研究では、数億人のユーザーが利用する大規模クラウドサービス Microsoft Teams における最近の高重篤インシデント 152 件とその事後報告(ポストモーテム)を詳細に調査する。調査では (a) インシデントの原因と解決方法、(b) 対応遅延を生んだ現行プロセスの問題点、(c) 信頼性向上に貢献しうる自動化の機会 を分析した。さらに、検知・根本原因分析・緩和という異なるトラブルシューティング段を相関させる多次元分析によって興味深い洞察を導き出し、複雑なインシデントへの対処指針を提供する。 ## 論文情報 | 項目 | 内容 | |---|---| | 著者 | Supriyo Ghosh, Manish Shetty, Chetan Bansal, Suman Nath | | 所属 | Microsoft | | 発表 | SoCC '22: ACM Symposium on Cloud Computing, November 7–11, 2022, San Francisco, CA, USA | | DOI | https://doi.org/10.1145/3542929.3563482 | ## 問題設定 大規模クラウドサービスの本番インシデントに関する先行研究は以下の限界を持つ。 - Liu et al. (2019) はコードバグに起因するインシデントのみを対象とし、非コード系根本原因を除外 - Gunawi et al. (2016) は外部公開インシデントのみを収集し、検知・緩和プロセスの詳細が得られない - 複数の段(検知・根本原因分析・緩和)を**横断・相関させた多次元分析**がない 本論文は [[Microsoft Teams]] (2億5千万ユーザー以上)の 2021/5/15〜2022/5/15 の 12 ヶ月間に発生した重篤度 0/1/2 のインシデント 152 件を対象に、エンドツーエンドのインシデントライフサイクルを初めて体系的に分析する。 ## 手法 ### データ収集と分類方法 - 各インシデントについて **6 要因**(根本原因・緩和手順・検知失敗・緩和失敗・自動化機会・レジリエンシの教訓)を手作業でアノテート - オープンコーディング手法による分類体系の構築: 60 件でタクソノミー設計 → 30 件で検証 → 62 件でテスト(コーエンのカッパ係数 0.88〜0.98) - 多次元分析にはカイ二乗検定(有意水準 α=0.05)を使用し、独立因子を排除 ### インシデントライフサイクルの 3 段 1. **検知(Detection)**: 自動監視ウォッチドッグか、ユーザー/パートナー報告か 2. **根本原因分析(Root Cause Analysis)**: OCE(オンコールエンジニア)が根本原因を特定 3. **緩和(Mitigation)**: 手順実行によるサービス健全性の回復 ## 主要な発見 ### 根本原因の分布(Finding #1) | カテゴリ | 割合 | |---|---| | コードバグ | 27.0% | | 依存障害 | 16.4% | | インフラ問題 | 15.8% | | デプロイエラー | 13.2% | | 設定バグ | 12.5% | | データベース/ネットワーク | 10.5% | | 認証障害 | 4.6% | コードや設定バグが 40% を占める一方、インフラ・デプロイ・依存障害など**非コード系が過半数(60%)**を占める。 ### 緩和戦略の分布(Finding #2, #3) | カテゴリ | 割合 | |---|---| | ロールバック | 22.4% | | インフラ変更 | 21.1% | | 外部修正 | 15.8% | | 設定修正 | 13.2% | | アドホック修正 | 11.8% | | コード修正 | 7.9% | | 一時的(自己回復) | 7.9% | **90% 超のインシデントがコード変更なしで緩和**される。緩和に要する時間はロールバック < インフラ変更 < コード/設定修正の順で長くなる。 ### 検知遅延の要因(Finding #7) - 約 55% が自動ウォッチドッグで検知、残り 45% は人手(外部ユーザー 29%・パートナー 10%・自チーム 6%) - 検知失敗 17% が「監視なし」か「テレメトリカバレッジ不足」で、いずれも検知時間を大幅に増加させる - **監視改善**(モニタバグ修正・閾値調整・テレメトリ追加)で自動検知率を 50% 改善できる ### 緩和遅延の要因(Finding #8) - デプロイ遅延: 外部承認 25%・権限不足 25%・変更反映の遅さ 50% - ドキュメント/手順の問題: **TSG の品質不良 50%**(緩和手順が不明確、チームをいつ呼ぶかが不明)、インフラ設定不備 31% - 複雑な根本原因: テレメトリ不足 27%・デバッグ問題 55% ### 多次元分析の主要洞察(Finding #11〜#16) - **検知失敗 × 根本原因**: 「監視なし」インシデントの 70% がコードバグ起因 → コード変更には**監視より自動テスト**が有効 - **根本原因 × 緩和**: 設定バグの 47% がロールバックで緩和(設定修正の 21% より多い)→ 設定変更の多くはテスト可能 - **緩和失敗 × 教訓**: 手動デプロイ遅延の 21% が文書・研修の改善を要求 → TSG の品質指標とドキュメント自動化が有効 - **検知失敗 × 自動化機会**: 監視不能インシデントの 57% がテスト改善を、23% のみが自動アラート改善を要求 ## 実験設定と結果 - 対象: Microsoft Teams、152 件の重篤度 0/1/2 インシデント - コーエンのカッパ係数: 0.88〜0.98(6 分類体系すべてで高い annotator 間一致) - インターアノテータ合意後に完全な分類済みデータセットを構築 ## 考察 ### 本研究の特異性 先行研究がコードバグ・特定障害タイプ・外部公開インシデントのみを対象としたのに対し、本研究は**7 種の根本原因すべて**を含む web スケールのサービスで初めてエンドツーエンドのライフサイクル分析を行う。多次元相関分析により「コードバグを検知するには監視よりテストが有効」「TSG 品質が緩和の律速」などの actionable な洞察が得られた。 ### 制限事項 - Microsoft Teams 単一サービスからの知見であり、他のクラウドサービスへの一般化には注意が必要 - 完全なポストモーテムを持つインシデントのみを対象(約 35% を除外) - Microsoft 固有の予防・自動化ツールが既に多数稼働しており、他社より「残留インシデント」の性質が異なる可能性がある ## 強み/弱点・課題 **強み** - エンドツーエンドのライフサイクル(検知→根本原因→緩和)を初めて統合分析 - 高い annotator 間合意(κ=0.88〜0.98)で分類の再現性が保証 - 多次元相関分析により単一次元分析では見えない洞察を体系化 - 将来研究への具体的な示唆(テスト、TSG 自動化、自動緩和)を提供 **弱点・課題** - 単一組織・単一サービスのデータに基づき外部妥当性が限定的 - ポストモーテム情報の質に依存(35% が除外) - 2022 年時点の知見であり、LLM/AI エージェントによる自動化が普及した現代とのギャップがある ## 関連 - 直接の後継研究: [[TSG自動化]] (FLASH・StepFly・LLexus など) が本論文の「TSG 品質問題」を直接引き継ぐ - 補完的な先行研究: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] (オペレータエラーの支配性) - 最新の GenAI 延長: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] - 関連 MOC: [[LLM4SRE - MOC]] / [[SRE - MOC]] ## 出典 - Supriyo Ghosh, Manish Shetty, Chetan Bansal, Suman Nath. 2022. "How to Fight Production Incidents? An Empirical Study on a Large-scale Cloud Service." SoCC '22, November 7–11, 2022, San Francisco, CA, USA. https://doi.org/10.1145/3542929.3563482