Examkin

Soru

Zorluk: Çok zorAligning Technical Service Level Objectives (SLAs/SLOs/SLIs) with Business Objectives

An enterprise digital healthcare platform on Google Cloud ingests real-time patient telemetry streams via Cloud Pub/Sub and processes them using a microservices pipeline backed by Cloud Spanner. The contract specifies a customer SLA of 99.9% availability, defined as telemetry processing latency staying under 1.5 seconds. During peak events, while the frontend HTTP Load Balancer immediately acknowledges incoming requests with HTTP 200, downstream processing queue backpressure causes ingestion processing times to frequently exceed 3 seconds. Consequently, the company incurs contract financial penalties despite internal metrics showing 99.99% HTTP request success rates. Which TWO actions should the Site Reliability Engineering (SRE) and business teams take to align technical service levels with business objectives and prevent SLA breaches?

  1. Define the Service Level Indicator (SLI) as the proportion of valid telemetry events whose end-to-end processing latency from ingestion to database write is under 1.5 seconds, and set the internal Service Level Objective (SLO) at 99.95%.Cevap
  2. B
    Define the Service Level Indicator (SLI) as a targeted goal of 99.9%, and configure the Service Level Objective (SLO) as the real-time proportion of HTTP 200 OK responses returned by the frontend load balancer.
  3. Establish an error budget policy that automatically halts new feature deployments and shifts engineering focus to database throughput optimization whenever the multi-window burn rate indicates the error budget will deplete before the end of the compliance cycle.Cevap
  4. D
    Configure static operational alerts that immediately page on-call engineers for every single telemetry event that exceeds 1.5 seconds processing time to trigger manual regional database failovers.

Cevap

The team should define the SLI based on end-to-end processing latency under 1.5 seconds with an internal SLO of 99.95%, and establish an error budget policy that halts feature deployments when error budget burn rates threaten SLA compliance.
The correct architectural strategy involves capturing true end-to-end processing latency as the SLI, setting an internal SLO tighter than the external SLA to build a safety buffer, and enforcing error budget policies that prioritize reliability over new features when the burn rate indicates an impending breach.

Adım Adım Çözüm

1
Analyze the misalignment between technical metrics and business SLAs.
The current technical metric (HTTP 200 success rate at the load balancer) reports 99.99% availability, but downstream queue backpressure causes actual latency (>3 seconds) to breach the business SLA threshold (1.5 seconds).
SLIs must reflect actual user/business experience rather than proxy metrics at ingestion boundaries.
2
Define an accurate SLI and internal SLO safety buffer.
SLI = (Valid events processed under 1.5s) / (Total valid events). Setting an internal SLO of 99.95% creates a 0.05% safety margin relative to the 99.9% customer SLA.
Internal SLOs should always be stricter than external SLAs to allow proactive mitigation before financial penalties occur.
3
Establish governance based on error budget burn rates.
When error budget consumption burns at a rate that threatens the compliance window, product releases are frozen and engineering effort is redirected to reliability and backpressure remediation.
Error budget policies bridge technical metrics and business decision-making by balancing velocity with reliability risk.

Anahtar Kavram

Aligning technical SLIs/SLOs with business SLAs and enforcing error budget governance
Bu soruyu puanla

Konular

Aligning Technical Service Level Objectives (SLAs/SLOs/SLIs) with Business Objectives