SSCS Tier 2 オンコールローテーションリーダー

Software Supply Chain Security（SSCS）Tier 2 オンコールプログラムのローテーションリーダー役へようこそ。このローテーションの初期のローテーションリーダーは @adil.farrukh、@ajaythomasinc、@ken.mcdonald です。ローテーションリーダーとして、あなたはチームのオンコールローテーションの健全性、公平性、効果性に責任を持ちます。このガイドはコアの責任とその実行方法を概説しています。

あなたの役割と責任

ローテーションリーダーとして、あなたは SSCS ローテーションの主要な窓口となります。責任には、3つの地域と3つのドメインにわたるスケジュールの管理、新しいチームメンバーのオンボーディング、ワークロード配分の追跡、チームの健全性の維持、プログラムの継続的改善の確保が含まれます。

スケジュールの管理

ローテーションの構築と維持

あなたはローテーションの全体的な構造と構成に責任があります:

3つの地域（APAC、EMEA、AMER）すべてで適切なカバレッジを確保する
3つのドメイン（認証、認可、パイプラインセキュリティ）すべてでカバレッジを確保する
バランスのとれたワークロードのために地域あたり6〜10名を目標とする
現在の配分: APAC: 7名、EMEA: 10名、AMER: 12名
チームメンバーが計画を立てられるよう、少なくとも1ヶ月前にスケジュールを公開する

カバレッジ時間の設定

SSCS ローテーションは、3つの8時間地域ブロックで構成される 24x5 モデルで運営されます:

APAC（ベストエフォート方式）: UTC 23:00 - 07:00
EMEA: UTC 07:00 - 15:00
AMER: UTC 15:00 - 23:00

カバレッジは月曜日〜金曜日のみ（初期イテレーションでは週末なし）。

スケジュールの公開と管理

Incident.io をすべてのスケジュールの唯一の情報源として使用する
スケジュールをチームに見えるようにし、定期的に更新する
カバレッジのスワップが必要な場合はオーバーライドを作成する
スケジュール変更を影響を受けるチームメンバーに速やかに伝える
可能であれば3〜6ヶ月先までのスケジュールを追跡する

スタッフィングと公平性

地域別ローテーション頻度

ローテーションは、チームの規模と地域カバレッジのニーズに基づいた特定の頻度を目標とします:

APAC（アジア太平洋）

カバレッジ: UTC 23:00 - 07:00（ベストエフォート方式）
1人あたり年約6〜7週
現在のチーム規模: 7名
チームが最小のため頻度が高い

EMEA（欧州/中東/アフリカ）

カバレッジ: UTC 07:00 - 15:00
1人あたり年約5〜6週
現在のチーム規模: 10名
中程度の頻度

AMER（南北アメリカ）

カバレッジ: UTC 15:00 - 23:00
1人あたり年約4〜5週
現在のチーム規模: 12名
チームが最大のため頻度が低い

公平な配分の確保

公平性を維持するためにワークロード配分を監視する:

すべてのエンジニアが地域内でほぼ同じ数のシフトを担当することを確認する
各人がオンコールを担当した回数を追跡する
シフト中に最も多くのアラートを処理した人を確認する
公平な割り当て以上を担っている人を特定する
誰かが一貫して忙しい週を担当するパターンがないか注意する
オンコール義務を最大で4週間に1回に上限設定する

ドメインバランス

ドメイン間で公平な配分を確保する:

ドメイン別（認証、認可、パイプラインセキュリティ）にインシデントを追跡する
1つのドメインが大幅に多くのインシデントを生成しているか監視する
1つのドメインが過負荷になっている場合はスタッフィングまたはアラートチューニングを調整する
クロスドメインの知識共有を確保する

四半期ごとの公平性レビュー

四半期ごとに以下を確認する:

各人が何回オンコールを担当したか？
地域内でシフトは公平に配分されたか？
バーンアウトまたは持続不可能な負荷を報告した人はいないか？
各地域のカバレッジ目標を達成したか？
ドメインカバレッジはバランスが取れているか？
配分が不公平になった場合は再調整する

新しいチームメンバーのオンボーディング

ローテーションへの追加

ローテーションに新しい人を追加するとき:

チームメンバーとそのマネージャーと協力して準備ができていることを確認する
彼らの地域（APAC、EMEA、AMER）と主要ドメインを特定する
連絡先情報（電話番号、メールアドレス）と共に Incident.io に追加する
初めてのシフト準備チェックリストを完了するよう確認する
必要なすべてのツールとドキュメントへのアクセスを提供する
最初のシフトをスケジュールし、明確に伝える
初期シフト中にサポートできるようにしておく

必要なオンボーディングリソース

新しいチームメンバーが以下にアクセスし、理解していることを確認する:

オンコールプロセスとポリシー
Tier 2 On Call Level Up チャンネル
SSCS 固有のランブックとプレイブック（開発中）
Incident.io のトレーニングとセットアップ
チームのエスカレーション基準
ドメイン向けの重要なダッシュボードとモニタリングプラットフォーム
コミュニケーションプロトコルと Slack チャンネル

祝日の管理

あなたの責任

ローテーションリーダーがすべての地域のすべてのチームメンバーの祝日を把握することは非常に困難です。期待事項を明確にする:

スケジュールされた祝日にカバレッジを見つけることはチームメンバーの責任
チームメンバーは会社のポリシーに従って祝日を別の日に自主的に変更することができる
例外: オランダの場合、チームメンバーは少なくとも2営業日前に通知する必要があり、労働協議会との合意に従い、チームメンバーではなくあなた（ローテーションリーダー）が代替カバーを見つける責任がある

祝日の競合への対応

チームメンバーが祝日の競合を特定した場合:

同じ地域の協力的な同僚とシフトをスワップするよう助ける、または
そのシフトを他の人に再割り当てするオーバーライドを作成する

祝日スケジュールを事前にチームに明確に伝える。

ワークロードと健全性メトリクスの追跡

アラートボリュームとページの監視

ローテーションの健全性を示すメトリクスを追跡する:

各エンジニアが8時間シフトあたり何回ページを受けるか？
ページはチームと地域全体で公平に配分されているか？
過剰なページを生成しているドメインがあるか（アラート疲労）？
ページが少なすぎるドメインがあるか（潜在的なカバレッジギャップ）？

ボリュームに基づくアクション:

多すぎる場合: アラートチューニングに取り組む、誤検知を減らす、ランブックを改善する
少なすぎる場合: 実際の問題が見逃されていないか確認；アラートカバレッジをチェックする

インシデント対応品質の追跡

インシデント対応の有効性を理解するためにメトリクスをレビューする:

宣言までの時間: インシデントはどの程度素早く認識・正式に宣言されるか？
修正までの時間: 宣言から解決までの時間は？
インシデントの総継続時間: 検出、宣言、修正、検証を含む全影響期間
目標: 5〜10分以内の宣言と30分以下の修正時間を目指す

エスカレーションパターンの監視

どのチームがスペシャリストにエスカレーションしているか、頻度を追跡する
クロスドメインエスカレーション（認証 → 認可など）を追跡する
エスカレーションが初回で正しいチーム/ドメインに届いていることを確認する（90%以上を目標）
エスカレーションされる内容のパターンとその理由を特定する
このデータを使ってランブックまたはトレーニングを改善する

ドメイン固有のメトリクス

ドメイン別にメトリクスを追跡する:

ドメイン別インシデント数（認証、認可、パイプラインセキュリティ）
ドメイン別平均解決時間
クロスドメインインシデントの頻度
ドメイン別ランブックカバレッジ

バーンアウト防止

四半期サーベイで以下を質問する:

「オンコールのワークロードはどの程度持続可能ですか？」
「オンコール中にサポートを受けていると感じますか？」
「オンコール関連のストレスや疲労を経験しましたか？」
「このプログラムを新しいチームメンバーに勧めますか？」
「主要ドメイン以外のインシデントを処理することに自信がありますか？」

エンジニアの80%以上がオンコールを持続可能と評価することを目標とする。スコアが低い場合はすぐに調査し、是正措置を取る。

チームメンバーのサポート

競合とスケジュール変更への対応

チームメンバーがオンコールから一歩引く必要がある場合:

正当な理由（長期休暇、大きなプロジェクトなど）に対応する
必要に応じてローテーション間の休息、シフトスワップ、または頻度の削減を提供する
一時的な変更を Incident.io に明確に文書化する
準備ができたときにスムーズに復帰させる

除外の管理

誰かがローテーションを永久に離れる場合:

彼らとそのマネージャーとオフボーディングプロセスを開始する
最後のシフトを決定する
Incident.io のスケジュールから削除する
進行中の責任を後任に引き渡させる
地域とドメインのカバレッジへの影響を評価する

持続不可能な負荷への対応

誰かが意図した以上に頻繁にオンコールを担当したり、過剰なアラートを処理している場合:

なぜそうなっているか調査する（スタッフィング、アラートボリューム、ドメイン固有の問題）
チームとリーダーシップと協力して解決する
問題と取られたアクションを文書化する
影響を受ける人に変更を伝える

プログラムの改善と学習

ランブックの文書化と改善

エスカレーションが来るたびに、ドキュメントのギャップを特定する:

Tier 2 エンジニアがエスカレーションするとき、より速く解決するために何の情報があれば良かったか確認する
インシデント後のレトロスペクティブを使ってランブックのギャップを特定する
頻繁なエスカレーションパターンに対するランブックの作成または更新を優先する
一般的なインシデントの80%をカバーする15〜20のコアランブックを目指す
ドメインあたり5〜7のランブックを目標とする（認証、認可、パイプラインセキュリティ）
一般的なシナリオに対するクロスドメインランブックを3〜5個作成する

効果的なレトロスペクティブの実施

S1/S2 インシデント（または重大な S3/S4 インシデント）に対して:

エスカレーションされた S1/S2 インシデントの100%に正式なレトロスペクティブまたは文書があることを確認する
システムの改善に焦点を当て、非難しない方法でレトロスペクティブを主導する
学んだことと改善できることを文書化する
アクションアイテムを追跡し、完了をフォローアップする
ドメインをまたいで学びを共有する

ランブック使用率の追跡

インシデントがランブックを参照しているか監視する
チームにどのランブックが最も役立つか確認する
使用されていないランブックを特定し、更新または削除する
エスカレーションパターンに基づいて新しいランブックを作成する
ドメイン別にランブックカバレッジを追跡する

コミュニケーションとエスカレーション

インシデント中のチームのサポート

チームがオンコールのとき:

質問とエスカレーションの決定に対応できるようにしておく
Tier 2 を超えたエスカレーションのタイミングを判断するのを助ける
顧客への影響とビジネス上の優先事項についてコンテキストを提供する
重大なインシデント後にデブリーフを行う
必要に応じてクロスドメインの調整を促進する

リーダーシップとのコミュニケーション

リーダーシップに以下を定期的に報告する:

ローテーションの健全性と持続可能性への懸念
ドメイン別のインシデントボリュームと解決時間のトレンド
スタッフィングのニーズ（採用または再配分が必要か？）
アラートチューニングとランブックの改善
ローテーションの文化的健全性
地域バランスとカバレッジギャップ

他チームとの調整

以下との関係を維持する:

エスカレーションを受けるインフラおよびプラットフォームチーム
チームにページするインシデントマネージャー
ベストプラクティスを共有する他のローテーションリーダー
3つの SSCS ドメインのエンジニアリングマネージャー
チームメンバーのサポートのためのチームのマネージャー

リーダーシップへのエスカレーションタイミング

以下の場合にマネージャーまたはリーダーシップに問題を報告する:

誰かが4週間に1回以上のペースで持続不可能なオンコールを担当している
バーンアウトまたは離職率が増加している
特定のドメインでアラートボリュームが管理不能
ある地域でスタッフィングレベルが不足している
ローテーション構造が機能していない
文化的な問題が発生している（責任追及、エスカレーション拒否など）
クロスドメインの調整が機能していない
1つのドメインが大幅に過負荷になっている

成功の指標

以下の場合にローテーションが健全です:

エンジニアがオンコールでバーンアウトしない
シフトが地域とチームメンバー間で公平に配分されている
インシデント対応時間が改善している（TTDec と TTFix が低下トレンド）
レトロスペクティブが非難せず、システムの改善に焦点を当てている
ランブックがすべてのドメインで定期的に使用・更新されている
エスカレーションが正しいチーム/ドメインに届いている
新しいエンジニアが最初のシフトでサポートを受けていると感じる
チームメンバーがオンコールを管理可能で教育的と見なしている
文化的健全性サーベイが持続可能性で80%以上のスコア
クロスドメインのコラボレーションがスムーズ
3つすべての地域が適切なカバレッジを持っている

クイックリファレンス: 主要な責任

スケジュール管理:

3つの地域と3つのドメインにわたる適切なカバレッジを維持する
1ヶ月以上前にスケジュールを公開する
四半期ごとに公平性を追跡する
個人のローテーション頻度を最大で4週間に1回に上限設定する

オンボーディング:

新しいメンバーを Incident.io に追加する
ツールアクセスとドキュメントを提供する
最初のシフトをサポートする
トレーニングの完了を確認する

ワークロード追跡:

地域とドメイン別にシフトあたりのページを監視する
インシデント対応メトリクスを追跡する
バーンアウトの指標に注意する
四半期ごとの公平性レビューを実施する

チームサポート:

スケジルの競合とスワップを支援する
欠勤用のオーバーライドを作成する
持続不可能な負荷に対処する
インシデント中のエスカレーションをサポートする
クロスドメインの調整を促進する

改善:

ドメイン別にランブックのギャップを特定する
非難しないレトロスペクティブを主導する
メトリクスとトレンドを追跡する
ドメインをまたいで学びを共有する