Create:Code Review BE エンジニアリングマネージャーの責務
Create:Code Review BE エンジニアリングマネージャーの責務とリソース一覧
Create:Code Review BE チーム
Create:Code Review BE チームは、Create ステージの Code Review グループに属するプロダクトカテゴリのすべてのバックエンド側面を担当しています。
チームのビジョンとミッション
コードレビューワークフローと GitLab CLI のカテゴリ方向性で、これらのプロダクトの現在の戦略と1年計画をご参照ください。
主要な責任
Create:Code Review BE チームは、DevOps ライフサイクルの Create ステージの Code Review グループに属するプロダクトカテゴリのすべてのバックエンド側面を担当しています:
グループメンバー
以下の方々が Create:Code Review グループの常設メンバーです:
チームメンバー情報は 原文 (英語) を参照してください。
安定したカウンターパート
他の機能チームの以下のメンバーが私たちの安定したカウンターパートです:
チームメンバー情報は 原文 (英語) を参照してください。
共通リンク
- GitLab チームハンドル:
@code-review-be - Slack チャンネル:
#g_create_code-review - Slack ハンドル:
@code_review_be - Issue トラッカー:
create-stage/code-review-be
常時監視する Issue リスト
メトリクスと KPI
以下のダッシュボードをご参照ください:
作業方法
メインの Code Review ページの作業セクションをご覧ください。
チームとの協力
マージリクエストページ、承認ルールなど、より注目度の高い機能の管理者として、これらおよびそれが含む依存機能に関する多数の問い合わせや支援・情報のリクエストを受け取ります。コラボレーションと成果の利益のために、これらを歓迎し、迅速に対応するよう努めていますが、効率性の価値もバランスさせる必要があります。
目標として、入ってくるリクエストには2営業日以内に対応しますが、チームメンバーの可用性、経験、ワークロードによっては、より迅速に対応することも多々あります。
GitLab での Code Review BE チームへの連絡には、@code-review-be ハンドルを使用できます。
アナウンスメント Issue
チーム全体への情報配布を促進し透明性を高めるために、チーム全体のメッセージ共有に Slack ではなくアナウンスメント Issue を使用しています。これらの Issue は固定のケイデンスではなく、必要に応じて送信されます。
アナウンスメント Issue は ~Announcements ラベルが付けられ、通常はバックエンドエンジニアとエンジニアリングマネージャーを対象にしています。アナウンスメント Issue テンプレートはプロダクトマネージャーおよび/または安定したカウンターパートへの通知オプションも提供しています。
チームの誰でもこの形式を使ってアナウンスメントを共有できます。マイナーまたは繰り返しのアナウンスメントはまだ Slack 経由で送信される場合があります（例: PTO のマイルストーンリマインダー）。
フォローアップ Issue
リリースで何かに取り組んだが技術的負債、フィーチャーフラグのロールアウトや削除、Issue の非ブロッキング作業などのタスクが残っている場合、フォローアップ Issue が蓄積します。これらについては、少なくとも2つの方法で対処できます:
- フォローアップ Issue に重みと、その Issue に取り組むことの重要性についての良い説明を付けた適切な将来のマイルストーンを追加する
- Issue を関連する計画 Issueに追加する
一般的に、完成の定義の一部であるフォローアップ作業を引き受けるべきです。できれば元の作業と同じマイルストーン、またはすぐ後のマイルストーンで行います。これが相当量の作業を表す場合は、スケジュールの決定に影響する可能性があるため、マネージャーに知らせてください。
フォローアップ Issue が多数ある場合は、エピックの作成を検討してください。
バックエンドとフロントエンドの Issue
多くの Issue はバックエンドとフロントエンドの両方での作業を必要としますが、その作業の重みは同じではない場合があります。Issue には単一の重みしか設定できないため、この場合は代わりにスコープ付きラベルを使用します: ~backend-weight::<number> と ~frontend-weight::<number>。
何に取り組むか
取り組むべきことの主要なソースは、現在のイテレーションサイクルの Code Review リリースボードです。これは、このサイクルにスケジュールされたすべての Deliverable と Stretch の Issue をリスト表示します。
リストはプロダクトマネージャーとエンジニアリングマネージャーがマイルストーン計画プロセスに従って、チームと他のステークホルダーのインプットを受けてまとめます。イテレーションサイクルは月の第3木曜日前の月曜日に開始し、リリースされる GitLab バージョンで識別されます。
Code Review バックエンド 割り当て Issue ボードもあります。これは同じ Deliverable と Stretch の Issue を担当者別にグループ化して表示し、左端のリストにはバックエンドエンジニアに現在割り当てられていない Issue が表示されます。
最初に何に取り組むか
Deliverable は最高優先度とみなされ、月の第3木曜日前の金曜日に終了するイテレーションサイクルの最後までに完了することが期待されています。これは月次リリースに間に合わせるためです。
これらの最高優先度 Issue はマイルストーン開始時またはそれ以前にエンジニアに割り当てられ、そのサイクル中に最善を尽くして完了させる責任があります。成功の妨げになるものがあればエンジニアリングマネージャーに知らせる必要があります。 割り当てられた Issue は Code Review バックエンド割り当て Issue ボードで確認できます。
月中には様々なことが起こり、Deliverable が実際にサイクルの終わりまでに完了しない結果になる可能性があります。これは通常、エンジニアリングマネージャーが Issue の重みを楽観的に見積もりすぎたか、エンジニアの他の責任が予想以上に時間を要したことを示していますが、これがエンジニアリングマネージャーへの驚きになってはいけません。
この潜在的な結果が早く予測され伝達されるほど、Deliverable のスコープを縮小したり、まだ開始されていない Deliverable を完了させる時間がより多くあるエンジニアを見つけたりするなど、防ぐために何かできることがあるかどうかを確認する時間が増えます。 この結果が回避できず Deliverable がサイクルを見逃す場合、それは単純に終了するために次のサイクルに移動され、エンジニアとエンジニアリングマネージャーは何が起こったかを振り返り学ぶ機会を得ます。
一般的に、Deliverable は月の作業時間の約75%を占めることが期待されます。残りの25%は他の責任（コードレビュー、コミュニティマージリクエストのコーチング、Slack での人々の助け、Issue でのディスカッションへの参加など）、および月中に発生してすぐに対応する必要がある緊急の Issue（回帰、セキュリティ問題、顧客問題など）のために確保されています。
次に何に取り組むか
Deliverable と他の活動が終了した後に時間がある場合、同じ Issue ボードにある Stretch Issue の作業に残りの時間を費やすことができます。
これらの低優先度 Issue はイテレーションサイクルの終わりまでに完了することは期待されていませんが、_次の_サイクルでの Deliverable となるため、事前に進捗があればボーナスです。
Stretch Issue は通常、誰かが作業する最も適切な人であることが明らかな場合（最近誰かが行った作業に関連した技術的負債やバグ、または以前に開始したが終える機会がなかった Issue など）を除き、直接人に割り当てられません。
まだ割り当てられた Stretch Issue がない場合、Code Review リリースボードをフィルタリングして新しいものを選ぶことができます。
Issue をすぐに開始することを妨げるものがある場合（未回答の質問や不明確な要件など）、Issue をスキップして別の Issue を考えることができます。ただし、次に来るエンジニアがより良い状態で見つけられるように、結果と質問を Issue に入力してください。
Stretch Issue を取り上げる代わりに、プロダクトや会社全体に大きな正の影響を与えると信じる他の何かに余裕時間を費やすことも選択できます。 一般的なガイドラインが述べているように、「インスピレーションは消えやすいものと認識しているため、比較的短い時間で大きな成果を生む何かに熱狂している場合は、それに取り組んでください。」
私たちは人々が自分自身のマネージャーであることを期待し、硬直性よりも責任を好みます。 そのため、Issue ボードにないものに取り組む場合は許可を求める必要はありませんが、他の責任を念頭に置き、Issue があること、それに割り当てられていること、そして #g_create_code-review で共有することを検討してください。
ディープダイブ
可用性とパフォーマンスの監視
Create:Code Review BE チームは、一部の API エンドポイントとコントローラーアクションを可用（つまりエラー/500 を出さない）かつ高性能（つまりレイテンシ目標以下）に保つ責任があります。
可用性ダッシュボード
以下のダッシュボードを使用して、エラーバジェットとフィーチャーユーザーに影響する問題を監視・特定します:
- （Grafana）Code Review: グループエラーバジェット詳細（内部のみ）
- （Sentry）Code Review ワークフロー - エラーを経験しているユーザー（内部のみ）
- （Sentry）MR ホームページ - エラーを経験しているユーザー（内部のみ）
根本原因分析のために、サイト全体/インフラの不安定性が問題を引き起こしているかどうかを調べます:
- 他のステージグループが同じ apdex/エラーパターンを経験しているかどうかを確認: ステージグループ
- 影響のためのシステム固有のダッシュボードを確認:
- gitlab-com/gl-infra/production/-/issues で最近のインシデントを検索
監視の自動化
フィーチャーカテゴリに影響するイベントのアラートは #g_create_code-review_alerts Slack チャンネルに投稿されます:
- Prometheus SLO 違反アラート（設定）
- エラーを経験しているユーザーへの Sentry アラート:
毎週月曜日、過去1週間の7日間エラーバジェットが #g_create_code-review に自動的に投稿されます。
以下のデータベース問題に対して Issue が自動的に作成されます:
パフォーマンスダッシュボード
エンドポイント/アクションでグループ化され P90 でソート（最も遅いものが先頭）された Kibana ダッシュボード:
- Create::Code Review コントローラーアクション（内部のみ）
- Create::Code Review: API エンドポイント（内部のみ）
- Create::Code Review: Sidekiq ワーカー（内部のみ）
Grafana ダッシュボード:
- general: アプリケーション SLI 違反: エンドポイントごとの apdex とエラーレート
- stage-groups: Code Review: グループダッシュボード: 各アクションとエンドポイントのより詳細な情報
AI 機能の監視に特化したダッシュボードもあります: Create: Code Review: AI Features（内部のみ）。このダッシュボードはコードレビュー AI 機能のパフォーマンスを監視し、特に Sidekiq と GraphQL 操作の両方の P50（中央値）期間を追跡します。
Issue 特定プロセス
- 過去1週間の7日間エラーバジェットが赤の場合、根本原因を特定するための調査 Issue を作成します（例）
- エラーバジェットに大幅に貢献しているエンドポイントまたはワーカーを特定した場合、（まだ作成されていなければ）Issue を作成し、重大度と優先度の基準に基づいてラベルを付けます
- Issue がすでに作成されている場合、重大度/優先度を更新する必要があるかどうかを確認します
- パフォーマンス Issue は専用の GLQL ビューを使用して計画中に自動的に表面化され、それに応じて優先順位付けされます
エンジニアリングオンボーディング
オンボーディングを開始するには、バックエンドエンジニアの Code Review オンボーディングテンプレートを使用して Issue をオープンしてください。
その他の関連ページ
- Create:Code Review BE エンジニアリソース（チームビルディングやキャリア開発など）
- Create:Code Review BE エンジニアリングマネージャーの責任（マイルストーン計画、タレント評価、プロジェクト管理など）
- Create:Code Review AI プロンプト（より効率的に使用する一般的なプロンプト）
