Scaling with Google Cloud Operations · Topic 4 of 4
Measuring Reliability with SRE
How reliability is measured with latency, traffic, saturation and errors, and DevOps and SRE concepts: service level indicators, objectives and agreements.
- 4 min
- Four signals: latency, traffic, errors, saturation.
- SLI measures, SLO targets, SLA promises with consequences.
- SLOs are stricter than SLAs.
What it is
To manage reliability you must measure it. Google's Site Reliability Engineering (SRE) practice measures services with four key signals (latency, traffic, errors, saturation) and sets targets with service level indicators (SLIs), service level objectives (SLOs) and service level agreements (SLAs). DevOps is the broader culture of developers and operations working together to deliver changes quickly and reliably.
How it works
The four signals
| Signal | What it measures | Example |
|---|---|---|
| Latency | How long it takes to respond to a request | Checkout page responds in 300 milliseconds |
| Traffic | How much demand the system receives | Requests per second |
| Errors | The rate of requests that fail | 0.5 percent of requests return an error |
| Saturation | How full the system is, relative to its capacity | Database at 90 percent of its connections |
These are often called the four golden signals. Watching all four gives a full picture: is it fast, how busy is it, is it failing, and is it about to run out of capacity?
Saturation warns before failure. A service at 95 percent memory still works, but not for long.
DevOps and SRE
| DevOps | SRE | |
|---|---|---|
| What it is | A culture and set of practices joining development and operations | Google's way of running production, applying software engineering to operations |
| Key ideas | Shared ownership, automation, small frequent releases, fast feedback | SLOs, error budgets, automation, blameless postmortems |
SRE is often described as one specific way to implement DevOps.
SLI, SLO and SLA
| Term | Meaning | Example |
|---|---|---|
| Service level indicator (SLI) | A measurement of a service's behavior | Percentage of requests that succeed; percentage answered in under 300 ms |
| Service level objective (SLO) | The target value for an SLI, set by the team | 99.9 percent of requests succeed over 30 days |
| Service level agreement (SLA) | A contract with customers promising a level of service, with consequences such as credits if it is missed | 99.5 percent monthly availability, or a service credit |
The SLO is usually stricter than the SLA, so the team sees and fixes problems before breaking the customer promise.
Error budgets
If the SLO is 99.9 percent success, the remaining 0.1 percent is the error budget: the amount of unreliability the team can accept. When the budget is healthy, the team can release new features quickly. When it is spent, the team slows releases and focuses on reliability. This turns the argument between "move fast" and "stay stable" into a shared, measurable rule.
No service aims for 100 percent: it is extremely expensive, and users cannot tell the difference above a certain level.
A worked scenario
A video streaming service defines an SLI: the percentage of videos that start within two seconds. Its SLO is 99.5 percent over 28 days, while its SLA to business customers promises 99 percent with service credits. Dashboards track latency, traffic, errors and saturation. One month a bad release uses most of the error budget, so the team pauses feature launches and fixes the cause, without ever breaking the SLA.
How the exam asks about this
- "A measurement such as the percentage of successful requests." SLI.
- "The internal target for reliability." SLO.
- "A contract with customers that includes penalties." SLA.
- "How full the system is compared with its capacity." Saturation.
- "Why not aim for 100 percent?" It is too costly and slows innovation; error budgets balance speed and reliability.
What to remember for the exam
- Four signals: latency, traffic, errors, saturation.
- SLI measures, SLO targets, SLA promises with consequences.
- SLOs are stricter than SLAs.
- Error budget = 100 percent minus the SLO; it balances releases and reliability.
- DevOps is the culture; SRE is Google's engineering approach to operations.
Do not confuse SLO and SLA. An SLA has contractual consequences; an SLO is an internal goal.
Common mistakes
Calling the target an SLI. The SLI is the measurement; the SLO is the target.
Aiming for 100 percent availability. It is not realistic or cost-effective.
Confusing traffic with saturation. Traffic is demand; saturation is how close you are to capacity.
Check yourself
What is the difference between an SLO and an SLA?
An SLO is an internal reliability target; an SLA is a contract with customers that carries consequences if missed.
Name the four golden signals.
Latency, traffic, errors and saturation.
What is an error budget?
The amount of unreliability allowed by the SLO, such as 0.1 percent for a 99.9 percent SLO.
Topic 4 of 4 in Scaling with Google Cloud Operations
Test yourself on Scaling with Google Cloud Operations
The full Google Cloud Digital Leader question bank has 512 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.