Examkin

Soru

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

An Educational Technology (EdTech) organization hosts its online testing platform on Google Cloud. The platform features two core workloads: an interactive Student Assessment Submission API that directly impacts user grading and customer contractual SLAs, and an asynchronous Student Learning Analytics Pipeline used for internal nightly progress reporting. The organization experiences unnecessary operational friction because both workloads currently share identical 99.99%99.99\% availability targets and generic infrastructure alerting. You need to redesign the reliability framework to align technical Service Level Objectives (SLOs) and Service Level Indicators (SLIs) with business impact while preventing burn-out on non-critical outages. Which design strategy should you implement?

  1. Define a high-stringency SLO (99.99%) for the Assessment Submission API measured by an SLI of successful HTTP POST requests divided by total requests, and establish a relaxed SLO (99.0%) for the Analytics Pipeline measured by an SLI of batch job completion within a 4-hour window.Cevap
  2. B
    Define the SLI for both services as a target goal of 99.99% availability, and set the SLO as the real-time ratio of successful backend requests recorded by Cloud Monitoring.
  3. C
    Enforce a uniform 99.99% SLO across both workloads and configure high-priority PagerDuty alerts triggered whenever backend Compute Engine CPU utilization exceeds static 85% thresholds for more than 5 minutes.
  4. D
    Provision an active-active multi-region failover architecture for both services to ensure zero RPO and RTO, triggering immediate multi-region disaster recovery procedures upon any error budget consumption.

Cevap

The correct strategy is to establish a strict 99.99% SLO measured by an SLI of successful HTTP POST request ratios for the critical Assessment Submission API, while defining a lower 99.0% SLO measured by job completion latency for the non-critical Analytics Pipeline.
The correct approach sets differentiated reliability targets based on business impact. The real-time Assessment Submission API directly affects student grading and client SLAs, warranting a strict 99.99% SLO and an SLI measured as the ratio of successful requests. Conversely, the asynchronous Analytics Pipeline can tolerate delays, making a 99.0% SLO and a batch completion time SLI appropriate. This avoids over-engineering non-critical infrastructure and protects operational error budgets.

Adım Adım Çözüm

1
Analyze business impact for each service component
Identified Student Assessment Submission API as high business impact (direct SLA penalties and user experience disruption) and Student Learning Analytics Pipeline as low business impact (internal asynchronous batch reporting).
SLOs and error budgets must directly reflect user-perceived degradation and financial risk.
2
Select appropriate Service Level Indicators (SLIs) for each workload type
Selected request success ratio (good requests / total requests) for synchronous HTTP submissions, and time-to-completion (jobs finished within window / total jobs) for batch analytics processing.
SLIs must quantify the actual performance metric relevant to how users or downstream systems consume the specific workload.
3
Set Service Level Objectives (SLOs) aligned with business risk tolerance
Assigned a tight 99.99% target for the high-impact submission service and a relaxed 99.0% target for the batch reporting pipeline.
Differentiating targets preserves engineering operational bandwidth and error budgets where minor downtime is business-acceptable.

Anahtar Kavram

Aligning SLO/SLI selection and error budget allocation directly with business impact.
Bu soruyu puanla

Konular

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