Examkin

Soru

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

A global fintech enterprise operates two core workloads on Google Cloud: a real-time API for evaluating transaction fraud risk and a background batch service for nightly ledger reconciliation. Business operations dictate that any un-evaluated real-time transaction causes immediate unrecoverable financial theft, whereas background ledger delays of up to four hours carry zero business or financial penalty. Currently, operations alerts on a single composite Service Level Indicator (SLI) measured as Successful RequestsTotal Requests\frac{\text{Successful Requests}}{\text{Total Requests}} aggregated across all API and batch requests. During a planned maintenance window, high-volume batch failures exhausted the quarterly error budget and triggered a critical P1 incident callout, despite the real-time fraud API maintaining 100% availability. How should the Cloud Architect realign the technical SLIs and SLOs with business impact?

  1. Decouple the workloads into separate SLIs and SLOs for real-time fraud evaluation and batch reconciliation, and restrict high-severity error budget burn-rate alerts to the real-time service.Cevap
  2. B
    Increase the single composite SLO target from 99.9% to 99.99% availability so that batch processing failures do not easily consume the shared error budget.
  3. C
    Replace the service availability SLI with static CPU and memory utilization thresholds across all underlying compute infrastructure.
  4. D
    Redefining the contractual SLA with business stakeholders to guarantee 99.999% uptime across both real-time and batch endpoints under a single financial penalty clause.

Cevap

Decouple the workloads into separate SLIs and SLOs for real-time fraud evaluation and batch reconciliation, and restrict high-severity error budget burn-rate alerts to the real-time service.
The correct response addresses the core Site Reliability Engineering (SRE) principle of aligning technical metrics with business impact. Because real-time fraud checks carry direct financial penalties upon failure while batch reconciliation is delay-tolerant, the services must have independent Service Level Indicators (SLIs) and Service Level Objectives (SLOs). High-severity paging alerts should only trigger when the error budget of the critical real-time service is burning rapidly.

Adım Adım Çözüm

1
Analyze business impact differences between services
Real-time fraud processing has zero tolerance for downtime (direct monetary loss), whereas nightly batch reconciliation tolerates up to 4 hours of delay.
SLOs and error budgets must directly map to business risk and user experience.
2
Evaluate the current composite SLI strategy
Aggregating batch and real-time requests into a single ratio Successful RequestsTotal Requests\frac{\text{Successful Requests}}{\text{Total Requests}} causes non-critical high-volume batch failures to exhaust the error budget of the critical path.
Combining heterogeneous workloads distorts telemetry and generates false-positive P1 operational alerts.
3
Define aligned SLIs/SLOs and alerting rules
Create independent SLIs and SLOs for each service. Configure paging burn-rate alerts strictly on the real-time fraud endpoint, while routing batch failures to low-priority ticketing queues.
This alignment prevents alert fatigue, protects critical business revenues, and allows batch workloads to consume their error budgets as intended.

Anahtar Kavram

Aligning technical SLIs/SLOs with distinct business impacts by separating critical user-facing metrics from non-critical batch processes.
Bu soruyu puanla

Konular

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