Why Site Reliability Engineering?
Engineering discipline applied to the question "is it up?"
SRE started at Google as an answer to a simple tension: developers want to ship fast, and operations wants things to stay stable. Instead of treating that as a fight, SRE treats reliability as a feature with a measurable budget — service level objectives (SLOs) define how reliable a system needs to be, and an error budget defines how much unreliability is acceptable before shipping slows down to fix it. The job is equal parts software engineer and firefighter: writing automation and tooling most of the time, and running structured incident response when something breaks.
It's a highly-paid, highly-respected role precisely because it demands both halves — deep systems and cloud knowledge, plus the calm, process-driven judgment to run an incident without making it worse. It overlaps closely with DevOps and Cloud Engineering, but with a sharper focus on measurable reliability, on-call practice, and postmortems. The roadmap below covers the full path: fundamentals and mindset first, then the systems and cloud skills underneath, then the observability and incident-response practices that define the discipline.
Quick intro — what is SRE?
A quick primer before you start the roadmap. Opens in a small player, no need to leave the page.
The SRE Roadmap
Work through these in order. Each step has a short lesson, official docs, and a repo to practice in.
SRE Fundamentals & Mindset
What SRE is, how it differs from traditional ops and from DevOps, and the core vocabulary: SLIs, SLOs, SLAs, and error budgets.
Programming & Scripting
Python or Go for automation and tooling, plus Bash for the glue scripts that run everywhere in production systems.
Linux & Systems Fundamentals
Processes, memory, filesystems, systemd, and how to read a struggling machine — the diagnostic skills every on-call shift depends on.
Networking Fundamentals
TCP/IP, DNS, HTTP, load balancing, and how requests actually travel from a user to your service and back.
Version Control & CI/CD
Git workflows and automated pipelines with GitHub Actions, GitLab CI, or Jenkins so deploys are repeatable, not manual and risky.
Cloud Platforms & Infrastructure as Code
Provision and manage infrastructure on AWS, Azure, or GCP declaratively with Terraform — reproducible, reviewable, and rollback-able by design.
Containers & Orchestration
Docker for packaging, Kubernetes for running services at scale with self-healing, rolling deploys, and resource limits baked in.
Observability & Monitoring
Metrics, logs, and distributed tracing with Prometheus, Grafana, or Datadog — the three pillars that let you answer "what's actually wrong" fast.
Incident Management & On-Call
Alerting that doesn't cry wolf, on-call rotations, runbooks, and blameless postmortems that turn every incident into a lesson.
Capacity Planning & Performance
Load testing, autoscaling policies, and resource forecasting so systems handle real traffic growth instead of falling over at 2am.
Chaos Engineering & Resilience
Deliberately inject failure to find weak points before an outage does — redundancy, failover, and disaster recovery planning.
Automation & Toil Reduction
Identify repetitive, manual, automatable work — "toil" — and eliminate it with self-healing systems and better tooling, freeing time for engineering.
GitHub Projects
Real, buildable projects to put on your own GitHub
Monitoring & Alerting Stack
Deploy Prometheus and Alertmanager against a sample service, define SLO-based alerts, and route them to a test notification channel.
Chaos Engineering Experiment
Use Chaos Mesh to kill pods, inject network latency, or simulate a disk failure in a Kubernetes cluster and observe how your system recovers.
Reliability Dashboard
Build a Grafana dashboard that tracks error budget burn rate, latency percentiles, and uptime for a service you're monitoring.
Postmortem Template & Practice
Study real incident postmortems, then write your own for a simulated outage — timeline, root cause, impact, and action items.
Track complete
Twelve steps, from error budgets to chaos experiments. Push what you built to GitHub so it's visible to employers, then keep going — reliability is learned by watching real systems fail and fixing them, not just reading the SRE book.
Where next?
Keep exploring by domain or drill into a single skill — or continue on to DevOps and Cloud Engineer