プロンプトとシナリオ
営業リーダーが契約内の99.9%のSLAを「製品が絶対に障害を起こさない約束」と捉え、エンジニアリングに対してパフォーマンス低下を一切起こさない保証を求めています。SLI、SLO、SLAを平易な言葉で説明し、指標の選び方、誤解の解き方、そしてこれらの用語がリリースや顧客コミュニケーションにどのように影響するかを説明してください。
面接官が見ているポイント
- 抽象的な信頼性の用語を、ユーザージャーニーやビジネス上のコミットメントと結びつけているか。
- パーセンテージを絶対的な保証として扱うのではなく、社内目標、観測されたシグナル、外部との契約の違いを明確に区別できているか。
- エラーバジェットがリリース、一時停止、リスクのトレードオフ判断をどのように支えるかを説明できるか。
- 相手に合わせて説明を調整し、理解度を確認した上で、実行可能な次のステップを設定できるか。
最初に確認すべき明確化の質問
- 99.9%はどのサービス、ユーザージャーニー、時間枠（ウィンドウ）、可用性の定義を対象としており、メンテナンスやサードパーティの依存関係は除外されていますか？
- そのSLAはクレジット（返金・補償）を伴う契約上のコミットメントですか、それとも営業資料に記載された契約外の目標ですか？
- すでにSLIデータ、SLO目標、エラーバジェット、顧客影響レポートは存在しますか？
- 主な懸念事項は、違反リスク、顧客体験、リリース速度、それとも社内リソースの優先順位付けのどれですか？
30秒での回答
まずサービスの対象範囲と99.9%の契約上の意味を確認し、飛行機の定時運航率を例えに使って説明します。SLIは実際に測定された結果、SLOはチームが達成を目指す目標、そしてSLAは範囲、免責事項、そして多くの場合クレジットが定められた顧客との公式なコミットメントです。99.9%は「障害ゼロ」ではなく、定義された期間内に許容される失敗の枠（バジェット）です。このシグナルをユーザーへの影響と残存リスクに変換し、バジェットがリリース、ペースダウン、または一時停止の判断にどう活きるかを説明します。その上で相手に理解した内容を言い直してもらい、担当者と見直しの時期を合意します。
詳細解説
1. 略語ではなく、ユーザージャーニーから始める
サインイン、注文の送信、レポートの閲覧など、どのようなタスクが「利用可能なサービス」とみなされるかを確認します。サーバー側の成功率は、クライアント側のタイムアウトやクリティカルフローの失敗を見逃してしまうことがあるため、SLIは可能な限りユーザーが体感する可用性、レイテンシ、正確性を表すものにする必要があります。まずはタスクと影響を説明し、その後に略語を導入します。
2. 3つの定義で境界を確立する
SLIは、重要なリクエストの成功率やレイテンシ閾値内に収まった割合など、再現性のあるシグナルです。SLOは、30日間で99.9%といった、一定期間におけるそのシグナルの目標です。SLAは、対象範囲、免責事項、事前通知、クレジットなどを定義する顧客やパートナーとの公式なコミットメントです。これらの数値は連動することもありますが、責任、根拠、結果はそれぞれ異なります。
3. パーセンテージをエラーバジェットに変換する
固定期間内において、エラーバジェットとは大まかに言えば許容される失敗の割合です。30日間で99.9%の場合、停止時間は約43分に相当します。これは目安の規模であり、実際の契約上の測定方法に従う必要があります。バジェットが健全な間は、リスク許容範囲内でリリースを進めることができます。消費ペース（バーンレート）が加速したりバジェットが枯渇したりした場合は、リスクの高い変更を一時停止し、復旧・修正を優先します。
4. SLAは「絶対に障害を起こさない」ことではないと説明する
契約は通常、測定方法、免責事項、対象範囲、クレジットを定義するものであり、すべてのリクエストが永久に成功することを約束するものではないと説明します。営業側が対外的な文言を必要としている場合は、社内目標を契約上の約束に置き換えるのではなく、SLO、SLA、ステータスページ、サポートフロー、インシデント通知のタイミングを整合させます。法務、営業、エンジニアリングが共同で免責事項を確認する必要があります。
5. 信頼性をリリース判断に結びつける
リリースレビューでは、エラーバジェットを共通の判断基準（ゲート）として活用できます。健全な間は計画通りにリリースし、消費が異常な場合はバッチサイズを縮小するか、長めに観察するか、一時停止します。枯渇した場合は、文書化された例外が承認されない限り修正を最優先します。信頼性が一方的な拒否権にならないよう、選択肢にはユーザー影響、収益やコミットメントへの影響、復旧時間、ロールバック条件を含める必要があります。
6. 理解度を確認し、継続的にガバナンスを行う
会話の後、相手に3つの定義と現在のリスクを自分の言葉で言い直してもらい、質問や合意事項を記録します。期間ごとに、SLIが依然としてユーザーを適切に代表しているか、SLOが有用な行動を促しているか、SLAが契約と一致しているかを見直します。指標が実際の体験と乖離している場合は、より高いパーセンテージを議論する前に測定方法を修正します。
完全で強力な回答例
99.9%の背景にあるサービス、ユーザージャーニー、時間枠、契約上の境界を確認し、ユーザーのタスクから説明を始めます。SLIは観測可能な結果、SLOは一定期間におけるチームの目標、SLAは範囲、免責事項、クレジットを含む顧客との公式なコミットメントです。例として、30日間で99.9%なら約43分の停止枠という規模を用いつつ、契約上の測定基準に従うことを示します。バジェットが健全ならリリースを進め、消費が異常ならペースを落とすか観察し、枯渇した場合は共同で例外が承認されない限り高リスクな変更を停止します。営業側にこのモデルを言い直してもらい、ステータスやサポートのコミュニケーションを整合させ、メトリクスが本当にユーザーを代表しているかを継続的に見直します。
よくある失敗パターン
- 責任の境界を説明せずに、SLI、SLO、SLAを同義語として扱う。
- 時間枠、範囲、免責事項を無視して、99.9%をいかなる時も障害が起きない約束と呼ぶ。
- 重要なジャーニーやクライアント側の体験を検証せず、サーバー側のメトリクスのみを見る。
- リリース、一時停止、例外判断に結びつけずにエラーバジェットに言及する。
- 理解度を確認したり次のアクションを割り当てたりせずに、相手を略語攻めにする。
フォローアップと発展課題
フォローアップ1：営業から社内SLOを契約に記載したいと言われたらどうするか？
測定方法、範囲、免責事項、事前通知、クレジットを確認した上で、法務、営業、サポート、エンジニアリングが共同でコストとリスクを評価します。社内目標をコミットメントの参考にすることはできますが、契約上の定義と運用能力の検証が依然として必要です。
フォローアップ2：複数のSLIをどのように選択するか？
単一の平均値がクリティカルパスを覆い隠さないように、ユーザージャーニーごとに可用性、レイテンシ、正確性、または鮮度（freshness）を分割します。各SLIについて、データソース、サンプリング、時間枠、欠損データの扱い、およびそれによって生じるアクションを定義します。
フォローアップ3：SLOは達成されているのに顧客から苦情が来る場合はどうするか？
SLIが実際のタスクを測定できているか、特定のリージョン、テナント、クライアント、またはビジネス上の成功条件を見落としていないかを確認します。苦情のサンプルをエンドツーエンドのシグナルと関連付け、SLIの追加や置き換え、および目標の調整を行います。
フォローアップ4：エラーバジェットとクレジット（返金・補償）はどのように関連しているか？
エラーバジェットは社内のリスクおよびリリース管理の仕組みであり、クレジットは契約上のSLA違反に対する結果です。両者は同じインシデント記録を使用する場合がありますが、互いに代替できるものではありません。外部向けのクレジットは契約に基づいて計算し、社内バジェットはエンジニアリングの優先順位付けと変更ペースの管理に使用します。