---

name: design-on-call-rotation description: > バランスのとれたスケジュール、明確なエスカレーションポリシー、疲労管理、 ハンドオフ手順を含む持続可能なオンコールローテーションを設計する。 バーンアウトを最小限に抑えながらインシデント対応のカバレッジを維持する。 初めてオンコールを設定する場合、チームを2〜3人から5人以上のエンジニアに スケールする場合、オンコールのバーンアウトやアラート疲れに対処する場合、 インシデント対応時間を改善する場合、またはポストモーテムがハンドオフの問題を 特定した後に使用する。 locale: ja source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: observability complexity: basic language: multi tags: on-call, rotation, escalation, fatigue-management, handoff

オンコールローテーションの設計

エンジニアの健全性とカバレッジのバランスを取る持続可能なオンコールスケジュールを作成する。

使用タイミング

• 初めてオンコールを設定する場合
• チームを2〜3人から5人以上のエンジニアにスケールする場合
• オンコールのバーンアウトやアラート疲れに対処する場合
• インシデント対応時間を改善する場合
• ポストモーテムがハンドオフの問題を特定した後

入力

• 必須: チームの規模とタイムゾーン
• 必須: サービスのSLA要件（レスポンス時間、カバレッジ時間）
• 任意: 過去のインシデント量とタイミング
• 任意: オンコール補償の予算
• 任意: 既存のオンコールツール（PagerDuty、Opsgenie）

手順

ステップ1: ローテーションスケジュールを定義する

チームの規模に基づいてローテーション長を選択する：

## Rotation Models

### Weekly Rotation (5+ person team)
- **Length**: 7 days (Monday 09:00 to Monday 09:00)
- **Pros**: Predictable, easy to plan around
- **Cons**: Whole week disrupted if alerts are frequent

### 12-Hour Split (3-4 person team)
- **Day shift**: 08:00-20:00 local time
- **Night shift**: 20:00-08:00 local time
- **Pros**: Shared burden, night coverage paid differently
- **Cons**: More handoffs, coordination needed

### Follow-the-Sun (Global team)
- **APAC**: 00:00-08:00 UTC
- **EMEA**: 08:00-16:00 UTC
- **Americas**: 16:00-00:00 UTC
- **Pros**: No night shifts, timezone-aligned
- **Cons**: Requires distributed team

### Two-Tier (Senior/Junior split)
- **Primary**: Junior engineers (first responder)
- **Secondary**: Senior engineers (escalation)
- **Pros**: Training opportunity, lighter senior load
- **Cons**: Risk of junior burnout

5人チームのスケジュール例：

Week 1: Alice (Primary), Bob (Secondary)
Week 2: Charlie (Primary), Diana (Secondary)
Week 3: Eve (Primary), Alice (Secondary)
Week 4: Bob (Primary), Charlie (Secondary)
Week 5: Diana (Primary), Eve (Secondary)

期待結果： 公平にローテーションし、24/7のカバレッジを提供するスケジュール。

失敗時： カバレッジのギャップがある場合は、エンジニアを追加するかSLAを営業時間のみに縮小する。

ステップ2: エスカレーションポリシーを設定する

PagerDuty/Opsgenieで段階的なエスカレーションをセットアップする：

# PagerDuty escalation policy (YAML representation)
escalation_policy:
  name: "Production Services"
  repeat_enabled: true
  num_loops: 3

  escalation_rules:
    - id: primary
      escalation_delay_in_minutes: 0
      targets:
        - type: schedule
          id: primary_on_call_schedule

    - id: secondary
      escalation_delay_in_minutes: 15
      targets:
        - type: schedule
          id: secondary_on_call_schedule

    - id: manager
      escalation_delay_in_minutes: 30
      targets:
        - type: user
          id: engineering_manager

エスカレーションフローチャートを作成する：

Alert Fires
    ↓
Primary On-Call Paged
    ↓
Wait 15 minutes (no ack)
    ↓
Secondary On-Call Paged
    ↓
Wait 15 minutes (no ack)
    ↓
Manager Paged
    ↓
Repeat cycle (max 3 times)

期待結果： 合理的な遅延を持つ明確なエスカレーションパス。

失敗時： エスカレーションが頻繁に発火する場合は、承認ウィンドウを短縮するかアラート品質を確認する。

ステップ3: ハンドオフ手順を定義する

構造化されたハンドオフチェックリストを作成する：

## On-Call Handoff Checklist

### Outgoing On-Call
- [ ] Update incident log with any ongoing issues
- [ ] Document any workarounds or known issues
- [ ] Share any alerts that are "noisy but safe to ignore" temporarily
- [ ] Note any upcoming deploys or maintenance windows
- [ ] Provide context on any flapping alerts

### Incoming On-Call
- [ ] Review incident log from previous shift
- [ ] Check for any ongoing incidents
- [ ] Verify PagerDuty/Opsgenie has correct contact info
- [ ] Test alert delivery (send test page to yourself)
- [ ] Review recent deploys and release notes
- [ ] Check capacity metrics for any concerning trends

### Handoff Meeting (15 min)
- Review any incidents from past week
- Discuss any changes to systems or runbooks
- Questions and clarifications

ハンドオフリマインダーを自動化する：

# Slack reminder script
curl -X POST https://slack.com/api/chat.postMessage \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "#on-call",
    "text": "On-call handoff in 1 hour. Outgoing: @alice, Incoming: @bob. Please use the handoff checklist: https://wiki.company.com/oncall-handoff"
  }'

期待結果： スムーズな知識の引き継ぎ、シフト間での情報の損失なし。

失敗時： 引き継ぐエンジニアが回避策を知らなかったためにインシデントが再発する場合は、ハンドオフを必須にする。

ステップ4: 疲労管理を実装する

バーンアウトを防ぐルールを設定する：

## Fatigue Prevention Rules

### Alert Volume Limits
- **Threshold**: Max 5 pages per night (22:00-06:00)
- **Action**: If exceeded, trigger incident review next day
- **Goal**: Reduce noisy alerts that disrupt sleep

### Time Off After Major Incident
- **Rule**: If on-call handles P1 incident >2 hours overnight, they get comp time
- **Amount**: Equal to incident duration (e.g., 3-hour incident = 3 hours off)
- **Scheduling**: Must be taken within 2 weeks

### Maximum Consecutive Weeks
- **Limit**: No more than 2 consecutive weeks on-call
- **Reason**: Prevents exhaustion from extended coverage

### Minimum Rest Between Rotations
- **Cooldown**: At least 2 weeks between primary rotations
- **Exception**: Emergency coverage (requires manager approval)

### Vacation Protection
- **Rule**: No on-call during scheduled vacation
- **Process**: Mark as "Out of Office" in PagerDuty 2 weeks in advance
- **Swap**: Coordinate swap with team, update schedule

アラート疲れのメトリクスを追跡する：

# Alerts per on-call engineer per week
count(ALERTS{alertstate="firing"}) by (oncall_engineer)

# Nighttime pages (22:00-06:00 local)
count(ALERTS{alertstate="firing", hour_of_day>=22 or hour_of_day<6})

# Time to acknowledge (should be <5 min during business hours)
histogram_quantile(0.95, rate(alert_ack_duration_seconds_bucket[7d]))

期待結果： オンコールの負荷が持続可能で、エンジニアが慢性的に疲弊していない。

失敗時： ルールにもかかわらずバーンアウトが発生する場合は、アラート量を削減するかエンジニアを採用する。

ステップ5: ランブックとエスカレーション連絡先を文書化する

オンコールのクイックリファレンスガイドを作成する：

# On-Call Quick Reference

## Emergency Contacts
- **Engineering Manager**: Alice Smith, +1-555-0100
- **CTO**: Bob Johnson, +1-555-0200
- **Security Team**: [email protected], +1-555-0300
- **Cloud Provider Support**: AWS Support Case Portal

## Common Runbooks
- [Database Connection Pool Exhaustion](https://wiki/runbook-db-pool)
- [High API Latency](https://wiki/runbook-api-latency)
- [Disk Space Full](https://wiki/runbook-disk-full)
- [SSL Certificate Expiration](https://wiki/runbook-ssl-renewal)

## Access & Credentials
- **Production AWS**: SSO via company.okta.com
- **Kubernetes**: `kubectl --context production`
- **Database**: Read-only access via Bastion host
- **Secrets**: 1Password vault "On-Call Production"

## Escalation Decision Tree
- **P1 (Service Down)**: Immediate response, escalate to manager after 30min
- **P2 (Degraded)**: Response within 15min, escalate if not resolved in 1 hour
- **P3 (Warning)**: Acknowledge, resolve during business hours
- **Security Incident**: Immediately escalate to Security Team, don't investigate alone

期待結果： オンコールエンジニアが2分以内に必要な情報を見つけられる。

失敗時： エンジニアが「Xはどこにあるか？」を繰り返し尋ねる場合は、ドキュメントを一元化する。

ステップ6: 定期的なオンコールの振り返りをスケジュールする

毎月オンコールの体験をレビューする：

## On-Call Retrospective Agenda (Monthly)

### Metrics Review (15 min)
- Total alerts: [X] (target: <50/week)
- Nighttime pages: [Y] (target: <5/week)
- Mean time to acknowledge: [Z] (target: <5 min)
- Incidents by severity: P1: [A], P2: [B], P3: [C]

### Qualitative Feedback (20 min)
- What was the most challenging incident?
- Which alerts were noisy/low-value?
- Were runbooks helpful? Which need updates?
- Any gaps in monitoring or alerting?

### Action Items (10 min)
- Fix noisy alerts identified
- Update runbooks that were incomplete
- Adjust rotation schedule if needed
- Plan alert tuning work

### Recognition (5 min)
- Shout-outs for excellent incident response
- Share learnings from interesting incidents

改善を時間とともに追跡する：

# Generate monthly on-call report
cat > oncall_report_2025-02.md <<EOF
# On-Call Report: February 2025

## Key Metrics
- **Total Alerts**: 38 (down from 52 in January)
- **Nighttime Pages**: 4 (within target)
- **P1 Incidents**: 1 (database outage, 45min MTTR)
- **P2 Incidents**: 3 (all resolved <1 hour)

## Improvements Made
- Tuned CPU alert threshold (reduced false positives by 40%)
- Added runbook for Redis cache failures
- Implemented log rotation (prevented disk full alerts)

## Upcoming Changes
- Migrate to follow-the-sun rotation (Q2)
- Add Slack alert integration (in progress)
EOF

期待結果： オンコールの体験が月を追って改善し、アラート量が減少する。

失敗時： メトリクスが改善しない場合は、リーダーシップにエスカレートする。機能開発を一時停止して運用上の問題を修正する必要があるかもしれない。

バリデーション

• ローテーションスケジュールが必要な時間（24/7または営業時間）をカバーしている
• エスカレーションポリシーがテストされている（テストアラートを送信）
• ハンドオフ手順が文書化されてチームと共有されている
• 疲労管理ルールが成文化されている
• オンコールリファレンスガイドが完成してアクセス可能
• 月次の振り返りがスケジュールされている
• オンコール補償が承認されている（該当する場合）

よくある落とし穴

• エンジニアが少なすぎる: 3人以下では2〜3週間ごとにオンコールになり、持続不可能。週次ローテーションには最低5人が必要。
• エスカレーション遅延なし: 即座のマネージャーエスカレーションはシニアの時間を無駄にする。プライマリに15分のレスポンス時間を与える。
• ハンドオフをスキップする: コンテキストの引き継ぎがないと繰り返しミスにつながる。ハンドオフを必須にする。
• アラート疲れを無視する: ノイズのためにエンジニアがアラートを無視すると、重大な問題が見落とされる。積極的にチューニングする。
• 補償なし: 報酬や代休なしのオンコールは不満を生む。予算化する。

関連スキル

• configure-alerting-rules - 疲れを引き起こすアラートノイズを削減する
• write-incident-runbook - オンコールシフト中に参照されるランブックを作成する