サービスが止まったとき、何から手をつけ、誰に何を伝えるかを決めていないと、復旧そのものより連絡や判断で時間を失います。この記事ではシステム障害対応の流れを 7 つの段階に分け、それぞれで何をするか、何を書いて送るかを具体的に説明します。専任の運用チームがない 2〜5 人の開発チームでも、そのまま始められる形にしています。
障害対応フローとは
障害対応フローは障害に気づいてから振り返りを終えるまでに、誰が・何を・どの順で行うかを決めた手順です。
障害の最中は、ふだんなら迷わない判断にも時間がかかります。原因が分からないまま問い合わせが増え、上司や営業から状況を聞かれ、複数の人が同じログを見て、誰も顧客に連絡していない、ということが起きます。フローを決めておく目的は、技術的な調査以外の判断をあらかじめ済ませておき、障害の最中には調査と復旧に集中できるようにすることです。
フローで決めておくのは、主に次の 3 つです。
- 誰が判断するか: 戻すか待つか、顧客に告知するか、を決める人
- 誰に何を伝えるか: 社内・顧客への連絡の宛先、間隔、文面
- 何を優先するか: 原因の究明より、まず被害を止めてサービスを戻す
障害対応の 7 つの段階
全体の流れを表にまとめます。後の節で順に説明します。
| 段階 | 目的 | 終わりの目安 |
|---|---|---|
| 1. 検知 | 異常に気づき、障害として宣言する | 対応用のチャンネルができ、宣言が投稿された |
| 2. 初動 | 指揮役を決め、記録を始める | 役割が決まり、直前の変更を洗い出した |
| 3. 影響の確認 | 誰に、何が、いつから、どれくらい起きているかを掴む | 重大度が決まった |
| 4. 連絡 | 社内と顧客に状況を伝える | 第一報を送り、次の更新時刻を約束した |
| 5. 暫定対処 | 原因が分からなくても、被害を止めてサービスを戻す | 主要な機能が使える状態に戻った |
| 6. 恒久対処 | 原因を取り除き、同じ障害が起きないようにする | 修正が本番に入り、暫定の変更を片づけた |
| 7. 振り返り | 記録をまとめ、再発防止策を決める | 報告書を共有し、対策に担当と期限がついた |
連絡は 4 番目に置いていますが、実際には 3〜6 の間ずっと続きます。暫定対処と影響の確認も並行して進むことが多く、表の順は「最初に手をつける順」と考えてください。
事前に決めておくこと
重大度 (障害のレベル) の定義
重大度は対応の大きさを決める物差しです。「レベル 1〜3」と名前だけ決めて、何が起きたらどのレベルかを書いていないフローをよく見かけます。これでは障害の最中に「これはレベル 2 か 3 か」の議論が始まってしまいます。影響を受ける人の数と、止まっている機能で書いておきます。
小さなチームなら、次の 3 段階で十分です。
| 重大度 | 定義の例 | 対応 |
|---|---|---|
| SEV1 | 全ユーザーがログインできない。決済・注文など売上に直結する機能が止まっている。データが失われた、または漏れた可能性がある | 夜間・休日でも全員を呼ぶ。顧客に告知する。経営者に連絡する |
| SEV2 | 一部のユーザーや一部の機能が使えない。主要な画面が極端に遅い | 担当者を呼ぶ。影響する顧客に告知するかを指揮役が決める |
| SEV3 | 管理画面の不具合、遅延しているが自動で追いつくバッチなど、利用者への影響が小さい | 翌営業日に対応する。チケットに記録する |
レベルの判断に迷ったら高い方で扱います。あとで「大げさだった」と分かるのは問題になりませんが、低く見積もって連絡が遅れると取り返せません。PagerDuty が公開している障害対応のドキュメントでも、迷ったら高い方として扱い、レベルの議論は振り返りの場で行うよう勧めています。
障害を宣言する基準
「障害と呼ぶほどか分からない」まま一人で抱え込むのが、対応が遅れるよくある理由です。Google の『Site Reliability Engineering』(SRE 本) は、次のどれかに当てはまったら障害として宣言することを勧めています。
- 自分のチームだけでは直せず、別のチームの助けが要る
- 顧客から見える影響が出ている
- 1 時間集中して調べても解決しない
同じ本は、早めに宣言して簡単に直ったら閉じればよいとも書いています。宣言を空振りしても責めない、とチームで決めておくと、宣言のハードルが下がります。
連絡先と道具
障害の最中に探さなくて済むよう、次の情報を 1 か所 (社内 Wiki やリポジトリの README など) にまとめておきます。
- 呼び出す人と順番 (電話番号を含む)。夜間・休日の当番がいるなら当番表
- 障害対応に使うチャット (Slack なら
#incidentのようなチャンネル) と、通話の URL - 顧客への告知の出し先 (ステータスページ、サービス内のお知らせ、メール) と、出す権限を持つ人
- クラウドの管理画面、監視ツール、DB に入るための手順
- 直近の変更を確認する場所 (デプロイの履歴、設定変更の履歴、定期バッチの予定)
1. 検知: 気づいた人が宣言する
障害に気づくきっかけは監視のアラート、顧客からの問い合わせ、社内の誰かの「なんか遅くない?」のどれかです。顧客からの問い合わせで初めて気づいた場合は、監視に穴があります。振り返りの議題に入れておきます。
気づいた人は、原因を調べ始める前に、対応用のチャンネルに宣言を投稿します。調べ始めると、宣言を忘れたまま 30 分経つことがよくあるからです。宣言は次のテンプレートで足ります。
【障害宣言】注文完了画面でエラー
- 気づいた時刻: 10:42
- 気づいたきっかけ: 監視アラート (注文 API の 5xx が増加)
- 今わかっていること: 10:35 ごろから注文確定の一部が 500 エラー
- 重大度 (仮): SEV1
- 指揮役: 山田 (変わる場合はここで交代を書く)
- 通話: https://meet.example.com/xxx
重大度は仮で構いません。影響の確認が進んだら更新します。
2. 初動: 最初の 15 分でやること
最初の 15 分で、次の順に手をつけます。
- 指揮役を決める。多くの場合、宣言した人がそのまま指揮役になります。作業に入りたい人がほかにいなければ、あとで交代すれば構いません。
- 記録を始める。対応用のチャンネルに、確認したこと・やったことを時刻つきで書いていきます。あとで報告書を書くときの材料になります。
- 直前の変更を洗い出す。障害の多くは何かを変えた直後に起きます。直前のデプロイ、設定の変更、DB のマイグレーション、インフラの変更、大量のデータ投入、定期バッチ、外部サービスの障害情報を確認します。
- 優先順位を確認する。SRE 本は障害対応の優先順位を「被害を止める、サービスを戻す、原因究明のための証拠を残す」の順に挙げています。原因の特定は最後です。
直前に変更があり、それが原因の可能性があるなら、原因が確定していなくても戻すことを検討します。切り戻しの判断は 5 の暫定対処で詳しく書きます。
3. 影響の確認: 誰に、何が、いつから
影響の確認では次の 4 点を埋めます。重大度の判断と、顧客への連絡の両方に使います。
- 誰に: 全ユーザーか、一部か (特定のプラン、地域、ブラウザ、テナント)
- 何が: どの機能が使えないか、遅いか。データに誤りや欠損が出ているか
- いつから: 最初に異常が出た時刻。気づいた時刻ではありません
- どれくらい: エラーの割合、失敗した注文の件数など
「いつから」は監視のグラフや業務の数字で確かめます。たとえば注文数を 1 時間ごとに数えると、どこから落ちたかが見えます。テーブル名と列名は自社のものに置き換えてください。
-- PostgreSQL の例: 直近 24 時間の注文数を 1 時間ごとに数える
SELECT date_trunc('hour', created_at) AS hour,
count(*) AS orders
FROM orders
WHERE created_at >= now() - interval '24 hours'
GROUP BY 1
ORDER BY 1;
前の週の同じ曜日・同じ時間帯と比べると、ふだんとの差がはっきりします。決済の失敗率やジョブの滞留件数など、事業にとって大事な数字も同じように数えておくと、影響の大きさを社内に説明しやすくなります。
アプリが遅い・タイムアウトしている場合は、DB で何が起きているかを見ます。PostgreSQL では pg_stat_activity で、いま動いているクエリと、どれくらい動き続けているかが分かります。
-- PostgreSQL: 動いているクエリを古い順に並べる
SELECT pid,
usename,
state,
wait_event_type,
wait_event,
now() - query_start AS running_for,
left(query, 100) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
AND backend_type = 'client backend'
ORDER BY query_start
LIMIT 20;
running_for が数分以上のクエリが並んでいる、wait_event_type が Lock のセッションが多い、state が idle in transaction のまま長く残っている、といった状態は原因の手がかりになります。ロック待ちが疑わしければ、誰が誰を止めているかを pg_blocking_pids で確かめます。
-- PostgreSQL: ほかのセッションに止められているセッションと、止めている側の pid
SELECT pid,
pg_blocking_pids(pid) AS blocked_by,
now() - query_start AS waiting_for,
left(query, 80) AS query
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;
MySQL では SHOW FULL PROCESSLIST で同じことを確かめます。PROCESS 権限がないと自分の接続しか見えない点に注意してください。
-- MySQL: 接続とその状態、実行中の SQL を表示する
SHOW FULL PROCESSLIST;
Time (その状態が続いている秒数) が大きい行や、State にロック待ちが並んでいる行から見ます。ロック待ちの詳しい調べ方は ロック待ちの原因と対処、接続数があふれている場合は Too many connections の原因と対処 で説明しています。
調査の SQL はできれば読み取り専用のユーザーで実行します。焦っているときに更新系の SQL を打ち間違えると、障害が広がります。
4. 連絡: 第一報は早く、次の更新時刻を約束する
連絡で大事なのは、内容の正確さより、途切れないことです。何も分かっていなくても「調査中であること」と「次にいつ連絡するか」を伝えれば、問い合わせや催促は減ります。分かっていないことは「調査中」「未確認」と書き、推測を事実のように書かないようにします。
社内向けの状況更新
社内向けは対応用のチャンネルとは別に、経営者や営業・サポートが見る場所に投稿します。対応用のチャンネルには調査のやりとりが流れるため、状況を知りたい人には読みにくいからです。
【障害 状況更新 #2】注文完了画面でエラー (11:10 時点)
- 状況: 対応中 / 重大度 SEV1
- 影響: 10:35 から、注文確定の約 3 割が失敗。対象は全ユーザー
- わかったこと: 10:30 のリリース以降に発生。リリースを戻す作業中
- 顧客対応: 11:00 にステータスページで告知済み。問い合わせには告知文の内容で回答してください
- 次の更新: 11:40 まで (変化があればそれより前に)
更新の間隔は SEV1 なら 30 分、SEV2 なら 1 時間程度を目安にし、事前に決めておきます。進展がなくても「進展なし、引き続き調査中」と時刻どおりに投稿します。
顧客向けの第一報
顧客向けの文面では専門用語を使わず、顧客がとるべき行動を書きます。原因の詳細は確定してから報告書で伝えれば十分です。
【障害のお知らせ】ご注文の確定ができない事象について
2026年11月1日 10時35分ごろから、一部のお客さまでご注文の確定ができない事象が発生しています。
現在、原因の調査と復旧の作業を進めています。
・影響: ご注文の確定時にエラーが表示される場合があります
・ご注文の状況: エラーが表示されたご注文は確定していません。二重に請求されることはありません
・お願い: 復旧まで、時間をおいてからお試しください
次回は 12時00分ごろまでに状況をお知らせします。
ご迷惑をおかけし、申し訳ございません。
「二重に請求されることはありません」のように、顧客が一番気にすることに答える一文は、確かめてから書きます。確かめられていなければ、「確認中です。確認でき次第お知らせします」と書きます。
5. 暫定対処: 原因が分からなくても戻す
暫定対処は原因を取り除く前に、サービスを使える状態に戻す処置です。次のような手があります。
- 直前のリリースや設定変更を戻す
- 問題のある機能を止める (機能フラグを切る、メンテナンス表示にする)
- 予備の系統やレプリカに切り替える、サーバーやコンテナを増やす
- DB の長時間クエリやロックを握ったままのセッションを止める (PostgreSQL の
pg_terminate_backend、MySQL のKILL) - 原因になっている定期バッチや外部連携を一時的に止める
切り戻しは「原因が確定してから」では遅くなりがちです。直前の変更と障害の時刻が合っていて、戻しても失うものが小さいなら、先に戻して様子を見ます。戻して直れば原因の切り分けにもなります。ただし、DB のマイグレーションのように戻すとデータが失われる変更は、戻す前に指揮役が判断します。
暫定対処のときは、次の 2 点を守ります。
- システムを変更する人を 1 人に絞る。SRE 本も、障害の最中にシステムを変更するのは作業役だけにするよう書いています。複数人が別々に設定を変えると、何が効いたのか分からなくなります
- やった操作を時刻つきで記録する。暫定の変更 (止めたバッチ、増やしたサーバー、切った機能フラグ) は、恒久対処の段階で元に戻すか正式な変更にする必要があります。記録がないと、暫定の変更が何か月も残ります
本番 DB を直接変える操作は、実行する SQL をチャンネルに貼り、もう 1 人が確認してから実行すると、打ち間違いを防げます。
6. 恒久対処: 収束を宣言してから落ち着いて直す
主要な機能が戻り、エラーや業務の数字がふだんの水準に戻ったら、指揮役が収束を宣言します。宣言のあと 30 分〜1 時間ほどはグラフを見続け、再発しないかを確かめます。収束したら、顧客と社内に復旧の連絡を出します。
恒久対処は原因を取り除き、同じことが起きないようにする作業です。バグの修正、インデックスの追加、設定値の見直し、監視の追加などがあたります。障害の最中に恒久対処まで終わらせようとせず、収束後に通常のレビューとテストを通して本番に入れます。急いだ修正が次の障害を起こすことがあるからです。
あわせて、暫定対処で入れた変更を片づけます。止めたバッチを再開する、失敗した処理をやり直す、データの不整合を直す、などです。失敗した注文や二重に処理されたデータが残っていないかは、業務の数字で確かめておきます。
7. 振り返り: 報告書と再発防止策
収束から数日以内に、記録をもとに振り返りを行います。時系列、原因、影響、対処、再発防止策を文書にまとめ、再発防止策には担当者と期限をつけます。期限のない対策は実行されないまま忘れられます。
振り返りでは個人のミスを責めず、仕組みの穴を探します。「確認を徹底する」のような対策ではなく、「本番 DB への更新系 SQL はレビューを必須にする」「この数字が落ちたらアラートを出す」のように、仕組みで防ぐ対策にします。報告書の書き方は 障害報告書の書き方とテンプレート、振り返りの進め方は ポストモーテムとは で詳しく説明しています。
役割分担と、小さなチームでの回し方
大きな組織の障害対応では次の 4 つの役割を分けます。SRE 本の役割 (指揮、作業、連絡、計画) をもとに、小さなチームで使いやすい形にしたものです。
| 役割 | やること | やらないこと |
|---|---|---|
| 指揮役 | 全体を把握し、作業を割り振り、戻すか待つかを決める。収束を宣言する | 自分でログを読み込んだり、コマンドを打ったりしない |
| 作業役 | 調査と暫定対処を行う。システムを変更するのはこの人だけ | 社内外への連絡 |
| 連絡役 | 社内向けの更新と顧客向けの告知を、決めた間隔で出す | 調査 |
| 記録役 | 時系列で起きたこと、やったこと、決めたことを書く | 判断 |
指揮役が作業に入ると、全体を見る人がいなくなります。PagerDuty の公開ドキュメントでも、指揮役は自分で調査や修復をせず、作業を人に任せるよう書いています。指揮役に技術の深い知識は要りません。
2〜5 人のチームでは人数に応じて役割を兼ねます。
- 1 人で対応する場合: 全部を 1 人で行うしかありません。作業に入る前に宣言を投稿し、タイマーを 30 分にかけて、鳴ったら作業を止めて状況更新を書きます。SEV1 なら、技術が分からなくても連絡役を引き受けられる人 (経営者やサポート担当) を呼びます
- 2 人の場合: 1 人が作業役、もう 1 人が指揮・連絡・記録を兼ねます。詳しい人が作業役になり、もう 1 人は作業に手を出さず、全体を見る側に回ります
- 3〜5 人の場合: 指揮役、作業役 (1〜2 人)、連絡と記録を兼ねる人に分けます。作業役が複数いるときは、指揮役が「A さんは DB、B さんはアプリのログ」と分担を決め、同じものを全員で見ないようにします
役割は固定せず、交代で経験しておくと、誰が休んでいても回ります。指揮役を交代するときは、チャンネルに「11:30 から指揮役は佐藤に交代」と書きます。
よくある落とし穴
「誰か見てもらえますか」と頼む。名指しでない依頼は、全員が誰かがやると思って誰もやりません。「鈴木さん、10 分で直前のデプロイの差分を確認して報告してください」のように、人と期限を指定します。
連絡が途絶える。調査が進まないと、報告することがないと感じて連絡が止まります。時刻どおりに「進展なし」を出します。
全員が通話に入ったまま、同じ画面を見ている。役割のない人は通話から抜けて、呼ばれたら戻ります。
収束宣言のあとに監視をやめる。暫定対処は根本の原因を取り除いていないため、負荷が戻ると再発することがあります。
フローを作ったまま使わない。フローは実際の障害で使って初めて穴が見つかります。小さな障害 (SEV3) でも宣言とテンプレートを使っておくと、大きな障害のときに迷いません。年に数回、過去の障害を題材に「この状況で誰が何をするか」を机上で練習するのも効果があります。
1 枚にまとめたフローの雛形
最後に、ここまでの内容を社内 Wiki に貼れる形にまとめます。宛先や時間は自社に合わせて書き換えてください。
# 障害対応フロー
## 宣言
- 異常に気づいたら、調べる前に #incident に宣言を投稿する (テンプレートは下)
- 迷ったら宣言する。空振りしても責めない
- 重大度に迷ったら高い方で扱う
## 重大度
- SEV1: 全ユーザー影響 / 決済・注文の停止 / データ消失・漏えいの可能性 → 全員呼ぶ、顧客告知、経営者に連絡
- SEV2: 一部ユーザー・一部機能 → 担当を呼ぶ、告知は指揮役が判断
- SEV3: 影響小 → 翌営業日、チケット
## 最初の 15 分
1. 指揮役を決める
2. #incident に時刻つきで記録を始める
3. 直前の変更を確認する (デプロイ、設定、マイグレーション、バッチ、外部サービス)
4. 影響を確認する (誰に・何が・いつから・どれくらい)
## 連絡
- 社内: #incident-status に、SEV1 は 30 分、SEV2 は 1 時間ごと
- 顧客: ステータスページ。出す権限: 山田、佐藤
- 必ず次の更新時刻を書く
## 暫定対処
- 直前の変更が怪しく、戻して失うものが小さければ先に戻す
- システムを変更するのは作業役 1 人だけ
- 本番 DB の更新はもう 1 人が確認してから
- 操作はすべて時刻つきで記録
## 収束後
- 収束宣言のあと 1 時間は監視を続ける
- 暫定の変更を片づける
- 5 営業日以内に振り返り。再発防止策に担当と期限をつける
検知と影響の確認を続けるには
障害対応のうち、検知と影響の確認は事前の準備でかなり速くなります。注文数や決済の失敗率など事業の数字を定期的に数える SQL を cron で実行し、ふだんの水準から外れたら通知する、監視ツールにアラートを設定する、といった方法があります。アラートの基準の決め方は アラートの閾値の決め方 で説明しています。
この部分を AI に任せる方法もあります。Scandock は、データベースの接続文字列を登録すると、AI がテーブルの構成と実データを読んで、注文数や決済の成否、ジョブの滞留のような数字の監視項目を決めます。固定の閾値ではなく値の推移などを踏まえて異常を判断し、異常と判断したときは読み取り専用のクエリで関連するデータを調べ、原因・影響・根拠・対処案をつけて Slack やメールなどに通知します。
参考
- Managing Incidents (Site Reliability Engineering, Google)
- Severity Levels (PagerDuty Incident Response Documentation)
- Incident Commander (PagerDuty Incident Response Documentation)
- PostgreSQL: The Cumulative Statistics System (pg_stat_activity)
- PostgreSQL: System Information Functions (pg_blocking_pids)
- PostgreSQL: System Administration Functions (pg_terminate_backend)
- MySQL 8.4 Reference Manual: SHOW PROCESSLIST Statement
- MySQL 8.4 Reference Manual: KILL Statement