【2026年最新】本番で障害が起きたときの一次対応7手順

本番の環境で不具合が起きたとき、最初に何をするかで復旧までの時間が変わります。原因の究明を先に始めると、影響が広がり続けます。この記事では、一次対応の順序を整理します。

一次対応の7手順

【結論】止血が最優先です。

1. 検知したことを共有する

一人で抱えないでください。関係者に状況を伝えます。

2. 影響範囲を把握する

何が使えないのか、どのくらいの利用者に影響しているのかを確認します。

3. 記録を始める

時刻と行った操作を記録します。後の振り返りに使います。

4. 止血する

直前の変更を戻すか、問題のある機能を切り離します。

5. 復旧を確認する

止血の後、実際に動くようになったかを確認します。

6. 利用者へ知らせる

影響が及んでいるなら、状況を伝えてください。

7. 原因を調べる

復旧してから、落ち着いて調査します。

段階	やること	やらないこと
検知	共有する	一人で抱える
把握	影響範囲を確認	推測で決める
止血	戻すか切り離す	原因究明を優先
調査	復旧後に行う	本番で試す

止血の方法

【結論】元に戻すのが最も速い場合があります。

直前の変更を戻す

変更の直後に起きた不具合なら、戻すことで解決する可能性が高くなります。

機能を切り離す

特定の機能だけが問題なら、その機能を止める方法があります。

接続を絞る

負荷が原因なら、受け付ける量を制限する方法があります。

手作業での代替

短期間なら、手作業で処理を回す判断もあります。

やってはいけないこと

【結論】本番で試さないでください。

思いつきで直す

原因が確かでないまま本番を触ると、状態が悪化します。

記録を残さない

何をしたか分からなくなると、元に戻せなくなります。

一人で判断する

影響の大きい操作は、必ず他の人に伝えてから行ってください。

ログを消す

調査の材料が失われます。容量が逼迫していても、退避してから消してください。

影響範囲の確認

【結論】推測ではなく実際に見ます。

エラーの発生状況

どの処理でどのくらいの割合が失敗しているかを確認します。

いつから起きているか

開始の時刻が分かれば、その時刻に何があったかを照合できます。

一部か全体か

特定の条件だけで起きているのか、すべてで起きているのかを切り分けます。

データへの影響

誤ったデータが記録されていないかを確認してください。復旧より手間がかかる場合があります。

知らせる相手

【結論】早めに伝えてください。

チーム内

最初に共有します。判断を分担できます。

関係する部署

問い合わせを受ける窓口には、早く伝えてください。

利用者

影響が出ているなら、分かる範囲で状況を知らせます。復旧の見込みは断定せず、分かった時点で更新します。

伝える内容

何が起きているか、いつから起きているか、次の連絡はいつかの3点で足ります。

記録に残すこと

【結論】時刻を必ず添えてください。

検知した時刻

誰がどのように気づいたかも記録します。

行った操作

何時何分に何をしたかを書きます。

観測した内容

画面の表示やログの内容を、そのまま残してください。

判断の理由

なぜその対応を選んだかを書いておくと、振り返りで役立ちます。

復旧後にやること

【結論】再発の防止まで含めて終わりです。

原因の特定

落ち着いてから、記録をもとに調べます。

恒久的な対策

止血は一時的な措置です。根本の対応を計画してください。

検知の見直し

利用者からの連絡で気づいたなら、検知の仕組みに穴があります。

手順の更新

今回うまくいかなかった点を、手順書に反映してください。

備えておくこと

【結論】平時に決めておくと動けます。

連絡の経路

誰に、どの手段で連絡するかを決めておいてください。

戻す手順

直前の変更を戻す手順を、事前に確認して記録しておきます。

権限の確認

止血に必要な操作を行える人が、すぐ動ける状態かを確認してください。

訓練

手順を試しておくと、実際の場面で迷いません。

役割の分担

【結論】同時に全員が調べないでください。

まとめ役を決める

判断と連絡を担う人を1人決めます。指示が分かれると混乱します。

調査する人

ログや状態を確認する役割です。得た情報はまとめ役へ集約します。

連絡する人

関係者や利用者への連絡を担います。調査と兼ねると、どちらも遅れます。

交代の準備

長引く場合に備え、引き継げるよう記録を残しながら進めてください。

時間を区切る

調査に区切りを設け、一定時間で進展がなければ止血へ切り替えると決めておくと、判断が遅れません。

よくある質問（FAQ）

Q1. まず何をしますか

検知したことを共有し、影響範囲を把握してください。原因究明はその後です。

Q2. 原因が分からないまま戻してよいですか

直前の変更が疑わしいなら、戻すのが最短です。原因は復旧後に調べます。

Q3. 利用者にはいつ知らせますか

影響が出ていると分かった時点で知らせてください。復旧の見込みは断定しないでください。

Q4. 記録は何を残しますか

時刻、行った操作、観測した内容、判断の理由です。

Q5. ログが溜まって容量が足りません

消す前に退避してください。調査の材料が失われます。

Q6. 復旧したら終わりですか

止血は一時的な措置です。恒久的な対策と検知の見直しまで行ってください。

まとめ

本番で不具合が起きたら、原因究明より先に影響を止めてください。原因が分かってから戻す順序にすると、その間ずっと影響が広がり続けます。

直前の変更が疑わしいなら、まず戻すのが最短です。特定の機能だけが問題なら、その機能を切り離す方法もあります。

影響範囲は推測せず、実際に確認してください。どの処理がどのくらいの割合で失敗しているか、いつから起きているかが分かれば、その時刻に何があったかを照合できます。

時刻と行った操作を記録しながら進めてください。復旧後の調査と振り返りに使います。止血は一時的な措置なので、恒久的な対策と検知の見直しまで行って初めて対応が終わります。

📱 運営の裏側・最新情報はXで発信中 → @ore_chusotsu