Incident Manager On Call オンボーディング
はじめに
このページはインシデントマネージャーとしてオンボーディングする際の出発点となることを目的としています。
いかなる単一の個人にも大きな負担をかけずに健全なインシデントマネージャーローテーションを確保するため、この役割をエンジニアリング全体のチームメンバーで担当します。
Incident Manager On Call（IMOC）はコール中に以下の目標を持ちます。
- GitLab 顧客への影響を特定・定量化する（メトリクス、カスタマーサポートリクエスト）
- 調査/解決のエリアをサポートする必要なメンバーを集める
- 貢献していない人には丁寧に退出を促し、コール参加者数が注意散漫になるほど多い場合は退出を要請する（30 人がある程度の目安）
- 最近のリリースとフィーチャーフラグを検証する（ロールバックまたはフラグ変更は可能か？）
- 参加したばかりの方のために恥ずかしがらずに現状を再説明する（あなたの理解の誤りはグループの明確化と学習の機会になります）
- 最速の軽減パスを特定し、必要に応じて割り込みをかける
- 定期的なペース（S1 は 5〜10 分ごと）で上記を確認する
- 適切なオーディエンスにステータスを伝達する
これらの一部は GitLab Values に反するように感じるかもしれません。これは私たちの Values を軽視したり損なうために設計・意図されたものではなく、顧客への影響をできるだけ早く軽減する必要性を認識し強化するためのものです。
インシデントマネージャーの参加者
インシデントマネージャーの役割はこのスコープ内のすべてのチームメンバーで担当されます。
- 適切なジョブレベル
- エンジニアリンググループ内のチームメンバー
- カスタマーサポートを除くエンジニアリンググループのすべての職種
- ページングされており 15 分以内の応答時間が求められる別のオンコールアサイン、またはその他の時間的制約のあるオンコールローテーション（例：DevEx Pipeline DRI）にすでに従事していないこと
- 会社に少なくとも 3 か月在籍していること
インシデントマネージャーとして、チームメンバーは GitLab.com および他の GitLab SaaS 環境の運用方法を学びます。オンコールの信頼性エンジニアや開発チームメンバーと連携して GitLab.com の可用性目標の確保を支援します。この役割で得られる経験と意識は、スケールでの GitLab 構築への理解を深め、最終的にはより信頼性の高いスケーラブルな GitLab SaaS サービスとプロダクトにつながります。
インシデントマネージャーのシフト
シフトは毎日以下の時間で4時間または6時間です。
- UTC 23:00 〜 05:00
- UTC 05:00 〜 11:00
- UTC 11:00 〜 15:00
- UTC 15:00 〜 19:00
- UTC 19:00 〜 23:00
各 Incident Manager On Call のアサインは 4 日間連続です。IMOC のシフトはインシデントマネージャーオンボーディング Issueで指定された個人の希望に基づいています。このローテーションアサインに基づいてシフトに週末が含まれる場合があります。
週末カバレッジをより公平にし、祝日および週末カバレッジに関する更新されたガイダンスに基づいて、2つのローテーションを設定しています。
- 平日と週末 — インシデントマネージャーの最大4日間のシフトは週の任意の日にスケジュールできます。これはこれまでのローテーションアサインのスケジュール方法です。
- 平日のみ — インシデントマネージャーの最大4日間のシフトは週末カバーができないチームメンバーに対して平日のみにスケジュールされます。このレイヤーは「平日と週末」レイヤーより優先されるため、_任意の日_にスケジュールされたインシデントマネージャーはシフトの頻度が少なくなります。
- 平日のみシフトの資格
- それぞれ 2023-12-07、2023-12-20、2023-06-06 以前の雇用契約を持つ英国、ドイツ、アイルランドのチームメンバーで、週末シフトに自発的に参加することを望まず、改正に署名していない場合。
- オーストリア、フランス、またはイタリアの雇用契約を持つチームメンバー。現地の制限により週末シフトを取るべきではありません。
- スイスまたはニュージーランドの雇用契約を持つチームメンバーは、現地の制限により祝日のカバーをすべきではありません。誤って祝日にスケジュールされた場合はシフトを交換してください。
特別カバレッジ日
祝日またはその他のグローバルな会社イベントによってチームメンバーの全体的な可用性が低い日は、少ない人数でより長いシフトで IMOC 役割をスタッフするほうが効率的です。これらの日は「特別カバレッジ日」として指定され、関連するシフトをカバーするボランティアが募集されます。これらの日の例には元旦および月次の Family & Friends Day が含まれます。多くの祝日は性質上ローカルなものであり、通常のシフト交換で簡単にカバーできるため、すべての祝日がこの方法でカバーされるわけではありません。
特別カバレッジ日は Issue の作成によって指定されます。Issue は特定のイベントのスケジュールへのアプローチを示し、ボランティアが名前を追加するためのテーブルを提供します。DRI が明確に記載され、得られたカバレッジを incident.io に転送する責任を持ちます。
Issue で示された特別カバレッジの期間中、incident.io スケジュールにオーバーライドが設定されます。
インシデントマネージャーとしてオンボードする
オンボーディングには、インシデントマネージャーオンボーディング Issue を作成してください。
インシデントマネージャーとしてオフボードする
資格ステータスが変更になった場合、または IMOC アサインから免除された場合は、インシデントマネージャーオフボーディング Issue を作成してください。
シフト中に何が起こるか
オンコールシフトの開始
シフトが始まる前に、Slack のアラートが機能していることと incident.io の連絡先が最新であることを確認してください。テストページを送信して、アラートを正しく受信していることを確認してください。シフト開始時間が 8 時間の SRE オンコールシフトの開始と一致する場合は、オンコール引き継ぎ Issueにアサインされることがあります。
オンコールシフトが始まると、シフトが開始していることの通知（メールまたはテキスト、incident.io の設定に応じて）を受け取ります。また、@incident-managers ユーザーグループに追加されたことについて Slack 通知も受け取ります。
インシデントが発生したとき
#incidents-dotcom Slack チャンネルのアナウンスに応答することが期待されています。一般的な本番インシデントのガイドラインを確認し、Issue の重大度ラベルを確認して、必要に応じて更新してください。
現在のインシデント中に S1 または S2 が発生した場合は、どちらのインシデントが顧客への影響が最も高いかを判断し、その Issue に取り組んでください。顧客への影響が少ない Issue については、インフラストラクチャリーダーシップエスカレーションに支援を求めてください。
エスカレーションと応答なしページ
誰かが Tier 2 SME にエスカレートして、そのページが 15 分以内に確認されない場合、あなたに転送されます。オンコールスケジュールを確認してそのローテーションのオンコール担当者に連絡するか、エスカレーションを支援できる別の人を見つける必要があります。そのエスカレーションのスケジュール内で別の人を見つけるか、その Tier 2 スケジュールの Slack チャンネルで確認できます。
オンコールシフトの終了
シフトが終わる前に、引き継ぎが必要なタスクを考慮し、次のオンコールインシデントマネージャーに積極的に伝えてください。これは進行中のインシデントについて次のオンコールインシデントマネージャーをページングして（incident.io または @incident-managers Slack ハンドル経由で）アクティブなトラブルシューティングコールに参加させること、またはある程度のフォローアップアクションが必要な対処した状況に対して手順やコンテキストを提供することを意味する場合があります。シフト中に発生した（またはアクティブに発生している）状況がある場合は、次のオンコールインシデントマネージャーを準備させる責任があります。
次のオンコールインシデントマネージャーが利用できない場合は、次のシフトをカバーできる利用可能なチームメンバーを見つけることを検討してください。このために #im-general、#staff_plus_engineers、#eng-managers チャンネルを使用できます。
シフトを終えて、カバレッジを探している間に次のシフトが始まる場合は、incident.io オーバーライドを作成（オーバーライドの作成例）して、この作業中にインシデントが発生した場合にページングされるようにしてください。
次のシフトのカバレッジを見つけられない、またはそのキャパシティがない場合は、インフラストラクチャリーダーシップエスカレーションを使用して支援を求めてください。
オンコールインシデントマネージャーへのページに応答がない場合はインフラストラクチャリーダーシップエスカレーションがページングされます。ただし、シフトの終わりに進行中のインシデントがある場合は、そのインシデントの Incident lead 役割（incident.io 上）がカバーされ、シフト終了時に引き継がれることが不可欠です。
追加リソース
よくある質問
インシデントマネージャーとは誰ですか？
インシデントマネージャーの責任は、開発部門とインフラストラクチャ部門のエンジニアリングマネジメントおよび Staff+ エンジニアの職種に期待されています。以前は、インシデントマネージャーの責任はインフラストラクチャ部門の少数のマネージャーのグループによって担われていました。これらの対象役職のすべてのチームメンバーがインシデントマネージャーローテーションに参加することが期待されています。
場合によっては、シニアエンジニアもインシデントマネージャーとして参加できます。これは特に、シニアエンジニアが役割の中で成長の追加機会を探しており、将来の昇進機会に備える際に有用です。シニアエンジニアはインシデントマネージャーオンボーディング Issue をオープンし、マネージャーが Issue での承認を示すことでインシデントマネージャープールに参加できます。他の場所で述べているように、チームメンバーはこの役割に似た1つのデューティにのみ参加すべきであり、同時に Dev On-call に参加すべきではありません（例えば）。リクエストを承認する際、マネージャーは対象者が重複してどちらのプログラムも完全にスタッフされなければならないため、インシデントマネージャーと Dev Oncall のバランスを維持する必要がある地域があることに留意する必要があります。
これはボランティアの取り組みですか？
いいえ。対象役職のすべてのチームメンバーはインシデントマネージャーローテーションへの参加が期待されています。対象のすべてのチームメンバーは incident.io にスケジュールされる予定です。今後のシフトが予定されている人は、インシデントマネージャーオンコールオンボーディング Issue の完了を優先する必要があります。 インシデントマネージャーになる準備ができていないと感じる方は、他の人とシフトを交換するプロセスに従い、マネージャーまたはインシデント管理コーディネーターと協力して直面している課題を解決してください。
参加できないと思う場合や代替スケジュールが必要な場合は、マネージャーに相談してください。参加のアサインと免除は Infrastructure の VP と Development の VP またはその代理人によって調整され、リクエストには参加者の報告マネージャーからの承認が必要です。この内部スプレッドシートが参加からの免除を追跡するために使用されています。
インシデントマネージャーローテーション中は Tier 2 オンコールから免除されますか？
はい。人はあなたが最も必要とされる1つのローテーションのみにいる必要があります。インシデントマネージャーローテーションにいる場合は、Tier 2 オンコールローテーションにも入るべきではありません。
インシデントマネージャーの職務を他の役割の期待事項とどのように優先順位付けしますか？
インシデントマネージャーオンコールにスケジュールされている場合、これはあなたの仕事の第1優先事項でなければなりません。ただし、優先事項であっても、インシデントがない場合もあります。インシデントマネージャーのリーダーシップを必要とするアクティブなインシデントがない場合は、通常の業務を維持します。
現在、インシデントマネージャーオンコールへのページは週に0〜4回程度発生しています。インシデントマネージャーがオンコールである間は、エスカレーションに対して 15 分間の SLA があります。これは、インシデントコールに参加するためにミーティング、1on1 などを退出することを意味する場合があります。このような需要はバランスを取るのを難しくし、短い通知で会議の再スケジュールが必要になることがあります。インシデント管理の割り込み主導の性質から、オンコール中に退出が困難な同期ミーティングは後日に移動することをお勧めします。
特に、オンコール中はカレンダーで時間をブロックして、シフト中に面接がスケジュールされないようにしてください。候補者が私たちとの面接のために設けた時間を尊重する必要があり、面接をページで中断すべきではありません。面接がシフト中にスケジュールされた場合は、採用チームに連絡して再スケジュールしてください。
シフト中に家族やその他の個人的な約束がある場合は？
インシデントマネージャーの役割は 15 分間の応答を必要とします。ただし、シフト全体を通じてインシデントを待ってデスクに座っていることは期待されていません。
応答を複雑にする可能性のある家族やその他の短い個人的な約束がある場合があります。ほとんどの場合、その約束中にインシデント Slack チャンネルで状況とタイミングをチームの他のメンバーに伝えるために数分取ることができる限り、45 分未満の任意の約束には安心して対応できます。
それより長いまたは Slack での情報提供の応答を許可しない定期的な約束がある場合は、別のシフトを選択することをお勧めします。このような偶発的な約束がある場合はシフトをブロックするべきではありません。インシデントマネージャーのチームが大きいことのメリットの1つは、予期しないまたは短期間の約束に対してお互いにカバレッジを提供できることです。
インシデントマネージャーシフトはどれくらいの頻度で発生しますか？
4日間のシフトとは、最大でも他の7人の IM と共にインシデントマネージャーシフトに参加するチームメンバーがシフトを持つ頻度が約1か月に1回であることを意味します。あなたの地域にプールに追加されるチームメンバーが増えるたびに、このタイミングが4日間延長されます。関与するチームメンバーが多ければ多いほど、個人が頻繁にシフトを持つことが少なくなります。
インシデントマネージャーはどのようにスケジュールされますか？
新しいインシデントマネージャーが継続的にローテーションに追加されているため、今後数か月のスケジュールは最終的なものではなく、人が追加または削除されるにつれて変化します。 詳細については、インシデントマネージャーコーディネーターの責任をご覧ください。
インシデントマネージャーオンコールの日をずらすことはできますか？
はい、これはインシデントマネージャーとして関与するチームメンバーのプールが充実していることのもう1つのメリットです。シフトの「交換」は incident.io で簡単に手配できます。アサインされたシフトがカバーされることを確実にするのはあなたの責任ですが、特別な状況では Infrastructure の VP に支援を求めてください。シフトの交換は完全に問題ありません。計画的な休暇や突然/緊急の家族の事情のためにカバーを得ることは、お互いにすべきことです。
シフトのカバーまたはカバーのリクエストについて：
#im-generalチャンネルに支援を求める投稿をしてください。緊急の状況にある場合は、必ず人を @mention するか @here を使用してください。カバーが必要な日時を伝えてください。- incident.io でオーバーライドをスケジュールしてください。リクエストする人または引き受ける人のどちらでもオーバーライドを入力できます。
例：誰かのカバーをする場合。incident.io のスケジュールにアクセスして、オーバーライドするシフトと人を選択します。自分自身と期間を選択できるポップアップが表示されます。
アサインされたシフトに参加できない場合は？
シフトはオンボーディング中に選択した業務時間に基づいてアサインされます。現在のプロセスは #im-general Slack チャンネルで誰かにこのシフトを引き受けるよう依頼してシフトを交換することです。
週末または祝日にシフトをした場合は？
オンコール中は、シフト全体をラップトップの前で座って待つことは期待されていません。15 分以内にページを確認して Slack または Zoom コールに参加できる状態にいる必要があります。週末と祝日に自分自身を利用可能にする中断に対して代替休暇を提供することを希望しています。 週末のシフトの代わりに個人の状況に最も合うオプションを探すことをすべての人にお勧めします。オンコール中は次の可能性があります。
- 週末の日と平日を交換する。
- 週末の日と平日の間で時間を交換する。
- 上記2つのオプションが個人のスケジュールに合わない場合、週末中に実施した作業時間の最大2倍の代替休暇を取得する。
- インシデントマネージャーが週末シフト中にスタンバイモード（例：ページなし）の場合、1.25 倍の代替休暇を取得できます。
- インシデントマネージャーが週末シフト中にコールバックモード（例：ページあり）の場合、2倍の代替休暇を取得できます。
- オーストラリア在住の方は、ハンドブックの代替休暇に関するガイドラインを参照してください。
- 個人のスケジュールへの影響が最も少ないワークライフバランスを促進する他の代替手段。
Workday で OOO イベントを作成し、On-Call Time in Lieu を選択してください。
現地の労働法を遵守することが重要であり、業務時間に関する制限があるかどうかを理解することをお勧めします。この情報の目的は、週末の中断を考慮してスケジュールに合わせて休暇を取得するよう促すことです。
さらに質問がある場合は、#im-general Slack チャンネルでガイダンスを求めてください。
オンコール中の携帯電話サービス費用は経費精算できますか？
はい、インシデント管理のオンコールは経費目的で「役職に不可欠」とみなされます。
部下がインシデントマネージャーとして活動している場合、マネージャーとしての責任は何ですか？
部下の役割にインシデントマネージャーの責任を追加するには、マネージャーとの協力が必要です。マネージャーはインシデントマネージャーの職務がアサインされた際、特に週末とシフトが重なる場合に支援する必要があります。インシデントマネージャーにはこれらの追加責任を考慮して一部の責任を委任、延期、または中断する権限があることを確認してください。
マネージャー自身もインシデントマネージャーとして活動している場合は、同様の行動をモデリングすることが部下をサポートすることと同様に重要です。
Google カレンダーから incident.io スケジュールを確認するには？
- incident.io の Incident Manager - GitLab.com SaaS スケジュールの webcal フィードを見つけます。右上の
...メニューで確認できます。また、「Sync calendar」ボタンでオンコールスケジュールページから自分の incident.io シフトにリンクすることもできます。 - Google カレンダーで Other Calendars ドロップダウンからカレンダーを追加し、
from urlを選択してwebcal://...URL をコピーしてください。webcal リンクを貼り付けます。 - 各インシデントマネージャーオンコールシフトがこの読み取り専用カレンダービューでイベントとして表示されます。カレンダーをわかりやすい名前（
webcal://...ではなく）に変更してください（例：IMOC Shifts、My On-Call Shifts など）。
incident.io の IMOC スケジュールを Google カレンダーに追加する利点：
- Google カレンダーで自分や他の人のシフトを検索できます。
- このカレンダーからイベントを自分のカレンダーに複製して時間をブロックし、それに応じてリマインダーを設定できます。
オンコールにスケジュールされたときの通知方法は？
新しいスケジュールは毎月 #im-general チャンネルでアナウンスされます。
インシデント管理について学ぶ
GitLab でのインシデント管理の方法をカバーする詳細なハンドブックページがあります。
