Your technical library
Site Reliability Engineering
9 modules · 48 topics
About this book
Site Reliability Engineering
This course teaches how to keep a fleet of services running: to predict how a design fails before it does, to bound the damage when it does, and to argue with numbers about what reliability is worth. It assumes the System Design course, not experience of running a fleet, and aims past what a senior staff engineer is expected to know. System Design teaches the performance laws, the serving path in normal operation and the basics of service-level objectives; this course starts where those end — what happens when parts fail, slow down or are overloaded, how failures spread and keep themselves going, how to contain them, and how changes, the most common trigger, are made safe. It also builds on Computer Networking and Mathematics.
Reliability as a number makes availability, service-level indicators and error budgets quantities you can compute and spend. How distributed systems fail covers correlated, gray and cascading failure and the health checks meant to catch them. Timeouts, deadlines and retries shows how well-meant retries multiply load, and overload shows how a system can stay broken after its trigger has gone, and the load shedding and throttling that prevent it. Containing the blast radius builds bulkheads, cells and shuffle sharding, and dependencies and degraded modes decides which failures a service must survive.
Safe change covers progressive delivery, canary analysis, rollback and feature flags. Incidents, learning and experiments covers incident response, postmortems and chaos engineering, and capacity, cost and the reliability review sizes headroom, prices each extra nine of availability, and closes by walking one service through the whole course.
48 topics across 9 modules, in dependency order.
This course is planned; no lessons are written yet. The map shows every module and topic so its coverage can be reviewed before authoring. Each topic will open with what to read first and close with what it leaves open.
Read at your own pace. Each topic is one continuous page; mark it done as you finish.
Start with 01.1 · Availability from failure and repair: why MTTR is the leverReview what you have finished↷ 0 skipped topics- 01.1Availability from failure and repair: why MTTR is the lever
- 01.2Specifying an SLI: good events over valid events, measured where users are
- 01.3Composing availability: parallel, k-of-n, and the failover that must work
- 01.4Error budgets as a spending model: what one bad change costs
- 01.5Burn-rate alerts as detectors: detection time, reset time and low-traffic noise
- 03.1Choosing a timeout from a latency distribution
- 03.2Deadline propagation: passing the remaining budget downstream
- 03.3Retry amplification: why retries at every layer multiply load
- 03.4Backoff and jitter: spreading retries in time, not reducing them
- 03.5Retry budgets: bounding amplification to a fixed ratio
- 03.6Circuit breakers: when to stop calling, and how they amplify partial failure
- 04.1Metastable failure: a stable bad state held up by its own feedback
- 04.2Goodput: why a server that accepts all work completes none
- 04.3Load shedding: rejecting cheaply, early and by priority
- 04.4Client-side throttling: rejecting locally from the observed accept rate
- 04.5Queue backlogs: when an asynchronous system can never catch up
- 04.6Adaptive concurrency limits: discovering capacity from latency
- 04.7Overload control end to end: which mechanism belongs at which layer
- 05.1Bulkheads: stopping one slow dependency from taking every thread
- 05.2Cells: replicating the whole stack to bound blast radius
- 05.3Shuffle sharding: combinatorial isolation between tenants
- 05.4Static stability: surviving an impairment without making any change
- 05.5Control plane and data plane: which half must keep working
- 05.6Constant work: making load independent of how much changed
- 05.7Choosing an isolation boundary: bulkheads, cells, shuffle shards and zones
- 06.1Hard and soft dependencies: which failures a service must survive
- 06.2Fallback is a second system that is rarely tested
- 06.3A cache you cannot lose: hit rate as load-bearing capacity
- 06.4Cold starts: bringing a fleet back with empty caches
- 06.5Synchronised demand: reconnect storms, top-of-the-hour jobs and the recovery herd
- 07.1Progressive delivery: bounding exposure in space and time
- 07.2Canary analysis: detecting a regression in a small slice
- 07.3Bake time: waiting for defects that need time or traffic to appear
- 07.4Rollback safety: making every deploy reversible
- 07.5Dynamic configuration and feature flags: the fastest global change
- 07.6Smaller, more frequent changes are safer: the batch-size argument
- 09.1Capacity headroom: sizing for peak during a failure
- 09.2Finding real capacity: load tests, the SLO knee and live-traffic tests
- 09.3Autoscaling as a control loop: lag, signals and oscillation
- 09.4What a nine costs: choosing a target from cost and value
- 09.5A reliability review: walking one service through the course
01.2Specifying an SLI: good events over valid events, measured where users are
01.3Composing availability: parallel, k-of-n, and the failover that must work
01.4Error budgets as a spending model: what one bad change costs
01.5Burn-rate alerts as detectors: detection time, reset time and low-traffic noise
02.1Correlated failure: why the redundancy multiplication lies
02.2Gray failure: when the failure detector and the user disagree
02.3Health checks: shallow, deep and the fail-open threshold
02.4Cascading failure: how losing capacity destroys the capacity that remains
03.1Choosing a timeout from a latency distribution
03.2Deadline propagation: passing the remaining budget downstream
03.3Retry amplification: why retries at every layer multiply load
03.4Backoff and jitter: spreading retries in time, not reducing them
03.5Retry budgets: bounding amplification to a fixed ratio
03.6Circuit breakers: when to stop calling, and how they amplify partial failure
04.1Metastable failure: a stable bad state held up by its own feedback
04.2Goodput: why a server that accepts all work completes none
04.3Load shedding: rejecting cheaply, early and by priority
04.4Client-side throttling: rejecting locally from the observed accept rate
04.5Queue backlogs: when an asynchronous system can never catch up
04.6Adaptive concurrency limits: discovering capacity from latency
04.7Overload control end to end: which mechanism belongs at which layer
05.1Bulkheads: stopping one slow dependency from taking every thread
05.2Cells: replicating the whole stack to bound blast radius
05.3Shuffle sharding: combinatorial isolation between tenants
05.4Static stability: surviving an impairment without making any change
05.5Control plane and data plane: which half must keep working
05.6Constant work: making load independent of how much changed
05.7Choosing an isolation boundary: bulkheads, cells, shuffle shards and zones
06.1Hard and soft dependencies: which failures a service must survive
06.2Fallback is a second system that is rarely tested
06.3A cache you cannot lose: hit rate as load-bearing capacity
06.4Cold starts: bringing a fleet back with empty caches
06.5Synchronised demand: reconnect storms, top-of-the-hour jobs and the recovery herd
07.1Progressive delivery: bounding exposure in space and time
07.2Canary analysis: detecting a regression in a small slice
07.3Bake time: waiting for defects that need time or traffic to appear
07.4Rollback safety: making every deploy reversible
07.5Dynamic configuration and feature flags: the fastest global change
07.6Smaller, more frequent changes are safer: the batch-size argument
08.1Incident response: roles, and mitigating before understanding
08.2Postmortems: contributing factors, hindsight and fixes that remove failure classes
08.3Chaos engineering: testing a steady-state hypothesis in production
09.1Capacity headroom: sizing for peak during a failure
09.2Finding real capacity: load tests, the SLO knee and live-traffic tests
09.3Autoscaling as a control loop: lag, signals and oscillation
09.4What a nine costs: choosing a target from cost and value
09.5A reliability review: walking one service through the course
Skipped topics
Moved past without finishing. A skipped topic still closes its module, and Continue goes on without it — open one to read it or mark it understood.