「障害が起きたら、その場でなんとかする」——これは運用ではなく、運頼みです。本番でお金が動くシステムを一人で設計・実装し、その信頼性・可観測性レイヤーを主導してきた経験から断言します。インシデント対応の品質は、障害が起きてから決まるのではなく、起きる前に決めた「役割・手順・基準」で決まります。
この記事は、Google SREの公式知見（Managing Incidents / Postmortem Culture / Incident Response（Workbook） / Being On-Call）に忠実に、しかし公式より**「いつ・どう・なぜ」の判断軸を厚く**して、現場で明日から使えるテンプレートとコードに落とすものです。私が環境分野のサーバーレス決済プラットフォームで実際に組んだ運用（CloudWatch Alarms + Slack通知 + 構造化ログ、AWS Backup / Vault Lock / PITRによるDR）を例に進めます。
この記事の射程：「監視を整えた、その先」。何を計測するか（メトリクス・トレース・ログ）は可観測性の柱の記事に書きました。本稿はその上で、人と組織が障害にどう動くかを設計します。可観測性が「見える化」なら、インシデント対応は「見えたものに、誰が・どう動くか」です。
0. 全体像：インシデント対応は「5つの部品」でできている
場当たり対応が破綻するのは、毎回ゼロから判断しているからです。本番に強いチームは、次の5部品を事前に用意しています。混同すると事故ります。
| 部品 | 役割 | この記事の章 |
|---|---|---|
| 指揮系統 | 誰が判断し、誰が手を動かし、誰が伝えるか | §1（Incident Commander） |
| 重大度基準 | 「これはインシデントか？」を即断する物差し | §2（SEV1〜4） |
| Runbook | 検知→緩和→検証→広報の定型手順 | §3 |
| 検知→対応の接続 | アラートがRunbookを指す配線 | §4 |
| ポストモーテム | 障害を組織の学習資産に変える | §5 |
加えて、これらを回し続ける土台がオンコール運用（§6）と、改善を駆動する指標（§7）です。順番に意味があります。役割を決め、基準を決め、手順を書き、アラートに繋ぎ、終わったら学ぶ。以下この流れで進めます。
1. Incident Commanderモデル：その場対応をやめ、役割で動く
複数人が同じログを見て、それぞれ勝手に再起動やデプロイを始める——これが最悪の本番対応です。Google SREはManaging Incidentsで、消防由来の Incident Command System（ICS） を採用しています。核心は「everybody involved in the incident knows their role and doesn't stray onto someone else's turf（全員が自分の役割を理解し、他人の領分に踏み込まない）」という責任の明確な分離です。
1-1. 4つの役割
SRE Workbook は良いインシデント管理を 3C（Coordinate / Communicate / Control） と表現します。これを担うのが次の役割です。
| 役割 | 一言で | やること | やらないこと |
|---|---|---|---|
| Incident Commander（IC） | 司令塔 | 全体状況の把握、役割の割り当て、意思決定、障害物の除去。委任していない役割はICが兼任 | 自分でシステムをいじる（手を動かさない） |
| Operations Lead（Ops） | 唯一の実行者 | 緩和・修復の実作業。「the only group modifying the system during an incident（障害中にシステムを変更する唯一の集団）」 | 全体調整・外部広報 |
| Communications Lead（Comms） | 対外の顔 | ステークホルダーへの定期更新、ドキュメントの正確性維持 | システム変更 |
| Planning Lead | 後方支援 | 長期課題、バグ起票、ハンドオフ準備、平常からの逸脱の追跡 | 直接の緩和作業 |
小規模チーム（あるいは個人）では、最初はICが全役割を兼ねるのが正しい姿です。重要なのは人数ではなく「いま自分は何の帽子をかぶっているか」を全員が認識していること。規模が大きくなったら委任して分離していきます。
1-2. 唯一の真実：Live Incident Document と Command Post
ICSが機能する土台は2つの「単一の真実」です。
- Recognized Command Post（指揮所）：ステークホルダーが集まる指定の連絡チャネル。Slackなら専用チャンネルを切る。「どこで会話しているか」を探す時間をゼロにします。
- Live Incident State Document（生きた障害ドキュメント）：公式が「most important responsibility is to keep a living incident document（最重要の責務は生きた障害ドキュメントの維持）」と言うほど中核。複数人が同時編集できる場所（Google Docs等）に置きます。
このドキュメントは、後の§5でそのままポストモーテムの素材になります。リアルタイムに書くからこそ、時系列が正確に残る。これが「あとで思い出して書く」との決定的な差です。
1-3. ハンドオフは「明示的な引き継ぎ」で
長時間の障害では指揮が交代します。公式が強調するのは曖昧な交代の禁止です。「You're now the incident commander, okay?」と明示的に宣言し、相手の確認を取ってから前任は離脱する。「なんとなく交代したつもり」が、指揮の空白＝二重対応や放置を生みます。
判断軸：いつICSを起動するか？ Workbookの教訓は明快です。「迷ったら宣言する（declare early）」。あるケーススタディでは「did not declare an incident when problems first appeared（問題が出た時点で宣言しなかった）」ことが解決遅延を招きました。宣言のコストは「Slackチャンネルを1つ切る」程度。過小宣言のほうが圧倒的に高くつきます。
2. 重大度（Severity）：SEV1〜4で「即断」できる物差しを持つ
「これは緊急か？」を毎回その場で議論していると、判断そのものが障害になります。重大度を事前に定義し、検知した人が5秒で当てはめられる状態を作ります。重大度は「対応の速さ・関わる人・連絡の範囲」を一意に決めるためのものです。
| 重大度 | 定義（影響） | 一次応答目標 | エスカレーション | 例 |
|---|---|---|---|---|
| SEV1 | 全体停止 / データ損失 / 決済の二重課金・取りこぼし | 即時（ページ） | IC即任命 + 関係チームリード + 経営報告 | 決済Webhookが全件失敗、本番DB接続枯渇で全API 5xx |
| SEV2 | 主要機能の重大な劣化（広範なユーザー影響） | 数分以内 | オンコール一次 + 必要に応じIC | 一部リージョンでログイン不可、課金は通るが領収書未発行 |
| SEV3 | 限定的・回避策あり / 単一機能の劣化 | 営業時間内 | オンコール一次が対応、必要時に起票 | 管理画面のCSV出力が失敗、非クリティカルなジョブ遅延 |
| SEV4 | ユーザー影響ほぼなし / 内部のみ | 翌営業日 | チケット化のみ | ステージングの軽微なエラー、ログのノイズ増加 |
数値（応答目標）は自チームのSLOから逆算して決めます。たとえば99.99%可用性なら四半期あたり許容ダウンは約13分。Being On-Callはこの水準を満たすために「paging response times（ページ応答時間）を重要サービスで5分、緊急度の低いもので30分」と例示しています。「うちのSEV1は何分以内に人が触り始めるか」を、SLOの数式から決める——ここが場当たりとの分かれ目です。
私が決済プラットフォームで設計した重大度の軸は、ユーザー数ではなく**「お金の整合性」**でした。表示が崩れるより、課金が一件でも狂うほうが上位。重大度の物差しは、そのプロダクトで「最も壊してはいけないもの」を映すべきです。
3. Runbook設計：検知 → トリアージ → 緩和 → 検証 → 広報
Runbookは「寝起きの当番でも、考えずに辿れる手順書」です。良いRunbookは創造性を要求しません。Workbookの大原則は「First responders must prioritize mitigation above all else（一次対応者は何よりもまず緩和を優先せよ）」。原因究明より止血が先です。公式の優先順位は「Stop the bleeding, restore service, and preserve the evidence（止血し、復旧し、証拠を保全する）」。
3-1. Runbookの骨格（テンプレート）
すべてのRunbookを同じ骨格に揃えます。フォーマットが揃うと、当番は「次にどこを見ればいいか」を迷いません。
# Runbook: <アラート名 / 障害シナリオ>
最終更新: 2026-06-24 / オーナー: <チーム> / 関連SLO: <SLO名>
## 0. このRunbookが対象とする症状
- 発火するアラート: <Alarm名 / メトリクス条件>
- 想定される重大度: SEV2（影響が全課金に及べばSEV1へ昇格）
## 1. Detect（検知）— 何が起きているか確認
- ダッシュボード: <URL>
- 確認クエリ/ログ: <構造化ログのフィルタ式>
- 「本物か」の判定: 単発スパイクか継続か、影響範囲は？
## 2. Triage（トリアージ）— 重大度を確定しICを立てる
- §2の表で重大度を判定
- SEV1/2 なら: 障害チャンネルを作成、ICを宣言、Live Docを開く
## 3. Mitigate（緩和）— まず止血する（原因究明より先）
- [ ] 第一手（最速で影響を止める）: 例) 機能フラグでOFF / 直前デプロイをロールバック
- [ ] 第二手: 例) スケールアウト / レート制限 / フェイルオーバー
- 各手順は「コピペで実行できるコマンド」で書く
## 4. Verify（検証）— 本当に直ったか
- 復旧の判定条件（メトリクスが閾値以下に N 分継続）
- 取りこぼした処理のリカバリ（再処理・補償トランザクション）
## 5. Comms（広報）— 誰に何を伝えるか
- 初報テンプレ / 定期更新の頻度（SEV1は30分ごと等）/ 復旧報
- ステータスページ更新の要否
## 6. Postmortem（事後）
- ポストモーテム要否（§5の基準）/ Live Doc へのリンク
3-2. 実例：決済Webhookのバックログ滞留（SEV2→SEV1候補）
決済プロバイダからのWebhook処理が詰まり、課金イベントが未処理のまま積み上がる——お金が動くシステムで最も怖い症状の一つです。具体化したRunbookの中核（緩和〜検証）はこうなります。
## 3. Mitigate（緩和）
- [ ] キュー深さを確認（SQS ApproximateNumberOfMessages / DLQ件数）
- [ ] コンシューマが落ちていないか（ECSタスク数 / エラーログの例外）
- [ ] 第一手: コンシューマをスケールアウトして滞留を吐き出す
- [ ] 落ちている場合: 直前デプロイをロールバック（原因コミットの切り戻し）
- ⚠️ 絶対にやらないこと: 滞留解消のためにイベントを「全消し」する
→ 冪等キーがあるので「全部再処理」が安全。消すと取りこぼす。
## 4. Verify（検証）
- [ ] キュー深さが平常値に戻り 10 分継続
- [ ] DLQ のイベントを再投入（冪等キーで二重課金は構造的に発生しない）
- [ ] 課金台帳とプロバイダ側の件数を突合（差分ゼロを確認）
ここで効くのが冪等性（idempotency）です。決済イベントに決定的な冪等キーを持たせ、処理側で重複を吸収していれば、「滞留したイベントを全部再処理する」が安全な緩和策になります。この設計があったからこそ、私の決済プラットフォームでは本番二重課金0件を維持できました。Runbookの緩和策は、システムの設計（冪等性・ロールバック容易性）に支えられて初めて安全です。手順だけ立派でも、土台がなければ「再処理＝二重課金」になりかねません。
3-3. もう一例：DB接続枯渇（SEV1）
サーバーレス構成で見落としがちなのがDB接続の枯渇です。Lambdaの同時実行が跳ね、各実行が接続を握ると、上限に達して全APIが5xxになります。
## 3. Mitigate（緩和）
- [ ] RDS の DatabaseConnections メトリクスが上限に張り付いていないか
- [ ] 第一手: 暴走している呼び出し元をレート制限 / 一時的に同時実行数を絞る
- [ ] 第二手: アイドル接続の強制クローズ、コネクションプロキシ（RDS Proxy）経由へ
- 恒久対策（緩和ではない / ポストモーテムのAIへ）:
接続プールの上限設計、サーバーレス前提のプロキシ常設
## 4. Verify（検証）
- [ ] 接続数が安全域に戻り、エラー率が SLO 内へ復帰して 15 分継続
Runbookは「生もの」。古いRunbookは無いより危険です。各Runbookにオーナーと最終更新日を必ず書き、ポストモーテムのたびに更新する。これを回す仕組みが§5・§6です。
4. 検知 → 対応の接続：アラートは必ずRunbookを指す
可観測性（OpenTelemetryで何をどう計測するか、AWS環境でのSRE実装）を整えても、アラートとRunbookが繋がっていなければ、当番は鳴った瞬間に「で、どうすれば？」で固まります。鉄則は一つ——すべてのページングアラートは、対応するRunbookへのリンクを持つ。
Being On-Callは**アラート疲れ（alert fatigue）**を警告します。低優先のアラートが氾濫すると「serious alerts to be treated with less attention than necessary（重大なアラートが必要な注意を払われなくなる）」。目指すは「1:1 alert/incident ratio（アラートとインシデントが1対1）」——鳴ったら必ず人が動くべき、を満たすアラートだけをページングにします。
// CloudWatch アラームを「Runbook付き」で定義する（CDK / TypeScript）
// 意図: アラートに必ず runbookUrl を持たせ、検知と対応を構造的に接続する
import { Alarm, ComparisonOperator, TreatMissingData } from "aws-cdk-lib/aws-cloudwatch";
import { SnsAction } from "aws-cdk-lib/aws-cloudwatch-actions";
const webhookBacklog = new Alarm(this, "WebhookBacklogHigh", {
metric: webhookQueueDepthMetric,
threshold: 1_000, // 平常値から逆算した「人が動くべき」閾値
evaluationPeriods: 3, // 単発スパイクで鳴らさない（誤検知でアラート疲れを招かない）
comparisonOperator: ComparisonOperator.GREATER_THAN_THRESHOLD,
treatMissingData: TreatMissingData.NOT_BREACHING,
// ★ アラーム説明に Runbook と重大度を埋め込む。通知から1クリックで手順へ。
alarmDescription: [
"SEV2: 決済Webhookの滞留。全課金に波及するなら SEV1 へ昇格。",
"Runbook: https://runbooks.internal/payment-webhook-backlog",
].join("\n"),
});
webhookBacklog.addAlarmAction(new SnsAction(oncallTopic)); // → Slack へ
Slack通知のペイロードにも、重大度・Runbookリンク・初動の3点を必ず載せます。通知本文が「考える起点」になり、当番は探さずに動けます。これは私が決済基盤で実際に組んだ配線そのものです——CloudWatch Alarm → SNS → Lambda → Slack に構造化ログのコンテキストを添えて流す。「you can't respond to what you can't see（見えないものには対応できない）」を、検知から手順までの一本の線に落とし込みます。
5. 非難なきポストモーテム：障害を「組織の学習」に変える
障害対応のROIは、ポストモーテムで回収されます。Postmortem Cultureは postmortem を「a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring（インシデントとその影響、緩和・解決のための行動、根本原因、再発防止のフォローアップを記した文書）」と定義します。
5-1. 「非難なき（blameless）」の本当の意味
blameless とは「優しくしよう」という話ではありません。公式は「assumes that everyone involved in an incident had good intentions and did the right thing with the information they had（関係者は皆、その時点の情報で善意かつ正しく行動したと仮定する）」と定義します。原因を個人ではなくシステム・プロセスに求める。理由は実利的です——「Removing blame from a postmortem gives people the confidence to escalate issues without fear（非難を取り除けば、人は恐れずに問題をエスカレーションできる）」。犯人探しをするチームは、次の障害を隠します。これが信頼性にとって致命傷です。
5-2. いつ書くか（基準を事前に決める）
公式の最重要メッセージ：「It is important to define postmortem criteria before an incident occurs（インシデントが起きる前に基準を定義せよ）」。私が使う基準は次の通りです。
✅ ポストモーテムを書く（いずれか1つでも該当）
・ユーザー影響のあるダウン/劣化が閾値を超えた（SEV1・SEV2は原則必須）
・いかなる種類であれデータ損失が発生した
・オンコールが手動介入した（ロールバック、トラフィック迂回など）
・解決までの時間が閾値を超えた
・監視が検知できず、人手で気づいた（＝監視のバグ。最重要級）
❌ 書かなくてよい
・SEV4 の内部のみ・影響なし（チケットで十分）
「監視が検知できず人手で気づいた」を基準に入れるのが肝です。これは可観測性自体の欠陥であり、放置すると次は気づけません。
5-3. ポストモーテム・テンプレート（穴埋め式）
# ポストモーテム: <タイトル> (SEV<N>)
状態: Draft / In Review / Final
作成者: <名前> レビュアー: <名前> 日付: 2026-06-24
## サマリー（3行）
何が・どれだけの間・誰に影響したか。
## 影響（Impact）
- 期間: <検知 HH:MM 〜 復旧 HH:MM>
- ユーザー影響: <数値で。憶測ではなく計測値>
- ビジネス影響: <例: 課金遅延 N 件。データ整合性は維持/喪失>
## タイムライン（Live Doc から転記）
- HH:MM アラート発火（自動 / 手動検知の別を明記）
- HH:MM IC 宣言、緩和開始
- HH:MM 緩和完了、検証開始
- HH:MM 復旧確認
## 根本原因（Root Cause）
「なぜ」を 5 回。技術的要因 + プロセス要因の両方を書く。
※ 個人名を主語にしない（「Aさんが消した」ではなく「削除を防ぐガードが無かった」）
## 検知（Detection）
どう気づいたか。自動検知でなかったなら、それ自体がアクションアイテム。
## 対応で良かった点 / 悪かった点
- Went well: 〜
- Went poorly: 〜
- Got lucky（運が良かった点）: 〜 ← 次は運に頼らない仕組みへ
## アクションアイテム（§5-4 の基準で）
| # | 内容 | 種類(予防/緩和/プロセス) | 担当 | 期限 | チケット |
| - | ---- | ----------------------- | ---- | ---- | ------- |
「運が良かった点（where we got lucky）」を明示的に書くのは公式由来の良い習慣です。今回たまたま助かった点は、次は運に頼らない仕組みに変えるべき箇所だからです。
5-4. 良いアクションアイテム vs 悪いアクションアイテム
ポストモーテムの価値はアクションアイテムの質でほぼ決まります。曖昧な反省は何も変えません。
| 観点 | ❌ 悪いAI | ✅ 良いAI |
|---|---|---|
| 具体性 | 「気をつける」「注意を徹底する」 | 「Webhook滞留アラートに自動スケールのRunbookを追加する」 |
| 担当・期限 | 誰がいつやるか不明 | 担当=@yuta、期限=7/15、チケット=OPS-123 |
| 根本/対症 | 「今回は手で再起動した」で終わる | 「接続枯渇を防ぐRDS Proxyを常設し、上限をアラート化」 |
| 検証可能性 | 完了の判定が曖昧 | 「障害ドリルで再現させ、自動緩和が効くことを確認」 |
| 主語 | 個人を責める（「○○が悪い」） | システム/プロセスを直す（「ガードを追加」） |
良いアクションアイテムは SMART（具体的・測定可能・割り当て済み・現実的・期限つき）です。そして起票して期限を切り、追跡するまででワンセット。やりっぱなしのポストモーテムは、ただの作文です。
文化を育てる仕掛けも公式は挙げています：Postmortem of the month（良い事例を全社共有）、Wheel of Misfortune（過去障害のロールプレイ訓練）、優れたポストモーテムへの可視な称賛。「障害を書いた人が報われる」状態が、隠蔽を防ぎます。
6. オンコール衛生：持続可能な当番制を設計する
どんなに良いRunbookとポストモーテムを用意しても、当番が疲弊すれば全部回りません。Being On-Callは、オンコールを「量」と「質」の両面から健全に保てと説きます。
6-1. 量の上限：燃え尽きを構造的に防ぐ
公式の具体的な数字は明快です。
- エンジニアリング時間を最低50%確保。残りのうち「no more than 25% can be spent on-call（オンコールは最大25%）」。これを満たすには単一サイト24/7で最低8名必要。
- 1件のインシデント対応（根本原因分析・修復・ポストモーテム執筆・バグ修正）には約6時間かかる。ゆえに持続可能な上限は「2 per 12-hour on-call shift（12時間シフトあたり2件）」。
この数字が重要なのは、「当番が多すぎる」を感覚でなくデータで判断できるからです。1シフトで毎回3件以上鳴るなら、それは人の根性ではなくアラート設計か信頼性そのものの問題です。
6-2. エスカレーションポリシー：迷ったら上げる
一次（primary）と二次（secondary）を定義します。二次は「fall-through for the pages the primary on-call misses（一次が取りこぼしたページの受け皿）」。明確なエスカレーション経路と「well-defined incident-management procedures（明確に定義された障害対応手順）」がストレスを下げ、ストレスホルモンで「impair cognitive functions（認知機能が低下する）」状態での判断ミスを防ぎます。疲れた人間に複雑な即興を求めない——これが設計の要点です。
# escalation-policy.yaml — エスカレーションを「設定」で表現する例
service: payment-platform
severity_routing:
SEV1:
page: primary_oncall
escalate_after: 5m # 一次が応答しなければ
then: [secondary_oncall, team_lead]
notify: [eng_manager, status_page]
SEV2:
page: primary_oncall
escalate_after: 15m
then: [secondary_oncall]
SEV3:
notify: oncall_channel # ページングはしない（営業時間内対応）
oncall:
rotation: weekly
handoff: "毎週月曜 10:00、未解決インシデントとRunbook更新を引き継ぐ"
compensation: "time-off-in-lieu（公式準拠：当番を金銭/代休で補償）"
6-3. toil（労苦）削減：手作業の根絶こそコスト削減
toil＝手作業で・繰り返しで・自動化可能な運用作業。toilは見えにくいコストです。毎回手で再起動・手でログ集計をしているなら、それは人件費という名の継続課金を払い続けている状態。Runbookの手順がコピペコマンドの羅列なら、それは自動化候補です。公式は、操作過負荷（operational overload）に陥ったチームが一時的に開発側へ「give back the pager（ページャを返す）」ことすら認めます。toil削減は福利厚生ではなくコスト最適化と信頼性向上の本丸です。
オンコールの過少も問題です。公式は「every engineer to be on-call at least once or twice a quarter（全エンジニアが四半期に1〜2回は当番に入る）」を推奨。当番経験が無いと、いざという時に動けません。
7. MTTD / MTTR とエラーバジェット：何を改善するかを数字で決める
「対応が良くなったか」を感覚で語ると改善は止まります。次の指標でどこに投資するかを決めます。
| 指標 | 意味 | これが悪いと… | 効く対策 |
|---|---|---|---|
| MTTD（平均検知時間） | 障害発生→検知まで | 監視の穴。手動発見が常態化 | 可観測性の強化、アラート閾値の見直し |
| MTTR（平均復旧時間） | 検知→復旧まで | 緩和が遅い／属人化 | Runbook整備、自動緩和、ロールバック容易化 |
MTTDが大きいなら可観測性に、MTTRが大きいならRunbookと自動化に投資する——指標が投資先を名指ししてくれます。なお、これらは「平均」ゆえに外れ値に弱い点に注意。少数のSEV1に引きずられるので、重大度別に見るか中央値・パーセンタイルも併用します。
数字は自分のシステムで計測した実測値だけを使うべきです。借り物のMTTRやでっち上げの稼働率は、最初の障害で信頼ごと吹き飛びます。私が公開できるのは、設計の結果として確かに達成した事実——本番二重課金0件のような、検証可能なアウトカムだけです。
そして指標を対応の発火条件に繋ぐのがエラーバジェットです。SLOが99.9%なら、許容されるエラー＝バジェットがある。バジェットを使い切ったら、新機能を止めて信頼性に投資する——「いつ対応モードに入るか」を政治でなくデータで決める仕組みです。これにより「障害対応 vs 機能開発」の綱引きが、感情論から数式に変わります。
8. よくある落とし穴
実際に現場で繰り返し見る失敗を、対策とセットで挙げます。
- ❌ 役割を決めずに全員でログを見る → 同時に複数人がデプロイ・再起動して傷口を広げる。✅ ICを立て、システム変更はOpsに一本化する（§1）。
- ❌ 原因究明から始める → 止血が遅れ被害が拡大。✅ まず緩和（mitigate first）。原因はポストモーテムで。
- ❌ アラートにRunbookが無い → 鳴った瞬間に当番が固まる。✅ 全ページングアラートにRunbookリンクと初動を埋め込む（§4）。
- ❌ アラートを鳴らしすぎる → アラート疲れで重大アラートを見逃す。✅ 「鳴ったら必ず人が動く」だけをページングに（1:1 alert/incident）。
- ❌ ポストモーテムで犯人探し → 次の障害が隠蔽される。✅ blameless徹底。主語はシステム・プロセス（§5）。
- ❌ アクションアイテムを起票しない → 同じ障害が再発。✅ SMARTに書き、期限・担当・チケットで追跡。
- ❌ 障害チャンネルに秘密情報を貼る → 復旧を焦るあまり、APIキー・トークン・顧客PIIをSlackやLive Docに貼ってしまう。✅ 障害広報にも衛生を。認証情報は貼らず参照名で示し、PIIは最小化。チャンネルやドキュメントは後で広く共有される前提で書く。
- ❌ Runbookが古い → 嘘の手順で被害拡大。✅ オーナー・最終更新日を必須化し、ポストモーテムのたびに更新。
- ❌ 当番が毎シフト鳴りっぱなし → 燃え尽き＆離職。✅ 「2件/12時間」を超えたら信頼性かアラート設計の問題と捉える（§6）。
横断的に効くのは4つの非機能要件です。可観測性（見えないものには対応できない）、信頼性（冪等性・ロールバック容易性が緩和策を安全にする）、コスト（toilは継続課金。自動化で消す）、セキュリティ（障害広報の衛生：秘密を貼らない）。インシデント対応は、この4つが交差する場所です。
まとめ：運用は「設計」できる
本番障害に強いチームは、根性ではなく事前設計で強い。要点を最後に5行で。
- Incident Commanderモデルで役割を分離する。ICは判断、Opsだけがシステムを触る、Commsが伝える。Live Doc と指揮所を「唯一の真実」に。迷ったら早く宣言する。
- SEV1〜4で重大度を即断できる物差しを持つ。応答目標はSLOから逆算。
- Runbookは検知→トリアージ→緩和→検証→広報の定型。止血が原因究明より先。手順は冪等性・ロールバックという設計に支えられて初めて安全。
- 非難なきポストモーテムで障害を学習資産に。基準は事前定義、アクションアイテムはSMARTで追跡。主語はシステム。
- オンコール衛生（2件/12時間、50/25%ルール、toil削減）とMTTD/MTTR・エラーバジェットで、改善先をデータで決める。
「一人 × 生成AI（Claude Code）で、速く・安く・安全に」——私はアプリケーションからインフラ、そして運用設計まで一気通貫で引き受けます。本記事の知見の出どころは、決済の信頼性レイヤーを主導し本番二重課金0件を実現したサーバーレス決済プラットフォームです。インシデント対応・Runbook整備・オンコール設計を含む運用込みの開発のご相談は、お問い合わせからどうぞ。