The words the on-call folks throw around, in plain English — plus the tools we use and where to go deeper. No shame in starting here; everyone did.
The main system dies, so we flip to the backup. Like the understudy going on when the lead actor is sick.
The "boss" copy that takes all the work, and the backup copy waiting in the wings in case the boss goes down.
How far behind the backup copy is. Zero is great. Growing means the backup is falling behind and might lose recent data if we switch.
RTO = how fast we get back up. RPO = how much data we can afford to lose. Two dials every DR plan sets.
A promise to customers (SLA), your internal target (SLO), and the actual measurement (SLI). Promise, goal, ruler.
How much breaks when one thing breaks. Small blast radius = the fire stays in one room.
Something's wrong (incident), and how bad it is (SEV1 = the building's on fire, SEV4 = a flickering lightbulb).
The person running the response — coordinating, deciding, keeping calm. Notably, not the person with hands on the keyboard.
After it's over, we figure out what broke, not who to blame. Systems fail; people learn.
The four vitals of any service: how slow (latency), how busy (traffic), how many errors, how full (saturation).
How slow it is for your slowest customers. p99 = "the worst 1% of requests." Averages lie; percentiles don't.
Mean Time To Recover — on average, how long from "it broke" to "it's fixed." Lower is the whole game.
Being able to see what's happening inside the system from the outside — metrics, logs, traces. You can't fix what you can't see.
Whose turn it is to carry the pager and answer if something breaks at 2am. It rotates. Be kind to whoever has it.
Offline decision-tree triage for databases, apps, and incidents. Where the judgment lives.
Sees inside your apps and infrastructure — traces, metrics, auto root-cause. Our observability.
Dashboards on top of your metrics — the panels you stare at to know if things are healthy.
Where tickets, incidents, and changes are tracked. The system of record for "what happened."
Takes a flood of alerts and groups them into one incident, so you're not drowning in noise.
Pages the right on-call person when something breaks. The thing that wakes you up.
↗ links go to the vendors' sites to learn the basics. Your team's own ServiceNow / BigPanda / Dynatrace live at internal URLs — ask your lead for those.
The free, canonical texts on Site Reliability Engineering. Start with the first one's incident chapters.
The practical companion — SLOs, alerting, and running incidents, with real examples.
Our own teaching page — how SQL Server Always On actually works, in plain terms.
The 60-second tour of the tools themselves.
Don't see your area — networking, Linux, Kubernetes, a vendor system? That's not a gap in the plan; it's an invitation. Every tool has a 💬 Feedback button — use it to request a domain or suggest a check, and it goes straight to the maintainer. The kit gets more robust every time someone does.
SRE 101 — a ReliabilityOps on-ramp. Definitions are intentionally simplified for newcomers; the linked resources have the full picture. External links (↗) open vendor and learning sites in a new tab.