Examkin

Soru

Zorluk: ZorDefining and Managing SLOs, SLIs, and Error Budgets

A digital banking SaaS platform operates a critical payment authorization API deployed on Google Kubernetes Engine (GKE). The service has an availability Service Level Objective (SLO) defined as a 99.95%99.95\% successful request rate measured over a rolling 30-day window. SRE engineers observed two recurring operational problems: slow, progressive budget consumption going undetected until the 30-day budget was completely exhausted, and transient 2-minute error spikes triggering high-priority pages that resolved prior to engineer intervention. The SRE team needs to establish an alerting strategy in Cloud Monitoring that reliably detects significant error budget consumption while eliminating alert fatigue from transient spikes. Which alerting implementation should the SRE team configure?

  1. Configure multi-window, multi-burn-rate alerts in Cloud Monitoring that page when both short-lookback (1-hour) and long-lookback (6-hour) windows simultaneously exceed a 14.4×14.4\times burn-rate threshold.Cevap
  2. B
    Configure a static metric threshold alert in Cloud Monitoring to page the on-call engineer whenever the HTTP 5xx error rate exceeds 0.05%0.05\% over a 5-minute evaluation interval.
  3. C
    Configure alerts based on GKE cluster node CPU and memory utilization thresholds exceeding 85%85\% for more than 10 minutes to infer service availability impact before error budgets are consumed.
  4. D
    Configure a single-window alert across the entire rolling 30-day window that pages the SRE team whenever accumulated error budget consumption reaches 50%50\%.

Cevap

The SRE team should implement multi-window, multi-burn-rate alerting in Cloud Monitoring using short-lookback (1-hour) and long-lookback (6-hour) windows to measure budget consumption rate accurately without noise.
According to Google SRE best practices, multi-window multi-burn-rate alerts evaluate error budget consumption rates across both short lookback windows (to ensure rapid response and quick alert reset) and long lookback windows (to ensure the error burn rate is sustained before paging). This dual-window requirement eliminates false alerts caused by transient spikes while ensuring critical outages that consume budget rapidly are flagged immediately.

Adım Adım Çözüm

1
Analyze the operational requirements for alerting on SLOs
Identified two requirements: detect sustained/significant error budget consumption quickly, and avoid alerting on transient spikes.
Static threshold alerts and single-window alerts fail to balance alerting speed with alert precision.
2
Evaluate Google Site Reliability Engineering (SRE) best practices for SLO alerting
Multi-window, multi-burn-rate alerting requires both short (e.g., 1-hour) and long (e.g., 6-hour) windows to exceed the burn rate threshold (e.g., 14.4×14.4\times burn rate consumes 2%2\% of error budget in 1 hour).
Requiring the burn rate to be sustained across both windows prevents transient spikes (which clear quickly from the 1-hour window) from paging engineers, while ensuring rapid detection of real outages.
3
Compare against incorrect distractor options
Static metrics, CPU alerts, and single 30-day window alerts either create alert fatigue or fail to catch critical burn events in time.
SLI/SLO management requires measuring actual user-impacting error budget consumption rates rather than raw resource consumption or fixed short static thresholds.

Anahtar Kavram

Multi-Window, Multi-Burn-Rate Alerting on Error Budgets
Bu soruyu puanla

Konular

Defining and Managing SLOs, SLIs, and Error Budgets

Bu konudan daha fazla soru