クイズの説明
Step 4「アラート設計とオンコールを整備しよう」の理解度を確認します。全6問、80%以上正解で合格です。
問題
Q1. アラート疲れ（Alert Fatigue）を防ぐために最も効果的な手法はどれですか？
- A) 全てのメトリクスにアラートを設定する
- B) アクション可能なアラートのみに絞り、適切な閾値を設定する
- C) アラートの通知先を1人に集中させる
- D) アラートの通知頻度を下げる
答えを見る
正解: B
アラート疲れを防ぐには、「このアラートを受け取った人が具体的なアクションを取れるか」を基準にアラートを設計します。情報提供だけのアラートはダッシュボードに表示し、通知は本当に対応が必要なものだけに絞ります。
Q2. オンコールローテーションの適切な設計として正しいものはどれですか？
- A) 最も経験豊富なエンジニア1人が常にオンコールを担当する
- B) チーム全員で均等にローテーションし、十分な引き継ぎ期間を設ける
- C) オンコールは不要で、業務時間内のみ対応する
- D) 外部ベンダーに全てのオンコールを委託する
答えを見る
正解: B
オンコールは特定の人に負荷が集中しないよう均等にローテーションし、引き継ぎ時に前シフトの状況を共有することが重要です。バーンアウトの防止と知識の分散が目的です。
Q3. ランブックに含めるべき内容として最も重要なものはどれですか？
- A) チームメンバーの趣味
- B) 具体的な診断手順、対応アクション、エスカレーション基準
- C) 会社の沿革
- D) 使用しているツールのライセンス情報
答えを見る
正解: B
ランブックは、アラート発生時に「何を確認し」「どう対応し」「いつエスカレーションするか」を具体的に記述したドキュメントです。深夜のオンコールでも迷わず対応できる具体性が求められます。
Q4. カオスエンジニアリングの正しい実施順序はどれですか？
- A) 本番で障害を注入 → 結果を観察 → 仮説を立てる
- B) 定常状態の仮説を立てる → 変数を注入 → 仮説の検証
- C) テスト環境で実験 → 結果が良ければ本番に適用
- D) 障害が起きてから分析する
答えを見る
正解: B
カオスエンジニアリングは科学的方法に従います。まず正常時の挙動（定常状態）を仮説として定義し、現実世界の事象（サーバー停止、ネットワーク遅延等）を注入し、仮説通りにシステムが振る舞うかを検証します。
Q5. 症状ベース（Symptom-based）アラートの例として適切なものはどれですか？
- A) CPU使用率が80%を超えた
- B) ユーザーから見たレスポンスタイムが500msを超えた
- C) ディスク使用率が70%を超えた
- D) メモリ使用率が90%を超えた
答えを見る
正解: B
症状ベースアラートは、ユーザーが体験する症状（レスポンスタイム、エラーレート等）に基づきます。原因ベース（CPU、メモリ等）よりもユーザー影響に直結するため、より効果的なアラートとなります。
Q6. Chaos Monkeyの起源として正しいものはどれですか？
- A) Google（2008年）
- B) Netflix（2010年）
- C) Amazon（2012年）
- D) Facebook（2015年）
答えを見る
正解: B
Chaos MonkeyはNetflixが2010年にAWSへの移行時に開発したツールです。本番環境でランダムにサーバーを停止させ、システムの回復力を検証しました。カオスエンジニアリングの先駆けとなりました。
結果
5問以上正解の場合
合格です。 アラート設計とオンコールの概念を理解しています。Step 5に進みましょう。
4問以下の場合
もう少し復習しましょう。 アラート設計の原則、オンコール体制、ランブック、カオスエンジニアリングを確認してください。