On-Call Handoff Patterns

オンコール シフト トランジションの効果的なパターン。シフト間の継続性、コンテキスト転送、信頼性の高いインシデント対応を実現します。

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

• オンコール責務の引き継ぎ
• シフト引き継ぎサマリーの作成
• 継続中の調査の文書化
• オンコール ローテーション手順の確立
• 引き継ぎ品質の改善
• 新しいオンコール エンジニアのオンボーディング

コア コンセプト

1. 引き継ぎの構成要素

構成要素	目的
Active Incidents	現在何が動作していないか
Ongoing Investigations	デバッグ中の問題
Recent Changes	デプロイ、設定
Known Issues	有効な回避方法
Upcoming Events	メンテナンス、リリース

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

推奨: シフト間に 30 分のオーバーラップ

Outgoing (送信側):
├── 15 分: 引き継ぎ文書の作成
└── 15 分: 受信側とのシンク通話

Incoming (受信側):
├── 15 分: 引き継ぎ文書のレビュー
├── 15 分: 送信側とのシンク通話
└── 5 分: アラート設定の確認

テンプレート

テンプレート 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

### 現在アクティブなインシデントなし

引き継ぎ時点でアクティブなインシデントはありません。

---

## 🟡 Ongoing Investigations

### 1. 断続的な API タイムアウト (ENG-1234)

**Status**: 調査中
**Started**: 2024-01-20
**Impact**: リクエストの約 0.1% がタイムアウト

**Context**:

- タイムアウトはデータベース バックアップ ウィンドウ (02:00-03:00 UTC) と相関
- バックアップ プロセスがロック競合を引き起こしている可能性あり
- PR #567 で追加ロギングを実装 (2024/01/21 デプロイ)

**Next Steps**:

- [ ] 今夜のバックアップ後、新しいログをレビュー
- [ ] 確認されたら、バックアップ ウィンドウの移動を検討

**Resources**:

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

---

### 2. Auth Service のメモリ増加 (ENG-1235)

**Status**: 監視中
**Started**: 2024-01-18
**Impact**: 現在なし (プロアクティブ)

**Context**:

- メモリ使用量が 1 日あたり約 5% 増加
- プロファイリングでメモリ リークは検出されず
- コネクション プール が適切に解放されていない可能性

**Next Steps**:

- [ ] 2024/01/21 のヒープ ダンプをレビュー
- [ ] 使用量が 80% を超えた場合、再起動を検討

**Resources**:

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

---

## 🟢 このシフト中に解決

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

- **Duration**: 23 分
- **Root Cause**: データベース コネクション枯渇
- **Resolution**: v2.3.4 をロールバック、プール サイズ増加
- **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 | ヘッダー パース バグ修正 |
| user-service | v2.8.0  | 01/20 10:00 | 新しいプロファイル機能     |
| auth-service | v4.1.2  | 01/19 16:00 | セキュリティ パッチ       |

### Configuration Changes

- 01/21: API レート リミットを 1000 から 1500 RPS に増加
- 01/20: データベース コネクション プール最大値を 50 から 75 に更新

### Infrastructure

- 01/20: Kubernetes クラスタに 2 ノードを追加
- 01/19: Redis を 6.2 から 7.0 にアップグレード

---

## ⚠️ Known Issues & Workarounds

### 1. ダッシュボードの読み込みが遅い

**Issue**: 月曜日の朝は Grafana ダッシュボードが遅い
**Workaround**: 08:00 UTC 後 5 分待ってキャッシュ ウォームアップを待つ
**Ticket**: OPS-456 (P3)

### 2. 不安定な統合テスト

**Issue**: `test_payment_flow` が CI で断続的に失敗
**Workaround**: 失敗したジョブを再実行 (通常、再試行で合格)
**Ticket**: ENG-1200 (P2)

---

## 📅 Upcoming Events

| Date        | Event                | Impact              | Contact       |
| ----------- | -------------------- | ------------------- | ------------- |
| 01/23 02:00 | Database maintenance | 5 分読み取り専用     | @dba-team     |
| 01/24 14:00 | Major release v5.0   | 注意深く監視         | @release-team |
| 01/25       | Marketing campaign   | 2 倍のトラフィック   | @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
# サービスの健全性を確認
kubectl get pods -A | grep -v Running

# 最近のデプロイ
kubectl get events --sort-by='.lastTimestamp' | tail -20

# データベース接続
psql -c "SELECT count(*) FROM pg_stat_activity;"

# キャッシュをクリア (緊急時のみ)
redis-cli FLUSHDB
```

重要なリンク

• Runbooks
• Service Catalog
• Incident Slack
• PagerDuty

---

引き継ぎ チェックリスト

送信側エンジニア

• アクティブなインシデントを文書化
• 継続中の調査を文書化
• 最近の変更をリスト化
• 既知の問題を記載
• 今後のイベントを追加
• 受信側エンジニアと同期

受信側エンジニア

• このドキュメントを読む
• シンク通話に参加
• PagerDuty があなたにルーティングされていることを確認
• Slack 通知が機能していることを確認
• VPN/アクセスが機能していることを確認
• 重要なダッシュボードをレビュー

### テンプレート 2: クイック引き継ぎ (非同期)

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

## TL;DR
- アクティブなインシデントなし
- 1 件の調査実施中 (API タイムアウト、ENG-1234 を参照)
- 明日メジャー リリース (01/24) - 問題に対応準備

## Watch List
1. 02:00-03:00 UTC 周辺の API レイテンシ (バックアップ ウィンドウ)
2. Auth service メモリ (> 80% の場合は再起動)

## 最近の変更
- 昨日 api-gateway v3.2.1 をデプロイ (安定)
- レート リミットを 1500 RPS に増加

## 今後のイベント
- 01/23 02:00 - DB メンテナンス (5 分読み取り専用)
- 01/24 14:00 - v5.0 リリース

## ご質問は?
本日 17:00 まで Slack で利用可能です。

テンプレート 3: インシデント引き継ぎ (インシデント中)

# INCIDENT HANDOFF: Payment Service Degradation

**Incident Start**: 2024-01-22 08:15 UTC
**Current Status**: 軽減中
**Severity**: SEV2

---

## 現在の状態

- エラー率: 15% (40% から低下)
- 軽減措置実施中: ポッドのスケーリング アップ
- 解決予想時間: 約 30 分

## わかっていること

1. 根本原因: payment-service ポッドのメモリ圧力
2. トリガー: 異常なトラフィック スパイク (通常の 3 倍)
3. 要因: チェックアウト フローの非効率なクエリ

## 実施済みの対応

- payment-service を 5 → 15 ポッドにスケーリング
- チェックアウト エンドポイントのレート制限を有効化
- 重要でない機能を無効化

## 実施が必要な対応

1. エラー率を監視 - 約 15 分で < 1% に低下するはず
2. 改善されない場合は @payments-manager にエスカレート
3. 安定したら、根本原因の調査を開始

## 主要メンバー

- Incident Commander: @alice (引き継ぎ側)
- Comms Lead: @charlie
- Technical Lead: @bob (受け取り側)

## コミュニケーション

- Status page: 08:45 に更新
- Customer support: 通知済み
- Exec team: 認識済み

## トラブルシューティング

**受信側エンジニアが、引き継ぎ文書が不完全なため、重大な問題を見落とす**
送信側チェックリストを門番として使用: 各セクションに少なくとも 1 つのエントリがあるか、または明示的に「なし」という記載があるまで、引き継ぎを完了したと見なさない。不完全な引き継ぎをブレームレス ポストモーテム アクション アイテムにする。

**タイムゾーン ギャップにより、30 分のシンク通話ができない**
非同期クイック引き継ぎ テンプレート (テンプレート 2) にフォールバック。Watch list を説明する短い Loom またはボイス メモで補足。受信側エンジニアがフォローアップ質問を持つ場合に直接問い合わせ方法を提供する。

**受信側エンジニアがインシデント中の引き継ぎを受け取り、すぐに圧倒される**
インシデント引き継ぎ テンプレート (テンプレート 3) を特別に使用。送信側エンジニアは引き継ぎ後 15 分間、オフコールでも Slack で利用可能な状態を維持し、明確化の質問に答える。

**複数のチーム間でオンコール引き継ぎ文書の形式が一貫していない**
シフト引き継ぎ テンプレート構成を組織全体で採用し、完成した引き継ぎを共有の場所 (wiki, Notion, Confluence) に保存。PagerDuty のオンコール スケジュール エントリから各引き継ぎへのリンク。

**受信側エンジニアが、送信側エンジニアがログオフする前にアラート設定が機能していることを確認できない**
標準的なステップを追加: 送信側エンジニアはテスト アラートを実行し、受信側エンジニアが PagerDuty と Slack で受信することを確認してから、オーバーラップ ウィンドウを終了。

## Related Skills

- [incident-classification](../../skills/incident-classification/SKILL.md) — 引き継ぎ文書に含める必要があるインシデントを分類および優先順位付けする
- [postmortem-facilitation](../../skills/postmortem-facilitation/SKILL.md) — シフト中の解決したインシデントを構造化されたポストモーテムに変換する