障害対応の初動テンプレート：PjMが現場を動かす実務ガイド
こんばんは！IT業界で働くアライグマです！
プロダクション障害は「初動の質」でその後の復旧時間も再発率も大きく変わります。本記事では、PjM視点での意思決定フレームと、現場を動かす実務テンプレートを紹介します。
前提と目的：安全停止と影響最小化
障害時の最優先は「顧客影響の最小化」と「被害の拡大防止」です。原因究明より先に、影響範囲を限定し被害を止める意思決定を行います。
- 目的：MTTD/MTTRの短縮と、顧客影響の最小化
- 対象：プロダクション環境でのサービス障害全般
- PjMの役割：判断基準の提示、ステークホルダー調整、連絡と記録の標準化
意思決定の基準：ユーザー影響が続くか／データ毀損の恐れがあるかで「安全停止」を優先。
初動フロー：T+0〜30分の行動順序
以下は即時に回せる初動チェックリストです（Slackチャンネルのテンプレ化推奨）。
- 検知：監視/通報を確認し、インシデント宣言（Severityを暫定で設定）。
- 安全化：影響を止める（機能停止、トラフィック遮断、ロールバック）。
- 指揮系統：IC(Incident Commander)を指名。PjMはコミュニケーション担当に。
- 状況共有：ステークホルダーへ初報（何が/誰に/どれほど/次報予定）。
- 暫定対応：復旧の仮説を立て、最小リスクから試行。
- 記録：時系列ログ（時刻・判断・実施）を残す。
参考書籍： 体系的に学ぶ 安全なWebアプリケーションの作り方
意思決定の基準：顧客影響>原因解明。安全化→暫定復旧→恒久対応の順序を厳守。
ロールと責務：小規模チームの分担
役割を明確にすると、判断と作業が並行できます。
- IC（指揮）：優先順位と承認、切り戻し判断、完了宣言。
- Ops（対処）：復旧作業、監視ボード操作、ロールバック実施。
- Comm（連絡）：初報・定時報・完了報の作成と送信。社内外の粒度調整。
- Rec（記録）：時系列ログ、エビデンス収集、後日レビュー準備。
学びを体系化するなら： ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ
意思決定の基準：1人2役まで。ICは作業しない（判断に専念）。
連絡テンプレ：初報/定時報/完了報
コピペで使える最低限のテンプレです。
【初報】 ・発生時刻： ・影響範囲： ・現象： ・暫定Severity： ・対応状況：安全化対応中／暫定復旧中 ・次報予定：XX:YY 【定時報】 ・前回からの変化： ・現在のSeverity： ・追加の影響：有／無（内容） ・次報予定：XX:YY 【完了報】 ・復旧時刻： ・原因： ・対応：暫定／恒久 ・再発防止：有（チケットNo）
情報設計の参考： SECOND BRAIN（セカンドブレイン） 時間に追われない「知的生産術」
意思決定の基準：次報予定時刻を必ず明示。内容が未確定でも沈黙しない。
監視と計測：復旧のKPIを揃える
復旧判断は感覚ではなく指標で行います。
- 主要KPI：MTTD、MTTR、エラーレート、成功率、遅延P95
- 復旧判定：直近N分の指標が正常範囲内（過去30日ベースライン）
- ポストモーテム：事実ベースで責任追及ではなく学習にフォーカス
自動化の足がかりに： 作業が一瞬で片付く Python自動化仕事術
意思決定の基準：KPIが基準内に戻るまで「復旧宣言」を出さない。
変更管理とロールバック：安全側に倒す
小さく戻せる構成と運用をデフォルトに。
- リリース：段階的リリース＋即時切戻しの手段を用意
- 設定：機能フラグで切り替え可能にし、コンフィグ変更を先行
- データ：バックアップ検証、リカバリ手順の演習
実務で効く基礎： リファクタリング 既存のコードを安全に改善する（第2版）
意思決定の基準：不確実性が高い場合は「切り戻しコストが低い案」を優先。
再発防止：恒久対応と学習の仕組み
事後対応は「仕組み」に落とし込みます。
- 恒久対応：チケット化し、期限と責任者を明確化
- 演習：定期的なGameDayで手順の磨耗を防ぐ
- 教育：ナレッジの共有、オンボーディング更新
個人装備のセキュリティも： YubiKey 5C NFC
意思決定の基準：再発防止は「行動の変更」まで定義して完了とする。
内部リンク：関連する読み物
意思決定の基準：読者の次アクション（参照先）を必ず用意。
まとめ
障害対応は「安全停止→暫定復旧→恒久対応」の順序が命です。PjMは判断基準とコミュニケーションを整備し、現場のボトルネックを取り除くことに集中します。今日、社内に初動テンプレを1枚流すところから始めてみてください。
