Runbook テンプレ

平常時/異常時の運用を統一し、判断を短時間で再現します。

コピペ用テンプレ

## 平常時

- 日次/週次/月次
- 監視項目と閾値

## 異常時

- アラート受信時の初動（確認順）
- 切り分け（範囲縮小/比較/変更点）

## エスカレーション

- いつ/誰に/何を伝えるか
- 必要情報（影響、暫定対応、次アクション）

## 復旧判断

- 暫定 vs 恒久
- ロールバック判断

## 成功条件（確認観点）の例

- 外形: 主要なユーザー操作が成立する（例: ログイン、保存、決済）
- メトリクス: エラー率が基準値に戻る、キュー滞留が解消する
- ログ: 例外の新規発生が止まり、再発兆候がない

## 連絡先

- オンコール
- 主管部署

記入例（最小）

注: 下記は例示です。監視項目/閾値/判断基準はサービス特性に合わせて要調整です。

平常時

• 日次: アラート件数と傾向を確認し、誤検知の候補を記録する
• 週次: 直近変更（デプロイ/設定変更）と主要メトリクスの相関を確認する
• 監視（例）:
  • API 5xx 率（閾値: 1% 超で注意、5% 超で緊急）
  • p95 レイテンシ（閾値: 1.5s 超で注意、3.0s 超で緊急）

異常時

• 初動（確認順）:
  1. 外形確認（主要ユーザー操作が成立するか）
  2. 直近変更の有無（デプロイ/設定変更/依存サービスの変更）
  3. 依存関係（DB/キュー/外部API）の健全性
• 切り分け（例）:
  • 影響範囲を縮小（特定の機能/リージョン/テナントに限定されるか）
  • 正常時との差分比較（昨日同時刻/直近リリース前）
  • ログ/メトリクスでボトルネック候補を列挙する

エスカレーション

• IC（Incident Commander）: 指揮・優先順位・関係者調整を担う役割
• 基準（例）:
  • 影響が継続し、15分以内に収束見込みが立たない
  • 重要機能（決済/認証など）の停止、またはデータ整合性リスクがある
• 伝達（最低限）: 影響範囲、暫定対応、次アクション、想定リスク、依頼事項

復旧判断

• 暫定対応: 影響を止める（例: 機能フラグで無効化、リソース拡張、遮断/迂回）
• 恒久対応: 真因に手を入れる（例: 設計修正、性能改善、検知強化）
• ロールバック判断（例）:
  • 直近変更が原因候補で、戻せば影響が止まる見込みが高い
  • データ互換性（スキーマ変更等）がある場合は、復旧手順を別途参照する

成功条件（確認観点）の例

• 外形: 主要操作（ログイン/保存/決済）が成立する
• メトリクス: エラー率・レイテンシが基準値に戻る
• ログ: 新規エラーが収束し、再発兆候がない

連絡先

• オンコール: Slack #oncall / 電話（要組織定義）
• 主管部署: SRE/インフラ
• 外部ベンダー: 契約窓口（要組織定義）

具体例（悪い例→良い例）

悪い例

異常時: 対応する
エスカレーション: 必要に応じて連絡
連絡先: 記載なし

良い例

初動: 1) エラー率 2) 直近変更 3) 依存関係（DB/キュー）
エスカレーション: 15分以上、復旧見込みなし→IC/主管へ
連絡先: オンコール、主管、外部ベンダー