ストーリー

オンコール体制の基本設計

オンコールとは

特定の期間中、システムのアラートに対応する責任を負う当番制度です。

ローテーション設計

interface OnCallRotation {
  // ローテーション名
  name: string;
  // 参加メンバー
  participants: string[];
  // ローテーション周期
  rotationPeriod: '1week' | '2weeks';
  // 交代タイミング
  handoffTime: string;
  // 交代曜日
  handoffDay: string;
}

const sreOnCallRotation: OnCallRotation = {
  name: 'SRE Primary On-Call',
  participants: ['engineer_a', 'engineer_b', 'engineer_c', 'engineer_d'],
  rotationPeriod: '1week',
  handoffTime: '10:00', // 朝のスタンドアップ後
  handoffDay: 'Monday',
};

// 最低人数の計算
// 推奨: 最低6名以上でローテーション
// 理由: 年間オンコール回数 = 52週 / 6名 ≒ 9回/人
// 4名の場合: 52 / 4 = 13回/人 → 負荷が高すぎる

ローテーションスケジュール例

Week 1:  [Engineer A] ← Primary  |  [Engineer B] ← Secondary
Week 2:  [Engineer B] ← Primary  |  [Engineer C] ← Secondary
Week 3:  [Engineer C] ← Primary  |  [Engineer D] ← Secondary
Week 4:  [Engineer D] ← Primary  |  [Engineer A] ← Secondary
Week 5:  [Engineer A] ← Primary  |  [Engineer B] ← Secondary
...（繰り返し）

エスカレーションポリシー

エスカレーションフロー

アラート発生
  │
  ├─ Level 1: プライマリオンコール（5分以内）
  │   └─ 応答なし or 対応不可
  │
  ├─ Level 2: セカンダリオンコール（10分以内）
  │   └─ 応答なし or 対応不可
  │
  ├─ Level 3: SREリード / テックリード（15分以内）
  │   └─ 対応不可 or SEV1
  │
  └─ Level 4: エンジニアリングマネージャー / CTO（20分以内）
      └─ ステークホルダー通知、経営判断

PagerDutyでの設定

# PagerDuty Escalation Policy
escalation_policy:
  name: "SRE Escalation"
  num_loops: 2  # ポリシー全体を2回繰り返す

  escalation_rules:
    - escalation_delay_in_minutes: 5
      targets:
        - type: schedule_reference
          id: "sre-primary-schedule"
      description: "プライマリオンコールに通知"

    - escalation_delay_in_minutes: 10
      targets:
        - type: schedule_reference
          id: "sre-secondary-schedule"
      description: "セカンダリオンコールにエスカレーション"

    - escalation_delay_in_minutes: 15
      targets:
        - type: user_reference
          id: "sre-lead-user-id"
      description: "SREリードにエスカレーション"

    - escalation_delay_in_minutes: 20
      targets:
        - type: user_reference
          id: "engineering-manager-id"
      description: "エンジニアリングマネージャーにエスカレーション"

# 通知ルール（各ユーザー設定）
notification_rules:
  - start_delay_in_minutes: 0
    contact_method: push_notification  # まずアプリ通知
  - start_delay_in_minutes: 1
    contact_method: sms               # 1分後にSMS
  - start_delay_in_minutes: 3
    contact_method: phone_call         # 3分後に電話

オンコールの負荷管理

ワークライフバランスの維持

負荷の計測と改善

interface OnCallMetrics {
  // 期間中のページ数（PagerDuty呼出回数）
  pageCount: number;
  // 深夜（22:00-06:00）のページ数
  nightPageCount: number;
  // ページあたりの平均対応時間（分）
  avgResponseMinutes: number;
  // 中断なく睡眠できた夜の割合
  uninterruptedNightRate: number;
}

function evaluateOnCallHealth(metrics: OnCallMetrics): string {
  // 週あたりのページ数が2回以下が健全
  if (metrics.pageCount > 7) {
    return '不健全: 週間ページ数が多すぎる。アラートの見直しが必要';
  }
  // 深夜ページが週1回以下が理想
  if (metrics.nightPageCount > 3) {
    return '改善必要: 深夜ページの削減が必要。自動復旧の導入を検討';
  }
  // 中断なし睡眠率80%以上が目標
  if (metrics.uninterruptedNightRate < 0.8) {
    return '要注意: 睡眠の質が低下。ノイズアラートの削減が急務';
  }
  return '健全: オンコール負荷は適正範囲';
}

Googleのオンコールガイドライン

Googleが実践するオンコール負荷の上限:

1. 1回のオンコールシフトで最大2件のインシデント
   └─ これ以上は品質が低下する

2. 各インシデント後にポストモーテム作成時間を確保
   └─ 「対応して終わり」にしない

3. オンコール中の通常作業は50%に制限
   └─ アラート対応のバッファを確保

4. オンコール後の「回復期間」を設ける
   └─ 深夜対応の翌日は午後出勤 or 代休

ハンドオフプロセス

オンコール交代時の引き継ぎ

interface OnCallHandoff {
  // 引き継ぎ日時
  handoffTime: Date;
  // 前任者
  outgoingEngineer: string;
  // 後任者
  incomingEngineer: string;
  // 未解決インシデント
  openIncidents: IncidentSummary[];
  // 進行中の作業
  ongoingWork: string[];
  // 注意事項
  watchItems: string[];
  // 最近のデプロイ
  recentDeployments: Deployment[];
}

interface IncidentSummary {
  id: string;
  severity: string;
  summary: string;
  status: 'investigating' | 'mitigated' | 'monitoring';
  actionItems: string[];
}

ハンドオフチェックリスト

# オンコールハンドオフテンプレート
handoff_checklist:
  outgoing:
    - "未解決インシデントの状況を共有したか"
    - "直近のデプロイとロールバック可能性を伝えたか"
    - "注意が必要なサービス/コンポーネントを伝えたか"
    - "オンコール期間中の重要な変更点を伝えたか"
    - "対応不要と判断したアラートの理由を記録したか"

  incoming:
    - "アラートチャンネルの通知設定を確認したか"
    - "PagerDutyアプリの通知テストをしたか"
    - "VPN/SSHアクセスが正常に動作するか確認したか"
    - "ランブックの最新版にアクセスできるか確認したか"
    - "直近のインシデント履歴を確認したか"

まとめ

チェックリスト

• オンコールローテーションの設計原則を理解した
• エスカレーションポリシーの段階設計ができる
• オンコール負荷の健全性指標を把握した
• ハンドオフプロセスの重要性を理解した
• PagerDutyの基本的な設定ができる

次のステップへ

次は「ランブックの作成」を学びます。オンコールエンジニアがアラートを受けた後、何をすべきか — 具体的な対応手順を文書化するランブックの設計と作成方法を学びましょう。

推定読了時間: 40分