Content last updated 2026-05-04

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

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

あなたの役割と責任

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

スケジュール管理

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

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

3 つの地域 (APAC、EMEA、AMER) すべてにわたって適切なカバレッジを確保する
3 つのドメイン (Authentication、Authorization、Pipeline Security) すべてにわたるカバレッジを確保する
バランスの取れたワークロードのために 1 地域あたり 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 (ベストエフォートベース)
一人あたり年間約 6-7 週間
現在のチームサイズ: 7 名のエンジニア
チームサイズが最小なので頻度が高い

EMEA (ヨーロッパ/中東/アフリカ)

カバレッジ: UTC 07:00 - 15:00
一人あたり年間約 5-6 週間
現在のチームサイズ: 10 名のエンジニア
中程度の頻度

AMER (アメリカ)

カバレッジ: UTC 15:00 - 23:00
一人あたり年間約 4-5 週間
現在のチームサイズ: 12 名のエンジニア
チームサイズが最大なので頻度が低い

公正な分配の確保

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

すべてのエンジニアがそれぞれの地域内でほぼ同じ数のシフトを取得することを確認する
各人がオンコール状態であった回数を追跡する
シフト中に最も多くのアラートを処理した人を確認する
公平な分担より多くを担っている人を特定する
一貫してより忙しい週を取得する人のパターンに注意する
オンコール業務を最大 4 週間に 1 回まで制限する

ドメインバランス

ドメイン間の公正な分配を確保します:

ドメイン (Authentication、Authorization、Pipeline Security) ごとのインシデントを追跡する
あるドメインが著しく多くのインシデントを生成しているかどうかを監視する
あるドメインが過負荷の場合、配員またはアラートチューニングを調整する
クロスドメインの知識共有を確保する

四半期公平性レビュー

四半期ごとに、以下のレビューを実施します:

各人がオンコール状態であった回数は?
シフトは地域内で公正に分配されていたか?
燃え尽きや持続不可能な負荷を報告した人はいたか?
各地域のカバレッジ目標を達成したか?
ドメインカバレッジはバランスが取れているか?
分配が不公平になった場合は再バランスする

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

ローテーションへの追加

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

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

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

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

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

祝日の管理

あなたの責任

ローテーションリーダーが、すべての地域のすべてのチームメンバーの祝日を知ることは非常に難しいです。期待を明確にします:

祝日にスケジュールされている場合、カバレッジを見つけるのはチームメンバーの責任です
チームメンバーは、会社のポリシーに従って、祝日を別の日に自発的に変更することがあります
例外: オランダの場合、チームメンバーは少なくとも 2 営業日前に通知し、Works Council との合意に従って、カバレッジを見つけるのは (チームメンバーではなく) あなたの責任です

祝日の衝突への対応

チームメンバーが祝日の衝突を特定したとき:

同じ地域の意欲ある同僚とシフトを交換するのを助ける、または
そのシフトを別の人に再割り当てするためのオーバーライドを作成する

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

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

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

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

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

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

高すぎる場合: アラートチューニングに取り組み、誤報を減らし、ランブックを改善する
低すぎる場合: 実際の問題が見落とされていないか確認する。アラートカバレッジをチェックする

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

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

宣言までの時間: インシデントが認識され、正式に宣言されるまでの速度は?
修正までの時間: 宣言から解決までの時間は?
総インシデント期間: 検出、宣言、修正、検証を含む全影響ウィンドウ
目標: 宣言は 5-10 分以内、修正時間は 30 分以下を目指す

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

どのチームがスペシャリストにエスカレートしているか、どのくらいの頻度かを追跡する
クロスドメインのエスカレーション (たとえば、Authentication → Authorization) を追跡する
エスカレーションが最初の試行で正しいチーム/ドメインに送信されることを確認する (目標 90%+)
何がエスカレートされ、なぜかのパターンを特定する
このデータを使ってランブックやトレーニングを改善する

ドメイン固有メトリクス

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

ドメインごとのインシデント (Authentication、Authorization、Pipeline Security)
ドメインごとの平均解決時間
クロスドメインインシデントの頻度
ドメインごとのランブックカバレッジ

燃え尽き防止

四半期ごとに以下を尋ねる調査を実施します:

「あなたのオンコールワークロードはどれほど持続可能ですか?」
「オンコール中にサポートされていると感じますか?」
「オンコール関連のストレスや疲労を経験しましたか?」
「新しいチームメンバーにこのプログラムを推奨しますか?」
「主要なドメイン外のインシデントを処理することに快適に感じますか?」

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

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

衝突とスケジュール変更の処理

チームメンバーがオンコールから離れる必要があるとき:

正当な理由 (長期休暇、主要プロジェクトなど) に対応する
必要に応じてローテーション間の休憩、シフト交換、または頻度の削減を提供する
Incident.io に一時的な変更を明確に文書化する
準備ができたらスムーズに再統合する

削除の管理

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

本人とそのマネージャーとオフボーディングプロセスを開始する
最終シフトを決定する
Incident.io のスケジュールから削除する
アクティブな責任を後任に引き継ぐことを確認する
地域とドメインのカバレッジへの影響を評価する

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

誰かが意図された頻度より多くオンコールである、または過剰なアラートを処理している場合:

これが起こっている理由 (配員、アラートボリューム、ドメイン固有の問題) を調査する
チームおよびリーダーシップと協力して解決する
問題と取られたアクションを文書化する
影響を受ける人に変更を伝える

プログラム改善と学習

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

エスカレーションが入ったら、ドキュメントのギャップを特定します:

Tier 2 エンジニアがエスカレートするとき、より速く解決するのに役立つ情報を尋ねる
インシデント後のレトロスペクティブを使ってランブックのギャップを特定する
頻繁なエスカレーションパターンのためのランブックの作成または更新を優先する
一般的なインシデントの 80% をカバーする 15-20 のコアランブックを目指す
ドメイン (Authentication、Authorization、Pipeline Security) ごとに 5-7 のランブックを目指す
一般的なシナリオのために 3-5 のクロスドメインランブックを作成する

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

S1/S2 インシデント (または重要な S3/S4 インシデント) について:

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

ランブックの使用状況の追跡

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

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

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

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

質問やエスカレーションの意思決定のために利用可能である
Tier 2 を超えていつエスカレートするかを判断するのを助ける
顧客への影響とビジネス優先事項のコンテキストを提供する
重要なインシデント後にデブリーフィングを行う
必要に応じてクロスドメインの調整を促進する

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

以下についてリーダーシップに情報を提供し続けます:

ローテーションの健全性と持続可能性に関する懸念
ドメイン別のインシデントボリュームと解決時間の傾向
配員のニーズ (採用または再分配が必要か?)
アラートチューニングとランブックの改善
ローテーションの文化的健全性
地域バランスとカバレッジギャップ

他のチームとの調整

以下との関係を維持します:

エスカレーションを受ける可能性のあるインフラストラクチャとプラットフォームのチーム
あなたのチームをページする Incident Manager
ベストプラクティスを共有するための他のローテーションリーダー
3 つの SSCS ドメインのエンジニアリングマネージャー
チームメンバーのサポートのためのチームのマネージャー

リーダーシップにエスカレートするタイミング

以下の場合、マネージャーまたはリーダーシップに問題を持ち込みます:

誰かが 4 週間に 1 回以上、持続不可能にオンコールである
燃え尽きまたは離職率が増加している
特定のドメインのアラートボリュームが管理不能である
地域の配員レベルが不十分である
ローテーション構造が機能していない
文化的問題 (非難、エスカレーションの欠如など) が出現する
クロスドメイン調整が崩壊している
1 つのドメインが著しく過負荷である

成功の指標

ローテーションが健全であることを示すのは:

エンジニアがオンコールから燃え尽きていない
シフトが地域とチームメンバー間で公正に分配されている
インシデント対応時間が改善している (TTDec と TTFix が低下傾向)
レトロスペクティブが責任追及せず、システム改善に焦点を当てている
すべてのドメインでランブックが使用され、定期的に更新されている
エスカレーションが正しいチーム/ドメインに行っている
新しいエンジニアが初回シフト中にサポートされていると感じている
チームメンバーがオンコールを管理可能で教育的なものと見なしている
文化的健全性調査が持続可能性で 80%+ のスコア
クロスドメインのコラボレーションがスムーズである
3 つの地域すべてが適切なカバレッジを持っている

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

スケジュール管理:

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

オンボーディング:

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

ワークロード追跡:

地域とドメインごとのシフトあたりのページを監視する
インシデント対応メトリクスを追跡する
燃え尽きの兆候を監視する
四半期公平性レビューを実施する

チームサポート:

スケジュールの衝突と交換を支援する
不在のためのオーバーライドを作成する
持続不可能な負荷に対処する
インシデント中のエスカレーションをサポートする
クロスドメイン調整を促進する

改善:

ドメインごとのランブックのギャップを特定する
責任追及のないレトロスペクティブをリードする
メトリクスと傾向を追跡する
ドメイン間で学びを共有する