Soru

Zorluk: ZorAligning Technical Service Level Objectives (SLAs/SLOs/SLIs) with Business Objectives

An enterprise logistics platform running on Google Cloud processes high-volume vehicle location updates via Cloud Pub/Sub and Dataflow. The company's customer contracts include a strict Service Level Agreement (SLA) guaranteeing 99.9% monthly availability for location lookup requests, with tier-1 financial penalties incurred if availability drops below this threshold. Executive leadership wants to ensure operational performance directly protects business revenue while preserving engineering release velocity. As a Cloud Architect, how should you define the Service Level Objectives (SLOs) and Service Level Indicators (SLIs) to align technical operational performance with this business objective?

  1. Define the SLI as the ratio of successful location lookup requests to total requests measured over rolling 30-day windows, set an internal SLO of 99.95% availability, and configure automated alerts on error budget burn rates to intervene before breaching the 99.9% contractual SLA.Cevap
  2. B
    Define the SLO as the ratio of successful location lookup requests to total valid requests over 30 days, and set the SLI target value to 99.9% to mirror the contractual SLA threshold exactly.
  3. C
    Define the SLI as the ratio of successful location lookup requests to total requests, set the internal SLO to 99.9%, and configure immediate high-severity alerts to trigger whenever CPU utilization on Dataflow worker nodes exceeds 85% for 5 minutes.
  4. D
    Define the SLI as end-to-end processing latency, set an SLO requiring zero recovery point objective (RPO) across all regions, and trigger automated regional traffic failovers whenever any individual request takes longer than 500 milliseconds.

Cevap

Define the SLI as the ratio of successful location lookup requests to total requests measured over rolling 30-day windows, set an internal SLO of 99.95% availability, and configure automated alerts on error budget burn rates to intervene before breaching the 99.9% contractual SLA.
The correct response properly distinguishes between SLI (the metric calculation of successful requests divided by total requests), SLO (the internal target goal of 99.95%), and SLA (the external contractual agreement of 99.9%). Setting an internal SLO higher than the external SLA creates an error budget buffer that absorbs minor outages without triggering financial penalties. Operational alerting on multi-window error budget burn rates ensures proactive intervention before breaching the contractual threshold.

Adım Adım Çözüm

1
Differentiate metrics (SLI vs. SLO vs. SLA)
SLI is the metric measuring actual performance (good requests / total requests). SLO is the internal target (99.95%). SLA is the business contract (99.9%).
Clear separation ensures operational measurements accurately feed target objectives without metric definition confusion.
2
Align internal target to business penalty boundary
Setting an internal SLO (99.95%) tighter than the customer SLA (99.9%) establishes an error budget cushion.
An error budget margin protects the business from financial penalties while allowing planned feature deployments and minor operational anomalies.
3
Implement proactive alerting mechanism
Alerting on error budget burn rate identifies consumption speed before total depletion.
Burn rate alerting enables SRE teams to mitigate issues before the external SLA boundary is violated.

Anahtar Kavram

SRE Service Level Alignment & Error Budget Management
Bu soruyu puanla