ストーリー
高橋アーキテクトがクイズを用意してくれた。
クイズの説明
Step 5 で学んだ内容の理解度をチェックします。
- 全8問
- 合格ライン: 80%（7問正解）
- 不合格の場合は復習してから再挑戦してください
問題
Q1. SREにおけるエラーバジェットの説明として最も適切なものはどれですか？
- A) エラー修正にかけられる開発工数の上限
- B) SLOで許容されるエラーの量であり、リリース判断の基準になる
- C) テストカバレッジの目標値
- D) アラートの最大発火数
解答と解説
正解: B
エラーバジェットは「SLO目標を達成しながら許容できるエラーの量」です。例えばSLO 99.9%の場合、月間0.1%（約43分）のダウンタイムが許容されます。エラーバジェットが残っていればリリースを推進し、使い切りそうなら信頼性改善を優先するという判断基準になります。
Q2. SREにおけるToil（トイル）の定義として正しいものはどれですか？
- A) バグ修正に費やす時間
- B) 手作業で反復的、自動化可能で、長期的な価値がない作業
- C) コードレビューにかかる時間
- D) チームミーティングの時間
解答と解説
正解: B
Toilは「手作業で、反復的で、自動化可能で、戦術的で、長期的な価値がない作業」と定義されます。SREの目標は、Toilを作業時間の50%以下に抑え、残りの時間をエンジニアリング（自動化、システム改善）に使うことです。
Q3. インシデント対応において最優先すべきことはどれですか？
- A) 根本原因の特定
- B) ポストモーテムの作成
- C) サービスの復旧（暫定対応）
- D) 詳細なログの収集
解答と解説
正解: C
インシデント対応では、まずサービスの復旧（暫定対応）を最優先にします。ロールバック、フェールオーバー、トラフィック制限などでユーザーへの影響を最小化することが最も重要です。根本原因の特定やポストモーテムは、サービス復旧後に行います。
Q4. カオスエンジニアリングの正しい進め方の順序はどれですか？
- A) 障害注入 → 仮説立案 → 結果確認
- B) 定常状態の仮説を立てる → 障害を注入 → 定常状態が維持されるか確認
- C) ログ収集 → アラート設定 → テスト実行
- D) 本番デプロイ → モニタリング → 障害報告
解答と解説
正解: B
カオスエンジニアリングは「定常状態の仮説を立てる」→「実世界のイベントを反映する変数（障害）を注入する」→「定常状態が維持されるか確認する」という順序で進めます。仮説なしに障害を注入するのは実験ではなく、ただの破壊行為です。
Q5. Blameless（非難なし）ポストモーテムの原則として正しいものはどれですか？
- A) 障害の責任者を特定し、再発防止を約束させる
- B) 人ではなくシステムとプロセスの弱点に焦点を当てる
- C) インシデントの詳細を公開しない
- D) 技術的な詳細は省略し、概要のみ記録する
解答と解説
正解: B
Blamelessポストモーテムでは、「なぜAさんがミスをしたのか」ではなく「なぜこのミスを防げる仕組みがなかったのか」に焦点を当てます。人を非難するのではなく、システムとプロセスの改善に集中することで、心理的安全性を保ちながら真の再発防止策を導き出せます。
Q6. エラーバジェットの残量が10%未満の場合、推奨されるアクションはどれですか？
- A) 通常どおりリリースを継続する
- B) リリース頻度を半分にする
- C) 新機能リリースを凍結し、信頼性改善に全力を注ぐ
- D) SLOの目標値を下げる
解答と解説
正解: C
エラーバジェットの残量が10%未満の場合、新機能のリリースを凍結し、セキュリティパッチとクリティカルバグ修正のみ許可するのが推奨されます。チーム全体で信頼性の改善に注力し、エラーバジェットを回復させてからリリースを再開します。
Q7. 5 Whys（なぜなぜ分析）の目的として正しいものはどれですか？
- A) 5人の担当者を特定する
- B) 表面的な原因から根本原因にたどり着く
- C) 5つのアクションアイテムを作成する
- D) 5つのサービスの問題を同時に分析する
解答と解説
正解: B
5 Whysは「なぜ？」を繰り返し問いかけることで、表面的な原因から根本原因にたどり着く分析手法です。例えば「なぜ決済が失敗した？→なぜAPIが400を返した？→なぜリクエスト形式が変わった？→なぜ変更に気づけなかった？→なぜレビュープロセスがなかった？」のように掘り下げます。
Q8. SREのカナリアリリースにおいて、ロールバックの判断基準として最も適切なものはどれですか？
- A) デプロイから一定時間が経過した場合
- B) 開発者がコード変更に不安を感じた場合
- C) SLOに基づくメトリクスが閾値を超えた場合
- D) テストカバレッジが目標を下回った場合
解答と解説
正解: C
カナリアリリースのロールバック判断は、SLOに基づくメトリクス（エラー率、レイテンシP99等）が閾値を超えた場合に行うのが最も適切です。客観的なデータに基づく判断により、人間の主観に依存しない自動的なロールバックも実現できます。
結果
7問以上正解の場合
合格です。おめでとうございます。
Step 5「信頼性設計とSRE」を完了しました。 次は Step 6「最終試験：オブザーバビリティチャレンジ」に進みましょう。
6問以下の場合
もう少し復習しましょう。
間違えた問題の内容を、該当するセクションで復習してください：
| 問題 | 復習セクション |
|---|---|
| Q1 | step5_1 SREの原則 |
| Q2 | step5_1 SREの原則 |
| Q3 | step5_2 障害対応とインシデント管理 |
| Q4 | step5_3 カオスエンジニアリング |
| Q5 | step5_4 ポストモーテムと継続的改善 |
| Q6 | step5_1 SREの原則 |
| Q7 | step5_4 ポストモーテムと継続的改善 |
| Q8 | step5_1 SREの原則 |
Step 5 完了
お疲れさまでした。
学んだこと
- SREの原則（エラーバジェット、Toil削減、段階的リリース）
- インシデント対応フローとオンコール体制
- カオスエンジニアリングの実践方法
- Blamelessポストモーテムと継続的改善
次のステップ
Step 6: 最終試験：オブザーバビリティチャレンジ（2時間）
全ステップで学んだ知識を総動員して、本番障害の原因を特定しましょう。
推定所要時間: 30分