インシデント対応

概要

インシデント対応は、サービス障害（インシデント）の検知から復旧までを、組織として秩序立てて進めるための活動です。障害そのものへの技術的な対処だけでなく、「誰が指揮を執るか」「誰がどこを調査するか」「顧客や社内へ誰がいつ知らせるか」といった役割分担と手順を事前に決めておき、非常時の混乱を防ぐことに主眼があります。

障害の渦中は、平時とはまったく違う環境です。アラートが鳴り続け、問い合わせが殺到し、原因は分からず、時間だけが過ぎていく。この状況で「全員が同じ画面を見て議論する」「上司が横から指示を重ねる」といった無秩序が起きると、復旧はむしろ遅れます。インシデント対応の本質は、火事場でも判断と作業が滞らない「非常時の組織の型」をあらかじめ用意しておくことにあります。

なぜ生まれたか

小さなチームが小さなシステムを運用していた時代は、詳しい人が駆けつけて直せば済んでいました。しかしシステムが分散システム化・大規模化し、24時間止められないサービスが当たり前になると、属人的な火消しは破綻します。原因調査をしている人に状況報告の問い合わせが集中して手が止まる、複数人が同じ設定を同時に触って事態を悪化させる、誰も全体像を把握しておらず復旧宣言の判断ができない — 障害そのものより「対応の混乱」が復旧を遅らせる事例が繰り返されました。

この問題に対する答えとして参照されたのが、米国の消防・災害対応で使われてきた Incident Command System（ICS）です。指揮者を一人に定め、役割を分担し、情報の流れを一本化するというこの枠組みを、Google をはじめとする大規模サービス運用者がソフトウェア障害に持ち込み、SRE の実践の中核として体系化しました。今日のインシデント対応プロセスは、災害対応の知見をIT運用に翻訳したものと言えます。

詳細

対応のライフサイクル

インシデント対応は大きく「検知 → トリアージ → 調査・緩和 → 復旧 → 振り返り」という流れをたどります。まずモニタリングとアラートが異常を検知し、オンコール担当者に通知します（ユーザーからの報告より先に自分たちで気づけることが理想です）。担当者は影響範囲と深刻さを見極めて重大度を判定し（トリアージ）、必要ならインシデントを正式に「宣言」して対応体制を立ち上げます。調査と並行して、まず出血を止める緩和策 — 直前のデプロイの切り戻し、フィーチャーフラグでの機能停止、トラフィックの迂回など — を優先し、根本原因の完全な解明は復旧後に回すのが定石です。

役割分担 — 指揮と作業を分ける

体制の核になるのが「インシデントコマンダー（IC、指揮者）」です。ICは自ら手を動かして直す人ではなく、全体像を把握し、優先順位を決め、作業を割り当て、対外的な判断を下す調整役に徹します。技術的に最も詳しい人がICを兼ねると、調査に没頭して指揮が空白になりがちなので、「直す人」と「仕切る人」を分けることが重要です。ICの下に、実際の調査・修復を行う実作業担当（オペレーションリード）、経営層・カスタマーサポート・ユーザーへの情報発信を引き受けるコミュニケーション担当、時系列の記録を残す書記などを置きます。小規模なチームでは一人が複数の帽子をかぶることもありますが、「役割として存在する」こと自体に意味があります。誰に聞けばよいか、誰が決めてよいかが常に明確になるからです。

重大度レベルと発動基準

すべての障害に総力戦で臨むのは持続不可能なので、影響の大きさに応じた重大度（Severity）レベルを事前に定義します。たとえば SEV1 は全ユーザーに影響する全面停止で全社的に即時対応、SEV2 は主要機能の劣化で営業時間外でも対応、SEV3 は限定的な影響で翌営業日対応、といった具合です。重要なのは、判定基準と各レベルの対応（誰を起こすか、どこまで報告するか）を平時に文書化しておくことです。渦中に「これは起こすほどか」を議論するのは判断の遅れと属人化を招きます。SLO や SLA への影響見込みは、この判定の客観的な物差しになります。迷ったら重い方に倒し、後で格下げする方が、軽く見て手遅れになるより安全です。

実務の勘所と落とし穴

調査の起点になるのはオブザーバビリティの三本柱、すなわちメトリクス・ログ・分散トレーシングです。「直前に何を変えたか」はインシデントの最有力容疑者であり、CI/CD のデプロイ履歴とアラートの時刻を突き合わせるのが最初の一手になります。典型的な落とし穴は、復旧を急ぐあまり検証不十分な変更を本番に重ねて二次災害を起こすこと、対応者が状況報告に忙殺されて作業が進まないこと（コミュニケーション担当を分離する理由です）、そして「直ったように見える」だけで終結宣言をしてしまい再燃することです。

もう一つ大切なのは、インシデントを「失敗」ではなく「学習の入力」として扱う姿勢です。終結はゴールではなく、ポストモーテムで原因と対応プロセス自体を振り返り、再発防止と体制改善につなげてはじめてサイクルが閉じます。この訓練を平時に行うのがカオスエンジニアリングのゲームデーであり、検知の入口を支えるのがアラート設計とオンコール体制です。インシデント対応は単発の技術ではなく、これらが噛み合った運用文化の中心に位置しています。