プロダクションエンジニアリング ネットワーキングとインシデント管理チーム

私たちはシステムへのトラフィックを制御するネットワーキングプラットフォームと GitLab のインシデント対応プロセスの両方を管理します

ミッション

私たちは 2 つのベクターから GitLab を保護します:

  • システムへのトラフィックの許可方法について、チームに最初の防衛ラインを提供するネットワーキングプラットフォームを提供します
  • GitLab がインシデントに対応する必要がある際の、インシデント管理プロセスとツールを通じた対応システムを管理します

私たちは GitLab の成長に合わせてスケールする革新的なネットワーキングソリューションの開発に焦点を当て、GitLab を支えるネットワーキングインフラストラクチャを構築・進化させることを目指しています。GitLab のチームがサービスに関連するインシデントへの対応に自信を持てるよう支援します。

ビジョン

  1. ネットワーキングインフラストラクチャの卓越性 スケーラブルでセキュアかつ効率的なソリューションを構築することで、GitLab のネットワーキング機能を前進させます。これには、すべての GitLab プラットフォームの増大する需要に対応するためのエッジサービス、ロードバランシング、レート制限、ネットワークセキュリティの進化が含まれます。集中化されたネットワーキングツールとインフラストラクチャを通じて、GitLab の継続的な成長とイノベーションを支える基盤を作ります。
  2. サービス所有権と標準化されたインシデント対応 チームが問題発生時に自信を持って対応できるフレームワークとツールを提供することで、チームが自らのサービスを自信を持って運用できるよう支援します。

所有範囲と責任

ネットワーキングとインシデント管理チームは以下に焦点を当てています:

  1. インシデント管理 - GitLab がインシデント管理のために使用するプロセスを改善する責任を担います。
  2. 障害回復 - 回復時間目標(RTO)の短縮に特に焦点を当てた障害回復プロセスの管理を担います。
  3. ネットワーキングインフラストラクチャ - ネットワークのエッジからアプリケーション層までトラフィックを管理するサービスの改善と拡大に積極的に取り組みます。

サポートの依頼

チームメンバー

チームメンバー情報は 原文 (英語) を参照してください。

作業方法

私たちはインフラストラクチャプラットフォームプロジェクト管理プラクティスに従います。

プロダクションエンジニアリング内の新チームとして、現在ワークフローとプロセスを確立中です。チームが進化するにつれてこのページを継続的に更新していきます。

ラベル

  • 受信リクエストには ~"NIM::Requests" を使用します。これはチーム外部から来るリクエストです。
  • ライトをつけ続ける(KTLO)Issue には ~"NIM::KTLO" を使用します。フルプロジェクトではない可能性がある、所有領域のメンテナンスに関連する Issue です。
  • プロジェクト作業には ~"NIM::Project Work" を使用します。ネットワーキングエピックまたはインシデント管理エピックに表示されているエピックの一部である Issue に適用する必要があります。
  • チームプロセス(レトロスペクティブ、プランニング、NIM チームプロセス変更)に関連する Issue には ~"NIM::Meta" を使用します。
  • アクセスリクエストには:
    • ~"NIM::Todo" - Cloudflare アクセスのすべてのベースラインエンタイトルメントテンプレートに自動適用されます。
    • ~"NIM::Doing" - [オプション] 対応に時間がかかる場合に、すでに対応中であることを他のメンバーに知らせるために使用します。
    • ~"NIM::Done" - アクセスリクエストが対応済みになったら、このラベルに変更します。

多くの Issue テンプレートはすでにこれらのラベルを適用しています。

定期タスクの委任

チームは定期的な注意が必要な複数の定期タスクを管理しています(通常、週約 1 時間の小さな時間コミットメント)。個々のチームメンバーがこれらのタスクを所有し、不在の際はカバレッジを見つける責任があります。

現在の定期タスク

  • incident.io で期限超過のインシデント後タスクを行うよう通知する - 週次 - 未完了のインシデント後アクションアイテムのフォローアップ。DRI: Alex
  • 信頼性レポート - 月次 - https://gitlab.com/gitlab-com/gl-infra/reliability-reports/-/issues に公開。DRI: Devin / Sarah
  • インシデントフォローアップ Issue の対応 - 週次 - インシデント中に特定された Issue の管理と解決追跡。DRI: Steve
  • EOC コーディネーター - 継続的 - Tier 1 SRE オンコールローテーションのリード。DRI: Sarah
  • IM コーディネーター - 継続的 - インシデントマネージャーオンコールローテーションのリード。DRI: Devin
  • Issue トリアージ - 週次 - 現在エンジニアリングマネージャーが所有し、受信 Issue のトリアージ、委任、スケジューリングを行う。DRI: Steve

タスク所有権の期待事項

  • 各タスクには、定期的なサイクルでの完了に対して責任を持つ DRI がいます。
  • タスクオーナーは不在の際にカバレッジを手配する必要があります。
  • カバレッジの手配は PTO カバレッジ Issue で周知する必要があります。

共通リンク


EOC オンボーディングバディ
はじめに EOC(Engineer on Call)オンボーディングバディは、オンコールローテーションに参加する新しいエンジニアにとってポジティブで効果的なオンボーディング経験を確保する上で重要な役割 …
EOC シャドウと EOC バディへの期待事項
EOC(Engineer on Call)のシャドウイングプロセスは、新しいエンジニアがライブインシデントの管理、アラートへの対応、システムの安定性確保について実践的な経験を積めるよう設計されていま …
SRE オンボーディング
オンボーディングテンプレート SRE のオンボーディングは主に2つの Issue テンプレートで処理されます。 マシンセットアップ コンテキストの収集 これらは SRE の入社時にアサインされます。こ …
オンコールハンドオーバー
オンコールハンドオーバー on-call-handovers プロジェクトには、各 SRE のオンコールシフトに対応する Issue が含まれています。交代するEOC(Engineer on …
プロダクションエンジニアリング ネットワーキングとインシデント管理チーム AI プロンプト
Duo Chat で使用する共通プロンプト
障害回復プラクティス(DR ゲームデー)
目的 GitLab.com の障害回復プロセスをテストし練習する理由はたくさんあります。 プロセスが期待通りに機能することを確認する。 回復プロセスを壊したり複雑にしたりする可能性のある変更に追いつ …