# インシデント対応の実務ガイド2026：Incident Commander・Runbook・ポストモーテム・オンコールをSRE流に設計する

> 本番障害に強いチームの作り方を、Google SREの公式知見に忠実に解説。Incident Commanderモデル、SEV1〜4の重大度設計、検知→緩和→検証→広報のRunbookテンプレート、非難なきポストモーテム、オンコール衛生（toil/アラート疲れ削減）、MTTD/MTTRとエラーバジェットまで、運用込みで設計する実務知を実コードとテンプレートで示します。

- 公開日: 2026-06-24
- 著者: 友田 陽大
- タグ: アーキテクチャ設計, AWS, TypeScript, サーバーレス
- URL: https://tomodahinata.com/blog/incident-response-runbook-postmortem-oncall-sre-guide

## 要点

- インシデント対応の品質は障害発生後ではなく、事前に決めた役割・手順・基準で決まる
- Incident Commanderモデルで役割を分離し、Opsだけがシステムを触り、迷ったら早く宣言する
- Runbookは検知→トリアージ→緩和→検証→広報の定型で、原因究明より止血を先にする
- 非難なきポストモーテムは基準を事前定義し、アクションアイテムをSMARTに追跡する
- オンコール衛生（2件/12時間・50/25%ルール・toil削減）とMTTD/MTTR・エラーバジェットで改善先をデータで決める

---

「障害が起きたら、その場でなんとかする」——これは**運用ではなく、運頼み**です。本番でお金が動くシステムを一人で設計・実装し、その**信頼性・可観測性レイヤーを主導**してきた経験から断言します。インシデント対応の品質は、障害が起きてから決まるのではなく、**起きる前に決めた「役割・手順・基準」で決まります**。

この記事は、Google SREの公式知見（[Managing Incidents](https://sre.google/sre-book/managing-incidents/) / [Postmortem Culture](https://sre.google/sre-book/postmortem-culture/) / [Incident Response（Workbook）](https://sre.google/workbook/incident-response/) / [Being On-Call](https://sre.google/sre-book/being-on-call/)）に忠実に、しかし公式より**「いつ・どう・なぜ」の判断軸を厚く**して、現場で明日から使えるテンプレートとコードに落とすものです。私が[環境分野のサーバーレス決済プラットフォーム](/case-studies/payment-platform-reliability)で実際に組んだ運用（CloudWatch Alarms + Slack通知 + 構造化ログ、AWS Backup / Vault Lock / PITRによるDR）を例に進めます。

> この記事の射程：**「監視を整えた、その先」**。何を計測するか（メトリクス・トレース・ログ）は[可観測性の柱の記事](/blog/opentelemetry-observability-production-tracing-metrics-logs)に書きました。本稿はその上で、**人と組織が障害にどう動くか**を設計します。可観測性が「見える化」なら、インシデント対応は「見えたものに、誰が・どう動くか」です。

## 0. 全体像：インシデント対応は「5つの部品」でできている

場当たり対応が破綻するのは、毎回ゼロから判断しているからです。本番に強いチームは、次の5部品を**事前に**用意しています。混同すると事故ります。

| 部品 | 役割 | この記事の章 |
| --- | --- | --- |
| **指揮系統** | 誰が判断し、誰が手を動かし、誰が伝えるか | §1（Incident Commander） |
| **重大度基準** | 「これはインシデントか？」を即断する物差し | §2（SEV1〜4） |
| **Runbook** | 検知→緩和→検証→広報の定型手順 | §3 |
| **検知→対応の接続** | アラートがRunbookを指す配線 | §4 |
| **ポストモーテム** | 障害を組織の学習資産に変える | §5 |

加えて、これらを**回し続ける土台**がオンコール運用（§6）と、改善を駆動する指標（§7）です。順番に意味があります。**役割を決め、基準を決め、手順を書き、アラートに繋ぎ、終わったら学ぶ**。以下この流れで進めます。

---

## 1. Incident Commanderモデル：その場対応をやめ、役割で動く

複数人が同じログを見て、それぞれ勝手に再起動やデプロイを始める——これが**最悪の本番対応**です。Google SREは[Managing Incidents](https://sre.google/sre-book/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](https://sre.google/workbook/incident-response/) は良いインシデント管理を **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](https://sre.google/sre-book/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を同じ骨格に揃えます。フォーマットが揃うと、当番は「次にどこを見ればいいか」を迷いません。

```markdown
# 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の中核（緩和〜検証）はこうなります。

```markdown
## 3. Mitigate（緩和）
- [ ] キュー深さを確認（SQS ApproximateNumberOfMessages / DLQ件数）
- [ ] コンシューマが落ちていないか（ECSタスク数 / エラーログの例外）
- [ ] 第一手: コンシューマをスケールアウトして滞留を吐き出す
- [ ] 落ちている場合: 直前デプロイをロールバック（原因コミットの切り戻し）
- ⚠️ 絶対にやらないこと: 滞留解消のためにイベントを「全消し」する
       → 冪等キーがあるので「全部再処理」が安全。消すと取りこぼす。

## 4. Verify（検証）
- [ ] キュー深さが平常値に戻り 10 分継続
- [ ] DLQ のイベントを再投入（冪等キーで二重課金は構造的に発生しない）
- [ ] 課金台帳とプロバイダ側の件数を突合（差分ゼロを確認）
```

ここで効くのが**冪等性（idempotency）**です。決済イベントに決定的な冪等キーを持たせ、処理側で重複を吸収していれば、「滞留したイベントを全部再処理する」が**安全な緩和策**になります。この設計があったからこそ、私の決済プラットフォームでは**本番二重課金0件**を維持できました。Runbookの緩和策は、**システムの設計（冪等性・ロールバック容易性）に支えられて初めて安全**です。手順だけ立派でも、土台がなければ「再処理＝二重課金」になりかねません。

### 3-3. もう一例：DB接続枯渇（SEV1）

サーバーレス構成で見落としがちなのが**DB接続の枯渇**です。Lambdaの同時実行が跳ね、各実行が接続を握ると、上限に達して**全APIが5xx**になります。

```markdown
## 3. Mitigate（緩和）
- [ ] RDS の DatabaseConnections メトリクスが上限に張り付いていないか
- [ ] 第一手: 暴走している呼び出し元をレート制限 / 一時的に同時実行数を絞る
- [ ] 第二手: アイドル接続の強制クローズ、コネクションプロキシ（RDS Proxy）経由へ
- 恒久対策（緩和ではない / ポストモーテムのAIへ）:
     接続プールの上限設計、サーバーレス前提のプロキシ常設

## 4. Verify（検証）
- [ ] 接続数が安全域に戻り、エラー率が SLO 内へ復帰して 15 分継続
```

> **Runbookは「生もの」**。古いRunbookは無いより危険です。各Runbookに**オーナーと最終更新日**を必ず書き、ポストモーテムのたびに更新する。これを回す仕組みが§5・§6です。

---

## 4. 検知 → 対応の接続：アラートは必ずRunbookを指す

可観測性（[OpenTelemetryで何をどう計測するか](/blog/opentelemetry-observability-production-tracing-metrics-logs)、[AWS環境でのSRE実装](/blog/aws-observability-opentelemetry-sre-ecs)）を整えても、**アラートとRunbookが繋がっていなければ**、当番は鳴った瞬間に「で、どうすれば？」で固まります。鉄則は一つ——**すべてのページングアラートは、対応するRunbookへのリンクを持つ**。

[Being On-Call](https://sre.google/sre-book/being-on-call/)は**アラート疲れ（alert fatigue）**を警告します。低優先のアラートが氾濫すると「**serious alerts to be treated with less attention than necessary**（重大なアラートが必要な注意を払われなくなる）」。目指すは「**1:1 alert/incident ratio**（アラートとインシデントが1対1）」——**鳴ったら必ず人が動くべき**、を満たすアラートだけをページングにします。

```ts
// 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](https://sre.google/sre-book/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**（インシデントが起きる前に基準を定義せよ）」。私が使う基準は次の通りです。

```text
✅ ポストモーテムを書く（いずれか1つでも該当）
   ・ユーザー影響のあるダウン/劣化が閾値を超えた（SEV1・SEV2は原則必須）
   ・いかなる種類であれデータ損失が発生した
   ・オンコールが手動介入した（ロールバック、トラフィック迂回など）
   ・解決までの時間が閾値を超えた
   ・監視が検知できず、人手で気づいた（＝監視のバグ。最重要級）

❌ 書かなくてよい
   ・SEV4 の内部のみ・影響なし（チケットで十分）
```

「監視が検知できず人手で気づいた」を基準に入れるのが肝です。これは**可観測性自体の欠陥**であり、放置すると次は気づけません。

### 5-3. ポストモーテム・テンプレート（穴埋め式）

```markdown
# ポストモーテム: <タイトル> (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](https://sre.google/sre-book/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**（認知機能が低下する）」状態での判断ミスを防ぎます。**疲れた人間に複雑な即興を求めない**——これが設計の要点です。

```yaml
# 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行で。

1. **Incident Commanderモデル**で役割を分離する。ICは判断、Opsだけがシステムを触る、Commsが伝える。Live Doc と指揮所を「唯一の真実」に。迷ったら**早く宣言**する。
2. **SEV1〜4**で重大度を即断できる物差しを持つ。応答目標は**SLOから逆算**。
3. **Runbook**は検知→トリアージ→緩和→検証→広報の定型。**止血が原因究明より先**。手順は冪等性・ロールバックという設計に支えられて初めて安全。
4. **非難なきポストモーテム**で障害を学習資産に。基準は事前定義、アクションアイテムは**SMART**で追跡。主語はシステム。
5. **オンコール衛生**（2件/12時間、50/25%ルール、toil削減）と**MTTD/MTTR・エラーバジェット**で、改善先をデータで決める。

「一人 × 生成AI（Claude Code）で、速く・安く・安全に」——私はアプリケーションからインフラ、そして**運用設計まで一気通貫**で引き受けます。本記事の知見の出どころは、決済の信頼性レイヤーを主導し**本番二重課金0件**を実現した[サーバーレス決済プラットフォーム](/case-studies/payment-platform-reliability)です。インシデント対応・Runbook整備・オンコール設計を含む**運用込みの開発**のご相談は、[お問い合わせ](/contact)からどうぞ。