SRE Fundamentals

Site Reliability Engineering (SRE) is a discipline Google popularized: apply the same rigor, measurement, and automation habits software engineering already has to the job of running systems reliably - instead of treating "operations" as a separate, more ad-hoc world of fire drills and tribal knowledge.

Reliability is a feature, with a cost

The instinctive goal is "100% uptime, always." In practice, that's both practically impossible and not actually what users need - chasing the last fraction of a percent gets exponentially more expensive for improvements users often can't even perceive. SRE treats reliability as a deliberately chosen target, not an unquestioned maximum - the next lesson, on error budgets, makes that precise.

Toil: the enemy of scaling operations

Toil is manual, repetitive operational work that's purely reactive and creates no lasting improvement - restarting the same stuck service by hand every few days, say. It doesn't scale: more services and more traffic just means more toil, forever, unless it gets automated away. A later lesson in this track covers reducing it directly.

What this track covers

This track walks through the core SRE toolkit in order: turning "reliable" into a measurable number (SLIs, SLOs, error budgets), responding to incidents when reliability slips, writing postmortems that make the next incident less likely, and finally automating away the toil that caused it in the first place.

Try it

uptime

When you're ready, hit Mark complete and move to the next lesson.