QUIZ 30分

ストーリー

高
高橋アーキテクト
Month 7の最終試験だ。オブザーバビリティとSREの全範囲から出題する

高橋アーキテクトが最後のクイズを用意した。

高
高橋アーキテクト
全8問、80%（7問正解）で卒業だ。自信を持って答えてほしい。ここまで来た君なら大丈夫だ

クイズの説明

Month 7 全体で学んだ内容の総合的な理解度をチェックします。

  • 全8問
  • 合格ライン: 80%（7問正解）
  • 不合格の場合は該当セクションを復習してから再挑戦してください

問題

Q1. 本番環境で「APIレスポンスタイムが遅い」という報告があった場合、最初に確認すべきオブザーバビリティデータの順序として最も効率的なものはどれですか？

  • A) ログ → メトリクス → トレース
  • B) メトリクス → トレース → ログ
  • C) トレース → ログ → メトリクス
  • D) ログ → トレース → メトリクス
解答と解説

正解: B

最も効率的な順序は「メトリクス → トレース → ログ」です。まずメトリクスで影響範囲と重要度を把握し（どのエンドポイント？いつから？どの程度？）、次にトレースで遅延の原因箇所を特定し（どのサービスのどの処理が遅い？）、最後にログでエラーの詳細を確認します。

Q2. OpenTelemetry Collectorの主な役割として最も適切なものはどれですか？

  • A) アプリケーションコードの自動テスト
  • B) テレメトリデータの受信、処理、バックエンドへの送信
  • C) Webアプリケーションのホスティング
  • D) データベースのバックアップ管理
解答と解説

正解: B

OpenTelemetry Collectorは、アプリケーションからテレメトリデータ（ログ、メトリクス、トレース）を受信し、バッチ処理やフィルタリングなどの処理を行い、Jaeger、Prometheus、Elasticsearchなどの各バックエンドに送信するコンポーネントです。

Q3. 構造化ログにtraceIdを含める最大の理由はどれですか？

  • A) ログファイルのサイズを削減するため
  • B) 複数サービスを横断する1つのリクエストのログを紐づけて追跡するため
  • C) ログの出力速度を向上させるため
  • D) ログレベルを自動的に判定するため
解答と解説

正解: B

traceIdをログに含めることで、分散システムにおいて1つのリクエストが複数サービスを横断する際の全ログを紐づけて取得できます。これにより、ログ検索でtraceId = "abc123"と指定するだけで、そのリクエストに関連する全サービスのログを時系列で確認できます。

Q4. PromQLで「直近5分間のHTTPエラー率（%）」を計算する正しい式はどれですか？

  • A) http_requests_total{status=~"5.."} / http_requests_total * 100
  • B) rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) * 100
  • C) count(http_requests_total{status=~"5.."}) * 100
  • D) sum(http_requests_total{status=~"5.."}) - sum(http_requests_total)
解答と解説

正解: B

Counterメトリクスの割合を計算するには、分子と分母の両方にrate()を適用する必要があります。rate(http_requests_total{status=~"5.."}[5m])で5分間のエラーリクエスト率を求め、rate(http_requests_total[5m])で全リクエスト率を求め、その割合に100を掛けてパーセンテージにします。

Q5. 分散トレーシングにおいて、以下のウォーターフォールから読み取れるボトルネックパターンはどれですか？

[Order Service]  ━━━━━━━━━━━━━━━━━━━━  800ms
  ├─[DB: get user]     ━━  30ms
  ├─[DB: get items]    ━━  30ms
  ├─[DB: get pricing]  ━━  30ms
  ├─[DB: get shipping] ━━  30ms
  └─[DB: save order]   ━━  30ms
  • A) N+1問題
  • B) 外部API遅延
  • C) シーケンシャル呼び出し（並列化可能）
  • D) メモリリーク
解答と解説

正解: C

このウォーターフォールでは、独立した5つのDBクエリが直列に実行されています（各30ms × 5 = 150ms）。get user、get items、get pricing、get shippingは互いに依存関係がないため、Promise.allで並列実行すれば、150msから30msに短縮できる可能性があります。N+1問題は「同じ種類のクエリがN回」、ここでは異なる種類のクエリです。

Q6. SLO 99.9%のサービスで、月初から15日間で既にエラーバジェットの60%を消費している場合、SREとして最も適切な判断はどれですか？

  • A) SLOの目標値を99.5%に下げる
  • B) 新機能リリースを制限し、信頼性改善タスクを優先する
  • C) エラーバジェットの計算期間を60日に延長する
  • D) アラートの閾値を上げてアラートを減らす
解答と解説

正解: B

月の半分でエラーバジェットの60%を消費している場合、このペースが続けば月末にはバジェットを使い切ります。この状況では新機能リリースを制限し、信頼性改善タスク（バグ修正、パフォーマンス改善、自動復旧の強化等）を優先すべきです。SLOの目標を下げるのはビジネス判断であり、安易に変更すべきではありません。

Q7. カオスエンジニアリングの実験で「Payment Serviceの50%のPodを停止」した結果、Order Serviceが全面停止した場合、最も優先度が高い改善策はどれですか？

  • A) Payment Serviceのレプリカ数を増やす
  • B) Order Serviceにサーキットブレーカーとフォールバックを実装する
  • C) カオス実験を中止する
  • D) Payment Serviceのリソース上限を引き上げる
解答と解説

正解: B

Payment Serviceの部分障害がOrder Service全面停止を引き起こしたのは、Order ServiceがPayment Serviceの障害を適切にハンドリングできていないことが根本的な問題です。サーキットブレーカーを導入してPayment Service障害時に早期にエラーを返し、フォールバック（後で決済を再試行する等）を実装することで、カスケード障害を防止できます。

Q8. 以下のインシデント対応のうち、Blamelessポストモーテムの原則に反しているものはどれですか？

  • A) 「設定変更のバリデーションチェックが不足していた」
  • B) 「デプロイパイプラインにステージングテストが含まれていなかった」
  • C) 「田中さんがマニュアルを読まずに操作した」
  • D) 「監視ダッシュボードにPayment Serviceのメトリクスが含まれていなかった」
解答と解説

正解: C

「田中さんがマニュアルを読まずに操作した」は個人を非難する表現であり、Blamelessの原則に反しています。Blamelessポストモーテムでは、「なぜマニュアルを読まなくても誤操作を防げる仕組みがなかったのか」という、システムやプロセスの問題に焦点を当てるべきです。

結果

7問以上正解の場合

合格です。おめでとうございます！

Month 7「システムの脈拍を見守ろう」を完了しました。

あなたは以下のスキルを身につけました：

  • オブザーバビリティの3本柱（ログ・メトリクス・トレース）を活用した障害調査
  • 構造化ログの設計と効率的な検索・分析
  • Prometheus/Grafanaを使ったメトリクス収集と可視化
  • 分散トレーシングによるパフォーマンスボトルネックの特定
  • SLI/SLO/SLAに基づく信頼性の定量管理
  • SREの原則に基づいたインシデント管理と継続的改善

6問以下の場合

もう少し復習しましょう。

間違えた問題の内容を、該当するセクションで復習してください：

問題復習セクション
Q1Step 1: オブザーバビリティの世界
Q2Step 1: OpenTelemetryの全体像
Q3Step 2: 構造化ログの基本
Q4Step 3: Prometheusによるメトリクス収集
Q5Step 4: パフォーマンスボトルネックの特定
Q6Step 5: SREの原則
Q7Step 5: カオスエンジニアリング
Q8Step 5: ポストモーテムと継続的改善

Month 7 完了

お疲れさまでした。

Month 7 で学んだこと

Stepテーマ主要な学び
Step 1オブザーバビリティの世界3本柱、OpenTelemetry、SLI/SLO/SLA
Step 2構造化ログの設計JSON構造化ログ、ログ集約、デバッグ手法
Step 3メトリクスとアラート設計Prometheus、Grafana、アラート疲れ回避
Step 4分散トレーシングSpan、Context Propagation、ボトルネック特定
Step 5信頼性設計とSREエラーバジェット、インシデント管理、カオスエンジニアリング
Step 6総合演習本番障害の原因特定、ポストモーテム

高橋アーキテクトからのメッセージ

「おめでとう。君はもう”システムの脈拍”を見守れるエンジニアだ。ログ、メトリクス、トレースという3つの目でシステムを見つめ、SREの原則で信頼性を設計できる。

でも忘れないでほしい。オブザーバビリティは”入れて終わり”じゃない。チームの文化として根付かせ、常に改善し続けることが大切だ。次のステップでも、今月学んだことを活かしていこう」

推定所要時間: 30分