引き継ぎと継続性

オンコールシフトの終わりは、始まりと同じくらい重要です。良い引き継ぎとは、次のエンジニアが成功できるよう準備することです。

引き継ぎとは何か？

引き継ぎとは、あなたから次の担当者へオンコール責任を正式に移譲することです。

SSCS の 24x5 ローテーションでは、引き継ぎは以下のタイミングで発生します：

• 地域間（APAC → EMEA → AMER → APAC）でカバレッジが移る8 時間ごと
• シフト終了時にインシデントが進行中の場合はその時点

引き継ぎが重要な理由

引き継ぎが不十分だと：

• コンテキストが失われ混乱が生じる
• 問題が見落とされる
• 作業が重複する
• 重要な詳細が見逃される
• エンジニアがストレスを受ける

良い引き継ぎは：

• 次の担当者が成功するために必要なことを伝える
• 作業の重複を防ぐ
• 見落としを防ぐ
• ローテーションへの信頼を築く
• タイムゾーンをまたいだ継続性を維持する

引き継ぎに含める内容

1. 現在のインシデント（進行中の問題）

進行中の問題がある場合：

必要な詳細：

• 何が問題か？ — 明確な説明
• どのドメインか？ — 認証、認可、またはパイプラインセキュリティ
• 影響は？ — 何人のユーザー／サービスが影響を受けているか？
• 何を試みたか？ — どのような調査ステップを行ったか？
• どこで行き詰まっているか？ — ブロッカーは何か？
• 次に何をすべきか？ — あなたの推奨事項

例：

「SAML ログインで認証失敗率が高い。認証サービスを 2 回再起動したところ、失敗は正常レベルに下がったが、30 分以内に再上昇した。最新のデプロイは 4 時間前。新しい SAML ハンドラーにセッション状態の問題があると思われる。デプロイの詳細を確認し、ロールバックを検討してください。悪化した場合は認証 EM にエスカレーションしてください」

2. 解決した最近の問題

シフト中に何を修正しましたか？

• 何が問題だったか？
• どのドメインが影響を受けたか？
• 根本原因は何か？
• どうやって修正したか？
• フォローアップ作業が必要か？（チケット、モニタリング変更など）

例：

「解決済み：午後 3 時頃に認可ポリシー評価エラー。Redis 接続タイムアウトによりポリシーキャッシュが更新されていなかった。キャッシュを手動でフラッシュし、Redis 接続プール設定を修正。キャッシュ更新失敗のモニタリングを追加するために Issue #12345 を作成した」

3. 発火したアラート（ノイズ）

発火したが実際の問題でなかったアラートはどれですか？

• どのアラートが発火したか？
• なぜ実際の問題でなかったか？
• どうすべきか？

例：

「PipelineSecurityScanTimeout が 6 回発火したが、常に誤検知だった。スキャンは正常に完了したが、アラートしきい値よりも時間がかかっていた。しきい値を上げるか、予想されるスキャン時間に合わせて調整すべき。緊急ではないが、記録に残しておく価値がある」

4. 保留中の変更またはデプロイ

シフト中にデプロイや変更は行いましたか？

• 何が変更されたか？
• いつ？
• なぜ？（ホットフィックス、計画変更など）
• 何に注意すべきか？

例：

「OAuth トークン更新の問題を修正するため、午後 8 時に認証サービスバージョン 2.1.3 をデプロイした。今のところ安定しているが、今後 1 時間は AuthTokenRefreshRate と SessionCreationErrors のメトリクスを注意深く監視してください」

5. ドメインをまたぐコンテキスト

ドメイン間の相互作用について次の担当者が知っておくべきこと：

• 複数のドメインが影響を受けているか？
• サービス間に依存関係があるか？
• 他のドメインチームと調整したか？

例：

「先ほどの認証の問題により、認可のタイムアウトも発生した。@AuthorizationEngineer と調整した。両サービスは現在安定しているが、認証に問題が再発した場合のカスケード効果に注意してください」

6. 保有しているコンテキスト

次の担当者が知らないかもしれないこと：

• 顧客は進行中の問題を把握しているか？
• リーダーシップが何かを追跡しているか？
• エスカレーションした未解決のインシデントがあるか？
• 次の担当者が知っておくべき会議や決定があったか？

例：

「大規模なパイプラインセキュリティスキャナーの更新が明日午前 10 時に予定されている。リーダーシップが問題を注視しているので、夜中に何か異常があった場合はすぐにエスカレーションしてください」

引き継ぎの方法

シフト終了前

30 分前：

• 引き継ぎメモを書き始める
• 進行中の問題を要約する
• 詳細とリンクを収集する

同期引き継ぎ（推奨）

可能であれば、次の担当者と直接話す：

1. 連絡する： 「シフトを終えます。10 分ほど引き継ぎの時間をもらえますか？」
2. 説明する： 各進行中の問題について話す
3. 質問に答える： 明確化の質問をさせる
4. 理解を確認する： 理解できているか確認する
5. 連絡先を残す： 「問題が発生したら Slack してください」

特にタイムゾーンをまたいだ引き継ぎでは 15 〜 20 分かかりますが、価値があります。

非同期引き継ぎ（必要な場合）

直接連絡できない場合（タイムゾーンをまたいだ引き継ぎでは一般的）：

1. Slack または共有ドキュメントに詳細なメモを書く
2. オンコールチャンネルに投稿する。次の担当者が見られるように
3. 次の担当者にダイレクトメッセージを送る： 「@次の担当者、引き継ぎメモをオンコールチャンネルで確認してください」
4. 推測や検索が不要なよう具体的に書く

引き継ぎメッセージの例

@Sarah, I'm handing off from AMER to APAC. Here's what you need to know:

**Active Issue:**

- HighAuthFailureRate on SAML login. Restarted service twice; failures are back up.
  Likely session state issue in new SAML handler from deployment 4 hours ago.
  Recommend checking the deploy; consider rolling back if it keeps happening.
  Domain: Authentication

**Resolved During My Shift:**

- Fixed authorization policy cache refresh (Redis connection timeout)
- Manually flushed cache at 3 PM
- Created issue #12345 for monitoring
  Domain: Authorization

**False Alarms:**

- PipelineSecurityScanTimeout fired 6 times. Not real, just longer scan times.
  Domain: Pipeline Security

**Deployments:**

- Authentication service v2.1.3 went out at 8 PM for OAuth fix. Stable so far but monitor metrics closely.

**FYI:**

- Big pipeline security scanner update tentatively going out tomorrow at 10 AM
- Leadership is tracking issues, so escalate early if anything seems wrong

Let me know if you have questions. I'm around for a bit if you need clarification.

まだインシデント対応中の場合

問題がシフト終了時に解決していない場合：

1. すぐに次の担当者に伝える
2. そのまま姿を消して、次の担当者に任せきりにしない
3. コンテキストを説明するための簡単な引き継ぎ会話のために少し残る
4. 助けを申し出る： 「悪化した場合は教えてください、戻れます」

次の担当者が謎を引き継ぐべきではありません。

引き継ぎ後

• 次の担当者が情報を受け取ったことを確認する
• あなたは公式にオンコールを外れます（ただし 30 分程度はラップトップの近くにいてください）
• 質問があれば連絡してもらって構いません
• 必要であれば助けることができます（ただし戻る義務はありません）

十分な引き継ぎを受けられなかった場合

コンテキストなしでシフトを引き継いだ場合：

1. Slack で聞く — 「この問題のコンテキストを教えてもらえますか？」
2. 最近のデプロイを確認する — 何が変わったか？
3. Incident.io を確認する — チケットやログはあるか？
4. 前の担当者に連絡する — オフラインでもすぐに助けてもらえる

これは不満の原因になるので、他の人にはこうならないようにしましょう。

引き継ぎでよくある間違い

❌ すぐに離脱する

シフト終了時にすぐオフラインにならないでください。まずコンテキストを伝えましょう。

❌ 曖昧すぎる

「すべて問題ない」は役立ちません。何を確認し、何が起きたかを具体的に伝えましょう。

❌ 相手がコンテキストを知っていると思い込む

次の担当者は別のタイムゾーン・ドメインにいるかもしれません。すべてを説明しましょう。

❌ 進行中の問題を無視する

何かがまだ壊れている場合、引き継ぎでそれを無視しないでください。何を試みたか、何を推奨するかを説明しましょう。

❌ ドメインを明記しない

問題が認証、認可、またはパイプラインセキュリティのどれに関わるかを常に明記しましょう。

❌ 防衛的になる

質問があれば明確に答えましょう。「そこまでデバッグしなかった」は問題ありません。「たぶんその問題じゃない」は役に立ちません。

関連ページ

• コミュニケーションと文化 — 引き継ぎ時の明確なコミュニケーション方法を学ぶ
• 初めてのシフト — 引き継ぎを受ける際に良い引き継ぎを受ける
• カバレッジとスケジューリング — 引き継ぎが発生するタイミングを理解する

ページのソースコードを見る - ページの編集 - please contribute.