Module 1: What Is Sre And Reliability As A Feature
7. The vocabulary you'll use all guide long
Description
You've already used, without formally defining them yet, most of this guide's central terms: error budget in lessons 3 and 6, SLO in lesson 3, blast radius inherited from previous guides. This lesson gathers them into a short, precise glossary, each one quoted directly from the official Google SRE source — never invented, never "roughly correct" — so that, before entering Module 2, you have the exact terminological foundation the rest of this guide assumes you already know.
Connection to the module
This is the last piece of vocabulary before lesson 8's deliverable. Every term in this glossary reappears, in more depth, in a specific module — SLI and SLO in Module 2, toil here and in Module 5 (on-call), on-call formally in Module 5, postmortem in Module 7 — so this lesson works as a quick-reference map, not the full development of each idea.
SLI — Service Level Indicator
"An SLI is a service level indicator—a carefully defined quantitative measure of some aspect of the level of service that is provided."
An SLI is a quantitative measure, carefully defined, of some aspect of the service level being delivered. The key word is "carefully defined" — not any raw metric counts as an SLI; a typical SLI is a ratio (good events ÷ total events), with an explicit criterion for what counts as "good." Example, on process-shipment-manifest: the proportion of invocations that finish with no error, out of the total valid invocations — Module 2 builds this definition with full precision.
SLO — Service Level Objective
"An SLO is a service level objective: a target value or range of values for a service level that is measured by an SLI."
An SLO is the target number — or range — an SLI should reach. If the SLI is "percentage of successful invocations," the SLO is the specific number, like 99.9%, that SLI should meet. You already used a hypothetical SLO in lesson 6 of this module; Module 2 picks Andes Cargo's real SLO, with its own justification.
SLA — Service Level Agreement
"SLAs are service level agreements: an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain."
An SLA is a contract — explicit or implicit — with real consequences, almost always financial (credits, refunds), if the SLO it contains isn't met. The distinction from an SLO is exactly that: an SLO is an internal engineering target; an SLA is an external promise with contractual consequences. This guide doesn't build any SLA for Andes Cargo — outside its scope, an internal system with no external customers paying for an availability contract — but you need the distinction so you don't confuse the three terms in a real conversation.
Error budget
"The error budget is 100% minus the SLO."
You already calculated it twice, in lessons 3 and 6 of this module: the portion of the SLO allowed to be "lost" before the target is missed, expressed in concrete minutes over a time window. At 99.9% monthly, 43.2 minutes. It's the mechanism, not just the formula, that turns an abstract goal into a daily operational decision.
Toil
"[Toil is] the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows."
Toil is operational work that meets, fully or partially, six characteristics: manual, repetitive, automatable, tactical (reactive, not strategic), devoid of enduring value, and scaling linearly with the service's size. It isn't "any boring work" — it's, specifically, work a software engineer, following Treynor's definition from lesson 2, would solve with automation instead of continuing to absorb it by hand. Google SRE is explicit about the limit it imposes on itself: "Our SRE organization has an advertised goal of keeping operational work (i.e., toil) below 50% of each SRE's time." — less than 50% of each engineer's time, never the majority of their work.
Blast radius
Already familiar from terraform-and-iac-guide and cloud-security-and-guardrails-guide: the real scope of what a change or a failure can affect, measured by what resources depend on what — never by the intent of whoever caused it. The Claude Code incident had such a large blast radius, according to those same guides, precisely because a single Terraform state managed all of DataTalks.Club's production infrastructure with no separation. This guide doesn't build the concept again — you already have it — but it actively uses it in Module 6, when operating the same incident.
On-call
"[On-call means] being available for calls during both working and nonworking hours" to keep services reliable — specifically, an engineer available to operate on production systems within minutes, per the alert response times the team has agreed on.
On-call isn't "keeping an eye on your phone just in case" — it's a formal commitment, with an agreed response time. Google SRE also imposes a hard limit on how much of an engineer's total work can be on-call: "no more than 25% can be spent on-call" — never the majority of anyone's time. This guide's Module 5 builds a real, deterministic rotation, with this same honesty about the human cost of on-call.
Postmortem
"A postmortem is a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring."
A postmortem is a document — not an informal conversation or a meeting with no record — with five mandatory pieces: what happened, what impact it had, what was done to mitigate it, what the root cause was, and what follow-up actions prevent it from recurring. The word "blameless" isn't a decorative adjective — the source itself is precise about it: "For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior", assuming that "everyone involved in an incident had good intentions and did the right thing with the information they had." This guide's Module 7 writes the real postmortem for the Claude Code incident, following exactly this structure.
The glossary, as a quick-reference table
| Term | What it measures/does | Where it's built in depth in this guide |
|---|---|---|
| SLI | A quantitative measure of service level | Module 2 |
| SLO | The numeric target an SLI should meet | Module 2 |
| SLA | An external contract with consequences for missing an SLO | Named here, not built (out of scope) |
| Error budget | 1 − SLO, in concrete minutes | Modules 2, 4, and 6 |
| Toil | Manual, repetitive operational work with no enduring value | Named here; the 50% limit cited |
| Blast radius | The real scope of a change or failure | Already familiar; reused in Module 6 |
| On-call | Committed availability to respond to incidents | Module 5 |
| Postmortem | The structured document that records an incident | Module 7 |
Common mistakes
Using "SLA" when you actually mean "SLO" (the market's most common vocabulary mistake). What happens: someone says "our SLA is 99.9%" to refer to an internal engineering target, with no external contract with real consequences involved. How to spot it: if the "SLA" you mention has, in practice, no contractual consequence (credits, refunds, penalties) if it's missed. How to fix it: if there's no external contract with consequences, it's an SLO, not an SLA — this lesson's distinction, quoted straight from the source, is exactly about this. Confusing the two terms in a technical interview is one of the fastest signals that someone memorized the acronyms without understanding the real difference.
Treating toil as a synonym for "any operational task" (over-generalization). What happens: someone classifies any operations work — including strategic work, like designing a new alert — as toil. How to spot it: if your definition of toil doesn't mention any of the six specific characteristics (manual, repetitive, automatable, tactical, devoid of enduring value, scales linearly). How to fix it: designing this guide's Module 4 burn rate alert is engineering work with enduring value — once built, it keeps working without repeating the effort; manually responding, every time, to the same alert without automating anything is toil. The distinction isn't "operations yes, development no" — it's whether the work repeats without accumulating any permanent value.
Assuming the 50% toil limit or the 25% on-call limit are arbitrary Google rules, with no application outside that company (misdirected skepticism). What happens: someone dismisses these limits as "Google-specific corporate culture," with no value for a small team like the one that would run Andes Cargo. How to spot it: if your reasoning is "that's for big companies, it doesn't apply here." How to fix it: the principle behind the limit — that repetitive, unautomated, unbounded work eats up all available engineering time — doesn't depend on team size; in fact, it's more urgent for a small team, where there's no margin of extra people to absorb unbounded toil. The exact number (50%, 25%) is Google's; the principle of setting some explicit, measured limit is universal, and this guide's Module 5 applies it to Andes Cargo's on-call rotation with the same honesty.
Exercises
Exercise 1 — Classify each term in the correct sentence. Complete: "Our ___ is that 99.9% of process-shipment-manifest invocations finish with no error (measured with our success-rate ___). If some external customer paid us to guarantee that number with penalties for missing it, that would be our ___."
See solution
"Our SLO is that 99.9% of process-shipment-manifest invocations finish with no error (measured with our success-rate SLI). If some external customer paid us to guarantee that number with penalties for missing it, that would be our SLA." The SLI is the measure (the concrete ratio); the SLO is the internal target on that measure; the SLA is the external contract with consequences, which Andes Cargo, with no external customers paying for availability, doesn't have and doesn't need in this guide.
Exercise 2 — Identify whether a specific task is toil, using the six characteristics. An Andes Cargo engineer manually reviews, every morning, the CloudWatch logs for process-shipment-manifest looking for errors, for fifteen minutes, every day, with no script doing it for them. Is it toil? Justify with at least three of the six characteristics.
See solution
Yes, it's toil — it comfortably meets four of the six characteristics: it's manual (a person does it by hand, every time), repetitive (every day, with no variation), automatable (an alert based on the error rate, exactly what this guide's Module 4 builds, replaces this manual review entirely), and devoid of enduring value (reviewing yesterday's logs leaves no artifact that reduces the work of reviewing tomorrow's). It isn't necessarily tactical in the sense of "interrupts other work" if it's scheduled — but meeting four of the six characteristics is already enough to classify it as toil, per the source itself: it doesn't need to meet all six.
Exercise 3 — Explain why a "blameless" postmortem doesn't mean "without root cause." A colleague argues that a blameless postmortem is, in practice, avoiding saying what really happened so as not to make anyone uncomfortable. Do you agree, using the definition quoted in this lesson?
See solution
Disagree. The quoted definition is explicit that a postmortem — blameless or not — must identify "the contributing causes of the incident" with full precision; what changes with "blameless" isn't the precision about what happened, but the frame used to interpret the role of the people involved: it's assumed they acted in good faith, with the information they had at the time, instead of looking for someone to "indict" for bad behavior. A blameless postmortem of the Claude Code incident, for example, does precisely name that a human approved the destroy without reading the full plan — that's the real contributing cause, and omitting it would make the postmortem useless — but it does so without treating that person as guilty of bad faith, exactly the distinction this guide's Module 7 is going to apply when writing that incident's real postmortem.
Summary and next step
In this lesson you gathered this guide's complete glossary — SLI, SLO, SLA, error budget, toil, blast radius, on-call, postmortem — each term quoted directly from the official Google SRE source, with the precise distinction between the ones that look alike (SLI/SLO/SLA) and the explicit limit Google imposes on itself for two of them (less than 50% of time in toil, no more than 25% on-call).
Before moving on you should be able to: distinguish SLI from SLO from SLA without hesitating; name toil's six characteristics and the 50% limit; and explain why "blameless" in a postmortem doesn't mean "with no identified root cause."
Lesson 8, this module's close, turns all of this module's vocabulary — reliability as measurement, error budget, the Claude Code incident measured with a real number — into this guide's first formal document: RELIABILITY-CHARTER.md.
Resources
- Google SRE Book, Chapter 4 — Service Level Objectives — the exact definitions of SLI, SLO, and SLA.
- Google SRE Workbook — Implementing SLOs — the exact error budget formula.
- Google SRE Book, Chapter 5 — Eliminating Toil — the complete definition of toil and the 50% limit.
- Google SRE Book, Chapter 11 — Being On-Call — the definition of on-call and the 25% limit.
- Google SRE Book, Chapter 15 — Postmortem Culture — the definition of postmortem and the "blameless" principle.