大規模障害の原因分析とは何か

小規模な障害であれば、 「LANケーブルが抜けていた」「ルーティング設定が誤っていた」 といった故障点を修正することで対応を完了できる場合があります。

一方、大規模障害では複数の条件が重なっていることが珍しくありません。

• 誤った設定が投入された
• レビューで設定ミスを発見できなかった
• 試験環境が本番構成と異なっていた
• 監視で異常を検知できなかった
• 冗長構成だったが同じ設定が両系へ反映された
• 切り戻し判断に時間がかかった
• 関係者への情報共有が遅れた

この場合、 「設定ミス」が障害のきっかけだったとしても、 それだけを原因とすると分析が浅くなります。

直接原因・根本原因・寄与要因を区別する

障害原因を正しく説明するには、 すべてを「原因」という1つの言葉でまとめないことが重要です。

まず障害タイムラインを作る

大規模障害では、多数のログや証言をいきなり分析すると混乱しやすくなります。 まず「いつ、何が起きたのか」を時系列へ並べます。

タイムラインの例

タイムラインを作ることで、 「設定変更の直後に経路が減少し、その後アプリケーション障害が発生した」 という因果関係の候補が見えてきます。

証拠を集めて事実と推測を分ける

原因分析では、 「たぶんこれだと思う」という経験則だけで結論を出してはいけません。

仮説を立てたら、ログ・設定・監視データなどの客観的な証拠で確認します。

「事実」と「仮説」を明確に分ける

仮説を事実のように扱うと、 調査が誤った方向へ進む可能性があります。

大規模障害を分析する8ステップ

1. 障害事象と影響範囲を定義する 何が利用できなかったのか、誰にどの程度影響したのかを整理します。
2. 障害タイムラインを作成する 変更、アラート、問い合わせ、判断、復旧作業を時系列へ並べます。
3. 障害発生前との差分を確認する 設定、ソフトウェア、経路、回線、トラフィックなど、 正常時から何が変化したかを確認します。
4. 原因仮説を複数作る 最初から1つに決めつけず、機器・回線・経路・DNS・セキュリティなど 複数の可能性を考えます。
5. 証拠を使って仮説を検証する ログ、設定差分、監視データ、パケットなどで仮説を確認します。
6. 直接原因と根本原因を分ける 「何が通信を止めたか」と「なぜそれを防げなかったか」を分離します。
7. 寄与要因を洗い出す 監視不足、冗長化不足、手順不足など、 障害規模や復旧時間を増やした要因を整理します。
8. 再発防止策と担当・期限を決める 改善案を書くだけではなく、実施責任者と期限まで決めます。

ケーススタディ：経路変更から全社障害へ

障害発生前

Branch
  |
WAN
  |
Core Router
  |
Cloud Connection
  |
Cloud System

Cloud routes: 850 prefixes
Status: Normal

障害発生後

Branch
  |
WAN
  |
Core Router
  |
  X  Cloud routes missing
  |
Cloud Connection
  |
Cloud System

Cloud routes: 12 prefixes
Status: Application unreachable

設定差分を確認する

Before:
permit cloud-prefix-list

After:
deny cloud-prefix-list
permit any

設定変更により、 本来許可する必要があったクラウド向け経路が拒否されていました。

ここで分析を終えてはいけない

「原因：経路フィルターの設定ミス」 と書けば技術的な直接原因は説明できます。

しかし、本当に再発を防ぐにはさらに確認します。

• なぜ誤った設定が作成されたのか
• なぜレビューで発見できなかったのか
• なぜ投入前の検証で検出できなかったのか
• なぜ経路数の急減を即座に検知できなかったのか
• なぜ切り戻しまで20分以上かかったのか

分析結果の例

5 Whysで根本原因を掘り下げる

直接原因が分かった後、 「なぜ」を繰り返して背景を掘り下げる方法があります。

先ほどのケースを例に考えます。

1. なぜクラウドへ接続できなくなったのか？
   クラウド向け経路がルーティングテーブルから消失したため。
2. なぜ経路が消失したのか？
   経路フィルターが対象経路を拒否していたため。
3. なぜ誤ったフィルターが本番へ投入されたのか？
   設定レビューで誤りを発見できなかったため。
4. なぜレビューで発見できなかったのか？
   レビューがコンフィグ内容の確認だけで、 経路広告結果まで確認するルールになっていなかったため。
5. なぜ経路結果を確認するルールがなかったのか？
   過去の変更手順が機器設定中心で作られており、 サービス影響を検証する観点が標準化されていなかったため。

再発防止策の作り方

再発防止策として、 「今後は十分注意します」「ダブルチェックを徹底します」 だけを書くのは不十分です。

技術・プロセス・監視・復旧の複数レイヤーで改善します。

再発防止策は原因と対応付ける

原因分析でよくある失敗

RCA報告書に残す内容

原因分析の結果は、 後から第三者が読んでも障害の全体像を追える形で残します。

技術原因だけでなく業務影響も記載する

たとえば、

だけでは、技術に詳しくない関係者には障害の重要性が伝わりません。

のように、 技術事象 → サービス影響 → 業務影響 の順番で整理すると伝わりやすくなります。

顧客・経営層への説明方法

技術担当者向け

技術担当者には、 原因となった設定、経路変化、ログ、再現条件などを詳細に説明します。

21:07の経路ポリシー変更により、
クラウド向けプレフィックスがフィルタリングされました。

変更前：850経路
変更後：12経路

その結果、各拠点からクラウド接続先への
有効な経路が失われました。

経営層・非技術者向け

経営層へ細かなルーティング設定を説明する必要はありません。

次の4点に絞ります。

1. 何が起きたか
2. どの業務へ影響したか
3. なぜ防げなかったか
4. 今後どう防ぐか

障害原因分析で使われる英語表現

ベンダーとのやり取りで使える表現

自分の言葉で説明する課題