Examkin

Soru

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

A retail enterprise operates a high-throughput checkout fraud scoring service deployed on Google Cloud Run backed by Cloud Firestore. The service has a defined availability Service Level Objective (SLO) of 99.9%99.9\% successful HTTP requests over a rolling 3030-day period. During flash sales, brief traffic spikes trigger transient CPU utilization spikes and temporary latency fluctuations that quickly self-heal without breaching the monthly SLO, yet they trigger frequent urgent page alerts for the operations team. The Site Reliability Engineering (SRE) team needs to reduce alert fatigue while ensuring they are promptly notified before significant portions of the error budget are consumed by genuine outages. Which alerting architecture should the team implement?

  1. Implement multi-window, multi-burn-rate alerts that trigger based on the rate of error budget consumption over short and long time windows.Cevap
  2. B
    Increase the static CPU utilization alert threshold on the Cloud Run instances to 95% with a 15-minute evaluation period.
  3. C
    Configure static metric threshold alerts on backend Cloud Firestore connection latency and pool saturation.
  4. D
    Redefine the Service Level Indicator (SLI) metric to track infrastructure container instance restarts instead of HTTP status codes.

Cevap

Implement multi-window, multi-burn-rate alerts that trigger based on the rate of error budget consumption over short and long time windows.
Implementing multi-window, multi-burn-rate alerting is the SRE standard recommendation on GCP. It measures the consumption speed of the error budget across multiple time horizons. High burn rates over short windows detect critical incidents fast, while moderate burn rates over larger windows catch subtle sustained errors, effectively filtering out transient spikes that do not threaten the rolling 3030-day SLO.

Adım Adım Çözüm

1
Analyze the operational problem.
The current static alerting strategy causes alert fatigue because transient spikes trigger pages even when the overall 3030-day 99.9%99.9\% SLO is not at risk.
Static threshold alerts evaluate raw metrics over brief periods without accounting for total allowable downtime (error budget).
2
Evaluate SRE best practices for alert design on Google Cloud.
Error budget burn-rate alerting measures how quickly an incident is consuming the remaining error budget.
Multi-window, multi-burn-rate alerting combines fast-burn short windows (for severe outages requiring quick intervention) and slow-burn longer windows (for persistent minor errors), eliminating false-positive pages caused by brief self-healing spikes.
3
Identify the correct option aligning with Google SRE practices.
Selecting burn-rate alerting based on error budget consumption.
It directly protects the SLO and prevents alert fatigue.

Anahtar Kavram

Multi-window, multi-burn-rate alerting for SLO error budget management
Bu soruyu puanla

Konular

Defining and Managing SLOs, SLIs, and Error Budgets

Bu konudan daha fazla soru