An enterprise payment processing service hosted on Google Cloud Run processes asynchronous webhook notifications. The Site Reliability Engineering (SRE) team is defining service level indicators (SLIs), service level objectives (SLOs), and alerting strategies to balance release velocity with availability. Which TWO strategies should the team implement to ensure effective SLO management and alerting?
- Define the SLI as the ratio of valid HTTP responses (non-5xx status codes) to total HTTP requests measured at the Google Cloud HTTP(S) Load Balancer.Answer
- Configure multi-window, multi-burn-rate alerts in Cloud Monitoring to page on-call engineers when a significant percentage of the monthly error budget is consumed rapidly.Answer
- CDefine the SLO by measuring average CPU utilization on Cloud Run instances to ensure system headroom remains above 20%.
- DConfigure static threshold alerts in Cloud Monitoring to page on-call engineers immediately whenever the 5-minute HTTP 5xx error percentage exceeds 0.1%.
Answer
The team should define the SLI as the ratio of valid HTTP responses (non-5xx) to total requests at the load balancer level, and configure multi-window, multi-burn-rate alerts in Cloud Monitoring to track error budget consumption rates.
Defining the SLI as a ratio of successful HTTP requests to total requests measured at the load balancer provides a direct, user-focused metric. Pairing this with multi-window multi-burn-rate alerts in Cloud Monitoring allows SRE teams to detect critical error budget exhaustion events while suppressing false alarms caused by short-lived traffic anomalies.
Step-by-Step Solution
Key Concept
Defining user-centric SLIs and implementing error budget burn-rate alerts