WEB問題集
SRE チームが新規サービスの SLO を定義しようとしています。サービスは Web API で、ユーザはレスポンス速度と可用性を重視します。最初に決定すべき指標として、もっとも適切なものはどれですか。
解説
正解の根拠
SLI はユーザが実際に受け取ったサービス品質を測る指標で、SLO はその SLI に対する目標値です。レスポンス速度と可用性を重視する Web API では、リクエスト成功率 (エラー率の裏返し) とレイテンシ分布 (p95 や p99) がユーザ体験を直接表すため、まずこの 2 つを SLI として定義し、その上で目標値と測定期間を決めます。ユーザ体験に紐づく指標を起点にすると、SLO 違反がそのまま顧客影響を意味するようになり、エラーバジェットの消費に基づくリリース判断や信頼性投資の優先順位付けが機能します。
選択肢比較
| 候補指標 | 測っているもの | SLI 適性 |
|---|---|---|
| 正解 (C) リクエスト成功率・レイテンシ | ユーザが受け取った品質 | 高い |
| A デプロイ頻度 | 開発プロセスの速度 (DORA 指標) | 不適 |
| B CPU・メモリ・ディスク IO | インフラの内部状態 | 不適 (原因分析用) |
| D 過去のインシデント件数 | 事後の集計値 | 不適 |
不正解の理由
- A: デプロイ頻度は DORA の開発生産性指標で、リリースの速さを表すものです。ユーザが体感する応答速度や可用性とは連動しません。
- B: CPU やメモリの使用率が正常でもユーザ側でエラーや遅延が起きるため、インフラ指標は体験の代理にならず、原因調査用の補助指標にとどまります。
- D: 過去のインシデント件数は事後に人が数える集計値で、連続的に測ってエラーバジェットを算出する用途には使えません。
Toil の特徴として SRE 本で定義されているものを 2 つ選択してください。
解説
正解の根拠
Toil は SRE 本で、本番サービスの運用に伴う「手作業で、繰り返しがあり、自動化可能で、戦術的かつ受動的で、長期的な価値を生まず、サービスの規模に比例して増える作業」と定義されます。A の手作業かつ繰り返しという性質と、B のこなしても恒久的な改善が残らないという性質は、いずれもこの定義そのものです。Toil が問題視されるのは、実行しても仕組みが改善されないためサービスが伸びるほど工数が線形に増え、エンジニアリングに使える時間を圧迫するからで、自動化や設計変更によって削減する対象と位置づけられます。
選択肢比較
| 選択肢 | SRE 本の Toil 定義との対応 | 判定 |
|---|---|---|
| A: 手作業であり繰り返し行われる | manual / repetitive に一致 | 該当 (正解) |
| B: 長期的な価値を生み出さない | no enduring value に一致 | 該当 (正解) |
| C: 高度な創造性を要する | 創造的作業はエンジニアリング | 非該当 |
| D: 自動化が技術的に不可能である | 定義は automatable (自動化可能) | 非該当 |
不正解の理由
- C: 高度な創造性や設計判断を要する作業は、恒久的な改善を残すエンジニアリング作業に分類され、繰り返しで価値が残らないという Toil の条件に当てはまりません。
- D: Toil は自動化が可能でありながら人手で回している作業を指します。自動化不可能であることは条件ではなく、むしろ削減余地があることが前提です。
参考：Google SRE Book - Toil ／ DevOps 能力 (Google Cloud アーキテクチャ センター)
SLO を 99.9% に設定したサービスで、月間エラーバジェットはおおよそ何分になりますか。30 日間の運用を前提とします。
解説
正解の根拠
エラーバジェットは 1 から SLO を引いた許容不良割合を対象期間に適用した値です。SLO が 99.9% なら許容割合は 0.1% であり、30 日は 30 × 24 × 60 = 43200 分ですから、43200 × 0.001 = 43.2 分が月間のバジェットになります。この値は期間の長さに比例するため、同じ 99.9% でも 7 日間の窓であれば約 10 分、90 日間なら約 130 分と変わります。バーンレート アラートはこの残量に対する消費速度で設定します。
選択肢比較
| 選択肢 | 値 | 対応する許容割合 |
|---|---|---|
| A | 約 4.3 分 | 0.01%（SLO 99.99%） |
| B | 約 432 分 | 1%（SLO 99%） |
| C（正解） | 約 43.2 分 | 0.1%（SLO 99.9%） |
| D | 約 4320 分 | 10%（SLO 90%） |
不正解の理由
- A: 43200 分の 0.01% にあたる値で、SLO が 99.99% の場合の月間バジェットです。99.9% では 1 桁小さすぎます。
- B: 43200 分の 1% にあたり、SLO 99% に対応します。許容割合を 0.1% ではなく 1% と取り違えた値です。
- D: 43200 分の 10% で SLO 90% 相当となり、月の 3 日分の停止を許すことになるため妥当ではありません。
エラーバジェットが急速に消費されている状況で SRE チームが取るべきアクションとして適切なものはどれですか。
解説
正解の根拠
エラーバジェットが急速に消費されている状態は、今のリリース速度と品質のままではウィンドウ内に SLO を割ることを示します。エラーバジェット ポリシーでは、この段階で開発の優先順位を新機能から信頼性向上へ切り替え、必要ならリリースを一時凍結すると事前に合意しておきます。凍結中に原因となった不具合の修正、監視やロールバック手順の整備といった投資を行えば消費速度が下がり、バジェットが回復してから通常のリリース速度に戻すという判断を、担当者の裁量に頼らず客観的に下せます。
選択肢比較
| 選択肢 | バジェットへの作用 | 妥当性 |
|---|---|---|
| A リリース継続 | 消費をさらに加速 | 不適切 |
| B SLO を事後に緩和 | 数値上だけ改善 | アンチパターン |
| C 監視を停止 | 消費は続き可視化を喪失 | 不適切 |
| D（正解）信頼性投資 + リリース凍結 | 消費速度を下げる | ポリシーどおり |
不正解の理由
- A: 消費が加速している最中に変更を入れ続けると、新たな障害要因を積み増してバジェットの枯渇を早め、SLO 違反が確定します。
- B: SLO を後から緩めるのはユーザー体験を変えずに数値だけ取り繕う行為で、指標が意思決定の基準として機能しなくなります。
- C: 監視を止めれば通知は減りますが、劣化が見えなくなるだけで実際の消費は続き、検知の遅れが影響をさらに広げます。
Postmortem (ポストモーテム) の作成において SRE 文化として推奨される姿勢はどれですか。
解説
正解の根拠
ポストモーテムの目的は、責任者を特定することではなく、システムとプロセスの弱点を組織の学習に変えることです。Blameless (非難しない) を原則にすると、対応者は判断の根拠やその時点で見えていた情報を率直に書けるため、真因と、検知や復旧を遅らせた要因が正確に記録されます。人を責める運用にすると報告が遅れ、都合の悪い事実が省かれ、同じ欠陥が別のシステムで再発します。記録された事実は担当者と期限のついた Action Items に変換され、次の設計判断の材料になります。したがって学習に焦点を当てる C が SRE 文化として推奨される姿勢です。
選択肢比較
| 選択肢 | 姿勢 | 学習への影響 |
|---|---|---|
| A | 他チームへ共有しない | 横断的な再発防止が働かない |
| B | 担当者の責任追及 | 報告が萎縮し事実が欠落 |
| C (正解) | Blameless で学習に集中 | 真因と改善策が残る |
| D | 短時間復旧なら省略 | 幸運による復旧を検証できない |
不正解の理由
- A: 社内秘にすると、同じ設計や依存関係を持つ他チームが同じ障害を繰り返します。ポストモーテムは横断的に共有して初めて再発防止の効果が広がります。
- B: 責任追及は報告の萎縮と事実の隠蔽を招きます。多くの障害は人ではなく仕組みの欠陥に起因するため、担当者に対策を課しても再発は止まりません。
- D: 短時間で復旧できたのは幸運や属人的な対応によることが多く、そこにこそ学びがあります。基準に該当する事象は復旧時間にかかわらず記録します。