on-call-handoff-patterns

モード：認知／プロンプト駆動 — 単独で実行するユーティリティスクリプトはありません。エージェントのコンテキストを通じて使用します。

オンコールの引き継ぎパターン

オンコールのシフト交代を効果的に行うためのパターンです。シフト間の継続性やコンテキストの伝達を確保し、信頼性の高いインシデント対応につなげます。

このスキルを使用する場面

• オンコールの担当を引き継ぐとき
• シフトの引き継ぎ概要を作成するとき
• 継続中の調査を記録するとき
• オンコールのローテーション手順を確立するとき
• 引き継ぎの質を向上させるとき
• 新しいオンコールエンジニアをオンボーディングするとき

基本概念

1. 引き継ぎの構成要素

構成要素	目的
対応中のインシデント	現在発生している障害
継続中の調査	デバッグ中の問題
最近の変更	デプロイ、設定
既知の問題	適用中の回避策
今後の予定	メンテナンス、リリース

2. 引き継ぎのタイミング

Recommended: 30 min overlap between shifts

Outgoing:
├── 15 min: Write handoff document
└── 15 min: Sync call with incoming

Incoming:
├── 15 min: Review handoff document
├── 15 min: Sync call with outgoing
└── 5 min: Verify alerting setup

テンプレート

テンプレート 1：シフト引き継ぎドキュメント

# On-Call Handoff: Platform Team

**Outgoing**: @alice (2024-01-15 to 2024-01-22)
**Incoming**: @bob (2024-01-22 to 2024-01-29)
**Handoff Time**: 2024-01-22 09:00 UTC

---

## Active Incidents

### None currently active

No active incidents at handoff time.

---

## Ongoing Investigations

### 1. Intermittent API Timeouts (ENG-1234)

**Status**: Investigating
**Started**: 2024-01-20
**Impact**: ~0.1% of requests timing out

**Context**:

- Timeouts correlate with database backup window (02:00-03:00 UTC)
- Suspect backup process causing lock contention
- Added extra logging in PR #567 (deployed 01/21)

**Next Steps**:

- [ ] Review new logs after tonight's backup
- [ ] Consider moving backup window if confirmed

**Resources**:

- Dashboard: [API Latency](https://grafana/d/api-latency)
- Thread: #platform-eng (01/20, 14:32)

---

### 2. Memory Growth in Auth Service (ENG-1235)

**Status**: Monitoring
**Started**: 2024-01-18
**Impact**: None yet (proactive)

**Context**:

- Memory usage growing ~5% per day
- No memory leak found in profiling
- Suspect connection pool not releasing properly

**Next Steps**:

- [ ] Review heap dump from 01/21
- [ ] Consider restart if usage > 80%

**Resources**:

- Dashboard: [Auth Service Memory](https://grafana/d/auth-memory)
- Analysis doc: [Memory Investigation](https://docs/eng-1235)

---

## Resolved This Shift

### Payment Service Outage (2024-01-19)

- **Duration**: 23 minutes
- **Root Cause**: Database connection exhaustion
- **Resolution**: Rolled back v2.3.4, increased pool size
- **Postmortem**: [POSTMORTEM-89](https://docs/postmortem-89)
- **Follow-up tickets**: ENG-1230, ENG-1231

---

## Recent Changes

### Deployments

| Service      | Version | Time        | Notes                      |
| ------------ | ------- | ----------- | -------------------------- |
| api-gateway  | v3.2.1  | 01/21 14:00 | Bug fix for header parsing |
| user-service | v2.8.0  | 01/20 10:00 | New profile features       |
| auth-service | v4.1.2  | 01/19 16:00 | Security patch             |

### Configuration Changes

- 01/21: Increased API rate limit from 1000 to 1500 RPS
- 01/20: Updated database connection pool max from 50 to 75

### Infrastructure

- 01/20: Added 2 nodes to Kubernetes cluster
- 01/19: Upgraded Redis from 6.2 to 7.0

---

## Known Issues & Workarounds

### 1. Slow Dashboard Loading

**Issue**: Grafana dashboards slow on Monday mornings
**Workaround**: Wait 5 min after 08:00 UTC for cache warm-up
**Ticket**: OPS-456 (P3)

### 2. Flaky Integration Test

**Issue**: `test_payment_flow` fails intermittently in CI
**Workaround**: Re-run failed job (usually passes on retry)
**Ticket**: ENG-1200 (P2)

---

## Upcoming Events

| Date        | Event                | Impact              | Contact       |
| ----------- | -------------------- | ------------------- | ------------- |
| 01/23 02:00 | Database maintenance | 5 min read-only     | @dba-team     |
| 01/24 14:00 | Major release v5.0   | Monitor closely     | @release-team |
| 01/25       | Marketing campaign   | 2x traffic expected | @platform     |

---

## Escalation Reminders

| Issue Type      | First Escalation     | Second Escalation |
| --------------- | -------------------- | ----------------- |
| Payment issues  | @payments-oncall     | @payments-manager |
| Auth issues     | @auth-oncall         | @security-team    |
| Database issues | @dba-team            | @infra-manager    |
| Unknown/severe  | @engineering-manager | @vp-engineering   |

---

## Quick Reference

### Common Commands

```bash
# Check service health
kubectl get pods -A | grep -v Running

# Recent deployments
kubectl get events --sort-by='.lastTimestamp' | tail -20

# Database connections
psql -c "SELECT count(*) FROM pg_stat_activity;"

# Clear cache (emergency only)
redis-cli FLUSHDB
```

重要なリンク

• ランブック
• サービスカタログ
• インシデント用 Slack
• PagerDuty

---

引き継ぎチェックリスト

引き継ぐエンジニア

• 対応中のインシデントを記録する
• 継続中の調査を記録する
• 最近の変更を一覧にする
• 既知の問題を記載する
• 今後の予定を追加する
• 引き継ぎ先のエンジニアと同期する

引き継ぐエンジニア

• このドキュメントを読む
• 同期ミーティングに参加する
• PagerDuty の通知先が自分に設定されていることを確認する
• Slack の通知が機能していることを確認する
• VPN／アクセスが機能していることを確認する
• 重要なダッシュボードを確認する

### Template 2: Quick Handoff (Async)

```markdown
# Quick Handoff: @alice → @bob

## TL;DR
- No active incidents
- 1 investigation ongoing (API timeouts, see ENG-1234)
- Major release tomorrow (01/24) - be ready for issues

## Watch List
1. API latency around 02:00-03:00 UTC (backup window)
2. Auth service memory (restart if > 80%)

## Recent
- Deployed api-gateway v3.2.1 yesterday (stable)
- Increased rate limits to 1500 RPS

## Coming Up
- 01/23 02:00 - DB maintenance (5 min read-only)
- 01/24 14:00 - v5.0 release

## Questions?
I'll be available on Slack until 17:00 today.

テンプレート 3：インシデントの引き継ぎ（対応中）

# INCIDENT HANDOFF: Payment Service Degradation

**Incident Start**: 2024-01-22 08:15 UTC
**Current Status**: Mitigating
**Severity**: SEV2

---

## Current State

- Error rate: 15% (down from 40%)
- Mitigation in progress: scaling up pods
- ETA to resolution: ~30 min

## What We Know

1. Root cause: Memory pressure on payment-service pods
2. Triggered by: Unusual traffic spike (3x normal)
3. Contributing: Inefficient query in checkout flow

## What We've Done

- Scaled payment-service from 5 → 15 pods
- Enabled rate limiting on checkout endpoint
- Disabled non-critical features

## What Needs to Happen

1. Monitor error rate - should reach <1% in ~15 min
2. If not improving, escalate to @payments-manager
3. Once stable, begin root cause investigation

## Key People

- Incident Commander: @alice (handing off)
- Comms Lead: @charlie
- Technical Lead: @bob (incoming)

## Communication

- Status page: Updated at 08:45
- Customer support: Notified
- Exec team: Aware

## Resources

- Incident channel: #inc-20240122-payment
- Dashboard: [Payment Service](https://grafana/d/payments)
- Runbook: [Payment Degradation](https://wiki/runbooks/payments)

---

**Incoming on-call (@bob) - Please confirm you have:**

- [ ] Joined #inc-20240122-payment
- [ ] Access to dashboards
- [ ] Understand current state
- [ ] Know escalation path

引き継ぎ同期ミーティング

アジェンダ（15 分）

## Handoff Sync: @alice → @bob

1. **Active Issues** (5 min)
   - Walk through any ongoing incidents
   - Discuss investigation status
   - Transfer context and theories

2. **Recent Changes** (3 min)
   - Deployments to watch
   - Config changes
   - Known regressions

3. **Upcoming Events** (3 min)
   - Maintenance windows
   - Expected traffic changes
   - Releases planned

4. **Questions** (4 min)
   - Clarify anything unclear
   - Confirm access and alerting
   - Exchange contact info

オンコールのベストプラクティス

シフト開始前

## Pre-Shift Checklist

### Access Verification

- [ ] VPN working
- [ ] kubectl access to all clusters
- [ ] Database read access
- [ ] Log aggregator access (Splunk/Datadog)
- [ ] PagerDuty app installed and logged in

### Alerting Setup

- [ ] PagerDuty schedule shows you as primary
- [ ] Phone notifications enabled
- [ ] Slack notifications for incident channels
- [ ] Test alert received and acknowledged

### Knowledge Refresh

- [ ] Review recent incidents (past 2 weeks)
- [ ] Check service changelog
- [ ] Skim critical runbooks
- [ ] Know escalation contacts

### Environment Ready

- [ ] Laptop charged and accessible
- [ ] Phone charged
- [ ] Quiet space available for calls
- [ ] Secondary contact identified (if traveling)

シフト中

## Daily On-Call Routine

### Morning (start of day)

- [ ] Check overnight alerts
- [ ] Review dashboards for anomalies
- [ ] Check for any P0/P1 tickets created
- [ ] Skim incident channels for context

### Throughout Day

- [ ] Respond to alerts within SLA
- [ ] Document investigation progress
- [ ] Update team on significant issues
- [ ] Triage incoming pages

### End of Day

- [ ] Hand off any active issues
- [ ] Update investigation docs
- [ ] Note anything for next shift

シフト終了後

## Post-Shift Checklist

- [ ] Complete handoff document
- [ ] Sync with incoming on-call
- [ ] Verify PagerDuty routing changed
- [ ] Close/update investigation tickets
- [ ] File postmortems for any incidents
- [ ] Take time off if shift was stressful

エスカレーションのガイドライン

エスカレーションするタイミング

## Escalation Triggers

### Immediate Escalation

- SEV1 incident declared
- Data breach suspected
- Unable to diagnose within 30 min
- Customer or legal escalation received

### Consider Escalation

- Issue spans multiple teams
- Requires expertise you don't have
- Business impact exceeds threshold
- You're uncertain about next steps

### How to Escalate

1. Page the appropriate escalation path
2. Provide brief context in Slack
3. Stay engaged until escalation acknowledges
4. Hand off cleanly, don't just disappear

ベストプラクティス

推奨事項

• すべてを記録する - 将来の自分に感謝されます
• 早めにエスカレーションする - 後悔するより安全を優先しましょう
• 休憩を取る - アラート疲れは実際に起こります
• 同期して引き継ぐ - 非同期ではコンテキストが失われます
• 環境をテストする - インシデント発生中ではなく、発生前に行いましょう

禁止事項

• 引き継ぎを省略しない - コンテキストの喪失はインシデントの原因になります
• 一人で抱え込まない - 必要なときはエスカレーションしましょう
• アラートを無視しない - 小さな問題に見えても無視してはいけません
• 体調が悪いときに勤務しない - 代わりにシフトを交代しましょう
• 連絡がつかない状態にならない - シフト中は連絡を受けられるようにしましょう

リソース

• Google SRE - オンコールを担当する
• PagerDuty オンコールガイド
• Increment オンコール特集

厳守事項

1. シフトを終える前に、必ず引き継ぎドキュメントを作成してください — 同期ミーティングだけでは不十分です。口頭で伝えたコンテキストは数時間で忘れられます。ドキュメントは、引き継ぐエンジニアが午前 3 時に見返せる、永続的な記録です。
2. オンコールの引き継ぎで、決して同期ミーティングを省略しないでください — 非同期のみの引き継ぎでは、ニュアンスや口調、質問に答える機会が失われます。15 分間重複して引き継ぐことで、引き継ぐエンジニアの何時間もの混乱を防げます。
3. インシデントの対応に行き詰まったら、必ず30 分以内にエスカレーションしてください — 一人で何時間もデバッグすると、解決が遅れ、オンコールエンジニアが疲弊します。エスカレーションは弱さではなく、適切な判断の表れです。
4. シフト開始前のアラート設定の確認を、決して省略しないでください — インシデント発生中に PagerDuty の通知先設定に誤りがあると気づいても手遅れです。シフトごとに、アラート経路全体をテストしてください。
5. 未解決の調査はすべて、次に行う手順を明記して必ず記録してください — 次の手順を示さずに引き継ぐと、引き継ぐエンジニアはゼロからやり直すことになります。対応項目を書き残せば、引き継ぎ後の立ち上がりにかかる時間を数時間から数分に短縮できます。

アンチパターン

アンチパターン	問題が起きる理由	正しい方法
非同期のみの引き継ぎ（同期通話なし）	コンテキストの喪失によりインシデントが発生し、細かなニュアンスが失われ、質問が未回答のままになります	必ず同期通話（最低15分の重複時間）と文書での引き継ぎを行います
引き継ぎ文書がない	次の当番エンジニアが進行中の問題を把握できず、午前3時からの対応開始は不可能です	毎回のシフト終了前に、完全な引き継ぎ文書を作成します
シフト前のアラート確認を省略する	インシデント発生時にルーティングの設定ミスが判明し、修正が間に合いません	毎回のシフト開始前にPagerDutyのルーティングとSlack通知をテストします
ヒーロー文化（エスカレーションしない）	個人の燃え尽き、解決の遅れ、疲労による不適切な判断につながります	行き詰まってから30分以内にエスカレーションします。エスカレーションは適切な判断です
次の手順を示さずに調査を引き継ぐ	引き継いだエンジニアは調査を最初からやり直さなければなりません	未解決の項目ごとに、現在の状況、仮説、証拠、明確な次の手順を記録します

メモリプロトコル（必須）

開始前： .claude/context/memory/learnings.mdを読みます

完了後：

• 新しいパターン -> .claude/context/memory/learnings.md
• 発見した問題 -> .claude/context/memory/issues.md
• 決定事項 -> .claude/context/memory/decisions.md

中断を想定してください。メモリに記録されていなければ、実施されていないのと同じです。