プロダクションエンジニアリング

チーム

プロダクションエンジニアリングは以下のチームで構成されています:

1. クラウドコスト最適化
2. ネットワーキングとインシデント管理
3. オブザーバビリティ
4. ランナープラットフォーム
5. Runway とフリート管理

作業方法

私たちは GitLab のバリューに沿って作業することをデフォルトとし、インフラストラクチャプラットフォームセクション全体のプロセスに従います。これに加えて、プロダクションエンジニアリングにおける作業に特有な、または特に重要なプロセスを以下に列挙します。

オペレーティングモデル

毎四半期、インフラストラクチャプラットフォームのエンジニアリングおよびプロダクトリーダーがオペレーティングモデルエピックを設定します。これらは、その四半期に達成が必要な目標を表します。

ディレクターとシニア EM が、それらの目標をサポートするためにその四半期にコミットするエピックを提供します。チームのエピックはこれらのオペレーティングモデルエピックにリンクされます。

プロジェクト上でリンクされたエピックを参照することで、それが部門や会社の目標にどのように結びついているかを確認できます。

ロードマップ

四半期目標に何を貢献できるかを把握するため、チームごとに事前にロードマップを準備します。各四半期の終わりに向けて、EM はロードマップレビューセッションを設定し、重要なプロジェクトについて合意します。

シニア EM がこれらのプロジェクトをインフラストラクチャプラットフォームのエンジニアリングおよびプロダクトリーダーに提案し、四半期開始前に追加または削除すべき作業を明確にします。

エピック構造

プロダクションエンジニアリングにはトップレベルエピックがあります。このエピックはすべてのチームのトップレベルエピックを参照しています。

各エンジニアリングマネージャーはトップレベルエピックを維持し、毎週のグループレビューに使用できるようにします。チームのトップレベルエピックには、チームが行っているすべての作業が表示されます。

プロジェクトエピック

1. 進行中の各プロジェクトはチームのトップレベルエピックにリンクされたエピックです。
2. プロジェクトエピックには DRI が割り当てられます。
3. DRI は毎週のグループレビューに間に合うようにプロジェクトのステータスを更新する責任があります。

非プロジェクトエピック - KTLO と受信リクエスト

毎四半期、各チームには KTLO 用のエピックと受信リクエスト用のエピックがあります。これらのエピックは、対応する四半期のプロダクションエンジニアリングエピックに集約され、さらにオペレーティングモデルエピックにリンクされます。

各四半期の終わりに、EM はクロージングサマリーで非プロジェクト作業をまとめます。

KTLO とは何ですか？

KTLO は「keeping the lights on（ライトをつけ続ける）」を意味します。これはシステムを可用性が高く、パフォーマンスが良く、信頼性が高く、セキュアに保つために行う必要がある作業です。 大きな KTLO が見込まれる場合は、計画を立ててプロジェクトに変えます。これらのプロジェクトには KTLO ラベルを使用します。 作業する小規模な KTLO アイテムは、そのチームの四半期 KTLO エピックにリンクする必要があります。

受信リクエストとは何ですか？

受信リクエストとは、他のチームから私たちに依頼される作業のことです。私たちが特定のサービスを所有しているか、特定の知識を持っているため依頼されます。 作業する受信リクエストは、そのチームの四半期受信リクエストエピックにリンクする必要があります。

別の作業をしている場合は…

おそらく KTLO エピックに追加できますが、確信が持てない場合はマネージャーに作業のアロケーション方法について確認してください。

インシデントへの関与

プロダクションエンジニアリングチームのメンバーは、インシデントの解決に役立つ専門知識を持っていることがよくあります。また、一部のメンバーはオンコールローテーションの一員である SRE でもあります。インシデントへの貢献については、以下のガイドラインに従います。

オンコール SRE の場合:

• EOC の通常のインシデント管理手順に従ってください
• シフト終了時に、進行中のインシデントや是正措置がある場合は、残りの作業の優先順位付けを支援する EM に知らせてください

インシデントマネージャーの場合:

• IM の通常のインシデント管理手順に従ってください
• ハンドオーバーは通常通りに行いますが、まだ作業中のアクティブなインシデントがある場合は EM に知らせてください

インシデント発生時に EOC でもインシデントマネージャーでもない場合:

• S1 インシデントの場合
  • 優先事項は GitLab.com を稼働させ、安定した状態に戻すことであり、プロジェクト作業より優先されます
  • システムが安定したら、根本原因の特定と是正措置の作成に貢献してください
  • IM またはインフラストラクチャ EM が是正措置を委任します
  • S1 から生じた作業の優先順位付けについてはプロダクションエンジニアリング EM と協力してください
• その他すべてのインシデントの場合
  • インシデントに呼び出された場合、優先事項は他の人が問題を解決できるよう支援することです
  • ハンズオフを維持し、必要に応じてガイダンスを提供し、できるだけ早くプロジェクト作業に戻ることが期待されます

この方針の理由は、私たちのプロジェクト作業が将来の大規模な S1 インシデントの発生を防ぐためです。 多くのインシデントへの参加と解決を試みると、プロジェクト作業が遅れ、将来の S1 インシデントのリスクが高まります。

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