Observability チーム

Observability は、メトリクス、ロギング、トレーシングを担う技術要素と、それらを活用するツールおよびプロセス全体を包含します。

ミッション

私たちのミッションは、世界クラスの Observability の提供と、GitLab のチームメンバーにとって摩擦のない運用体験を提供し維持することです。

共通リンク

チームメンバー

以下のメンバーが Observability チームに所属しています。

Name	Role
Liam McAndrew	Engineering Manager, Observability
Taliesin Millhouse	Site Reliability Engineer, Observability

チームは世界中のさまざまなタイムゾーンに分散しています。

技術的な原則、目標、責務

私たちの原則と目標の詳細については、テクニカルブループリントを参照してください。

以下は、私たちのスコープとオーナーシップの概要です。

1. モニタリングの基礎
   1. メトリクススタック
   2. ロギングスタック
2. エラーバジェット
   1. コンセプトと実装のオーナーシップ
   2. 月次エラーバジェットレポートの提供
3. キャパシティプランニング
   1. .com 向けトリアージローテーション
   2. GitLab Dedicated キャパシティプランニングの運用面
   3. 予測ツールである Tamland の開発
   4. GitLab Dedicated のキャパシティレポート
4. GitLab.com のプロダクションサービスを対象とするサービス成熟度モデル。
5. GitLab.com の可用性レポート: 基盤となるデータと集計値の提供

ドキュメント

私たちは、Observability サービスやプラットフォームを利用するチームと、自分たちのチーム内利用の両方に向けた技術ドキュメントを提供する必要性を認識しています。

これまでは、所有または貢献するプロジェクト、または runbooks プロジェクト内でリファレンスドキュメントを提供してきました。 これらのプロジェクトが散在しているため、ユーザーにとって関連ドキュメントを発見するのはなかなか難しい状況です。

ドキュメントを再構築するにあたり、私たちは以下のアイデアと原則に従います。

1. Infrastructure Observability ドキュメントハブは、私たちが提供する Observability 関連ドキュメントへのエントリポイントです。
2. 入念に作成されたドキュメントは、後付けではなく Observability プラットフォームのコアプロダクトです。
3. ドキュメントハブは、プラットフォームとして提供する Observability インターフェースについて Engineering 全体とコミュニケーションする手段だと考えています。
4. リファレンスドキュメントに加えて、特定の利用者層を対象としたガイドやチュートリアルなどのドキュメントを提供することを目指します。
5. ドキュメントハブはチーム内利用に向けてコンセプトやアーキテクチャを説明する場としても使い、共通理解を作り、全員がすべての領域に貢献できるようにします。

さまざまな種類のドキュメントをどこに置くか?

ドキュメントには様々な種類があり、それぞれ適切な置き場所があります。

ドキュメントハブの外にあるドキュメントは、ハブからリンクされる必要があります（だからこそハブと呼んでいます）、逆もまたしかりで、発見可能性を高めることに役立ちます。

これは、（オープンソースかどうかにかかわらず）あらゆるプロジェクトに期待されるように、リファレンスドキュメントをそのプロジェクトと一緒に出荷する必要性を認識したものです。 ここでの利点は、機能の変更が同じマージリクエスト内でリファレンスドキュメントも更新できることです。

一方、これらのプロジェクトをスタック内でどのように利用するかについては、プロジェクト自体と一緒に出荷するには固有性が高すぎます。 多くの場合、私たちは大きな枠組みと、プロジェクト同士がどのように連携するかを理解したいと考えます。 これは特定のプロジェクトと一緒に出荷される技術ドキュメントのスコープ外なので、その情報はドキュメントハブに置きます。

チーム内利用の観点でも、所有するサービスとその運用方法について検討するためにドキュメントハブを使います。 これはチームの全員に役立ち、チーム内の様々な役割や視点を持つメンバーが共通理解を育むのに役立つと期待しています。

ドキュメントの種類とその整理方法に関するおすすめの読み物として、Divio Documentation System があります。

どのようにドキュメントを作成するか?

ドキュメントを再構築・構築するにあたり、ドキュメントハブはあらゆる貢献から恩恵を受けます。

1. 既存のコンセプトを説明する
2. 既存ドキュメントを互いにリンクする
3. 既存ドキュメントを集約し、適切な場所に移動する
4. システムアーキテクチャや運用原則に関する文章・図の執筆

私たちは Handbook First の考え方と同じように、ドキュメントを主要な存在として作成・維持することを目指しています。 たとえば、チームメンバーからの個別の質問（Slack 上の質問など）に個別に答える代わりに、これをドキュメントを書く機会として捉え、書いたものをレビューしてもらい、それを使って作業してもらうことができます。

指標

このグループは、Infrastructure 部門の指標に積み上がるいくつかのパフォーマンス指標のオーナーです。

1. GitLab.com のプロダクションサービスを対象とするサービス成熟度モデル。
2. キャパシティプランニングは、キャパシティ警告を用いてインシデントを未然に防ぎます。

これらを組み合わせることで、チームのプロジェクトをより適切に優先順位付けできるようになります。

これらの指標がどのように使われ得るかの過度に単純化した例（特定の順序ではない）:

• サービス成熟度 - サービスとの関連で Observability スタックから受け取るデータがどれだけ信頼できるかの詳細を提供する。レベルが低いほど、そのサービスの Observability 改善に注力する必要がある
• キャパシティプランニング - 特定のサービスの予測を提供する

これら異なるシグナルを合わせて、私たちは過去・現在・未来の比較的（不）正確な視野を持ち、GitLab.com のスケーリングニーズの優先順位付けに役立てています。

プロビジョニングされたサービス

チームは、tech_stack.yml ファイルに従って、以下のサービスへのアクセスのプロビジョニングを担当します。

1. Kibana は Okta 経由でアクセスします。チームメンバーは以下のいずれかの Okta グループに所属する必要があります: gl-engineering（Engineering 部門全体）、okta-kibana-users。後者は Engineering 外のチームメンバーへのアクセスをアドホックに管理するために使われます (背景)。チームメンバーは Access Request (例) を通じてプロビジョニング／デプロビジョニングされる必要があります。アクセスリクエストが承認されたら、プロビジョナーがユーザーをこのグループに追加すると、Okta 内の同名グループに自動同期されます。
2. Elastic Cloud は、Elastic スタックへの管理アクセスのためのものです。ログイン画面はこちらで、Google SSO 経由でアクセスします。チームメンバーは Access Request (例) を通じてプロビジョニング／デプロビジョニングされる必要があります。承認されたら、プロビジョナーはメンバーシップページでアクセスが必要なインスタンスに対する適切な権限とともにメンバーを追加/削除できます。
3. Grafana は Okta 経由でアクセスします。ログイン画面はこちらです。GitLab のチームメンバーであれば誰でも Grafana にアクセスできます。プロビジョニング／デプロビジョニングは Okta を通じて処理されます。

私たちの働き方

私たちは GitLab のバリューに沿って働くことをデフォルトとし、より広い Infrastructure Platforms セクションのプロセスと、AI 利用原則に従います。 これに加えて、Observability での働き方に特に固有または重要なプロセスを以下に挙げます。

ロードマップ

私たちは透明性をもって、このエピックでロードマップに優先順位を付けています。roadmap:: ラベルですべてのエピック／Issue がどのようにグループ化されているかを確認できます。

プロジェクト管理

私たちが取り組むほとんどのプロジェクトは、複数の Issue を含むエピックで表現されます。シンプルなタスクは、親エピックなしの Issue で進められます。

プロジェクトのサイジング

プロジェクトには、できれば SRE と BE の両方の役割から、チームの少なくとも 3 名のエンジニアがアサインされます。これにより、知識を共有し、人が不在のときでもプロジェクトを前進させられるようになります。

チームの人数と KTLO・オンコールの追加負荷を考えると、同時に進行できるプロジェクトは 2 件までです。

ラベル

私たちのチームに関連するすべてのエピック／Issue には ~"group::Observability" ラベルが付いています。

チームの現在の優先順位を表すために、以下の roadmap:: ラベルを使用します:

• roadmap::now 現在取り組んでいる項目
• roadmap::next 次に取り組む候補の項目
• roadmap::later 直接的に取り組む計画はない項目
• roadmap::perpetual バージョンアップグレードなど、常に関連する項目

Category: ラベルは、作業項目の機能領域を表すために使います。例として Category:Logging や Category:Capacity Planning があります。

theme:: ラベルは作業の種類とその利点をグループ化するために使います。ラベルには以下があります:

• theme::Operational Excellence プロダクションでシステムを稼働させ続けるための運用プロセス
• theme::Performance Enablement システムが負荷変動に適応する能力
• theme::Reliability システムが障害から回復し機能を継続する能力
• theme::Security アプリケーションとデータを脅威から保護する
• theme::Cost Optimization 価値を最大化するためのコスト管理
• theme::Shift Left 他のステージグループのセルフサービスを促す項目
• theme::Enablement & Assistance 他ステージグループを直接支援する必要がある項目。Shift Left によりこの作業を最小化することを目指します。

最初の 5 つの theme ラベルは Well-Architected Frameworks がカバーする主要な柱に対応しています。詳しくはこちらを参照してください。

特定のエピックや Issue が作業サイクル内のどこにあるかを示すために、workflow-infra:: ラベルも使用します。

また、すべての Issue にはサービスラベルか、もしくは team-tasks、discussion、capacity planning のいずれかのラベルが必要です。

ボード

• 担当者別 Issue
• ワークフロー別エピック
• ロードマップ別エピック
• テーマ別エピック
• カテゴリ別エピック

担当者

Issue の担当者割り当てによって、その Issue の DRI が誰かを示します。 Issue の担当者は、ステータスを定期的に Issue 上で更新し、何が完了し何が残っているかを可能な限り明確に示すことが期待されます。 担当者はその Issue を完了まで推進することが期待されます。 担当者ステータスは通常、そのチームメンバーが現在積極的に取り組んでいるか、比較的すぐに戻ってきて取り組む計画があることを意味します。 積極的に取り組んでいない、あるいは数日以内に再開する予定がない Issue については、担当を外します。

グループレビュー

Production Engineering グループレビューは毎週木曜日に開催されます。roadmap::now ラベルの付いた作業項目には、毎週水曜日にステータス更新があることを保証します。更新を共有するためにこのエピックを使用します。このエピックはこのスクリプトで生成されます。

進行中のすべての作業の可視性を高めるため、各チームメンバーは Group Review エピックの roadmap::now セクションに表示される少なくとも 1 つのプロジェクトに、DRI または参加者としてアサインされることが期待されます。

レトロスペクティブ

チームレベルのレトロスペクティブ Issue は 6 週間ごとに作成され、チームが定期的に振り返りを行い、継続的改善の文化を促進できるようにします。レトロスペクティブ Issue の作成は、Engineering Manager の責任です。レトロスペクティブはこちらで確認できます。

Slack での更新

週次更新には GeekBot を使用しており、#g_observability チャンネルに投稿されます。

更新を投稿する際は、関心のあるチームメンバーが自身で深く調べられるように、十分なコンテキスト（リンクなど）を提供することを心がけてください (low context)。

チームのハッピネス

毎週木曜日、Slack チャンネルでチームメンバーに対し、このフォームを使ってその週のハッピネスをスコア付けするようリマインドが送られます。チームメンバーは結果をこのスプレッドシートで確認できます（‘Graph’ シートにビジュアライゼーションもあります）。

コスト管理

私たちの Observability サービスの日々の運用コストの詳細については、Observability スタックのコストドキュメントを参照してください。アクセス手順とコスト内訳が含まれています。

歴史と成果

このセクションには、チームの歴史と成果に関するメモが含まれます。網羅的なものではありません。

• 2024-02、キャパシティプランニング: 飽和度予測で見られた postgres CPU スパイクの先回り調査でデータベース設計の問題を発見
• 2024-03、キャパシティプランニング: Tamland が redis CPU の飽和を予測し、Practices による Redis の先回りスケーリングにつながった (スライド)
• 2024-05、メトリクス: Thanos から Mimir への移行が完了し、メトリクスの精度とダッシュボードのパフォーマンスに大きな改善をもたらしました。

Year-in-Review の Issue

• 2024

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