オンコールのプロセスとポリシー

GitLab のオンコール

プロダクションインシデントが発生した際は、迅速かつ安全に解決する必要があります。インシデントに対応できるチームメンバーが常駐していることを確保するために、一連のオンコールローテーションを維持しています。

ハンドブックのこのセクションでは、その方法と関与するチームメンバーの責任について説明します。

インシデントの管理方法の詳細はインシデント管理ハンドブックページに記載されています。

ローテーションとは何ですか？

ローテーションとは、インシデントの解決を支援するために連絡可能な特定の知識とスキルを持つチームメンバーのセットです。

ローテーションにはローテーションを調整するリーダーがいます。リーダーは、適切なカバレッジレベルを提供するのに十分なチームメンバーがいることを確認し、チームメンバーがローテーションの要件を理解していることを確認し、ローテーションの定期的なレビューを実施します。

ローテーションには、ページングシステムを通じて支援のリクエストに対応するチームメンバーもいます。

ローテーションにはティアとカバレッジターゲットがあります。

ティアとカバレッジシステム

ティア

ローテーションには3つのティアがあります。

1. Tier 1 — チームメンバーがシステムによってページングされる（自動アラートによる）
2. Tier 2 — チームメンバーが人間によってページングされる（インシデントに関与した人間が特定の判断でさらなる支援を要請する）
3. エスカレーション — リーダーシップの介入が必要な場合、またはページが応答されなかった場合

カバレッジ

カバレッジのレベルは複数あります。

1. 24x7 — いつでも名前のあるチームメンバーがページに対応できる。Tier 1 ローテーションは常に 24x7。Tier 2 ローテーションも 24x7 の場合がある。
2. 24x5（フルカバレッジ） — 営業週（月/火/水/木/金）の任意の時間に名前のあるチームメンバーがページに対応できる。
3. 24x5（パーシャルカバレッジ） — 営業週（月/火/水/木/金）のほとんどの時間に名前のあるチームメンバーがページに対応できる。カバレッジにドキュメント化されたギャップがある。
4. ベストエフォートローテーション — ページが名前のあるチームメンバーではなくチームメンバーのグループに送信される。任意の時点でページに対応する責任を持つ単一のチームメンバーはいない。

ベストエフォートローテーションに参加するチームメンバーは「オンコール」とはみなされないことに注意することが重要です。

誰かがオンコールの場合、特定の職務を実行するよう指定されています。ページャーを保持し、ページングされたときに迅速に対応することが期待されています。現在のアイテムを脇に置いてページャーに対応することが期待されています。

ベストエフォートローテーションでは、任意の時点でページに対応する役割責任を持つ単一のチームメンバーはいません。作業中にページに対応すべきであり、このページは他の作業アイテムより優先されるべきです。

この区別は重要です。オンコールカバーには法的および HR 上の影響があり（レベルによって異なる）、ベストエフォートローテーションには法的または HR 上の影響はないためです。

カバレッジ期間

1日の 24 時間は各 8 時間の3つの期間に分けられます。エスカレーションローテーション以外のローテーションでは、1日3回発生する8時間のカバレッジ期間を標準化しています。

チームメンバーは通常の業務時間に最も合う3つのスロットのいずれかを選択でき、3か月前の通知で別のスロットに移動できます。

推奨（UTC）：

1. APAC 23:00 - 07:00
2. EMEA 07:00 - 15:00
3. AMER 15:00 - 23:00

ローテーションリーダーは、ニーズに合わせて異なる8時間の期間を選択できます。

週末と祝日のカバレッジ

ローテーションが 24x7 の場合、週末と祝日のカバレッジが必要です。より具体的な情報については、ティアページをご覧ください。

国固有の要件

1. ニュージーランド — 祝日シフトは自発的であり、チームメンバーが祝日にシフトを担当することを選択する場合、祝日のページへの対応は補償が必要なため、マネージャーの承認が必要です。祝日のカバーや承認を手配するのはチームメンバーの責任です。詳細についてはニュージーランドガイドをご覧ください。

ローテーションリーダーの責任

ローテーションリーダー用 Slack チャンネル：#oncall-rotation-leaders

1. 定義と維持：
   1. エスカレーションルール
   2. ローテーションへの参加を支援するオンボーディング資料
   3. ドキュメントとランブック
2. タイムゾーンに十分な注意を払いながら、合意されたカバレッジレベルでローテーションを維持する。
3. 新しいチームメンバーが参加したり既存のチームメンバーが離脱したりする際は、必ずスケジュールを更新する。短期間のローテーションが中断されないよう、60日前にスケジュール変更を行うことをお勧めします。60日以内に必要な変更はオーバーライドで対応できます。
4. 毎年 11 月の第4木曜日より前に祝日カバレッジ計画を準備・公開する。
   1. American Thanksgiving から年末にかけては、他のどの時期よりも PTO の取得者が多いため、特別なカバレッジ計画を依頼しています。
5. 確認されていないページを処理するエスカレーションパスを維持する。

Tier 1 と Tier 2 両方のオンコール責任と期待

オンコールの場合、以下のことが期待されます。

1. オンコールスケジュールを定期的に確認し、いつオンコールかを把握してください。インシデント管理システムを使用してオンコールシフトが始まる前にアラートを出すことができます。
2. 通知設定が正しく設定されていることを確認し、これらの設定でページを確認する方法を理解してください。
3. 外部のコミットメントにより引き受けられないシフトにアサインされた場合、カバーを見つけるのはあなたの責任です。チームの Slack チャンネルを使用して、カバーを探していることをローテーションリーダーに通知してください。部分的なカバー（数時間）、日次カバー、またはフルカバーを探せます。
4. 病気で勤務できない場合は、オンコールをすべきではありません。マネージャーに病欠を伝える際に、オンコールであることを知らせてください。マネージャーがカバーを手配します。
5. シフト中に個人的な緊急事態が発生した場合、マネージャーへの不在メッセージに、このローテーションのオンコールであることを知らせてください。マネージャーがカバーを見つける責任を持ちます。
6. 15 分以内にページを確認し、その後できるだけ早くインシデント解決の支援のために職場に戻ってください。
7. 面接を行っているか、アクティブな面接官プールに参加している場合は、ModernLoop の設定を最新の状態に保ち、オンコール中に面接がスケジュールされないようにしてください。オンコール期間に面接がスケジュールされた場合は、その時間の部分的なカバーを探してください。
8. 育児休業などの長期休暇を取る場合は、オンコールスケジュールを調整するためにローテーションリーダーに連絡する必要があります。

上記の例外

1. オランダのチームメンバーについては、アサインされたシフトを引き受けられない場合、少なくとも2営業日前にローテーションリーダーに通知しなければなりません。カバーを見つける責任はチームメンバーではなくローテーションリーダーにあります（労使協議会との合意による）。

オンコールの一般的な期待事項

• オンコールの場合は、PagerDuty ページまたは incident.io エスカレーションに対して可能な限り早く、カスタマーエマージェンシーの場合はサービスレベル契約で定められた応答時間内に対応できる状態で準備していることが期待されます。オンコールシフト中にワークスペース外で予定がある場合は、ラップトップと信頼できるインターネット接続を持参する必要があることがあります。
• 私たちはオンコールを真剣に受け止めています。一次対応者が時間内に対応しない場合に別のチームメンバーにアラートを出すエスカレーションポリシーがあります。このようなポリシーは通常の運用では発動することは期待されておらず、極端かつ予測不可能な状況をカバーするためのものです。
• GitLab は非同期ワークフローの会社であるため、Slack でのオンコール個人への @mention は通常のメッセージとして扱われ、それらには SLA の応答は関連付けられません。
• リリースプロセスでリリースマネージャーへのサポートを提供する。
• メインハンドブックに記載されているように、Tier 1 または Tier 2 ローテーションのオンコール後は、必要に応じて休暇を取ってください。シフト中に多くのページやインシデントに関与し、休息が必要だと感じる場合はそうしてください。ストレスの多いオンコールシフト後の休息はバーンアウトを防ぐために不可欠です。休暇を取る時間をチームに必ず知らせてください。
  • シフト（5日以上のシフト）から回復するために必要な場合は「代替休暇」として1〜2日の休暇を取ることが期待されます。
  • シフトのプレッシャーについてマネージャーとコミュニケーションし、アラート、プロセス、またはインシデント解決の他の側面の改善に対処できるようにすることが期待されます。
  • オーストラリアのチームメンバーはオーストラリアの代替休暇ポリシーを確認してください。
• オンコール職務中は、チームメンバーが現地の規則と規制に従って行動する責任があります。不明な場合はマネージャーおよび/または担当の People Business Partnerに連絡してください。

オンコールの実践的な側面

1. 電話に特定のものをインストールする必要はありません。ページングシステムはメール、電話、SMS、または（アプリをインストールする場合）アプリ内通知で通知するよう設定できます。
2. シフト中に休憩を取ることができます。15 分以内にページを確認し、その後まもなくデスクに戻れる状態を確保する必要があります。

オンコールローテーションの設定方法

参加者の特定

新しいローテーションに参加するチームメンバーを特定します。

トレーニングとオンボーディングの作成

LevelUp を使用して、このローテーションに参加するチームメンバー向けのトレーニングを作成・実施します。

ローテーションを設定するには何人必要ですか？

すべてのタイムゾーンにわたるカバレッジを提供するには、地域ごとに最低4人を目標にする必要があります。これにより、1週間のうち4週間に1回のオンコールパターン（4週間に1回1週間のオンコール）が可能になります。

地域ごとに12人以上のチームメンバーがいる場合、チームメンバーがオンコールであることを忘れたり、ページングされたときに何をすべきかわからないリスクがあります。地域ごとのローテーションは12人未満のチームメンバーにすることをお勧めします。

一部のタイムゾーンでこれより少ないチームメンバーがいる場合は、24x5 を使用してカバレッジのギャップを宣言できます。チームが非常に小さい場合は、ベストエフォートローテーションを検討できます。

ローテーションパターンの定義

AMER、EMEA、APAC の3つのチームメンバーグループを作成することをお勧めします。上記のカバレッジ期間を参照してください。

管理しやすいよう等しい長さの3つのシフトが推奨されますが、ローテーションリーダーはチームメンバーの通常の業務時間を考慮し、可能な限りこれを取り入れる必要があります。

エスカレーションパスの定義

オンコールチームメンバーがページに対応しない場合のエスカレーション手順を定義します。これらのエスカレーションパスは各ローテーションの Incident.io でコード化されます。以下のオプションがあります。

オプションには：

1. 15 分後にすべてのチームメンバーにラウンドロビンでページを設定する
2. 対応しないオンコールチームメンバーのローテーションにエスカレートする。各ローテーションは Tier 2 ハンドブックページの「Escalation upon non-response: @here + msg on appropriate slack channel #tier-2-(team-name)-rotation-swaps」、またはその他の同様のアクションを列挙すべきです。
3. IMOC が対応できない特別なケースの場合、カスタムエスカレーションスケジュールを作成する

エスカレーションはまれですが、支援のリクエストに対応する計画を持つことが依然として重要です。

参加者リストの更新

既存のローテーションにチームメンバーを追加すると、スケジュールが自動的に再計算され、現在誰がオンコールかが変わる可能性があります。現在のシフトをそのまま維持するために、新しいチームメンバーをリストの先頭に追加して、以下のオプションのいずれかを選択します。

1. ユーザーを追加するときに表示される延期ボタンをクリックする
2. 「delay changes」オプションを選択して、現在のシフトの終了時に有効日を設定する
3. 現在のオンコール担当者が自分のポジションにとどまり、新しいメンバーがシフトを開始すべき場所に配置されるようにユーザーリストを並べ替える

これにより、次のスケジュール済みの引き継ぎ時に変更が適用され、新しいチームメンバーが更新されたローテーションの最初のシフトを担当します。

チームメンバーを一時的または永久にローテーションから削除する必要がある場合（例：休暇、チーム異動、または変更された責任のため）は、ローテーションリーダーに連絡してください。ローテーションリーダーが近日のシフトのカバーを手配してスケジュールを更新します。

Slack チャンネル

一部のチームがすでに効果的なコミュニケーションチャンネルを持っている場合があることを認識して、各ローテーションの Slack チャンネルの設定はオプションです。既存のチャンネルを使用するか、スケジュール全体に1つのチャンネルを作成するか、地域ごとに1つのチャンネルを作成するかは、ローテーションオーナーの判断に委ねられています。

使用する Slack チャンネルはTier 2 ハンドブックページに追加する必要があります。

ただし、Slack チャンネルを作成する場合は、次の形式に従っていることを確認してください。

• tier-2-(team-name)-rotation-swaps
• tier-2-(team-name)-rotatoin-swaps-apac
• tier-2-(team-name)-rotatoin-swaps-emea
• tier-2-(team-name)-rotatoin-swaps-amer

incident.io

オンコールスケジュールの設定と適切な個人への通知のルーティングに incident.io を使用しています。

オンコール職務の交換

誰かのためにシフトをカバーするチームメンバーは、incident.io でオーバーライドを追加する責任があります。これは #eoc-general Slack チャンネルまたは incident.io の Request Coverage 機能で手配できます。このタスクをリクエスターに委任できますが、リクエストされたシフトをカバーすることを明示的に確認した後のみ可能です。オーバーライドを設定するには、ページの右上の「Create Override」ボタンをクリックするか、スケジュールビューの関連する時間ブロックをクリックします。このアクションはオーバーライドの担当者をデフォルトであなたに設定します — incident.io はあなたがオーバーライドを申し出る人だと仮定します。別のチームメンバーのためにこれを処理している場合は、ドロップダウンリストからその人の名前を選択する必要があります。参考としてこの記事もご覧ください。

ロスターへの追加と削除

オンコールロスターに新しいチームメンバーを追加すると、ローテーションスケジュールが変更することは避けられません。新しいチームメンバーを追加するマネージャーは、可能な限り現在のスケジュールを変更しないよう、現在のローテーションの最後の方に個人を追加します。ローテーションに新しいチームメンバーを追加する際、マネージャーはチームに話題を提起して、全員が変更を確認するのに十分な時間があることを確認します。

Slack

オンコールプロセスと生活の質についての非公式な会話、シフトの調整、より広範なアナウンスのコミュニケーションを促進するために、#eoc-general チャンネルがあります。

その他のエンジニアリングオンコールローテーション

以下のオンコールローテーションは Infrastructure Platforms の外部に存在しますが、単一の参照ポイントとしてここに記録されています。

カスタマーエマージェンシーオンコールローテーション

• 場所に基づいたフォローザサンスタイルで、8時間シフトを7日間実施します。
• 10分後にアラートが確認されない場合、オンコールのサポートマネージャーにアラートが出ます。さらに5分後、3つの全地域のシニアサポートリーダーシップにアラートが出ます。
• 緊急として提起されたすべてのチケットは緊急 SLA を受けます。オンコールエンジニアの最初のアクションは緊急リクエストのトリアージを行い、顧客と共に最善の方向性を見つけることです。
• 30分後、顧客が最初の連絡に応答していない場合は、緊急チケットをクローズして通常優先度のチケットをオープンしていることを通知してください。必要に応じて新しい緊急チケットを開けることも知らせてください。
• PagerDuty でスケジュールとエスカレーションポリシーを確認できます。オンコールスケジュールをサブスクライブすることもでき、これは毎日更新されます。
• アラート/インシデントがあった場合、各シフト後にオンコール担当者は次のオンコール担当者に何が起きたか、何が進行中かを説明し、適切な Issue とその進捗を示したハンドオフメールを送信します。
• 現在のオンコールエンジニアに連絡する必要があり Slack でアクセスできない場合（例：週末またはシフトの終わり）は、PagerDuty インシデントを手動でトリガーして注意を引き、Customer Support を Impacted Service として選択して関連するサポートエンジニアにアサインできます。
• 顧客緊急事態の処理に関するより包括的なガイドは GitLab サポートオンコールガイドをご覧ください。

セキュリティチームオンコールローテーション

セキュリティオペレーション（SecOps）

• SecOps のオンコールローテーションは 24 時間シフットを7日間実施します。
• 15分後にアラートが確認されない場合、オンコールのセキュリティマネージャーにアラートが出ます。
• PagerDuty でセキュリティオペレーションスケジュールを確認できます。
• オンコール中は、オンコールを改善する作業（プロジェクトの構築、システム、メトリクスの追加、ノイズの多いアラートの削除を含む）を優先してください。プロダクションチームと同様に、オンコール中は何もすることがなく、意味のあるアラートとページを持つことを目指しています。これを達成する唯一の方法は、自動化に時間を投資することです。
• オンコール中の主な期待は、ページの緊急性をトリアージすることです — GitLab のセキュリティが危険にさらされている場合は、問題を理解して適切な対応を調整するよう最善を尽くしてください。何をすべきかわからない場合は、オンコールのセキュリティマネージャーに支援を求めてください。
• 詳細は Security Operations オンコールガイドとセキュリティインシデント対応ガイドをご覧ください。

セキュリティマネージャー

• セキュリティマネージャーのオンコールローテーションは 12 時間シフットを7日間実施します。
• SecOps オンコールページが15分以内に応答されない場合、オンコールのセキュリティマネージャーにアラートが送信されます。
• PagerDuty でセキュリティマネージャースケジュールを確認できます。
• オンコールのセキュリティマネージャーは、プライマリが利用できない場合に代替/バックアップの SecOps エンジニアを招集する責任があります。
• GitLab に対する高影響のセキュリティインシデントが発生した場合、オンコールのセキュリティマネージャーがクロスチーム/部門調整の支援のために招集されます。

Developer Experience ステージオンコールローテーション

• Developer Experience のオンコールは GitLab の通常業務時間外の作業を含みません。プロセスはパイプラインオンコールローテーションページに定義されています。
• ローテーションは3つのタイムゾーン（APAC、EMEA、AMER）で週次ベースで行われ、トリアージ活動は各チームメンバーの業務時間中に行われます。
• このオンコールローテーションは、継続的なリリースプロセスに直接影響する正確で安定したテストパイプラインの結果を確保するためのものです。
• モニタリングされるパイプラインのリストはパイプラインページに定義されています。
• スケジュールとロスターはスケジュールページに定義されています。

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