X止まって大混乱、クラウドが重すぎる…被害を拡大させないIT運用「たった1つ」の考え方(2/2)

連鎖障害を起こす起点と増幅点

　連鎖障害は「1つの根因」よりも、「起点」と「増幅点」を押さえると再現性が高い。起点は最初に異常が出る場所で、増幅点は影響を広げる経路だ。

　2025年の事例を教材にすると、起点は大きく4つに分けられる。

　第1はエッジ（CDN、WAF、DNS）で、ここが揺らぐと多くのサービスの入口が同時に狭まる。第2はコントロールプレーン（設定配布、API、管理画面）で、運用者が直せない状態が長引きやすい。第3はアイデンティティ（SSO、認証基盤）で、可用性が高く見えても単一点になりやすい。第4は観測（監視SaaS、ログ基盤）で、障害そのものより「判断不能」が被害を大きくする。

　増幅点は3つが多い。第1は依存関係の見落としで、ユーザー向けサービスだけでなく、デプロイ、課金、サポート、通知といった周辺系が同じ基盤に乗っていると、障害時に逃げ道がなくなる。

　第2は変更の伝播方式で、段階展開できるものと全域一括で入るものが混在していると、リスク評価が外れる。Cloudflareの事例でも、第1の変更は段階展開だった一方、第2の変更は数秒で全体に広がる方式だった。

　第3は観測の遅延・欠損で、メトリクスが遅れたり欠けたりすると、復旧に向けた判断が遅れる。監視SaaSの稼働状況ページでは、イベント処理の遅延によりストリームやウィジェットに遅延や欠損が出る可能性があると説明する事例もある。監視が遅れれば、障害の初動は必ず弱くなる。


　この4つの起点と3つの増幅点を、自社のアーキテクチャー図に当てはめるだけでも、連鎖の起こりやすさは見えてくる。重要なのは、起点をゼロにすることではなく、増幅点を減らして「失敗しても小さくする」ことだ。

明日から効く連鎖遮断の実装レシピ

　連鎖遮断の実装レシピは3段階で考えると現場で使いやすい。

　第1は切り離しで、外部依存を境界で分ける。具体的にはタイムアウト、リトライ上限、サーキットブレーカーをそろえ、依存先が不安定なときに自分も巻き込まれないようにする。

　第2は縮退で、機能を落としてもコア体験を維持する。たとえば、決済の代替、検索の簡易化、画像の遅延表示など、事前に「落とす順番」を決める。

　第3は第2監視系で、主要SLI（Service Level Indicator：サービス品質指標）だけでも別経路で見えるようにすることだ。監視SaaSやログ基盤が遅れる局面では、外形監視や最小メトリクスが最後のよりどころになる。

　変更管理は、コード以外に範囲を広げる必要がある。Cloudflareは、脅威対策や設定配布のような迅速さが求められる変更にも、段階展開、健全性検証、迅速なロールバックといった安全策を持ち込む方針を示している。

　これは一般のIT企業でも再現できる。設定はGitで管理し、適用は小さな単位に分割し、異常検知の条件を先に決め、戻す手順を自動化する。

　全域一括でしか反映できない仕組みが残るなら、適用前に「失敗したときに何が起きるか」を机上で列挙し、最悪ケースを許容できない場合は設計の変更を検討する。

　最後に、教材を組織に埋め込む。月に1度、直近のアウトージ（機能停止）を7項目で整理し、起点と増幅点だけを議論する。次に、最も連鎖度が高いシナリオを1つ選び、縮退手順と連絡手順を20分で机上演習する。

　これを繰り返せば、障害の当事者になったときの初動が速くなる。2025年を振り返った教訓は「止めない」ではなく、「止まっても小さくし、戻す」へ運用の前提を更新することにありそうだ。