SRE・可観測性・障害対応 問題集・練習問題クイズ

検索APIの可用性SLIを、利用者体験に最も近い形で定義したい。適切なのはどれですか？

答え： 有効な検索要求のうち、契約どおりの結果を期限内に返した割合

可用性SLIは、利用者が期待する有効な要求のうち、正しく十分速い応答を得られた割合として測ると、内部構成に左右されにくくなります。

30日間で可用性99.9%のSLOを設定した。単純化して許容される失敗時間の目安はどれですか？

答え： 約43分

30日間は43,200分で、0.1%は約43.2分です。実運用では時間基準かRequest基準か、除外条件、集計窓も明示します。

月初の短い障害で30日Error Budgetの40%を消費した。適切な判断はどれですか？

答え： 消費速度と原因を確認し、Release Riskを抑える措置と信頼性改善を優先する

残量だけでなくBurn Rateを見ると、同じ速度が続いた場合のSLO違反を早期判断できます。Policyに沿って変更抑制や改善へ切り替えます。

SLO違反を早期検知しつつ、一時的なSpikeによる誤Pageを減らしたい。適切なAlert条件はどれですか？

答え： 短い窓と長い窓の両方でBurn Rate閾値を超えた場合にPageする

Multi-window Burn Rate Alertは、短い窓の即応性と長い窓の持続性確認を組み合わせ、重大なBudget消費をPage対象にできます。

On-callへPageするAlertとして最も適切なのはどれですか？

答え： 利用者影響が進行中で、即時の人手対応が必要かつ有効なRunbookがある

Pageは緊急性とActionabilityがある症状に限定します。予測や傾向はTicket、情報通知はDashboardなど適切なChannelへ分けます。

Database接続ErrorとAPI 5xxが同時に増えた。最初にPage対象とする考え方はどれですか？

答え： 利用者症状であるAPI成功率低下をPageし、DB指標は原因調査へ関連付ける

症状ベースPageを入口にし、原因候補のDashboardやLinkを付けると、重複Pageを抑えながら影響と診断を結び付けられます。

AlertのSeverityを決める基準として最も適切なのはどれですか？

答え： 利用者・事業影響、緊急度、回避策の有無を定義済み基準へ当てはめる

共通基準でSeverityを決めると、対応資源・通知範囲・更新頻度を一貫して選べます。内部Error量だけでは事業影響を表せません。

HTTP Request Metricへ追加するとCardinality爆発を招きやすいLabelはどれですか？

答え： user_id

MetricはLabel値の組合せごとにTime Seriesを持つため、利用者IDや生URLのような非境界集合は避け、詳細検索はLogやTraceへ寄せます。

Online ServiceのGolden Signalsを素早く確認したい。RED Methodの組合せはどれですか？

答え： Rate・Errors・Duration

REDは要求率、Error率、処理時間を中心にServiceの利用状況と症状を捉えます。資源側の飽和調査にはUSEなどを組み合わせます。

NodeのResource BottleneckをUSE Methodで調べる。確認する組合せはどれですか？

答え： Utilization・Saturation・Errors

USEはCPU・Memory・Disk・Networkなど各資源について使用率、待ち行列や枯渇、Errorを確認し、Bottleneck候補を体系的に探します。

Latency分布を複数Instanceで集約し、全体のp95を求めたい。適切なMetric型はどれですか？

答え： 共通Bucketを持つHistogram

HistogramのBucket CountはInstance間で加算でき、集約分布からQuantileを推定できます。Instance別Quantileの平均は全体Quantileになりません。

Metric上のLatency Spikeから代表的なTraceへ直接移動したい。適切な仕組みはどれですか？

答え： HistogramへTrace ID付きExemplarを関連付ける

Exemplarは集約Metricの観測点へTrace Contextを関連付け、異常Bucketから具体的なRequestのTraceへ遷移できるようにします。

通常時はTraceを10% Samplingしているが、希少なError Traceを残したい。適切な方針はどれですか？

答え： CollectorでTail Samplingし、Errorや高Latency Traceを優先保持する

Tail SamplingはTrace完了後のStatusやLatencyを見て保持判断できます。ただしCollectorのBuffer、遅延、容量と障害時の流量を設計します。

障害調査に使いやすく、機密情報も抑えたApplication Logはどれですか？

答え： 時刻、Level、Service、Event名、Trace ID、非機密の業務識別子を構造化して記録する

構造化Fieldと相関IDにより検索・集計・Trace連携が容易になります。Secretや不要な個人情報はMaskまたは収集対象外にします。

非同期Message処理を元のHTTP RequestのTraceへ関連付けたい。適切なのはどれですか？

答え： Producer ContextをMessageへ伝播し、Consumer Spanで親子関係またはLinkを記録する

Trace ContextまたはSpan LinkをMessage Metadataで伝播すると、Queue待ちを含む因果関係を追跡できます。信頼境界では受信Contextも検証します。

複数HostのLog時刻がずれ、障害Timelineが矛盾して見える。優先すべき対策はどれですか？

答え： 時刻同期を監視し、Event時刻と受信時刻を区別して相関IDでも順序を補う

NTPなどの同期状態自体を監視し、Event発生時刻と収集時刻を保持します。分散処理の因果順序はTraceやMessage IDも併用します。

Service Overview Dashboardの最上段に置く情報として最も有効なのはどれですか？

答え： 主要SLI、SLO状況、Traffic、直近Deploy、依存先Healthへの導線

Overviewは利用者影響と変更点を短時間で把握し、原因調査DashboardへDrill-downできる構造にします。

内部Metricは正常だが、外部利用者からLogin不可の報告がある。追加すると有効な監視はどれですか？

答え： 外部地点から認証Flowを定期実行するSynthetic Monitoring

Synthetic監視はDNS、CDN、TLS、認証画面など外部経路を含む重要Journeyを継続確認し、内部監視の盲点を補います。

実利用者のBrowserで地域別の表示遅延を測りたい。適切なTelemetryはどれですか？

答え： RUMでNavigationやWeb Vitalsを地域・Versionなど境界のある属性で集計する

Real User Monitoringは端末・Network・配信経路を含む実体験を測れます。Privacy、Sampling、属性Cardinalityを設計して集約します。

障害時にTelemetry量が急増し、Collector Queueが満杯になった。設計として適切なのはどれですか？

答え： Collector自身のQueue・Drop・Export失敗を監視し、容量制限と優先度付きSamplingを設ける

観測基盤も容量とFailure Modeを持ちます。ApplicationへのBackpressure、Buffer上限、重要Signalの保持、Drop可視化を明示します。

重大障害で多数のEngineerが同時に変更を始め、状況が悪化している。最初に整えるべき体制はどれですか？

答え： Incident Commanderを明確にし、Ops・Communication・Planningの役割と変更権限を分ける

明示的な指揮と役割分担により、変更競合を防ぎ、技術対応と情報更新を並行できます。未委任の責任はIncident Commanderが保持します。

障害のSeverityを暫定宣言する時点として適切なのはどれですか？

答え： 利用者影響と範囲が基準を満たした時点で暫定宣言し、情報に応じて更新する

Severityは対応体制とCommunicationを起動するための暫定判断です。原因確定を待たず、共通基準と現在のImpactで宣言します。

障害対応中のStakeholder更新として適切なのはどれですか？

答え： Impact、開始時刻、実施中の軽減策、次回更新時刻を定期的に共有する

既知の事実と不明点を分け、次回更新時刻を約束すると、復旧担当への個別問い合わせを減らし信頼を保てます。

決済失敗が拡大中で、原因はまだ不明である。最初の技術目標として適切なのはどれですか？

答え： 安全なRollbackやTraffic制限で影響を封じ込め、並行して証拠を保存する

Incident中は利用者影響の軽減をRoot Cause確定より優先します。ただし不可逆操作を避け、Timeline・Log・変更履歴などの証拠を保持します。

Deploy直後にError率が上がった。Rollback判断を速める準備として最も有効なのはどれですか？

答え： Deploy前にGuardrail Metric、閾値、観測時間、自動停止・Rollback条件を定義する

事前のGuardrailとVersion別Telemetryにより、正常変動とRegressionを共通基準で判定し、Canary停止やRollbackを迅速化できます。

外部推薦Serviceの障害で画面全体が失敗している。Feature Flagの使い方として適切なのはどれですか？

答え： 推薦機能だけを無効化するKill Switchを用意し、基本画面を縮退提供する

機能単位のKill Switchで非必須依存を切り離すと、Core Journeyを維持できます。権限、Audit、Default値、期限切れFlagの削除も管理します。

実用的なRunbookに含める内容として最も適切なのはどれですか？

答え： Trigger、影響確認、権限付き診断手順、安全な軽減策、検証、Escalation、Rollback

Runbookは圧力下でも安全に実行でき、各Stepの期待結果と中止条件を示す必要があります。定期演習で有効性と権限を確認します。

一次On-callが15分調査しても影響を軽減できない。適切なEscalationはどれですか？

答え： 定義済み時間・影響基準に従い、Service OwnerやIncident CommanderへContext付きでEscalateする

Escalationは失敗ではなく、時間と専門性を適切に投入する仕組みです。Impact、仮説、実施済み操作、結果、必要な支援を渡します。

障害Timelineを正確に残す運用として適切なのはどれですか？

答え： Alert、判断、Command、変更、観測結果を時刻と実行者付きで共有記録へ追記する

Live Incident Documentへ事実と判断を逐次残すと、交代・並行作業・Postmortemで共通の時系列を使えます。

Incident Commanderを別地域の担当へ交代する。安全なHandoffはどれですか？

答え： Live Documentを用いて口頭確認し、新担当の明示的な受諾を全体へ通知する

明示的な受諾と全体通知により、常に一人の指揮者と共通状態を保ちます。Impact、変更、仮説、Risk、次Actionを引き継ぎます。

Blameless Postmortemで避けるべき記述はどれですか？

答え： 担当者が注意不足だったことだけをRoot Causeとし、仕組みの改善を終える

個人非難で終えると、同じ条件で別の人も失敗します。設計、Tool、Review、権限、負荷など再現可能な条件と防御改善を扱います。

PostmortemのAction Itemとして最も実行可能なのはどれですか？

答え： Owner、期限、完了条件、追跡Ticketを持つ具体的な防止・検知改善

Actionは追跡可能で効果を検証できる粒度にします。項目を増やしすぎず、再発可能性とImpactを下げる高価値対策へ絞ります。

冗長系が自動切替に成功し利用者影響がなかったNear Missをどう扱うべきですか？

答え： 防御が機能した事実と余裕、次回失敗し得る条件を分析して学習対象にする

Near Missは利用者被害なしで弱点を学べる機会です。防御層が意図どおりか、Capacityや復旧時間に余裕があったかを確認します。

Error率が平常へ戻った直後にIncidentをCloseしてよいか判断する。必要な確認はどれですか？

答え： 主要SLIの安定、Backlog解消、Data整合性、縮退解除、再発監視を一定時間確認する

RecoveryはError停止だけでなく、遅延作業・整合性・Capacity・暫定措置を含めて安定状態へ戻ったことを確認します。

Primary DB障害後のFailoverで旧Primaryが書込みを再開し、Split Brainの恐れがある。必要な対策はどれですか？

答え： 旧PrimaryをFenceし、GenerationやLeaseで新Primaryだけに書込み権限を与える

FailoverはRoutingだけでなく旧Writerを確実に排除する必要があります。Fencing TokenやSTONITH、Lease世代で古い権限を拒否します。

Backup Jobは毎日成功している。復旧可能性を保証する次の確認はどれですか？

答え： 隔離環境で定期Restore Drillを行い、整合性と実測RTO・RPOを確認する

Backup成功はRestore成功を意味しません。暗号鍵、権限、手順、依存Data、整合性、所要時間を実際の復元で検証します。

通常時CPU 45%だが、Trafficが2倍になるEventを予定している。Capacity判断として適切なのはどれですか？

答え： Load TestでService Time・Concurrency・依存先上限を測り、障害余力を含むHeadroomを確保する

CPUだけでなくDB接続、Queue、Rate Limit、Scale速度、N+1障害時を含めてHeadroomを検証します。非線形な飽和は実負荷試験で確認します。

外部Address Validation APIが停止した。注文受付を安全に継続する縮退策はどれですか？

答え： 入力形式を最低限検証して保留状態で受付け、復旧後に再検証する

業務上許される場合、状態を明示したDeferred ValidationでCore Flowを維持できます。再処理、期限、利用者通知、重複防止を設計します。

障害開始時刻の直前に複数のDeployと設定変更があった。切分けとして適切なのはどれですか？

答え： 変更Eventを共通Timelineへ重ね、Version・対象範囲・Control Groupごとの差を比較する

変更は有力な仮説ですが、時刻一致だけで因果とは限りません。Version別Telemetryや未変更群と比較し、一変更ずつ結果を記録します。

Game Dayを本番相当環境で実施する目的と進め方として適切なのはどれですか？

答え： 復旧仮説と成功条件を定め、限定したFailureを注入して人・手順・Telemetryを検証する

Game Dayは仮説駆動の演習です。Blast Radius、停止条件、責任者、Rollbackを事前に定め、検出・連絡・復旧・検証のGapをActionへ変えます。