# 運用障害分析 ## 定義 運用障害分析（operational failure study / failure data analysis）は、本番システムの障害事後報告や障害追跡データベースを体系的に収集・分類し、障害原因の分布・修復時間・緩和技法の有効性を実証的に明らかにする取り組みである。Gray (1986) の Tandem システム障害研究が嚆矢であり、[[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] がインターネットサービスに拡張した。障害を原因種別（ハードウェア・ソフトウェア・オペレータエラー・ネットワーク・環境等）と場所（フロントエンド・バックエンド・ネットワーク等）の 2 次元で分類し、コンポーネント障害からサービス障害への伝搬率や修復時間 (TTR) を定量化する。目的は、研究・設計の労力をどこに集中すべきかを実データで示すことにある。(Source: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) ## 横断的知見 - **「非コード系根本原因が過半数」という発見は 2003 年の知見を web スケールで更新・拡張する**: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] はオペレータエラーを最大カテゴリ（Online 33%、Content 36%）とし設定ミスが主体と報告した。[[@2022__SoCC__How to Fight Production Incidents]] は Microsoft Teams の 152 件で同様に**コードバグ 27% に対して非コード系 60%** を示す——デプロイエラー 13.2%・インフラ問題 15.8%・依存障害 16.4% は 2003 年の「オペレータエラー」の細分化に対応する。「人間起因の障害が常に過半数」という構造的持続性が、web スケール・10 億人級サービスに対しても成立することを独立に確認した。(Source: [[@2022__SoCC__How to Fight Production Incidents]], [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) - **「緩和の 90% がコード変更なし」は障害分析に「緩和戦略」という新次元を加える**: Oppenheimer (2003) は障害原因と TTR のみを扱い、緩和の種別分布を体系化しなかった。Ghosh et al. (2022) は初めて緩和戦略を 7 カテゴリに分類し、ロールバック(22.4%)・インフラ変更(21.1%)が 90% 超を占めてコード修正(7.9%)が少数であることを示す。「障害を直す」のではなく「障害の影響を速く止める」緩和行動の実態が、同種の実証研究としては初めて定量化された。(Source: [[@2022__SoCC__How to Fight Production Incidents]]) - **多次元相関分析が「単一次元では見えない洞察」を体系化するアプローチとして確立**: Gray (1986) と Oppenheimer (2003) は各軸を独立に集計する単一次元分析に留まった。Ghosh et al. は Chi-square 検定で独立因子を排除した上で「検知失敗 × 根本原因」「根本原因 × 緩和戦略」「緩和失敗 × 教訓」などの多次元相関を分析し、「コードバグの 70% は監視なし → テストが有効」「設定バグの 47% がロールバックで緩和 → 設定変更の多くはテスト可能」など **actionable な洞察**を導いた。この多次元設計は今後の障害データ分析の方法論的な発展として位置づけられる。(Source: [[@2022__SoCC__How to Fight Production Incidents]]) ## 未解決の問い - Oppenheimer et al. (2003) が提唱した「業界横断の障害データリポジトリ」は、20 年以上経った現在も実現していない。クラウドプロバイダごとの障害報告は部分的に公開されるが、標準化されたスキーマによる横断比較は依然として困難である。航空業界の ASRS（Aviation Safety Reporting System）に相当する仕組みはインターネットサービス業界に成立し得るか。 - 2003 年時点でオペレータエラーが支配的であったが、Infrastructure as Code、GitOps、自動化の進展により、現代の大規模サービスでも同じ傾向が続くか。「人間のエラー」の形態が設定ミスからポリシー定義ミスや自動化スクリプトのバグに変容している可能性がある。 - 障害追跡データベースのフォーム入力の不正確さ（オペレータのナラティブとの矛盾）は、LLM による自動分類・構造化で解消し得るか。([[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) - Ghosh et al. (2022) は完全なポストモーテムを持つインシデントのみを分析対象とし、約 35% を除外している。不完全なポストモーテムのインシデントに固有のパターン（例: 前例のない障害で記録が残りにくい）があるとすれば、分析結果にどのような偏りが生じるか。([[@2022__SoCC__How to Fight Production Incidents]]) - Ghosh et al. は Microsoft Teams というコミュニケーションサービス単社の知見を示す。データベース・AI 推論・ストリーミングなど異なる特性を持つクラウドサービスで同様の多次元分析を行えば、根本原因分布や多次元相関にどのような差異が現れるか。([[@2022__SoCC__How to Fight Production Incidents]]) ## 関連 - [[インシデント管理]] — 障害のライフサイクル全体（検知→トリアージ→診断→緩和）を扱うプロセス。運用障害分析はその事後的な知見蓄積に相当する。 - [[根本原因分析]] — 個々の障害の根本原因を特定する技法。運用障害分析は RCA の結果を集約して統計的傾向を導出する。 - [[障害注入]] — 運用障害分析で特定された障害パターンは、障害注入ベンチマークの障害モデルの根拠となる。 - [[障害緩和]] — 運用障害分析は緩和技法の有効性を事後評価する枠組みを提供する。 ## 出典 - [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]