プロンプトとコンテキスト
多数のサービスのSLO、エラーバジェット、バーンレートを計算し、信頼性ゲートやアラートをトリガーするサービスを設計してください。遅延データ、ウィンドウ、サイレンス、バックフィル、例外をどのように処理しますか？
これはSRE、プラットフォーム、バックエンド、システムデザインの職種に適した設問です。Google SREワークブックでは、エラーバジェットを信頼性とデリバリー速度のバランスをとる手段として説明しており、バーンレートアラートはそのバジェットがどれだけ急速に消費されているかに焦点を当てています。この設計では、定義、計算、アラート、意思決定、監査可能性を結びつける必要があります。
面接官がテストしていること
- SLIイベント、SLOターゲット、コンプライアンス期間、エラーバジェット、バーンレートの区別。
- 高速ウィンドウと低速ウィンドウが互いに補完し合う理由と、ノイズを抑制する方法の説明。
- 重複排除、遅延データ、重複サンプル、バックフィル、バージョン管理された再計算の設計。
- デプロイメントゲート、オンコール対応、サイレンス、手動例外からのアラートの分離。
- テナント分離、クエリコスト、履歴の追跡可能性、権限の境界設定。
- ダッシュボードを描くだけでなく、データ品質メトリクスとリプレイによるポリシーの検証。
30秒の回答フレームワーク
「このサービスを、SLO仕様、イベント取り込み、ウィンドウ集約、バジェット計算、ポリシー評価、通知監査に分割します。各SLOは、成功イベントと合計イベント、ターゲット、コンプライアンス期間、バージョンを固定し、バーンレートは観測されたエラー率を許容エラー率で割ったものとします。高速ウィンドウでスパイクを検知し、低速ウィンドウで継続性を確認し、鮮度とサンプルサイズのチェックを行います。遅延データやバックフィルされたデータは、監査された決定を黙って書き換えるのではなく、バージョン管理された再計算を生成します。」
ステップごとの詳細解説
ステップ1：SLIとイベントコントラクトの定義
SLO仕様では、サービス、メトリクスタイプ、成功イベント、合計イベント、ターゲット、コンプライアンス期間、集約ディメンション、タイムゾーンを指定します。カウンタには、安定した重複排除キーとイベント時刻が必要です。明示的なポリシーがない限り、クライアントのキャンセル、依存関係の障害、プラットフォームのフォールトを混在させるべきではありません。公開された仕様はバージョン管理され、過去の計算には当時アクティブだったバージョンが使用されます。
ステップ2：バジェットとバーンレートの計算
99.9%のターゲットの場合、コンプライアンス期間中に許容されるエラー率は0.1%です。現在のウィンドウのエラー率をその許容率で割ることでバーンレートが得られます。1は計画どおりのペースでバジェットを消費していることを示し、1を超える値はより速く消費していることを示します。割合のみを保持するのではなく、結果を再計算できるように、分子、分母、時間境界とともに未加工のカウントと集約を保存します。
ステップ3：高速ウィンドウと低速ウィンドウの組み合わせ
高速ウィンドウはリリースのスパイクを迅速に検出し、低速ウィンドウはその影響が継続していることを確認します。ポリシーには、両方のウィンドウ長、バーンレートのしきい値、最小イベント量、必要な評価を記録します。鮮度と分母のサイズが十分な場合にのみトリガーします。サービスごとに異なるポリシーを使用できますが、すべてのアラートを1つのしきい値に強制するのではなく、テンプレートには目的を明記する必要があります。
ステップ4：遅延データ、重複データ、バックフィルデータの処理
イベントIDまたはタイムバケットによって取り込みを冪等にし、集約ウォーターマークと補正バージョンを永続化します。許容される遅延内の遅延イベントは再計算をトリガーし、それを超えるイベントはデータを不完全としてマークします。バックフィルによって過去の通知やゲートを黙って変更してはなりません。古い値、新しい値、オペレータ、理由、影響を受ける決定IDを記録します。
ステップ5：アラート、ゲート、例外の連携
アラートサービスは通知とエスカレーションを行い、デプロイメントコントローラは一時停止や承認要求を行い、ポリシーサービスは証拠に基づいた状態を出力します。例外にはスコープ、有効期限、承認者、理由があります。サイレンスは通知のみを抑制し、バジェット計算を停止することはありません。すべてのゲートには、決定を監査できるように、SLO、ウィンドウ、カウント、鮮度、ルールのバージョンが含まれます。
ステップ6：サービスのスケーリングとオブザーバビリティ
サービス、リージョン、テナントごとに集約をシャード化し、高カーディナリティのディメンションを制限し、反復クエリをキャッシュします。取り込みラグ、損失、重複、集約遅延、評価時間、通知成功率、ポリシーエラーを監視します。過去のインシデントをリプレイしてウィンドウを検証し、障害注入を行ってイベントからアラート、およびイベントからゲートまでのエンドツーエンドのレイテンシを測定します。不完全なデータは正常として報告するのではなく、不明として表示しエスカレーションする必要があります。
トレードオフ、境界、情報の獲得
エラーバジェットサービスは、信頼性ターゲットを監査可能なエンジニアリング上の決定に変換します。バーンレートのしきい値をより敏感にするとノイズとアラートの負担が増加し、ウィンドウを長くすると応答が遅くなります。計算されたファクト、通知アクション、デプロイ決定を分離します。過去のバージョンを保持しながら、修正された再計算を許可します。このサービスは共有された証拠を提供するものであり、チームの優先順位を選択するものではありません。
模範的な高品質の回答
「まず、成功イベントと合計イベント、ターゲット、コンプライアンス期間、ディメンション、重複排除を網羅する、バージョン管理されたSLO仕様から始めます。冪等な取り込みにより、サービスおよびウィンドウごとに分子、分母、時間境界、ウォーターマークが保存されます。集約により、エラー率、許容エラー率、バーンレートが計算されます。ポリシー評価では、スパイク用の高速ウィンドウと継続性用の低速ウィンドウを使用し、最小ボリュームと鮮度をチェックします。
通知、デプロイメントゲート、人間の例外は別々のコンシューマです。サイレンスは通知を抑制しますが計算は実行したままにし、ゲートはSLO、ウィンドウ、カウント、ルール、データバージョンを含む証拠を出力し、例外は承認され、期限があり、監査可能です。遅延データは、過去の決定を静かに変更するのではなく、バージョン管理された再計算を生成します。
大規模環境では、サービス、リージョン、テナントごとにシャーディングし、高カーディナリティのラベルに上限を設け、取り込みラグ、重複、損失、集約遅延、通知成功率を監視します。リプレイと障害注入によってポリシーを検証します。不完全なデータはエラーゼロとしてカウントされるのではなく、不明としてマークされエスカレーションされます。」
よくある間違い
- SLOの割合のみを保存する → サンプルサイズと境界が失われる → 分子、分母、ウィンドウ、ウォーターマークを保持する。
- すべてのサービスに1つのしきい値を適用する → リスクとトラフィックが異なる → ターゲット、ボリューム、ウィンドウごとにポリシーをバージョン管理する。
- サイレンスを計算の停止として扱う → バジェットのファクトが失われる → 通知のみを抑制し、監査を継続する。
- 遅延データで履歴を上書きする → リリース決定を再構築できなくなる → 再計算をバージョン管理し、新旧の値を保持する。
- 欠損データを正常として扱う → 収集の失敗が隠蔽される → 不明として表示し、データ品質に関するアラートを発行する。
- ゲートを通知状態に依存させる → 通知の再試行によってリリースの結果が変わる → ゲートは不変の評価証拠を読み取るようにする。
フォローアップの質問と回答
なぜ高速ウィンドウと低速ウィンドウの両方を使用するのですか？
高速ウィンドウはスパイクの検出時間を短縮し、低速ウィンドウは一時的なノイズをフィルタリングして継続的なバジェット消費を確認します。これらを組み合わせることで応答速度と誤検知のバランスをとりますが、しきい値はイベント量に対して検証する必要があります。
バックフィルによってバーンレートが変更された後、古いアラートはどうなりますか？
古い評価と通知の記録を保持し、新しいデータバージョンでタグ付けされた再計算を作成し、現在のゲートが変更されるかどうかを示します。履歴を削除してはなりません。対応者には当時利用可能だったファクトが必要です。
高カーディナリティのディメンションがシステムを圧迫するのをどのように防ぎますか？
許可されるラベルを制限し、ティアごとにテナントやルートのスライスをサンプリングし、価値のあるビューのみをマテリアライズし、クエリのバジェットとタイムアウトを強制します。サービスレベルのSLOが無制限のディメンションを要求するべきではありません。
例外がゲートを永続的にバイパスするのをどのように防ぎますか？
各例外をサービス、変更、または時間範囲にバインドし、承認者と理由を要求し、自動期限切れを強制します。その後デフォルトのポリシーを復元し、例外カバレッジを監査メトリクスとして測定します。