障害対応の初動：直す前に影響を確認して記録する | 仕組み解説

本番サイトが表示されないと、すぐ設定やコードを変えたくなります。しかし、状況を確認せず変更を重ねると、原因と影響が分からなくなります。

障害対応の最初の目的は、完全な原因究明ではなく影響を抑えることです。

初動の順番

原因究明と復旧は同じ作業ではありません。まず旧バージョンへ戻して復旧し、その後に落ち着いて原因を調べる判断もあります。

10:02 監視で5xx増加を検知
10:04 トップページは表示、ログインAPIのみ失敗を確認
10:07 直前リリースを停止
10:11 前バージョンへ戻す
10:14 5xxが通常値へ戻ったことを確認

「たぶんDBが原因」のような推測は、観察事実と分けて記録します。

「サイトが壊れた」より、「ログイン済み利用者の保存操作だけが10:02から失敗している」の方が対応を選べます。

一次対応は、機能停止、ロールバック、アクセス制限などで被害を抑える作業です。恒久対応は、原因となったコードや運用手順を改善する作業です。

緊急時に大きな設計変更を入れると、新しい問題を増やします。復旧と改善を分けます。

削除、再起動、権限変更、DB操作などは、実行前に対象環境とコマンドを読み直します。可能なら別の人にも確認してもらいます。

注意: 障害調査のログや画面を共有する時は、個人情報、Cookie、トークン、接続情報を伏せてください。