Tier 2 オンコール FAQ
APAC タイムゾーンの懸念事項
Q：APAC カバレッジが「ベストエフォート」のみとされているのはなぜですか？
A：APAC のタイムスロット（02:00-10:00 UTC）は、ほとんどの APAC チームメンバーにとって非常に早い時間から始まります。たとえば、IST のチームメンバーは午前 4:30 から対応可能である必要があります。この課題を踏まえ、APAC のカバレッジはベストエフォートで、エンジニアが呼び出し通知に応答できる場合はそうしますが、ビジネスデーが始まったあとにフォローアップすることもできます。
Q：APAC のエンジニアが午前 4:30 に呼び出し通知へ応答できない場合、何が起こりますか？
A：業務時間外の応答に対するペナルティはありません。期待されるのは、通常の業務時間中に合理的に可能なタイミングで応答することです。エスカレーション層（EM が 24x5 でカバー）がギャップを埋めるのに役立ちます。
Q：APAC のチームメンバーは他の地域より多くのシフトを取ることが期待されますか？
A：現在、APAC のチームメンバーはチームサイズが小さい（8 名）ため、52 週間の期間で一人あたり約 6-7 週間が割り当てられています。ただし、これは以下を通じて積極的に取り組まれています：
- 新しい APAC チームメンバーをローテーションにオンボーディングする
- 負荷をよりバランスよくするための Sec クロスステージカバレッジオプションを検討する
Q：APAC のエンジニアはシフト時間を調整できますか？
A：タイムスロットは固定で、すべての地域にわたる継続的なカバレッジを確保するために世界規模で調整されています。ただし、APAC カバレッジのベストエフォートの性質により、割り当てられた週の中で実際に応答するタイミングに柔軟性が与えられます。
医療予約のカバレッジ
Q：オンコール週に医療予約がある場合、どうすればよいですか？
A：標準の Incident.io オーバーライドプロセスに従ってください：
- #sscs-tier2-rotation-coordination で、レポート先のマネージャーまたは @adil.farrukh、@jpr0c、@mmishaev（ローテーションリーダー）に連絡する。
- 連絡した相手またはチームメンバーと協力して、そのタイムスロットをカバーする
- 上記の Slack チャンネルでマネージャーとチームに通知する。
- オーバーライドを事前に文書化する（緊急でない場合は理想的には 48 時間以上前の通知）
Q：シフト中に医療緊急事態が発生した場合は？
A：あなたの健康が最優先です。応答できない場合：
- 可能であれば、すぐにマネージャーまたはエスカレーション層（EM）に通知する
- エスカレーション層がカバレッジを処理する
- カバレッジの取り決めについて話し合える状態になったら、マネージャーにフォローアップする
Q：オンコール中の医療予約には PTO を使う必要がありますか？
A：いいえ。通常の業務時間中の医療予約は、GitLab の標準的な PTO と柔軟性のポリシーに従って処理されるべきです。オンコールシフトは通常の業務スケジュールに合わせられているため、予約は通常どおりに扱ってください。
Q：割り当てられた週中に予定された手術や長期医療休暇がある場合は？
A：衝突を知った時点でできるだけ早くマネージャーに連絡してください。マネージャーは：
- あなたの週を別のチームメンバーと交換するようにチームと協力する
- incident.io でスケジュールを更新する
- カバレッジの隙間がないことを確認する
ドメインの専門知識が不足している場合のエスカレーション手順
Q：自分の専門領域外の問題で呼び出された場合（たとえば、Authentication 出身だが問題が Pipeline Security の場合）？
A：これは想定内であり、ローテーション設計で認識されています。以下のエスカレーションパスに従ってください：
- 呼び出し通知に 15 分以内に確認応答 し、オーナーシップを確立する
- 利用可能なランブックとプレイブック、コードベース調査を使って 初期トリアージを実施する
- 関連するチームの Slack チャンネルに投稿して ドメインエキスパートを巻き込む
- Slack リクエストへの応答が 5 分以内に見られない場合は EM 層にエスカレートする
- ドメインエキスパートが技術的解決を引き継いだとしても、調整のための DRI（Directly Responsible Individual）として残る
Q：エスカレーション層には誰がいますか？
A：エスカレーション層は、Software Supply Chain Security チームのエンジニアリングマネージャーで構成され、24x5 で利用可能です。これには非 AMER 時間のエスカレーションカバレッジのための @mmishaev が含まれます。
Q：EM 層にエスカレートすべきタイミングは？
A：以下の場合にエスカレートしてください：
- 問題があなたが持っていないドメインの専門知識を必要とする
- インシデントの重要度が S1/S2 で、追加のリソースが必要。なお、S1/S2 にはすでに IMOC がインシデントに割り当てられていることに注意。
- 適切な対応や緩和策について不確かである
- 複数チーム間の調整に助けが必要
- 進捗なしに 30 分以上 1 つの問題に取り組んでいる
Q：インシデント中に利用できるリソースは何がありますか？
A：以下にアクセスできます：
- ランブックとプレイブック（プログラムの進展とともに拡張中）
- Level Up Channel 内の Tier 2 オンコールトレーニング
- EM エスカレーション層（24x5 カバレッジ）
- ドメイン固有の質問のための チーム Slack チャンネル
- Incident.io ドキュメント とインシデント履歴
- オンコール手順に関する GitLab ハンドブック
Q：自分の専門外の問題を修正することが期待されていますか？
A：いいえ。Tier 2 としてのあなたの役割は：
- SRE よりも速くドメイン知識にアクセスできるようにする
- インシデント対応を調整・所有し、フィーチャーフラグの無効化、ロールバック、回避策、コード変更などのさまざまなツールを使って良好な状態に戻す。
- 一般的な SSCS の知識を活用して、効果的にトリアージする
- 専門知識が必要な場合は適切にエスカレートする
このプログラムは、Authentication、Authorization、Pipeline Security のすべてのエンジニアが互いの領域に精通しているわけではないことを認識しています。ランブックは時間とともにこれらのギャップを埋めるのに役立ちます。
現在の Dev-On-Call との違い
Q：Tier 2 は現在の dev-on-call や IMOC とどう違いますか？
A：主な違い：
| 観点 | 現在の Dev-On-Call/IMOC | Tier 2 SME オンコール |
|---|---|---|
| スコープ | 広いエンジニアリングカバレッジ | ドメイン固有（SSCS のみ） |
| 一次対応者 | GitLab.com の SRE | SRE/SIRT が一次対応（Tier 1） |
| 呼び出されるタイミング | あらゆるインシデント | ドメインの専門知識が必要な場合のみ |
| 応答時間 | 15 分 | 15 分 |
| カバレッジ | 24x7 カバレッジのための業務時間中の pagerslack と週末 dev-oncall の組み合わせ | 24x5（月-金のみ） |
| ローテーション頻度 | さまざま | 地域によって年間 4-7 週間 |
| 期待される専門知識 | 一般的な運用知識 | 深い製品／コード知識 |
Q：IMOC や週末 dev-on-call にも引き続き入りますか？
A：いいえ。2026 年 1 月 5 日に Tier 2 ローテーションが開始されると、IMOC または現在の dev-on-call スケジュールから外されます。複数のローテーションに参加することは期待されません（必要に応じて議論できる重大なカバレッジ問題がない限り）。
Q：どのような種類のインシデントで呼び出されますか？
A：以下の場合に呼び出されます：
- SRE または SIRT が SSCS 関連のインシデントのためにドメイン固有の専門知識を必要とする場合
- インシデントが Authentication、Authorization、または Pipeline Security のコンポーネントを含む場合
- Tier 1 が初期トリアージを完了したが、解決に専門知識が必要な場合
- 顧客に影響を与える問題が深い製品／コード理解を必要とする場合
以下の場合には呼び出されません：
- SRE が処理できる定型的な運用問題
- インフラのみの問題
- SSCS ドメイン外の問題
- 重大でないサポート問題
Q：8 時間のシフト全体でコンピュータの前にいる必要がありますか？
A：いいえ。期待されるのは：
- 15 分以内に呼び出し通知へ応答できる
- ラップトップと安定したインターネット接続にアクセスできる
- 割り当てられたシフト時間中に利用可能である
- 必要に応じてインシデントコールに参加できる
これは通常の業務スケジュールに合わせられているため、オンコール中も通常の業務を続けることができます。
Q：週末はどうなりますか？
A：現在の 24x5 ローテーションには週末は含まれません。週末カバレッジは Legal、HR、Works Council の承認を受けて、今後のイテレーションで対応されます。
Q：自分がオンコール中であることをどうやって知ることができますか？
A：以下によって知ることができます：
- incident.io スケジュール（確認後に作成）で割り当てられた週を確認する
- シフトが始まると incident.io 通知を受け取る
- オンコール期間のためのカレンダー招待をセットアップする
- Incident.io アプリで今後のローテーションが見える
Q：最初のシフト前に必要なトレーニングは何ですか？
A：スケジュールが許す限りすぐに、Tier 2 オンコール Level Up Channelでトレーニングを完了してください。トレーニングは以下をカバーします：
- インシデント対応手順
- incident.io と PagerDuty の使用
- エスカレーションパス
- ランブックとプレイブック（時間の経過とともに拡大）
すべてのチームメンバーは、2026 年 1 月 5 日の開始日前にこれを完了する必要があります。
追加の質問
Q：チームメイトとシフトを交換できますか？
A：はい。あなたの地域のチームメイトと直接調整し、次に：
- PagerDuty でオーバーライドを更新する
- マネージャーに通知する
- チーム Slack チャンネルで交換を文書化する
Q：割り当てられた週に PTO 中の場合は？
A：衝突を知った時点でできるだけ早くマネージャーに連絡してください。マネージャーがカバレッジを手配し、スケジュールを更新します。
Q：ここでカバーされていない質問があれば誰に連絡すればよいですか？
A：以下に連絡してください：
- スケジュールやカバレッジの質問は直属のマネージャーに
- プログラム関連の質問は @adil.farrukh に
- アクティブなインシデント中は EM エスカレーション層に
- 一般的な質問はチーム Slack チャンネルに投稿する
Q：この FAQ は更新されますか？
A：はい。プログラムの進展と新しい質問の発生に伴い、この FAQ は拡張されます。追加のトピックに関するフィードバックや提案を歓迎します。
a1f3c26a)