プロンプトと背景
対象サービスには99.99%の可用性SLOと0.01%の月間エラーバジェットが設定されています。ユーザーに見える障害によってすでにバジェットを超過していますが、大規模な契約更新に関わる機能がリリース待ちの状態です。指標をどのように定義し、バジェットが本当に消費されたかを検証し、どの変更を一時停止するかを決定し、健全なリリースペースをどのように回復するかを説明してください。
Google SREでは、エラーバジェットをSLOによって許容される障害の余力として扱います。バジェットが残っている間は妥当な範囲内でリリースが可能ですが、使い果たした後は、緊急のセキュリティ修正や現在の障害に対する修正を除き、通常は変更が凍結されます。これはリスク判断のインプットであり、プロダクトに対する無条件の禁止令ではありません。
面接官が見ているポイント
優れた回答は、ユーザー中心のSLIから始まり、バジェット消費をリリース、ロールバック、復旧時間と関連付けて説明します。サーバー側のメトリクスがユーザーの体感可用性と乖離する理由、一時的なスパイクと持続的な消費（バーン）の切り分け方、例外を正当化する根拠、凍結を解除できる権限保持者についての質問を想定してください。
「すべての開発を停止する」という対応は、セキュリティ、データ整合性、コンプライアンス上の責務を無視しています。「ビジネス上重要だからリリースする」という対応は、共通のリスク言語を放棄することになります。
最初に確認すべき明確化のための質問
ユーザー影響とメトリクスの境界
SLIが実際のユーザージャーニーに基づいており、クライアント、依存関係、クリティカルなワークフローを含んでいることを確認します。リクエストの失敗、レイテンシ、不正なデータ、完全な利用不可状態を区別します。単一の平均値では、テールレイテンシや特定の顧客層に対する深刻な影響を見落とす可能性があります。
バジェット期間とバーンレート
バジェットが月次、四半期、ローリングのいずれのウィンドウであるか、現在のバーンレートと不確実性を明確にします。残量は単に割合を示すだけでなく、「この状態をあとどれくらい維持できるか」に答えられる必要があります。
価値とリリースリスク
収益、コンプライアンス、セキュリティ上の価値を評価します。その機能をカナリアリリース、ロールバック、または特定のテナントのみに限定することは可能でしょうか。検証可能な価値と復旧手段がなければ、顧客からのプレッシャーはリスクを正当化する根拠にはなりません。
30秒の要約回答
「私はまず、ユーザー側のSLI、SLO期間、バーンレートを検証し、シグナルが持続的な問題なのか、それとも計測エラーなのかを確認します。バジェットが本当に枯渇している場合は、重要度の低いリリースを一時停止し、リソースとエンジニアリングリソースをSLOの復旧、根本原因の修正、モニタリングの検証に振り向けます。セキュリティ、コンプライアンス、またはインシデント緩和のための変更は、影響範囲が小さく、リバーシブルであり、責任者が明確である場合に限り例外として認めます。大口顧客向けの機能については、テナントの分離や段階的なカナリアを検討し、リスクレビューを実施した上で進行の可否を決定します。合意されたバジェットマージンが回復したら、段階的にリリースを再開し、SLOがユーザー価値を正しく反映しているかを再評価します。」
ステップ別の解決手順
ステップ1：ユーザーアウトカムとしてSLIを定義する
クリティカルなワークフローについて、可能な限りクライアントまたはエッジのデータを使用して、成功率、エンドツーエンドのレイテンシ、正確性を定義します。何をもって有効なリクエストとみなすか、メンテナンスウィンドウ、テナントセグメンテーションを明記します。ユーザーにとってエクスポートの完了が重要であれば、APIのHTTP 200応答に依存せず、ジョブ完了SLIを作成します。
ステップ2：バジェットとバーンレートを計算する
99.99%の可用性目標では、指定された期間内で0.01%のエラー率が許容されます。具体的な許容ダウンタイム（分）は期間と計測方法によって異なります。1つのクエリで残存バジェット、バーンレート、不確実性を算出し、データの遅延状況を明記します。異常に対処する前に、二重カウント、テレメトリの欠落、依存関係の帰属をチェックします。
ステップ3：リリースゲートを確立する
バジェットが健全な場合でも、通常のリリースにはロールバック体制とモニタリングが必要です。枯渇に近づくにつれてレビューレベルを引き上げ、バッチサイズやカナリア露出を縮小します。枯渇した後は重要でない変更を凍結し、インシデント修正、データ整合性対応、重大なセキュリティまたはコンプライアンス変更のみをロールバック手順の提示を条件に許可します。口頭での合意に頼るのではなく、ツールと責任分担マトリクス（RACI等）にゲートを組み込みます。
ステップ4：例外を評価する
すべての例外について、ユーザーメリット、リスク、影響を受けるテナント、公開割合、ロールバック条件、観察期間を記録します。単一テナントへの分離、シャドウトラフィック、内部ユーザーへの限定公開は有効な判断材料となります。プロダクト、変更責任者、SREが共同で承認を行い、営業上の約束だけで決定を下すことはしません。
ステップ5：完璧さを追う前に信頼性を回復する
凍結期間中は、復旧SLO、バジェットマージン、期限を設定した上で、根本原因、キャパシティの制限、モニタリングのギャップを解消します。目標達成のために長期的な無理が生じる場合は定期レビューで調整しますが、リリースを通すためだけに事後的に期間を変更したり障害を除外したりしてはいけません。
ステップ6：顧客およびチームとコミュニケーションを取る
影響を受けるワークフロー、対象期間、緩和策、次回の更新予定を説明します。顧客向け機能については、検証可能な代替策やスケジュールを提示し、根拠のない復旧時間を安請け合いしないようにします。社内では単一のバジェットダッシュボード、インシデントタイムライン、責任者リストを使用し、プロダクトとエンジニアリングの間の政治的な駆け引きを減らします。
ステップ7：復旧を管理・統制する
バジェットが合意されたしきい値に達したら、小さなバッチから段階的にリリースを再開します。失敗した変更、検知の遅れ、ロールバック所要時間、顧客への影響をレビューします。SLOがユーザー価値を表していない場合は、データに裏付けられた改定を提案します。凍結、例外、承認、結果の記録を保持し、四半期ごとのリスクレビューに役立てます。
高品質な模範回答
私は「営業が急いでいる」や「バジェットがゼロだから」という理由だけで短絡的な決定を下しません。ユーザー側のSLI、統計期間、データの整合性、バーンレートを検証し、計測エラーや重複カウントを排除します。バジェットが真に枯渇している場合は、必須ではないリリースを凍結し、復旧、修正、モニタリングに投資します。セキュリティ、コンプライアンス、データ修復、インシデント緩和に関する変更については例外申請を受け付けます。
大口顧客向けの機能を進める必要がある場合は、テナントを分離し、少量のカナリアリリースを実施し、自動ロールバックを設定して観察期間を定めます。プロダクト、変更責任者、SREがメリット、リスク、停止条件を記録した上で共同承認します。バジェットが回復した後は、目標値やプロセスを変更する前に、段階的に凍結を解除し、SLOが実際のユーザーアウトカムを測定できているかを検証します。
よくある間違い
- 間違い： バジェット枯渇後にすべての変更を一律に凍結する。 → 失敗の理由： セキュリティ、データ修復、インシデント緩和が遅れる可能性があります。 → 対策： 範囲を限定した例外規定、承認者、ロールバックの根拠を定めます。
- 間違い： サーバー側の平均レイテンシのみを使用する。 → 失敗の理由： クライアント側の障害、テールレイテンシ、主要テナントの体験を見落とします。 → 対策： ユーザージャーニーからエンドツーエンドのSLIを定義します。
- 間違い： リリースを通すためにSLOの期間を変更したり、障害をカウントから除外したりする。 → 失敗の理由： バジェットの比較可能性が失われ、リスクが隠蔽されます。 → 対策： 現在の期間を維持し、今後の変更には正式なガバナンスプロセスを適用します。
- 間違い： 1回のカナリア成功を完全リリースの証拠として扱う。 → 失敗の理由： 露出規模、依存関係、テールリスクが異なります。 → 対策： 自動ロールバックを備えた上で段階的に拡大します。
フォローアップ質問と回答
フォローアップ1：99.99%はどれくらいのバジェットを表しますか？
指定された期間内で許容されるエラー率は0.01%です。これを分単位に変換するには、対象期間、計算方法、メトリクスがリクエストベースか時間ベースかを確認する必要があります。前提条件なしの数値を提示するのではなく、期間を明記することが重要です。
フォローアップ2：営業が約束した機能は例外として認められますか？
商業的な価値だけでは例外の根拠になりません。ユーザー、収益、コンプライアンスへの影響を示し、分離、カナリア、ロールバック、モニタリングの計画を提示した上で、共同承認を得る必要があります。露出リスクを低減できない場合は、リリースを延期し代替策を提示します。
フォローアップ3：バジェットの計算が間違っている可能性がある場合はどうしますか？
高リスクなリリースを一時停止し、並行してテレメトリのカバレッジ、重複カウント、時間遅延、依存関係の帰属、クライアントサンプリングを調査します。修正後に再計算を行いますが、結果が不確実な間はリスクの露出を拡大してはいけません。
フォローアップ4：SLOはいつ変更すべきですか？
安定稼働時の実績とレビューデータにより、目標がユーザー価値、コスト、チームのケイパビリティと一致していないことが示された場合に変更します。事前に旧目標、新目標、影響、承認者を記録します。障害の発生やリリースのプレッシャーは、アドホックに目標を下げる理由にはなりません。
フォローアップ5：凍結解除のタイミングをどのように判断しますか？
事前に復旧条件を定義しておきます。具体的には、SLIが観察期間中に目標を満たしていること、バジェットが所定のしきい値まで回復していること、根本原因の修正が検証されていること、ロールバックが機能することなどです。その上で、即座に通常速度に戻すのではなく、小さなバッチから再開してモニタリングを継続します。