How to Become a Site Reliability Engineer: Skills, Projects and Paths In

SRE job posts can feel contradictory. One asks for strong Go or Python skills like a software engineering role. The next asks for deep Linux, networking and on-call experience like an operations role. Both are right. Site reliability engineering sits in the middle, and that mix is exactly what makes it hard to break into and valuable once you do.

Google, which coined the term, describes SRE as what happens when you ask a software engineer to design an operations team. In practice, that means SREs keep production systems reliable by writing software, not by doing the same manual fixes again and again.

This guide explains the skills SRE roles expect, in what order to learn them, and how people actually get their first SRE job.

What a site reliability engineer does

An SRE is responsible for the reliability, performance and scalability of production systems. Typical work includes:

• Defining service level indicators (SLIs) and service level objectives (SLOs), such as “99.9% of requests succeed within 300 milliseconds”
• Building monitoring, alerting and dashboards that catch real problems without paging people for noise
• Being on call and leading incident response when systems break
• Writing blameless postmortems and fixing the root causes
• Automating repetitive operational work, which SREs call “toil”
• Planning capacity and testing how systems behave under load or failure
• Working with developers on safer releases, such as canary deployments and quick rollbacks

Google’s SRE book describes a cap of 50% of SRE time on operational work like tickets and on-call. The rest goes to engineering projects that reduce future manual work. Not every company follows that rule, but it captures the spirit: an SRE should be making the system better, not just keeping it alive.

For a deeper look at the discipline itself, see our explainer on what site reliability engineering is.

SRE vs DevOps vs systems administration

People often use these titles interchangeably, but the emphasis differs.

At smaller companies, 1 person may do all 4 jobs. At larger ones, SRE is usually a separate team that partners with product engineering. Our DevOps vs SRE guide covers the overlap in detail.

The coding half of the SRE skill set

Many people coming from operations underestimate how much SRE roles expect them to code. You don’t need to be a computer science expert, but you should be able to write and maintain real tools.

What to learn:

• 1 general-purpose language, well. Python is the most common starting point. Go is widely used for infrastructure tools, and Kubernetes itself is written in Go.
• Data structures and algorithms basics. Enough to pass a coding interview and to write code that does not fall over at scale. Our guide on how to prepare for a coding interview covers the essentials.
• Working with APIs. Most automation means calling cloud, monitoring or ticketing APIs.
• Testing and code review. SRE tools run in production, so they need tests like any other software.
• Git and CI/CD. You will ship your own tools through pipelines and often own the pipelines too.

A good test: can you write a script that pulls metrics from an API, decides whether something is wrong and opens a ticket or rolls back a deploy? If yes, you are on track.

The operations half of the SRE skill set

The other half is understanding how production systems actually behave and fail.

• Linux internals. Processes, memory, file systems, system calls, and how to debug with tools such as top, strace, ss and journalctl. Google’s SRE book notes that UNIX system internals and networking are the most common specialist skills among its SREs.
• Networking. DNS, TCP/IP, HTTP, TLS, load balancers and how latency adds up.
• Cloud platforms. At least 1 of AWS, Microsoft Azure or Google Cloud.
• Containers and orchestration. Docker and Kubernetes. See Kubernetes explained if you are starting fresh.
• Infrastructure as code. Terraform or similar tools. Our guide to infrastructure as code explains the idea.
• Observability. Metrics, logs and traces, with tools such as Prometheus, Grafana and OpenTelemetry. Read observability vs monitoring for the difference.
• Databases and queues. How replication, failover and backpressure work.

SRE-specific practices

These are what set SRE apart from general operations:

1. SLIs, SLOs and error budgets. An error budget is 1 minus the SLO. A service with a 99.9% availability target can fail 0.1% of requests over the measurement window. If the budget is spent, the team slows releases and works on reliability.
2. Incident response. Clear roles (incident commander, communications lead), runbooks and calm escalation. Our incident response plan guide shows the structure.
3. Blameless postmortems. Writing up what happened and what will change, without blaming individuals. See how to write a blameless postmortem.
4. Toil reduction. Measuring repetitive manual work and automating it away.
5. Capacity planning and load testing. Knowing when a system will run out of room before it does.

Key takeaway: SRE employers want people who can do both halves. A strong coder who has never debugged a production outage, or a strong operator who can’t write maintainable code, will find SRE interviews hard. Close your weaker gap first.

Certifications that help (and their limits)

No certification is required to be an SRE, and hiring managers care more about what you have run in production. Still, a few credentials help structure your learning and get past resume filters:

• Certified Kubernetes Administrator (CKA) from the Linux Foundation. It is a 2-hour, performance-based exam where you solve tasks from a command line, so it tests real skills.
• Google Cloud Professional Cloud DevOps Engineer. Its exam guide includes applying SRE practices, such as defining SLIs, SLOs and error budgets, alongside CI/CD and observability.
• AWS or Azure professional-level DevOps certifications, if your target employers run on those clouds.

Prices and exam formats change, so check the certifying body’s page before you register. For help prioritizing, see how to choose an IT certification.

SRE project ideas that prove you can do the job

Projects matter more than certificates for career changers. Build 1 or 2 of these and write them up on GitHub with a clear README:

1. SLO dashboard for a real app. Deploy a small web app, instrument it with Prometheus metrics, define 2 SLOs and build a Grafana dashboard with error budget burn alerts.
2. Chaos experiment. Run the app on Kubernetes with 3 replicas, then kill pods, add network latency or fill a disk. Document what broke and what you fixed.
3. Toil-killing tool. Write a Python or Go tool that automates a real manual task, such as rotating certificates, cleaning up unused cloud resources or checking backups.
4. Postmortem portfolio. Break your own system on purpose and write a blameless postmortem with a timeline, root cause and action items.
5. Infrastructure as code from scratch. Rebuild the whole environment with Terraform and a CI/CD pipeline, then destroy and recreate it in under 30 minutes.

Common paths into SRE

Very few people start their careers as SREs. The most common routes are:

• From software engineering. Volunteer for on-call, build internal tooling and fix production issues. This is often the smoothest path because coding is the harder half to learn.
• From DevOps or cloud engineering. You already know pipelines and infrastructure; strengthen your coding and learn SLO-based reliability practices. See how to become a DevOps engineer for overlapping skills.
• From systems administration or IT operations. You know production well; invest heavily in programming and cloud-native tools. Our guide on how to become a systems administrator explains how that role is moving toward automation.
• From support or network engineering. Deep troubleshooting skills transfer well; add coding and Kubernetes.

Internal moves are often easier than external ones. If your company has an SRE or platform team, ask to join their on-call rotation or pick up a reliability project.

SRE interviews typically include coding, troubleshooting scenarios (“this service is slow, walk me through what you check”), system design with a reliability focus, and behavioral questions about incidents you have handled.

Where to start this month

1. Rate yourself from 1 to 5 on coding, Linux, networking, cloud, Kubernetes and observability. Pick the 2 lowest.
2. Set up a home lab using a free cloud tier or local Kubernetes tool such as kind or minikube.
3. Read the free Google SRE book at sre.google, starting with the chapters on SLOs, eliminating toil and postmortems.
4. Build project 1 from the list above and publish it.
5. Get closer to production at work. Join on-call, review incidents or automate a manual task your team hates.
6. Apply for adjacent roles such as DevOps, platform or production engineer if SRE openings are scarce. They lead naturally into SRE.

The bottom line

Becoming an SRE means becoming good at 2 things at once: writing software and running production systems. Pick your weaker half and work on it first, learn SLOs and error budgets, and prove your skills with projects that break and recover. Most SREs arrive from software, DevOps or operations roles, so the job you have now is probably your best starting point.

Sources

• Google SRE Book: Introduction — definition of SRE, 50% cap on operational work, common specialist skills and error budgets
• Google SRE Book (free online) — SLOs, toil, monitoring and postmortem practices
• Linux Foundation: Certified Kubernetes Administrator (CKA) — exam format and scope
• Google Cloud: Professional Cloud DevOps Engineer — certification areas including applying SRE practices