Soru

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

A digital B2B SaaS company operates two core microservices on Google Cloud: a synchronous Payment Processing Gateway that directly processes customer payments, and an asynchronous PDF Invoice Generator that produces monthly billing summaries. The business leadership requires technical service levels to accurately reflect financial business impact without incurring unnecessary operational overhead or alert fatigue. Which TWO architectural and operational strategies best align the technical SLOs and SLIs with these business objectives?

  1. Define the Payment Processing Gateway Service Level Indicator (SLI) as the proportion of successful HTTP 2xx requests over total valid requests, and establish a high-stringency Service Level Objective (SLO) monitored via multi-window error budget burn-rate alerting.Cevap
  2. Define the PDF Invoice Generator Service Level Indicator (SLI) based on task completion latency within an acceptable multi-hour window, establishing a relaxed Service Level Objective (SLO) with a generous error budget.Cevap
  3. C
    Treat the target 99.99% availability goal as the Service Level Indicator (SLI) for both services to ensure uniform monitoring metrics across the entire platform.
  4. D
    Configure static threshold alerts on Compute Engine CPU utilization for both backend workloads to trigger immediate high-priority paging whenever CPU exceeds 80%.

Cevap

The team should define the Payment Gateway SLI as the ratio of successful HTTP requests paired with a strict SLO using error budget burn-rate alerts, while defining the PDF Invoice Generator SLI based on asynchronous task latency with a relaxed SLO and generous error budget.
Aligning technical service levels with business objectives requires distinguishing between synchronous, revenue-critical transactions and asynchronous batch operations. For the payment gateway, measuring successful HTTP request ratios (SLI) and applying error budget burn-rate alerts ensures immediate detection of revenue loss without alerting on transient spikes. For the invoice generator, establishing a latency-based SLI with a relaxed SLO prevents over-engineering non-critical background processes.

Adım Adım Çözüm

1
Differentiate critical user-facing services from non-critical background workloads based on business impact.
Payment processing directly impacts revenue and requires strict availability goals, whereas batch invoice generation is asynchronous and tolerant to minor delays.
Business alignment requires spending engineering effort and tight error budgets only where customer friction or financial loss occurs.
2
Formulate appropriate Service Level Indicators (SLIs) for each service type.
Use successful HTTP request ratio for the synchronous payment API and completion latency over a multi-hour window for the asynchronous invoice generator.
SLIs must measure real user experience and functional satisfaction relevant to the workload type.
3
Implement error budget burn-rate alerting for high-priority services while setting relaxed targets for batch background services.
Prevents alert fatigue and over-engineering of non-critical components while preserving proactive alerting for revenue-critical paths.
Burn-rate alerting detects sustained budget consumption before severe outages occur.

Anahtar Kavram

Aligning Service Level Indicators (SLIs) and Service Level Objectives (SLOs) with business impact requires tailoring metrics to workload criticality, utilizing error budget burn-rate alerts for synchronous paths, and allowing relaxed SLOs for asynchronous background tasks.
Bu soruyu puanla