Glossary¶
Core SRE/DevOps terms, defined the way they get used in practice — not textbook definitions.
Backpressure : A mechanism for a system under load to signal upstream callers to slow down (via queue limits, rejected requests, or explicit throttling) instead of silently degrading or falling over.
Blast Radius : The scope of what breaks if a given change, deploy, or failure goes wrong — how many users, services, or regions are affected. Reducing blast radius (canaries, feature flags, cell-based architecture) is a core mitigation strategy, independent of preventing the failure itself.
Canary Deployment : Rolling a change out to a small subset of traffic first, watching key metrics, then progressively increasing the percentage — so a bad release affects a fraction of users instead of everyone at once.
Chaos Engineering : Deliberately injecting failure (killing pods, adding latency, cutting network paths) into a system — ideally in production — to verify your assumptions about resilience actually hold, instead of discovering they don't during a real incident.
Circuit Breaker : A pattern that stops calling a failing downstream dependency after enough errors, failing fast instead of piling up slow/timed-out requests, then periodically retries to see if the dependency has recovered.
Error Budget : The amount of unreliability an SLO allows before you've "spent" it — e.g. a 99.9% SLO gives roughly 43 minutes of downtime per month. Burning through the budget is a signal to slow down feature work and prioritize reliability.
Idempotency : A property of an operation where running it multiple times has the same effect as running it once. Critical for safe retries — if a payment API call isn't idempotent, a network timeout followed by an automatic retry can charge a customer twice.
Immutable Infrastructure : Servers/containers are never modified in place after deployment — instead, changes are made by building and deploying a new image/instance and discarding the old one. Eliminates configuration drift and makes rollbacks trivial (redeploy the previous image).
Incident Commander : The single person coordinating an incident response — making decisions, delegating tasks, and communicating status — so responders can focus on fixing the problem instead of on who's in charge.
MTTA (Mean Time to Acknowledge) : The average time between an alert firing and a human acknowledging it. A high MTTA usually points to alert fatigue, unclear on-call ownership, or noisy/low-signal alerts.
MTTR (Mean Time to Restore/Repair) : The average time from when an incident starts impacting users to when service is restored. The metric that actually matters most to users — they experience downtime, not root cause.
Observability : The ability to understand a system's internal state from its external outputs — logs, metrics, and traces — well enough to answer questions you didn't anticipate when you instrumented it. Monitoring tells you that something's wrong; observability helps you find out why.
On-Call : A rotation where an engineer is designated to respond to alerts/incidents outside normal working hours for a defined period, with a clear escalation path if they can't resolve it alone.
Postmortem : A written, blameless account of an incident — timeline, root cause, impact, and follow-up action items — produced after resolution so the same failure mode doesn't recur and the org actually learns from the outage.
Rollback : Reverting a deployment to the previous known-good version, usually the fastest path to restoring service during an incident caused by a bad release — fix-forward can wait until after impact is contained.
Runbook : A step-by-step procedure for handling a specific, known operational scenario (e.g. "database failover," "certificate renewal") — written so that anyone on-call, not just the original author, can execute it correctly under pressure.
SLA (Service Level Agreement) : An external, often contractual, commitment to a customer about service reliability — typically with financial or other consequences if breached. Usually looser than the internal SLO that backs it, to leave margin for error.
SLI (Service Level Indicator) : A specific, measured metric used to quantify a service's behavior — e.g. "percentage of requests served in under 300ms." SLOs are targets set on top of SLIs.
SLO (Service Level Objective) : An internal target for an SLI over a time window — e.g. "99.9% of requests succeed, measured over 30 days." The basis for error budgets and the core tool for balancing reliability work against feature velocity.
Toil : Manual, repetitive, automatable operational work that scales linearly with service growth and provides no lasting engineering value — the thing SRE practice is explicitly meant to drive down over time.
Missing a term you'd expect here? Suggest an addition alongside whatever content change prompted the question — glossary entries land best next to the page that needed them.