パイプライン DRI オンコールローテーション
Developer Experience サブ部門のパイプライントリアージオンコールローテーション
これは、複数の環境で実行されるさまざまなスケジュールパイプラインの失敗をデバッグ / 分析する責任を共有するためのスケジュールです。 Developer Experience サブ部門のオンコールは、GitLab の通常の業務時間外の作業を含みません。週末とFamily and Friends Daysも除外されます。SET はオンコール週中に 1:1 ミーティングや部門ミーティングへの出席を非同期に変更する完全な自律性を持ちますが、マネージャーへの適切な連絡をお願いします。
現在のイテレーションでは、タイムゾーンベースのローテーションがあり、トリアージ活動は各チームメンバーの勤務時間中に行われます。
詳細なスケジュールパイプラインの一覧と、失敗したテストの適切なレベルの調査方法および次のステップを判断するための具体的な手順については、デバッグ失敗テストのガイドラインとスケジュールパイプラインの一覧、パイプライントリアージをご参照ください。
責任
失敗のトリアージ、記録、ブロック解除
- 新しいローテーション開始の前の土曜日、ハンドオーバーボットがpipeline-triageプロジェクトに Issue を作成します。
- ハンドオーバーボットは、以下のスケジュールに従って、次週の DRI に作成されたトリアージ Issue を割り当てます。
- スケジュールされた期間中、テスト実行に関連するサポートタスクは、Directly Responsible Individual（[DRI]）の最高優先事項となります。
- Production、Canary、Staging パイプラインのエンドツーエンドテスト失敗の報告と分析は、GitLab
masterやGitLab FOSSmasterよりも優先されます。これはテストの修正よりも優先されることにも注意してください。 - Preprod パイプラインは、リリース週の月曜日から木曜日のリリース候補テスト期間中、
ProductionおよびStagingパイプラインと同等の優先度を持ちます。 - 時間的制約がある場合、DRI はStaging、Canary、Productionパイプラインの失敗をアプリケーション問題かインフラ問題かを判断するのに十分な範囲で報告・分析し、適切にエスカレーションしてください。それらのパイプラインで報告されたすべての失敗は、そうでないと判断されるまで ~priority::1/~severity::1 として扱われます。つまり、できるだけ早く（理想的には報告から 2 時間以内に）調査する必要があります。DRI が対応できない場合は、対応できない調査を翌週の DRI に委任してください。どちらの DRI も対応できない場合は、
#s_developer_experienceSlack チャンネルでヘルプを求めてください。 - スモークスペックで新しい ~severity::1 リグレッションが見つかった場合、インシデントを作成してリリースをブロックすることを検討してください。
- 他のすべての失敗調査を適時（理想的には報告から 24 時間以内）に完了することが重要です。DRI がすべてのパイプラインで報告されたすべての失敗を時間内に調査できない場合は、
#s_developer_experienceSlack チャンネルでヘルプを求めてください。 - https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/530 のような横断的な Issue は、オンコール DRI がトリアージして次のアクションを決定します。他のチームメンバーがそのような Issue に遭遇した場合は DRI に通知してください。DRI は必要に応じて
#s_developer_experienceチャンネルを通じて部門の残りのメンバーに通知できます。 - Developer Experience サブ部門の全員がオンコール DRI をサポートし、Zoom コールに参加したり、必要に応じてヘルプを提供できるようにしてください。
- gitlab-org/gitlabの CI/CD 変数に変更が必要で DRI がアクセス権を持っていない場合、
#dx_maintainersと#developmentSlack チャンネルでヘルプを求めることができます。Quality のメンテナーであれば、支援するのに十分なアクセス権を持っているはずです。
- gitlab-org/gitlabの CI/CD 変数に変更が必要で DRI がアクセス権を持っていない場合、
- 毎日、APAC/EMEA/AMER の DRI はこのように、その日に見つかった失敗をトリアージ Issue にまとめます。これは他のタイムゾーンの DRI への非同期ハンドオフとして機能します。
- DRI は dri gem を使用して、報告のハンドオフを自動化し、新規作成された失敗や環境ごとに有効化されたフィーチャーフラグなどの有用なトリアージ情報を表示することができます。
- staging/canary でスモークスペックが失敗すると、デプロイヤーパイプラインがブロックされ、本番インシデントとして扱われる可能性があることに注意してください。
スケジュール
パイプライントリアージのローテーションスケジュールを確認するには、pipeline-triageプロジェクトをご覧ください。
または Slack の chatops で /chatops run quality dri schedule コマンドを使用してください。
スケジュールされたパイプラインの DRI の責任
- DRI はトリアージを行います。さらなる支援が必要な場合は
#s_developer_experienceSlack チャンネルでヘルプを求めてください。 - DRI はテストを修正するか検疫するかを判断します。
- すべての修正または検疫は、リリースの遅延を避けるためにすべてのリリースブランチに適用してください。
- DRI は共有所有権のテスト（
group::unknownでラベル付けされた MR）に対する自動生成された検疫 MRをレビューし、マージするかクローズするかを決定します。 - DRI は定期的に未割り当ての検疫 Issue のリストを確認して対応してください。
- スケジュールされた期間中に DRI が利用できない場合（2 日以上）、別のチームメンバーとスケジュールを交換できます。スケジュール中の DRI の不在が 2 日未満の場合、翌週の同じタイムゾーンの DRI がカバーできます。
デプロイメントパイプラインの DRI の責任
- DRI はデリバリーチームがリリースプロセスに影響するテスト失敗のデバッグを支援します。
- DRI が利用できない場合は、翌週の同じタイムゾーンの DRI が代わりに対応します。
新規採用者のオンコールシャドウ
新規採用者が初めてのオンコールローテーションに備えられるように、最初のローテーションの数日前に DRI のシャドウを行ってください。新規採用者が DRI になったとき、翌週の DRI は質問に答えてテスト失敗のトリアージ / デバッグを支援するために、数日間新規採用者とペアを組んでください。
インフラおよび環境アップグレードのサポート
Developer Experience チームは、GitLab 環境への計画されたアップグレードのサポートを提供します。これにより、変更がデプロイ前後に適切なテストスイートを通じて適切に検証されることが保証されます。
アップグレードサポートを要請するチーム（勤務時間内外を問わず）向け：
事前に計画する：RFH（ヘルプリクエスト）Issueを使用してください。少なくとも 2 週間前にリクエストを提出してください。
重要な詳細を含める：
- 提案されたアップグレードの日付と時刻
- アップグレード予定の環境
- アップグレードの種類（インフラ、データベース、サービスの分解など）
- リクエストの例：
リクエスト提出後の対応について：
- リクエストはトリアージされ、カバレッジスケジュールが作成されます。
- 勤務時間内：
- リクエストは現在のパイプライン DRIが対応します
- 週末：
- 24 時間をカバーするための 4 時間シフトのスケジュールが作成されます。
- 勤務時間内：
- スケジュールと希望するコミュニケーション方法は、予定されているアップグレードの 1 週間前までに共有されます。
- オンコールの全員を専用 Slack チャンネルに追加して、シフト中にアップグレードの進捗を監視できるようにしてください。
- リクエストはトリアージされ、カバレッジスケジュールが作成されます。
注意：APAC エリアにはチームメンバーが多くないため、4 時間の空白時間が発生することがあります。その間は以下のトラブルシューティングガイドを使用することをお願いします：
パイプライン DRI 向け：
アップグレード前の準備：
- 要請チームとアップグレード計画をレビューする
- 変更を検証するための適切なテストスイートを特定・文書化する
- テスト環境の準備が整っていることを確認する
- テストスイートを実行してテスト結果のベースラインを取得する
アップグレード中：
- テスト結果を監視・レビューする
- テスト関連の問題に支援を提供する
- 観察された問題や異常を文書化する
アップグレード後：
- 特定された問題や改善事項のフォローアップ Issue を作成する
- 学んだ教訓を文書化する
利用できない場合：
- 計画されたアップグレード（特に時間外アップグレード）に参加できない場合は、すぐにチームに連絡してカバレッジを見つける
- 代替 DRI にアップグレード計画とテスト要件を説明する
Developer Experience サブ部門のインシデント管理オンコールローテーション
EM はインシデントの監視、対応、軽減の責任を共有してください。 Developer Experience サブ部門のオンコールは、GitLab の通常の業務時間外の作業を含みません。週末とFamily and Friends Daysも除外されます。 現在のイテレーションでは、インシデント管理活動は各チームメンバーの勤務時間中に行われます。
責任
- Engineering Manager は Slack チャンネル
#incidentsに参加していることを確認してください。 - Engineering Manager はインシデント管理チャンネルの監視、追跡、直接支援、委任、そして Developer Experience サブ部門内のインシデントの認知向上を適切に支援してください。
- 現在の DRI はインシデント Issue に明確に記載されているべきです。
- 是正措置が必要な場合、EM は DRI が Issue を作成して ~‘corrective action’ のラベルを付けていることを確認してください。
- Developer Experience サブ部門の全員がオンコール DRI をサポートし、必要に応じて Zoom コールに参加したりヘルプを提供できるようにしてください。
