Defining SLIs (e.g., availability, latency), SLOs, and SLAs

Differentiating and Aligning SLIs, SLOs, and SLAs

The Metric Hierarchy

Service Level Indicators (SLIs) are the raw, measurable data points that show how a service is performing. Common examples are availability, measured as the ratio of successful responses to total requests, and latency, which is the time it takes to respond. These metrics are the technical foundation, but they don't set a target on their own.

Service Level Objectives (SLOs) are the internal goals set for those SLIs. An SLO is a target like "99.9% availability" measured over a specific compliance period, such as a rolling 30-day window. The gap between 100% and the SLO target creates an error budget, which is the acceptable amount of unreliability. This budget is a crucial tool for balancing the speed of new releases with system stability.

Service Level Agreements (SLAs) are the external, legally binding contracts made with customers. An SLA takes the promises from an SLO and formalizes them, including details about support and any financial credits or penalties for missing the target. A key operational practice is to keep a defensive safety margin between your internal SLO and your external SLA. For example, if your SLA promises customers 99.5% availability, your internal SLO should be stricter, like 99.9%, to create a buffer and ensure you consistently meet the legal commitment.

Formulating and Measuring Service Level Indicators (SLIs)

Defining Quantifiable Metrics

An SLI is typically formulated as a ratio of "good" events to total valid events. For a web service, availability is the count of successful HTTP responses divided by all valid requests. To measure user experience, latency tracks how long requests take. It's important to choose metrics that reflect the true user experience, which means sometimes excluding client-side errors from the total count.

Choosing the Right Evaluation Method

There are two main ways to evaluate SLI compliance, and the choice affects what you learn about performance. A request-based method looks at individual transactions, counting how many meet a threshold like "under 200ms." However, this can miss problems with tail latency, which are the slowest requests that frustrate users. A window-based method evaluates performance over many small, consecutive time blocks (like five-minute windows). For compliance, a certain percentage of these windows must meet a goodness criterion. This approach is better for catching sustained periods of poor performance.

Monitoring with Google Cloud Tools

In Google Cloud, you can collect SLI data without modifying your application code by using built-in sources. Cloud Load Balancing automatically provides metrics for traffic it handles. For microservices, Cloud Service Mesh uses sidecar proxies to track traffic flowing between services. These tools feed data into Cloud Monitoring, where you can define and visualize your SLIs.

Designing Service Level Objectives (SLOs) and Managing Error Budgets

Setting Achievable Targets

A Service Level Objective (SLO) is the target you set for an SLI, like "99.95% availability." The target must be realistic and aligned with what users actually need. Setting an SLO too high can waste engineering effort on a level of perfection users won't notice, while setting it too low can damage trust. An internal tool might only need 99% availability, while a critical customer-facing payment service might require 99.99%.

The Role of the Error Budget

The error budget is calculated directly from the SLO. If your SLO is 99.9% availability over 30 days, your error budget is the remaining 0.1% of allowed downtime. This budget is a powerful governance tool for release velocity. When the budget is healthy, teams can deploy new features and changes. When the budget is depleted, the focus must shift to improving reliability, which may trigger a deployment freeze. This creates a systematic balance between innovation and stability.

Selecting a Compliance Period

The compliance period is the time window over which the SLO is measured. You can choose a calendar period, like a fixed month, or a rolling period, like the last 30 days. Rolling periods provide more frequent and dynamic feedback because compliance is re-evaluated every day, allowing teams to react to reliability issues faster than waiting for a calendar month to end.

The Contractual Layer: SLAs

The Service Level Agreement (SLA) is the final step, where SLO targets become contractual promises to customers. SLAs detail the guaranteed performance level, the responsibilities of both parties, and the specific financial remedies, like service credits, if the commitment is not met. Google Cloud provides its own SLAs for many services, which define uptime percentages and credit policies. Understanding this entire hierarchy—from raw SLI metrics to internal SLOs and error budgets, and finally to external SLAs—is essential for applying Site Reliability Engineering practices effectively in GCP.