Professional Cloud DevOps Engineer

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

A Service Level Indicator (SLI) is a carefully chosen measurement of a specific aspect of service performance, such as availability (percentage of time the service responds) or latency (how fast it responds). The team decides which SLIs matter most to users and collects them over a measurement window. A Service Level Objective (SLO) is the target value for that SLI—for example, “99.9% of requests succeed within 200 milliseconds.” The SLO defines the acceptable level of reliability that the team commits to internally. A Service Level Agreement (SLA) is the external contract with customers that formally guarantees a certain level of service, often with penalties if violated. The SLA is typically equal to or stricter than the SLO, because the team builds a safety margin: they aim for an SLO that is higher than the SLA so they can still meet the contract even when small failures occur. In Google Cloud, you can monitor SLIs using Cloud Monitoring and define custom dashboards to track SLO burn rates, which show how fast the error budget is being consumed.

Error budgets (e.g., Cloud Service Mesh definitions)

An error budget is the amount of unreliability the service can tolerate over a given period, calculated as 100% – SLO. For example, an SLO of 99.9% over a 30‑day window gives an error budget of 0.1% of total requests, or roughly 43 minutes of downtime. The error budget is the key mechanism that balances change velocity with reliability: when the budget is high (few failures so far), the team can release new features or infrastructure changes more aggressively; when the budget is low or exhausted, the team focuses on stability and pauses risky deployments. In a Cloud Service Mesh environment such as Anthos Service Mesh, the mesh can automatically track request failure rates between services and compute an error budget for each service or even for specific paths. This allows teams to define and enforce reliability policies at the mesh level, so that a service that has already used most of its error budget can be protected from further changes that might cause additional errors. The error budget creates a shared vocabulary between development and operations: both teams agree that the risk of pushing a change is acceptable only while the budget remains positive.

Opportunity cost of risk and reliability (e.g., number of “nines”)

Reliability is not free—each additional “nine” (for example, going from 99.9% to 99.99% availability) demands significantly more engineering effort, infrastructure redundancy, testing, and operational rigor. The opportunity cost of pursuing extremely high reliability is that the same time and money could have been spent on new features, faster delivery, or other business initiatives. Deciding the right SLO involves a trade‑off: choose too low an SLO and users experience frequent failures that damage trust; choose too high an SLO and the team spends most of its energy on reliability while competitors move faster. The number of nines a service needs depends on its business impact. A core transaction service might require 99.99%, whereas an internal reporting tool might be fine at 99.0%. In Google Cloud, you can model these trade‑offs by comparing the cost of extra infrastructure (like multi‑zone or multi‑region deployments) against the revenue or user‑satisfaction loss from downtime. The key insight is that every additional nine has diminishing returns, and the error budget helps quantify the risk you are willing to take so that you can invest in reliability only up to the point where the cost of extra reliability exceeds the cost of occasional failure.