障害の分類と対応体制

障害が発生したとき、最初に判断すべきは「これはどれくらい深刻か」と「誰が何をするか」です。これが曖昧だと、全員が同じことを調べたり、逆に誰も対応しなかったりします。

---

重大度（Severity）の定義

重大度基準

レベル	名前	基準	対応期限	例
Sev 1	緊急	サービス全体が利用不可	即時	DB 接続不能、アプリ全台停止
Sev 2	重大	一部ユーザーまたは一部機能が利用不可	30分以内	特定機能のエラー率急増
Sev 3	中度	性能劣化、一部ユーザーに影響	4時間以内	レイテンシ 3倍以上、間欠的エラー
Sev 4	軽度	影響限定的、回避策あり	翌営業日	管理APIの一部エラー、ログ欠損

判断フローチャート

障害発生
  │
  ├── 全ユーザーがログインできない？
  │   └── YES → Sev 1（緊急）
  │
  ├── 特定テナントまたは機能が使えない？
  │   └── YES → Sev 2（重大）
  │
  ├── 遅いが使える？エラーが間欠的？
  │   └── YES → Sev 3（中度）
  │
  └── ユーザー影響が小さい or 回避策あり？
      └── YES → Sev 4（軽度）

迷ったときの原則

高い方に倒す。 Sev 2 か Sev 3 か迷ったら Sev 2 として対応する。後から下げるのは簡単だが、上げるのは遅れにつながる。

---

対応体制

役割

役割	人数	責任
インシデントコマンダー（IC）	1名	対応全体の指揮。判断と意思決定。技術対応はしない
調査担当	1-2名	原因調査、ログ分析、メトリクス確認
復旧担当	1名	対処の実行（ロールバック、スケールアウト等）
コミュニケーション担当	1名	ステークホルダーへの状況報告、ステータスページ更新

小規模チーム（3名以下）の場合:
  IC + 調査 = 1名
  復旧 = 1名
  コミュニケーション = 1名（兼任可）

  → 最低2名いれば対応可能
  → 1名の場合は IC + 調査 + 復旧を兼ねて、
    コミュニケーションは復旧後にまとめて行う

インシデントコマンダーの仕事

IC がやること:
  ✅ 重大度の判定と宣言
  ✅ 担当の割り当て
  ✅ 対応方針の決定（ロールバックするか、修正パッチを当てるか）
  ✅ エスカレーションの判断
  ✅ タイムラインの記録指示
  ✅ 復旧の宣言

IC がやらないこと:
  ❌ 自分でログを調べる
  ❌ 自分でコマンドを実行する
  → IC が手を動かすと全体の指揮がおろそかになる
  → ただし小規模チームでは兼任もやむを得ない

---

エスカレーション

いつエスカレーションするか

状況	エスカレーション先
Sev 1 が発生	即座に全員に通知（Slack/PagerDuty）
30分以内に原因が特定できない	追加の技術者を招集
復旧の見込みが立たない	マネージャーに報告
テナントへの影響が確定	カスタマーサポートに連絡
AWS サービス自体の障害の疑い	AWS サポートケース起票

エスカレーションの原則

❌ 「もう少し調べてからエスカレーションしよう」
   → 30分後に「まだ調べてます」は最悪のパターン

✅ 「原因不明だが影響が出ている。助けが必要」
   → 早すぎるエスカレーションで怒られることはない
   → 遅すぎるエスカレーションで信頼を失う

---

コミュニケーション

障害発生時の報告テンプレート

【障害発生】Sev X: {概要}
発生時刻: YYYY-MM-DD HH:MM JST
影響範囲: {全テナント / 特定テナント / 特定機能}
現在の状況: {調査中 / 原因特定済み / 復旧作業中}
対応者: {IC名}
次回報告: {30分後 / 1時間後}

報告の頻度

重大度	報告間隔
Sev 1	15分ごと
Sev 2	30分ごと
Sev 3	1時間ごと
Sev 4	状況変化時のみ

報告すべきこと: 状況が変わっていなくても「変化なし」と報告する。沈黙は「忘れている」と解釈される。

---

まとめ

障害発生時にまずやること:

  1. 重大度を判定する（迷ったら高い方）
  2. IC を決める（最初に気づいた人が暫定 IC）
  3. 役割を割り当てる
  4. 最初の報告を出す
  5. 調査・復旧を開始する

→ ここまでを 5分以内に

次のステップ

• アラート設計: 障害を検知する仕組み