障害対応の初動：直す前に影響を確認して記録する

定義と結論

障害対応とは、サービスの予期しない停止や品質低下が利用者へ影響している時に、その影響を把握し、拡大を防ぎ、復旧させ、関係者へ伝え、学びを次の改善へつなげる活動です。コードを直す作業だけを指しません。

初動の最優先は、根本原因を完全に証明することではなく、利用者への影響を安全に小さくすることです。 発生確認、影響評価、記録、役割分担、緩和、復旧確認の順で進め、恒久修正は状況が安定してから行います。

本番サイトが表示されないと、すぐ再起動や設定変更をしたくなります。しかし観測前に変更すると証拠が失われ、変更同士が干渉し、悪化した時に戻せなくなります。「急ぐ」と「手順を飛ばす」は別です。

なぜ初動設計が必要なのか

障害中は、技術調査、意思決定、利用者対応、社内共有が同時に発生します。担当者が全てを抱えると、調査中に問い合わせが割り込み、重要な変更が記録されず、複数人が同じ操作を行う危険があります。

平常時に役割、連絡経路、重大度、変更権限、ロールバック手順を決めておけば、緊急時の判断負荷を下げられます。Google SREのIncident Responseでも、障害解決と、対応全体の調整・コミュニケーションは区別して扱われています。

登場人物と役割

小規模チームでは一人が複数役を兼ねても構いませんが、責任は分けて考えます。

利用者も重要な対象です。技術的な内部事情より、「何が使えないか」「回避策はあるか」「次回更新はいつか」が必要です。個人情報漏えいの疑い、決済やデータ破壊の可能性がある場合は、通常の可用性障害と同じ扱いにせず、組織のセキュリティ・法務手順へ直ちにエスカレーションします。

初動から収束までの流れ

1. 発生を確認して宣言する

アラートが誤検知ではないか、利用者視点の確認や別の監視指標で裏を取ります。ただし確認に時間をかけすぎず、一定以上の影響が疑われたらインシデントとして宣言し、専用の連絡場所と責任者を決めます。

開始時刻は「誰かが気づいた時刻」と「実際に影響が始まった推定時刻」を分けます。ログやメトリクスから後者が更新されたら、推定であることを明記します。

2. 影響範囲と重大度を評価する

「サイトが壊れた」では対応を選べません。次の観点を埋めます。

影響範囲は技術コンポーネントではなく、利用者が何をできないかまで言語化します。 「認証APIの5xx」より「新規ログインの約半数が失敗し、既存セッションの閲覧は可能」の方が判断に役立ちます。

3. 観察事実と判断を記録する

記録は後の報告書だけでなく、進行中の共有メモです。

10:02 監視でログインAPIの5xx増加を検知（観察）
10:04 既存セッションの閲覧は成功、新規ログインのみ失敗（観察）
10:06 09:55のリリースとの関連を調査する方針（判断）
10:10 リリースを前バージョンへ戻す操作を開始（操作）
10:14 5xxが通常範囲へ戻った（結果）

「DBが原因らしい」は仮説です。ログの値や操作結果と混ぜません。誰が、何を、どの環境で、なぜ実行し、結果がどうだったかを残します。

4. 影響を緩和する

緩和策には、直前リリースのロールバック、問題機能の停止、feature flagによる無効化、読み取り専用化、トラフィックの退避、レート制限などがあります。選択基準は、影響軽減までの速さ、成功確率、追加リスク、元に戻せるか、データ整合性です。

障害中の変更は、小さく、可逆的で、結果をすぐ観測できるものを優先します。 原因が断定できなくても、直前リリースを戻すと安全に復旧できるなら有力です。反対に、根拠のないDB更新や複数設定の同時変更は避けます。

5. 状況を共有する

最初の通知は完全でなくて構いません。確認済みの影響、開始時刻、対応中であること、回避策、次回更新時刻を伝えます。原因未確定なら「調査中」と明示し、推測を断定しません。

更新間隔を先に決めると、担当者が問い合わせへ個別対応する負担を減らせます。内部向けには技術詳細、利用者向けには影響と行動を中心にし、内容が矛盾しないようコミュニケーション担当を一本化します。

6. 復旧を確認する

操作が成功したことと、サービスが復旧したことは別です。エラー率が下がっただけでなく、利用者の主要操作を実行し、遅延、キュー、データ整合性、関連機能を確認します。キャッシュや監視集計の遅れも考慮し、一定時間安定してから収束を宣言します。

7. 恒久対応と学習につなげる

復旧後に、タイムライン、影響、検知、対応判断、寄与要因を整理します。個人の注意不足だけで終わらせず、設計、レビュー、テスト、監視、権限、手順、組織間連携の改善を探します。アクションには担当者、期限、完了条件、優先度を設定します。

一次対応と恒久対応の違い

緩和で症状が消えても根本原因が残る場合があります。一方、根本原因の修正に数時間かかるなら、その間も利用者影響を放置すべきではありません。この二つを分けることで、復旧を急ぎながら恒久対応の品質も守れます。

具体例：リリース後にログインが失敗する

09:55にリリースし、10:02からログインAPIの5xxが増えたとします。まず直前リリースが原因と断定せず、リリース時刻、エラー増加時刻、対象バージョン、既存セッションへの影響を確認します。同時に、ロールバックの可否とデータ移行の互換性を確認します。

旧バージョンへ安全に戻せるなら、ロールバックしてエラー率と実ログイン操作を観測します。通常値へ戻ればサービスを復旧させつつ、「新バージョンが関与する」という強い証拠が得られます。その後、検証環境で差分を小さく再現し、修正と回帰テストを作ります。

ロールバック後も失敗するなら、外部認証、DB、設定変更などへ候補を広げます。一つの操作結果で次の判断が変わるように、仮説と観測点を対応させます。

よくある誤解

最も詳しい人が全部指揮する

技術的に詳しい人を問い合わせ対応で中断すると、復旧が遅れます。指揮、技術対応、記録、広報を分け、技術担当が調査へ集中できる状態を作ります。

原因が分かるまで通知できない

利用者は原因より、影響と次の見通しを必要とします。確認済み情報だけで早期通知し、一定間隔で更新します。

メトリクスが戻れば復旧完了

平均値が正常でも、一部利用者や特定操作だけ失敗していることがあります。代表的なユーザーフロー、地域・バージョン別の指標、データ整合性を確認します。

誰かのミスを特定すれば再発防止になる

個人を罰しても、同じ操作を許した権限、レビュー、テスト、手順、監視は残ります。事実に基づき、システムとプロセスを改善します。

注意とベストプラクティス

• 本番操作前に対象環境、コマンド、影響、戻し方を読み上げ確認する
• DB削除や権限変更など不可逆な操作は、可能なら別担当の確認を得る
• 調査ログやスクリーンショットから個人情報、Cookie、トークン、接続情報を除く
• 専用チャネルを作り、意思決定と操作を一か所へ集約する
• 交代時は、現在の影響、実施済み操作、未検証仮説、次の判断を引き継ぐ
• Runbookは平常時に演習し、実行できる状態を保つ
• 重大度やエスカレーション基準を事前に定義する

デバッグと復旧確認のチェック

技術調査では、メトリクスで「いつ・どれだけ」、ログで「どの処理が・なぜ」、トレースで「どこに時間や失敗が集中したか」を見ます。直前のデプロイだけでなく、設定、feature flag、証明書、依存サービス、トラフィック、データ量の変化も確認します。

復旧判定では、アラート解消、主要ユーザーフロー、エラー率、遅延、バックログ、データ整合性、サポート問い合わせを確認します。監視画面だけでなく、実際の利用者と同じ経路から試します。変更前後の値を同じ時間幅・条件で比較し、安定確認の時間を設けます。

「アラートが消えた」「操作が成功した」「利用者影響が解消した」を別々に確認することが重要です。

まとめ

障害対応では、影響を利用者の言葉で把握し、事実と判断を時系列で記録し、役割を分けて、可逆的な緩和策から実行します。復旧は監視値だけでなく主要操作とデータまで確認し、原因調査と恒久対応は安定後に続けます。

良い初動は、焦らないことではなく、焦っている時でも次の判断に必要な情報を失わない仕組みです。

参考資料

• Google SRE Workbook: Incident Response
• Google SRE: Managing Incidents
• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide

次に読む記事

• オブザーバビリティの3本柱
• ロギングのベストプラクティス
• ロールバックとロールフォワード
• 障害タイムラインの書き方

×

PR

×

PR