Question

Difficulty: MediumAligning Technical Service Level Objectives (SLAs/SLOs/SLIs) with Business Objectives

A healthcare enterprise operates a multi-tenant Telehealth Video Consultation platform on Google Cloud. The system consists of two primary services: a synchronous Video Signaling API that directly manages real-time patient-doctor video sessions, and an asynchronous EHR Audit Log Archival service that exports patient interaction logs to BigQuery for regulatory compliance. Currently, transient network spikes trigger low-priority alerts that escalate into system-wide automated failovers, causing unnecessary operational overhead. As a Cloud Architect, you are tasked with aligning the technical Service Level Objectives (SLOs) with business impact to optimize reliability and reduce engineer fatigue. Which TWO SRE practices should you implement to achieve this alignment?

  1. Define a high-stringency availability and latency SLO for the Video Signaling API using successful request ratios as the SLI, and configure multi-window burn-rate alerts against its error budget.Answer
  2. B
    Set the target SLO percentage of the Video Signaling API as the primary SLI metric in Cloud Monitoring dashboards, using it as a live real-time measurement of current system uptime.
  3. Establish a throughput and data freshness SLO evaluated over a rolling 30-day window for the EHR Audit Log Archival service, allowing transient failures during peak hours to be absorbed by its error budget.Answer
  4. D
    Configure static single-minute threshold alerts on CPU utilization for both services to trigger immediate pod scaling whenever CPU utilization exceeds 80%.

Answer

The correct practices are to define a high-stringency availability and latency SLO for the Video Signaling API using successful request ratios as the SLI backed by multi-window burn-rate alerts, and to establish a data freshness SLO over a rolling 30-day window for the asynchronous EHR Audit Log Archival service.
The correct decisions appropriately differentiate between synchronous user-facing impact and asynchronous backend tolerance. Measuring real-time successful request ratios as the SLI for the Video Signaling API and alerting based on error budget burn rate ensures that paging occurs only when critical user experience is threatened. Meanwhile, establishing a longer rolling window (30 days) for the asynchronous audit log archival workload allows transient delays to consume error budget without triggering false-alarm incidents.

Step-by-Step Solution

1
Analyze business criticality for both workloads
Identify that the Video Signaling API is synchronous and critical to real-time revenue and patient care, whereas the EHR Audit Log Archival service is asynchronous and tolerates latency.
Business impact determines the strictness of SLOs, appropriate window lengths, and alert severity.
2
Differentiate SLIs from SLOs and error budget alerting strategies
SLIs measure specific performance metrics (e.g., successful request ratio), while SLOs set target threshold goals. Error budget burn rates should drive alerts rather than static thresholds.
Prevents mistaking target objectives for current metric values and avoids alert fatigue from transient blips.
3
Align technical measurement with business tolerance
Apply multi-window burn-rate alerts to the synchronous API, and evaluate the asynchronous archival job over a wider rolling window (30 days).
Ensures high-priority alerting only occurs when business-critical error budgets are genuinely at risk.

Key Concept

Aligning SLOs/SLIs and Error Budgets with Workload Criticality
Rate this question