How to Become a Site Reliability Engineer

Overview

Site reliability engineering applies software engineering to the problem of running systems. The defining idea is that reliability is a product feature with a budget, not an absolute — you decide how reliable a service needs to be, measure it, and spend the remainder on change. SREs sit close to production and are usually the people called when something serious breaks. This page describes the work honestly, including the on-call reality, and how the career tends to progress.

What a Site Reliability Engineer actually does

The idealised description is eliminating toil through automation and designing for resilience. The real week includes a good deal of firefighting, writing post-mortems, and negotiating with product teams who want to ship faster than the error budget allows. On-call is not incidental; it is central, and it does mean nights and weekends in most organisations, though how bad it is varies enormously with engineering maturity. Much of the work is investigative — reading unfamiliar code under pressure, correlating a latency spike with a deployment, and forming a hypothesis quickly with incomplete information. The rest is prevention: capacity planning, load testing, dependency analysis and the slow institutional work of making the same incident not happen a third time.

The career path

The skills that matter

How to break in

• #1

  Move across from backend engineering — the systems knowledge transfers directly and the reliability mindset can be learned on the job.

• #2

  Move across from operations or DevOps and deliberately strengthen your coding, because the SRE bar for software skill is usually higher.

• #3

  Volunteer for on-call in your current role. Nothing else on a CV substitutes for having been responsible for production at 3am.

• #4

  Practise systems design and troubleshooting interviews specifically — SRE loops lean heavily on both, and they are distinct from standard algorithm rounds.

• #5

  Learn to write a good post-mortem and bring an example. It demonstrates analytical depth, ownership and communication all at once.

• #6

  Build something you must keep running for months, with alerting and a documented runbook. Operating your own system teaches lessons that reading cannot.

What drives pay

Compensation varies too much by country, sector and company size for a single figure to be useful. These are the factors that actually move it.

• The severity of the on-call commitment and how much production risk sits with you personally

• Depth in distributed systems and performance analysis, which is a narrower skill pool than general infrastructure work

• Operating at genuine scale or with strict latency requirements, where the failure modes are harder and the experience is rarer

• Sectors where downtime is directly and immediately costly — payments, trading, telecoms, large-scale commerce

• Whether you can lead incident response and set reliability standards for others, rather than only responding within them

Where demand is heading

The function is durable because the underlying problem does not go away: systems keep getting more distributed, and someone has to own whether they stay up. Manual runbook execution and hand-tuned alerting are steadily being automated, and routine first-line response is increasingly assisted by tooling. The parts that keep growing are designing for resilience up front, reasoning about complex failure across services, and owning reliability commitments in businesses where downtime is expensive. The title itself varies — some organisations fold it into platform engineering — but demand for people who can be trusted with production has not softened.

Roles this transfers to

Common mistakes

• Becoming the human alerting system — absorbing manual work indefinitely instead of insisting on engineering time to remove it.

• Letting coding skills atrophy, which pushes you towards operations roles and away from senior SRE ladders.

• Chasing perfect availability rather than agreeing an objective, which burns the team and slows product delivery for little gain.

• Writing post-mortems that assign blame or stop at the proximate cause, so the underlying pattern recurs.

• Tolerating noisy alerts until the team stops trusting the pager, at which point a real incident gets missed.

• Ignoring the personal cost of a badly run rotation instead of raising it early, which is a common route to burning out of the profession.

Frequently Asked Questions

Explore another career