障害対応runbookテンプレート｜初動・切り分け・連絡・記録を1枚に
夜中にスマホが鳴る。「サイトが見られないんですけど」。 画面を開くと、たしかにトップページが真っ白。心臓がぎゅっとなって、頭の中で「どこから見ればいい？」「誰に連絡すれば？」が一気に押し寄せる——。
一人で保守運用をしていると、この最初の数分がいちばんしんどいですよね。 やることは分かっているはずなのに、いざ鳴ると順番が飛ぶ。慌ててサーバーに入って、ログを見て、でも上司への第一報を忘れていた、なんてことも起きがちです。
だからこそ、障害のときに「考えなくても手が動く」1枚を、落ち着いている今のうちに作っておきます。 それが障害対応runbook（手順書）です。この記事では、そのまま埋めれば完成するテンプレートを一緒に作っていきましょう。
結論：障害対応runbookは、初動 → 切り分け → 連絡 → 記録の4ブロックを1枚にまとめるだけで十分はじめられます。完璧な手順書を目指さず、「鳴った瞬間に最初の3手」がすぐ読める状態を最優先に。まずは今いちばん止まったら困るシステム1つ分、A4一枚から作りましょう。
runbookの細かい構成や粒度は、システムの規模やチーム体制で変わります。 この記事の型はあくまで出発点として、自分の現場に合わせて足し引きしてください。
なぜ「記憶」ではなく「1枚」に頼るのか
障害対応がうまくいかないのは、知識が足りないからではありません。 焦っている人間は、知っていることでも順番通りに思い出せない——ただそれだけです。
落ち着いているときなら「まず影響範囲を確認して、第一報を入れて…」とスラスラ言えます。 でも、電話口で相手が不安そうな声を出していて、画面は赤いアラートだらけ。そんな状況では、ベテランでも手が止まります。
runbookは、その「思い出す」という負荷を肩代わりしてくれる道具です。 頭で覚えておく代わりに、紙やドキュメントに置いておく。すると、本来いちばん頭を使いたい「原因の切り分け」に集中できます。
一人運用なら、なおさらです。隣に聞ける先輩がいない分、自分の代わりに段取りを覚えていてくれる1枚が、いちばん頼れる相棒になります。
runbookに入れる4つのブロック
runbookは、次の4ブロックに分けて考えると迷いません。 鳴った瞬間に読むのはいちばん上の「初動」だけ。残りは落ち着いてから順に下りていきます。
- 初動：最初の3〜5分で何をするか（落ち着く・影響範囲を見る・時計を見る）
- 切り分け：どこが悪いかを上流から順に絞る
- 連絡：誰に・何を・どの順で伝えるか
- 記録：いつ何をしたかを残す
一度に全部を完璧に書こうとすると、たいてい完成しません。 まずは見出しだけ4つ置いて、思い出せる範囲で中身を埋める。それで十分スタートできます。
ブロック1：初動（最初の3〜5分）
障害対応で最初にやることは、コマンドを打つことではありません。 ひと呼吸おいて、状況を「見る」ことです。
- 深呼吸する：1分焦っても1分早くは直りません。まず落ち着く、をあえて手順に書きます。
- 影響範囲を確認する：全面ダウンか、一部の機能だけか。全員か、特定のユーザーだけか。ここで対応の重さが決まります。
- 発生時刻をメモする：「気づいた時刻」を最初に書き留めます。後の記録と連絡の起点になります。
- 直近の変更を思い出す：「さっき何かリリースした／設定を変えた」がないか。原因の半分くらいはここに隠れています。
初動の目的は、原因を当てることではなく、「これはどのくらいヤバいのか」を握ることです。 ここが握れていれば、この後の連絡も切り分けも、落ち着いて進められます。
なお、心当たりの変更があるなら、丁寧に切り分けるより先に「直近の変更を戻す（ロールバック）」を試すのが初手になることもよくあります。机上の順序にこだわらず、戻して直るなら戻す——それから次のブロックで腰を据えて切り分けても遅くありません。
ブロック2：切り分け（上流から順に）
切り分けは、あちこち手当たり次第に見ると迷子になります。 利用者に近いところから、システムの奥へと、一方向に進むのがコツです。
おおまかな順番の例です（自分の構成に合わせて並べ替えてください）。
- 外形（ユーザー目線）：本当に見えないか。自分のスマホ・別回線でも再現するか。自分だけの問題ではないか。
- ネットワーク・DNS・証明書：名前解決はできるか。SSL証明書が切れていないか。
- Webサーバー／アプリ：プロセスは生きているか。エラーログに何が出ているか。
- データベース・外部連携：DBに接続できるか。決済や外部APIなど、頼っている先が落ちていないか。
- リソース：ディスク使用率が100%になっていないか。メモリ・CPUは振り切れていないか。
各ステップに「見る場所（ログのパス・コマンド・管理画面のURL）」を具体的に書いておくと、本番で迷いません。 「どこを見ればいいか」を障害の最中に思い出すのが、いちばん時間を食うところだからです。
ひとつ注意です。原因を調べる手を動かす前に、今からやる操作は戻せるかを一拍考えてください。再起動やキャッシュ削除は有効ですが、戻し方とセットで。本番をいじるなら、できる範囲で先に状態を記録してからにします。
ブロック3：連絡（誰に・何を・どの順で）
技術的に直すことと同じくらい、「ちゃんと連絡が来ている」という安心を相手に届けることが大切です。 原因が分からない段階でも、第一報は出せます。
第一報のテンプレ（埋めるだけ）：
【障害連絡・第一報】
発生確認：◯時◯分ごろ
事象：（例）トップページが表示できない
影響範囲：（例）全ユーザー／一部機能のみ／調査中
現状：原因を調査中です
次の連絡：◯時ごろ、または状況が変わり次第
対応者：（自分の名前）ポイントは3つです。
- 原因が分からなくても、まず出す：「調査中です」だけでも、相手の不安は大きく減ります。
- 次にいつ連絡するかを書く：これがあると、相手から「どうなった？」の催促が来なくなり、対応に集中できます。ただし、予告した時刻に追われて復旧作業が止まっては本末転倒です。間に合わなければ「まだ調査中・次は◯時」の一行だけ送ればOK。それで十分間がもちます。
- 連絡先の順番を決めておく：第一報は誰に、エスカレーションは誰に。深夜なら誰の電話番号か。runbookに名前と連絡先を書いておきます。
一人運用だと「自分で抱えて、直ってから報告すればいい」と思いがちですが、途中経過の一報があるだけで、周りの空気はずいぶん変わります。
ブロック4：記録（時系列で1行ずつ）
記録は、後回しにすると必ず忘れます。 完璧な議事録は要りません。「◯時◯分、何をした／何が分かった」を1行ずつ残すだけで十分です。
01:31 利用者から「表示されない」と連絡。確認したらトップが真っ白
01:33 別回線でも再現。自分だけの問題ではない
01:35 第一報を送信（影響範囲：全ユーザー）
01:40 ディスク使用率100%を確認。ログが肥大化していた
01:48 古いログを退避し復旧を確認
01:55 復旧の連絡を送信この1行ログには、3つの効果があります。
- 対応中の自分が混乱しない：「さっき何を試したっけ」が一目で分かります。
- 連絡がラクになる：報告は、このログをつなげればほぼ完成します。
- 次に活きる：これがそのまま、後日の振り返り（ポストモーテム）と再発防止の材料になります。
タイムスタンプは、ターミナルやチャットに残った時刻をコピーするだけでも構いません。 「丁寧に書く」より「とにかく残す」を優先しましょう。
そして一人運用では、対応中にこの記録まで手が回らない場面が必ずあります。復旧を優先したいときは、書くのを後回しにしてOKです。時刻はあとからターミナルの履歴やチャットの送信時刻を見れば復元できます。せめて「ヤバいと思った時刻」だけ口頭メモに残しておけば、落ち着いてから1行ログに起こせます。記録のために復旧が遅れるのは本末転倒——書くのは「あとから」でいいのです。
影響：1枚あると、何が変わるか
runbookがあると、対応そのものが速くなるのはもちろんですが、いちばん変わるのは気持ちのほうです。
- 鳴った瞬間に「まず初動の3手」を読めばいいと分かっているので、パニックになりにくい。
- 連絡の型があるので、「何て報告しよう」で固まらない。
- 記録が残るので、次に同じ障害が来たとき「前はこう直した」をたどれる。
- 自分が休みの日に別の人が見ても、最低限のところまで進められる。属人化が少しずつほどけていきます。
逆に、runbookがないまま記憶だけで戦い続けると、毎回ゼロから思い出すことになり、対応する人が代わるたびに品質が振れます。 1枚にしておくことは、未来の自分と、いつか引き継ぐ誰かへの贈り物です。
明日やること：A4一枚から始める
いきなり全システム分は作らなくて大丈夫です。 明日できる、いちばん小さな一歩はこれです。
- 今いちばん止まったら困るシステムを1つ選ぶ。
- 紙でもドキュメントでもいいので、「初動・切り分け・連絡・記録」の4見出しを書く。
- 連絡先の名前と電話番号だけ、今すぐ埋める（これは障害中に調べると遅い）。番号を直接書くのが気になるなら、別の安全な場所（社内名簿など）への参照でも構いません。退職・異動で古くなりやすいので、更新は四半期に一度の目視チェックだけと決めておくと、負担なく保てます。
- 切り分けの「見る場所（ログのパス・コマンド・管理画面URL）」を、思い出せる範囲で書く。
- 残りは、次に何か起きたときに1行ずつ追記して育てる。
完成版を目指さないのがコツです。 4見出しと連絡先だけでも、それは立派なrunbookの第一稿です。
障害対応runbook チェックリスト
これは「障害中にやること」ではなく、落ち着いているときに作ったrunbookの品質を確かめるための項目です。負荷は低いので、コピーして自分のrunbookに当てて「○／要追記」を付けてみてください。
10項目あると一人だと後回しになりがちなので、まずこの3つだけ埋まれば第一稿として合格という最低ラインを先に示します。
- 鳴った瞬間に読む「最初の3手」が、いちばん上にあるか
- 連絡先の名前・電話番号（または参照先）と連絡の順番が書いてあるか
- 各切り分けステップに「見る場所（パス・コマンド・URL）」が書いてあるか
ここから先は、余裕があるときに少しずつ。
- 影響範囲を確認する手順が初動に入っているか
- 心当たりの変更を「先に戻す（ロールバック）」選択肢に触れているか
- 切り分けが、利用者に近い側から奥へ一方向に並んでいるか
- 第一報のテンプレ（埋めるだけの文面）があるか
- 「次にいつ連絡するか」を伝える欄があるか（間に合わなければ一行でよい、も含めて）
- 記録は「あとから書いてもよい」と分かる置き場所になっているか
- 本番操作の前に「戻せるか」を確認する一言が入っているか
全部に○が付かなくても大丈夫です。 上の3つの最低ラインさえ埋まっていれば、何もないときよりずっと落ち着いて対応できます。
最後に
障害の電話が怖いのは、あなたが真面目に「ちゃんと直さなきゃ」と思っているからです。 その責任感は、すでに現場を支えています。
runbookは、その責任を一人で抱え込まないための道具です。 今日は4つの見出しと連絡先だけでも書いておきましょう。次に鳴ったとき、その1枚が「ひとりじゃない」と背中を押してくれます。
一度に完璧な手順書を作らなくて大丈夫です。 4つの見出しを書いた時点で、もうあなたの現場は、昨日より少しだけ落ち着いて夜を越せます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。