設問と適用される場面
面接官は「システム設計において、信頼性とリリース速度のバランスを取るためにエラーバジェットをどのように活用しますか？」と質問することがあります。SLI、SLO、エラーバジェットがリリース、ロールバック、キャパシティ、チーム間の調整にどのように影響するかを説明する必要があります。これは、高可用性、頻繁なリリース、複数のチーム依存関係を伴うSRE、プラットフォーム、バックエンド、シニアシステム設計の面接に適しています。
面接官が見ているポイント
この設問は、単に99.99%と暗唱できるかを試すものではありません。ユーザー体験の目標を実行可能な意思決定ルールに変換できるかどうかが問われています。Google SREでは、エラーバジェットをSLOの下に残された猶予領域であり、信頼性の向上作業とイノベーションを調整するために使用されるものと定義しています。バジェットを使い果たすと、信頼性が回復するまで通常の変更は一時停止されます。面接官はまた、測定期間、データ品質、プログレッシブデリバリー、監査可能な例外にも注目しています。
自問すべき明確化のための質問
ユーザーは誰か、どのジャーニーが重要か、サービスの境界はどこにあるか、目標は可用性、レイテンシ、鮮度、正確性のどれかを明確にします。SLOの対象期間、リージョン、依存関係の責任範囲、ロールバック能力を確認します。具体的な数値が示されていない場合は、4週間の対象期間、99.9%の可用性、有効なユーザーリクエストによる測定などの前提条件を提示します。
30秒で答えるフレームワーク
5つのステップを使用します：
- ユーザーから見えるSLIとSLOを定義する。
- 対象期間のエラーバジェットを計算し、何がそれを消費するかを説明する。
- バジェットをプログレッシブデリバリー、自動ロールバック、変更ゲートに連携させる。
- バジェットを使い果たした場合は通常の変更を凍結し、セキュリティや緊急修正の明示的な例外を設けた上で信頼性向上作業にリソースを充てる。
- ポストモーテム、依存関係の帰属、バジェットの傾向を活用して次の計画サイクルを調整する。
ステップバイステップの詳細な回答
1. ユーザーの成果からSLIを定義する
デフォルトでサーバーのCPU使用率や平均レイテンシを信頼性ターゲットとして使用しないでください。リクエスト型サービスの場合は、成功したリクエストの割合やレイテンシ閾値を下回るリクエストの割合を選択し、非同期ジョブの場合は、期限内の完了や結果の鮮度を使用します。ノイズによってバジェットが消費されないよう、ユーザーに影響を与える障害を内部リトライや無効なトラフィックから分離します。
2. 説明可能なSLOと対象期間を選択する
例えば、4週間で有効なリクエストの成功率99.9%とすると、約0.1%の失敗が許容されます。対象期間によって、短期的なインシデントと長期的なトレンドに対する感度が制御されます。複数のSLOがある場合は、その組み合わせルールを明記します。クリティカルなユーザージャーニーはリリースをブロックできるようにし、セカンダリメトリクスはアラートや計画の参考情報とします。母集団と重み付けを説明せずにパーセンテージを平均化してはいけません。
3. バジェット消費の原因を特定する
総バジェット、バーンレート、原因を記録します。リリース、設定、依存関係の障害、キャパシティ不足、誤検知を個別にタグ付けします。信頼できる帰属特定があって初めて、チームはコード修正、キャパシティ追加、依存関係の規約変更、監視の修正のどれを行うべきかを判断できます。Googleのサンプルポリシーでも、自サービス内の障害、他チームが所有する障害、SLOのスコープ外のトラフィックを区別しています。
4. リリースゲートとプログレッシブロールバックを設計する
通常の変更はトラフィックの小割合または1つのリージョンに送信し、エラー率、レイテンシ、バーンレートを観察してから拡大します。ゲートは、残りのバジェットと短期ウィンドウのバーンレートの両方をチェックする必要があります。月間平均が安全そうに見えても、急速に悪化しているインシデントが隠れている可能性があるためです。予期しない動作が発生した場合は、復旧時間を短縮するために原因究明の前にロールバックを実行します。ロールバックには冪等性とデータの互換性も必要です。
5. バジェット消費後に何が起きるかを定義する
バジェットを使い果たすことは、開発が恒久的に停止することを意味するわけではありません。通常の機能開発や必須ではないデータ変更を凍結し、キャパシティ、テスト、依存関係の分離、グレースフルデグラデーション、根本原因の修正を優先します。セキュリティ修正やSLO未達に対処するための緊急の不具合修正は例外とすることができますが、「緊急」が恒久的な回避策にならないよう、理由、承認者、フォローアップレビューを記録します。
6. 依存関係とチーム間の所有権を処理する
すべての外部障害を自サービスのSLO内に隠してはいけません。依存関係、クライアント、サービスの各エラーを個別に追跡し、修復とコミュニケーションの責任者を明確にします。チーム間でバジェットのルールについて意見が一致しない場合は、ユーザージャーニーと共有メトリクスに基づいて調整し、サービスオーナーを通じてエスカレーションします。責任を他に転嫁することは信頼性戦略ではありません。
高品質な回答例
この架空の回答は、実際の数値と境界に置き換えて使用する必要があります：
最も重要なユーザーリクエストに対して、成功率とレイテンシのSLIを定義します。例えば、有効なリクエストの成功SLOが4週間で99.9%である場合、エラーバジェットは有効リクエストの0.1%になります。監視では、サービス境界外のトラフィックを除外し、残りのバジェット、1時間のバーンレート、障害の帰属を表示します。リリースは1つのリージョンでトラフィックのわずかな割合から開始し、段階的に拡大します。バーンレートの閾値を超えた場合はロールアウトを停止し、ロールバックをトリガーします。バジェットに余裕がある間は、プロダクトとSREは許容リスクの範囲内でリリースを進めることができます。バジェットを使い果たした後は通常の変更が凍結され、チームはキャパシティ、テスト、依存関係の分離、根本原因の修正を優先し、セキュリティ作業については例外としてログに記録します。すべてのインシデントで非難のない振り返り（blameless postmortem）を行い、その修正は次の計画サイクルに組み込まれます。したがって、リリース速度は主観的な希望ではなく、残りのバジェットと観測されたリスクに基づいて統制されます。
よくある間違い
エラーバジェットを障害を起こす許可とみなす
バジェットはユーザーが許容できる障害の猶予枠を表すものであり、インシデントを引き起こすためのノルマではありません。ユーザーへの影響、対象期間、バーンレート、修復の責任について説明してください。
可用性の数値のみを提示する
SLI、母集団、対象期間がなければ、99.99%という数値は意思決定の指針にはなりません。有効なリクエスト、レイテンシまたは鮮度、無関係なトラフィックを除外するルールを追加してください。
バジェット未達後にリリースを永久に凍結する
これではセキュリティ修正、マイグレーション、復旧作業が無視されてしまいます。例外がデフォルトの手段にならないように、例外規定、承認、ロールバック、レビューを定義してください。
プログレッシブデリバリーとロールバックの互換性を無視する
「監視してリリースする」だけでは不十分です。トラフィックの段階、自動停止条件、ロールバックの順序、新旧の読み取りおよび書き込みの互換性について説明してください。
フォローアップと発展的な実践
SLOは健全ですが、1時間のバーンレートが高くなっています。リリースしますか？
長期ウィンドウの残量と短期ウィンドウの傾向を比較します。消費が継続している場合は、トラフィックの拡大を停止し、実際のユーザーへの影響か、トラフィックのスパイクか、監視の不具合かを確認した上で、ロールバックするかどうかを決定します。
外部の依存関係がバジェットを使い果たしました。あなたのチームも凍結すべきですか？
サービスのコミットメントにその依存関係の障害が含まれているかどうかを確認し、ユーザージャーニーに基づいて判断します。所有権が外部にある場合でも、ユーザーを保護し、デグラデーションを有効にします。凍結ルールは、証拠の共有とエスカレーションを含めて事前に合意しておく必要があります。
複数のSLOが同時に未達となりました。どのように優先順位をつけますか？
クリティカルなユーザージャーニー、影響範囲（blast radius）、バーンレート、可逆性によってランク付けします。インシデントを拡大させたり復旧を妨げたりする可能性のある指標に最初に対処し、その後に局所的なパフォーマンス問題に対処し、トレードオフを明記します。
バジェットを使い果たした後に、プロダクトマネージャーからリリースを求められました。どう対応しますか？
議論をデータに変換します。残りのバジェット、ユーザーへの影響、ロールバックのコスト、修復時間を提示します。小規模な実験または延期を提案します。真のビジネス上の緊急事態が残る場合は、完全に記録された例外を適用し、信頼性向上作業とレビューのスケジュールを設定します。