エンジニアリングのエラーバジェット

エンタープライズグレードのプラットフォームとして GitLab SaaS を強化する という 3 年戦略 の一環として、GitLab.com には特定の 可用性 と パフォーマンス の目標があります。

これらの目標は、ユーザーにプラットフォームの信頼性の指標を提供します。

さらに、GitLab.com サービスレベル可用性 は、プラットフォームの顧客との契約上の合意の一部でもあります。契約では特定の目標数値が定義されている場合があり、その合意を守らないと財政的・評判的な負担が生じる可能性があります。

エラーバジェットとは？

Google SRE ブックは一般的に推奨される読み物であり、「エラーバジェットの動機」 セクションでは以下のように述べています：

エラーバジェットは、1 四半期以内にサービスがどの程度の信頼性を許容できるかを決定する、明確で客観的な指標を提供します。この指標は、どのくらいのリスクを許容するかを決定する際の SRE とプロダクト開発者間の交渉から政治性を取り除きます。

これは私たちも目指している目標ですが、同じレベルの洗練度に達するためには、私たち固有の状況、成熟度、追加の要件を考慮する必要があることも認識しています。私たちの初期アプローチは、エラーバジェット SLO を既存の可用性アプローチに直接結び付けます。

エラーバジェットの将来のイテレーションでは、機能のベロシティとリスク許容度のバランスをとるプロダクトマネージャーの重要性をさらに発展させることを目指します。上記の開発者と SRE の間の明確さは、各サービスまたはプロダクトエリアに適切な測定と目標を確立することによって達成されます。最終的には、新しい機能の作業とユーザーへの継続的なサービス期待のバランスをとります。

エラーバジェットのコンポーネントとは？

エラーバジェットはまず SLO（サービスレベル目標）を確立することに依存します。SLO は目標、SLI（サービスレベル指標）、タイムフレームで構成されています。

• 目標：望ましい成功レベル（パーセンテージで示す）
• SLI：失敗したイベントの数を区別するために使用される評価
• タイムフレーム：SLI に直近性バイアスを適用

これらの要素の例：

• 目標：99.95%
• SLI：5 分間の API リクエストの 95 パーセンタイルレイテンシが 100ms 未満
• タイムフレーム：過去 28 日間

これらをまとめると、上記の SLO は次のようになります：過去 28 日間で、5 分間の API リクエストの 95 パーセンタイルレイテンシが 100ms 未満であるのは 99.95%

エラーバジェットは次に 1 - SLO の目標（この場合 1 - .9995 = .0005）です。28 日のタイムフレームを使用すると、エラーの「バジェット」は 20.16 分（.0005 * (28 * 24 * 60)）となります。

上記の例では SLI がレイテンシ測定として示されていますが、他の測定（エラーの割合など）も SLI に適切な要素であることに注意してください。

GitLab の現在のエラーバジェットの実装では、SLO とエラーバジェットの上記の洗練度の一部のみを使用していますが、将来的に洗練度を高めることを期待しています。SLO とエラーバジェットの実践は、目標と SLI の両方が、サービスの重要性と、それに依存する他のサービスやコンポーネントの回復力に基づいて（適切に）変化するように進化することが期待されています。

どのタイプのエラーが含まれますか？

500 ステータスコードエラーになった Web リクエストが計算されます。Sidekiq では、未処理の例外により失敗したジョブが計算されます。

グループに カスタム SLI がある場合、またはメトリクスカタログで固定フィーチャーカテゴリが設定された SLI がある場合、それらのエラーも計算されます。

エンジニアは Gitlab::ErrorTracking.track_exception やその他のロギングを、エラーバジェットに影響を与えずに自由に使用できます。

なぜエラーバジェットを使用するのですか？

GitLab は高可用性の SaaS プラットフォームとして提供する必要がある複雑なシステムです。長年にわたり、機能提供のベロシティを維持しながら SaaS の信頼性が継続的に向上することを確保するための課題に対処するために、いくつかのプロセスが導入されました。

Infradev プロセス は、インシデントや機能低下が発生した後の Issue を優先解決するために作成されました。このプロセスは成功しましたが、イベントフォーカスかつイベント駆動型です。

エンジニアリングアロケーションプロセス は、長期的なチーム効率、パフォーマンス、セキュリティ項目に対処するために作成されました。

GitLab でのエラーバジェットの初期イテレーションは、客観的なデータを導入し、個々の機能が長期間にわたってどのように機能しているかについてより深い洞察を生み出すシステムを確立することを目指します。これは、フォーカスを正しく配分し、リスクのバランスが適切で、システム全体が長期間にわたってより健全であり続けることを確保するために組織が使用できます。

フィーチャーカテゴリへのエラーバジェットの割り当ては特定の機能のベースラインを設定し、ひいては GitLab SaaS にとって重要なことの優先付けを確保するべきです。

最高優先度の改善をどのように決定しますか？

各グループはバジェット詳細ダッシュボードに Budget spend attribution セクションがあり、バジェットがどこで使われているかを発見する ことができます。

Budget failures パネルと Failure log links パネルの各リンクは、エラー数で順序付けられています。これらのテーブルのトップ違反者の修正を優先することが、使用されたバジェットへの最大の影響を持ちます。

異なるトラフィックパターンを持つ簡略化した違反シナリオを見てみましょう：

エンドポイント A の Apdex 比率が低いですが、エンドポイント B の違反を修正する方がエラーバジェット全体への影響が大きくなります。なぜなら、エラーバジェットに影響する違反の大半を占めているためです。

次に、より複雑な違反シナリオを見てみましょう：

エンドポイント A と エンドポイント B の 30 件のエラーはどちらもエラーバジェットへの影響が同じです。ただし、エンドポイント B の方が遅いリクエスト数 / 全体のリクエスト数の比率が高いため、エンドポイント B に取り組む方が良いです。エンドポイント A はすでに 99.95% の目標を満たしているため、追加の作業は必要ありません。99.97% は良いスコアであり、ここでの意図的な改善は早計な最適化と見なされる可能性があります。

エンドポイント B の違反数は Apdex の閾値を下回っているため、これら 2 つのエンドポイントが主要な違反者であれば、エンドポイント B の改善を検討すべきです。

GitLab.com のエラーバジェットポリシー

エラーバジェットプロセスにはいくつかの明確なアイテムがあります：

1. バジェットステークホルダー
2. バジェット配分
3. バジェット使用と会計
4. ステークホルダー間のコミュニケーション

バジェットステークホルダー

エラーバジェットプロセスのステークホルダーは：

1. ステージチーム（プロダクト部門とプロダクトカテゴリページで代表されるサポートエンジニアリングチーム）
2. インフラチーム（インフラチームページで代表されるチーム）
3. VP of Infrastructure とインフラリーダーシップ
4. VP of Development と VP of Product

バジェット配分

エラーバジェットは可用性の目標に基づいて計算されます。

現在の目標 99.95% 可用性では、許容される停止ウィンドウは 28 日間ごとに 20 分です。

プロダクトのレポーティング方法と一致させるために 28 日の期間を使用することにしました。

バジェットは SaaS プラットフォームに設定されており、ステージチームとインフラチームの間で共有されます。サービス可用性の計算方法の詳細は GitLab.com サービス可用性ページ に記載されています。

これには、すべての Rails コントローラー、API エンドポイント、Sidekiq ワーカー、およびサービスカタログで定義された他の SLI が含まれます。これはフィーチャーカテゴリを定義することでグループに帰属されます。フィーチャーカテゴリ化に関するドキュメントは開発者ガイドで確認できます。

チームが所有する機能の数や複雑さ、既存のプロダクト優先事項、チームの規模はバジェットに影響しません。

バジェットレポーティング

毎月 4 日に、ステージグループ別のバジェット使用に関するエラーバジェットレポートが提供されます。アナウンスは #product、#eng-managers、#f_error_budgets、#development に表示されます。

多くのステージグループがインフラの根本的な Issue によりバジェットを超過する月があることがあります。レポートが生成される際、5 つ以上のグループがバジェットを超過している場合（グループのトラフィックシェアが >0.1% の場合）、Scalability グループはレポートを発行する前に使用量の増加を調査します。調査を始める前に Slack チャンネルで発表します。これは複数のチームによる重複した調査を防ぐためです。ステージグループは月次エラーバジェットレポートをレビューし、フィーチャーカテゴリの超過についてコメントすることが求められます。

エンジニアリングアロケーションミーティングでのエラーバジェット

ステージグループはエラーバジェット使用量について毎週報告することは求められていません。3 ヶ月連続して割り当てられたバジェットを超えた月次使用量を持つフィーチャーカテゴリは、議論のためにアジェンダに追加されます。

バジェット使用（サービス別）

現在のバジェット使用量は一般的なサービス可用性ダッシュボードで確認できます。

使用されたバジェットとは、ユーザー向けサービスが指定された閾値を下回るエラーの割合と指定された目標を超えるレイテンシを経験した時間（分単位）です。サービス可用性の計算方法の詳細は GitLab.com サービス可用性ページ で確認できます。

バジェット使用量は現在、プライマリサービスレベルで集計されています。

バジェット使用量に貢献した内容の詳細は、発生したインシデントを調べ、特定のサービスダッシュボード（とそのリソース）を探索することでさらに確認できます。

バジェット使用（ステージグループ別）

これがどのように構築されているかをより詳しく見た例があります。

現在の 28 日間 のバジェット使用量は各ステージグループダッシュボードで確認できます。そのステージグループのフィーチャーカテゴリは単一の値にまとめられています。

ステージグループはダッシュボードを使用してバジェット使用量の原因を調べることができます。バジェット使用量を調査するプロセスは開発者ドキュメントに記載されています。

可用性の計算式：

満足な Apdex を持つ操作数 + エラーのない操作数
/
Apdex 測定の総数 + 操作の総数

これにより、正常に完了した操作のパーセンテージが得られ、分に変換されます：

(1 - ステージグループ可用性) * (28 * 24 * 60)

Apdex とエラー率については ハンドブックページ で詳しく説明されています。

エラーバジェット使用量情報は Tableau の エラーバジェット概要ダッシュボード で確認できます。

システム全体のインシデント

共有サービス（データベースや Redis など）に影響するシステム全体のインシデントは、チームのエラーバジェット使用量に影響する可能性があります。28 日間の期間で使用量を確認しているため、これらの短命なイベントの影響はほとんどの場合無視できるほど小さいはずです。

影響が大きい場合は、月次レポートでこのインシデントが使用量を手動調整する根拠になるかどうかを議論できます。

現時点では、システム全体のイベントをグループレベルのエラーバジェットから自動的に除外することは検討していません。チームはエラーバジェットの強固な基盤を構築することに集中しており、各グループに関連するのに十分なチューニング機能を持つことを目指しています。

エラーバジェット帰属の変更方法

エラーバジェットイベントは、フィーチャーカテゴリ化によってステージグループに帰属されます。エンドポイントのフィーチャーカテゴリを変更するには、フィーチャーカテゴリ化開発ドキュメントに記載されているようにエンドポイントを更新してください。

フィーチャーカテゴリの更新は、将来のイベントがステージグループにマッピングされる方法のみを変更します。以前に報告されたイベントは遡及的に更新されません。

Observability チーム は、Web サイトリポジトリでフィーチャーカテゴリが変更されたときにマッピングを最新の状態に維持することを担当しています。stages.yml でカテゴリが変更されると、スケジュールされたパイプラインがビルドボードに Issue（Issue の例）を作成します。Issue にはパイプラインリンクと説明の手順が含まれています。カテゴリは次の 2 つの場所に同期する必要があります：

1. Rails アプリケーション。
2. ランブックリポジトリ。

新しいグループのエラーバジェット

グループが作成されると、グループは stages.yml に追加されます。そのマージリクエストで、新しいグループには新規または既存のフィーチャーカテゴリが割り当てられます。

この MR がマージされると、Scalability はレコーディングインフラのメトリクスカタログを更新するための自動化された Issue を受け取ります。これは新しいグループが stages.yml に追加されてから 1 週間以内に発生します。

メトリクスカタログが更新されると、関連するフィーチャーカテゴリのメトリクスが新しいステージグループに帰属されます。帰属が変更された場合と同様に、変更は遡及的ではありません。つまり、既存のフィーチャーカテゴリが 15 日に source code から code review に移動した場合、そのフィーチャーカテゴリは 1 日から 15 日まで source code のエラーバジェットに貢献します。15 日以降のメトリクスは code review のエラーバジェットに計算されます。

グループが名前変更されたり、ステージが移動した場合も同様です：グループの名前変更が 15 日にメトリクスカタログでマージされた場合、28 日レポートにはグループの古い名前の 15 日間のデータが含まれ、最近の日々は新しい名前のグループに帰属されます。

契約

特定の月にトラフィックシェアが >0.01% のステージグループは、機能開発と信頼性開発のバランスをとるためにこの契約を遵守する必要があります。ステージグループのトラフィックシェアは月次エラーバジェットレポートで確認できます。

エラーバジェットはプロダクト開発タイムラインの一部として月次でレビューされるべきです。

フィーチャーカテゴリの機能開発と信頼性開発のバランスは次のようにすべきです：

3 ヶ月連続して割り当てられたバジェットを超えた月次使用量を持つフィーチャーカテゴリには、追加の機能開発制限が課される場合があります。

異なるエラーバジェットを持つステージグループ

私たちの現在の契約は 99.95% の可用性と 20 分の月次エラーバジェットです。ただし、以下のグループはビジネスニーズに基づいて一時的に調整されたバジェットを持っています：

例外

一時的な例外は、付与された例外が GitLab.com の信頼性に追加のリスクをもたらさないと推定される場合に、異なるステークホルダーがより高い優先度のビジネスニーズを満たせるようにするための手段として付与されます。例外は、エンドポイントに受け入れ可能なパフォーマンスを定義するプロパティを設定するカスタムターゲットとは異なります。

例外の正当な理由：

1. エラーバジェットを改善するための作業がスコープ設定・完全に計画・資金調達されている。作業が完了するまでに 1 リリース月以上かかる見込みがあり、作業が完了するまでエラーバジェットが定期的に使用されることが予想される。
2. エラーバジェットを改善するための作業がスコープ設定・完全に計画されているが、現在資金が調達されていない。ステークホルダーは資金確保のプロセス中であり、追加資金が確保されるまでエラーバジェットが定期的に使用される。
3. 一時的に最高優先度が重要なビジネス目標の達成にあり、GitLab.com の信頼性に直接影響しない。グループはこの他の優先事項に集中している間、エラーバジェットを定期的に使用する可能性が高い。

例外リクエストの手順

例外をリクエストするには、MR を開いて上記のテーブルにステージグループを追加してください。説明には以下の詳細を提供してください：

1. バジェット使用の原因となっている問題の明確な説明
2. 作業のスコープが設定されていることを示す関連リソース
3. 例外を再検討する必要がある目標日

追加ガイダンス

1. Epic と Issue を使用して作業を文書化する
2. 作業が明確にスコープ設定されることを確保するために、Epic と Issue に詳細な説明を追加する。
3. 作業の完了にどれくらい時間がかかるかを透明にするために、Epic に開始日と期限日を追加する。
4. 作業がいつ計画されるかを透明にするために、Issue にマイルストーンを追加する。

以下の質問への回答を提供してください：

1. この例外によるチームのバジェットのうちどの程度がこの例外によるものですか？この例外でカバーされる違反エンドポイントを削除した場合、エラーバジェットはグリーンになりますか？
2. チームのエラーバジェット使用量の主な要因は何ですか？それはレスポンスタイムですか？
3. 参照された Epic の終了時点での成功の定義は何ですか？

承認プロセスを迅速化するために上記のガイダンスと手順に従ってください。

MR の承認者：

1. 影響を受けるステージグループのプロダクトディレクター以上
   • ビジネスニーズが満たされることを確保する責任があり、報告チェーンの上下にその変更を伝える必要があります。
2. インフラのシニアマネージャー以上
   • GitLab.com が悪影響を受けないことを確保する責任があり、報告チェーンの上下に例外を伝える必要があります。

エラーバジェット改善

エラーバジェットの改善に関連する作業は Issue で詳細に説明する必要があります。これらの Issue には Error Budget Improvement と group:: ラベルを付けて、レポートで追跡できるようにしてください。

エラーバジェット DRI

• エンジニアリングアロケーションを持つグループについては、エラーバジェットの使用量を維持する責任は、プロダクトマネジメントチームではなく開発チームにあります。

現在の状態と将来の意図

現在の状態

1. エラーバジェットは各フィーチャーカテゴリに存在し、標準的な Apdex 閾値とエラー率を組み込んでいます。
2. エラーバジェットは Grafana と Sisense ダッシュボードを通じてステージグループとステージに公開されています。
3. 貢献要因は Grafana ダッシュボードで利用可能なリンクを通じて探索できます。
4. エラーバジェットはプロダクト優先順位付けプロセスに含まれています。

ロードマップ

以下の変更はエラーバジェットの成熟度を高めることを目指しています。

1. エラーバジェット計算の精度を高める（Apdex 部分）

改善

• キャンセル済み エラーバジェットに使用されていた SLO 目標は、インフラ監視に使用されるアラートと結合されていました。Sisense を使用してステージグループ別に目標を設定することを提案しましたが、このアプローチは支持されませんでした。インフラ監視とエラーバジェットに別の目標を使用する方法を見つけましたが、目標を同じに保ち、エラーバジェットの Apdex 部分のデフォルトレイテンシ閾値を調整するという決定がなされました（次のアイテムを参照）。
• 完了済み SLI の計算に使用されたリクエスト期間閾値は、すべてのエンドポイントに適切ではありませんでした。閾値は 9 月 21 日に 5 秒に増加されました。エラーバジェットに完全な効果が現れるまでに 28 日かかります。
• 完了済み ステージグループは次に、SLI リクエスト期間閾値の設定可能性を拡張することにより、エンドポイントごとに独自の SLI を設定できるようになります。Epic。
• 現在 not_owned のエンドポイントは正しいフィーチャーカテゴリに帰属されます。これは以下によって対処されます：
  • 完了済み Sidekiq に呼び出し元情報を使用する、および
  • graphQL クエリとフィーチャーの相関付けが行われます。
• エラーバジェットに対するシステム全体の停止の影響をより明確にする。
• エラーバジェットとサービス可用性の両方についてレポートする PM へのガイダンスを提供する（Runner や Pages など）。

プロダクト開発活動

プロダクト開発チームは以下を推奨されます：

• 戦略的優先コード、Infradev、是正措置、セキュリティ、エンジニアリングアロケーション Issue に優先順位付けガイドラインに従って引き続き取り組む
• エンドポイントの SLO を提案する
• カスタムターゲット期間を使用した新しい Apdex 計算方法へのオプトイン
• エラーバジェットの将来の改善のためのさらなるフィードバックを提供する

2. エラーバジェットの可視性を高める（エラー部分）

• ステージグループにはエラーカウント情報が提供されています。これはSentry でエラー情報を探索可能にすることでさらに補完できます。

3. エラーバジェットのスコープを調整する

• P1/S1 インシデントをエラーバジェット計算に組み込むことを検討する。

詳細情報

• エラーバジェット AMA
• ステージレベルのエラーバジェットダッシュボードの理解
• 定期的な Slack アップデートの設定

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