Site Reliability Engineering
Reliability as an engineering discipline, explained from first principles. Learn SLIs, SLOs and error budgets, golden signals and burn-rate alerting, incident response, safe releases, toil and DORA metrics — and remember it with spaced repetition.
- flashcards
- 123
- flashcards
- per day
- ~10 min
- per day
- level
- Beginner → Intermediate
- level
- modules
- 8
- modules
What is Site Reliability Engineering?
Site Reliability Engineering (SRE) is the practice of running services by treating operations as a software problem. Instead of chasing 100% uptime, SRE asks a sharper question: how reliable does this service actually need to be, and how do we spend the rest of that budget on shipping features? The answer is built from measurable targets rather than gut feeling.
The core loop is SLIs, SLOs and error budgets. An SLI is what you measure (the fraction of requests served well), an SLO is the target you hold it to, and the error budget is the allowance of unreliability that target leaves you — the number that decides when to keep shipping and when to freeze and stabilize. Around that sit the daily disciplines: structured incident response, cutting toil through automation, and measuring delivery with DORA's four keys.
This track breaks SRE into bite-sized, practical questions across reliability targets, monitoring and alerting, incident management, resilience patterns, release engineering, toil and automation and DORA metrics — plus a scenario module that puts you in front of real situations: a retry storm that will not clear, a canary that proves nothing, a rollback that breaks the database. Spaced repetition keeps it all there for the day you are the one on call.
8 modules, seed to bloom
Each module is a set of flashcards — 123 in total. Answer, review, and watch your knowledge grow from seed to full bloom.
Reliability Targets
SLI vs SLO vs SLA, error budgets, budget policy, and choosing the right reliability target
16 cardsMonitoring & Alerting
Golden signals, percentiles, symptom versus cause alerting, error budget burn rates, and keeping the pager honest
16 cardsIncident Management
Incident command roles, on-call load, escalation, detection and repair time, and blameless postmortems
15 cardsResilience Practices
Overload handling, retries and timeouts, circuit breakers, bulkheads, failure isolation, and chaos experiments
16 cardsRelease Engineering
Canaries, blue-green, feature flags, reversible schema changes, staged rollouts, and making releases safe to undo
15 cardsToil & Automation
What counts as toil, the 50% cap, measuring it, choosing what to automate, and the risks automation brings
15 cardsDORA Metrics
The four keys in detail — what each one counts, where its clock starts, and how throughput and stability trade off
15 cardsPractical Scenarios
Real-world what-would-you-do situations — diagnose bad SLIs, retry storms, fake canaries, hidden toil, and detection gaps
15 cardsSample questions
A taste of the real flashcards. Pick an answer, then reveal the explanation.
How does the SRE Workbook express a Service Level Indicator as a formula?
- AGood events divided by valid events, expressed as a percentage of the traffic that counted
- BGood events divided by every event the system emitted, including requests it never accepted
- CFailed events divided by valid events, so a lower resulting number means a healthier service
- DValid events divided by the peak request rate the service was provisioned to handle safely
What does the Incident Commander do that the other incident roles deliberately do not?
- AHolds the overall picture and delegates, staying out of hands-on debugging to avoid tunnel vision
- BRuns the mitigation directly, taking the console and applying changes to the failing system
- COwns every outward update, publishing incident status to customers and to internal leadership
- DKeeps the incident record, maintaining the timeline and the handover notes as events land
In SRE, what is toil?
- AManual, repetitive, automatable operational work that has no enduring value and scales with service size
- BAny difficult engineering project that requires deep design thinking and permanently improves the service
- CThe paperwork of meetings, planning, and email that surrounds a team but never touches production systems
- DOne-off creative debugging of a novel outage that the team has never encountered or documented before
What do the DORA “four keys” metrics measure?
- ASoftware delivery and operational performance — how quickly and reliably a team ships changes to production
- BThe raw code quality of a repository — how many style violations and bugs a static analyzer can detect
- CIndividual developer productivity — how many lines of code and commits each engineer produces per sprint
- DInfrastructure spend efficiency — how much a team pays per server and how fully its capacity is utilised
Learn it once, keep it for good
Answer a question
Each card is one practical concept with multiple options. Pick what you think is right.
Get the full answer
See the correct option plus a clear explanation, and a link to deeper docs when one is available.
Review at the right time
A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.
Why SRE is worth your time
A framework for reliability decisions
SLOs and error budgets turn "is it reliable enough?" from an argument into a number the whole team can act on.
Calmer incidents
Knowing the Incident Commander model and structured response means outages get coordinated instead of chaotic.
Automate the right things
Spotting toil — repetitive, automatable work with no lasting value — is how you win back time to actually engineer.
Interview-ready
SLIs/SLOs, error budgets and DORA metrics are staple topics in SRE, platform and senior DevOps interviews — and the <a href="/interview-questions/sre">SRE interview questions</a> page drills the same ground as spoken answers.
Common questions
Do I need to be an SRE already? +
No. The track starts from what reliability means and builds up SLIs, SLOs and error budgets from first principles, so developers and ops engineers moving toward reliability work both benefit.
How is this different from the Kubernetes reliability track? +
This track covers the SRE discipline itself — targets, incidents, toil, DORA and resilience — independent of any platform. The Kubernetes Ops: Reliability & Security track applies similar ideas to running workloads on Kubernetes specifically.
Is it free? +
Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.
How long does it take? +
About 10 minutes a day. Spaced repetition means short, frequent sessions beat long cramming, so the concepts stick.
Ready to master SRE?
Plant your first seed today. Ten minutes a day is all it takes to grow real, lasting reliability skills.