What Is Site Reliability Engineering?

Define reliability targets. Service level indicators measure what users experience, such as request success rate or latency. Service level objectives set the target for those indicators over a window. Together they replace arguments about whether a service is reliable enough with a number both sides agreed in advance.

Run incident response. On-call rotations, escalation paths, and the discipline of restoring service before diagnosing root cause. SREs typically own the response process, not just their own systems.

Write postmortems. After significant incidents, a written analysis of what happened, why the system allowed it, and what will change. Blameless in the sense that the target is the system and process, not the individual.

Remove toil. Toil is manual, repetitive operational work that scales with traffic and produces no lasting value. SRE practice treats reducing it as engineering work with its own priority, often capped as a proportion of time.

Build platform capability. Deployment pipelines, observability, capacity planning, load balancing, failover, and the tooling other teams use to run their services.

Review designs for reliability. Involvement before launch: failure modes, dependencies, degradation behaviour, and whether the service can be operated at all.

Error budgets

Where SREs sit in an organisation

DevOps is a broad set of principles about collaboration between development and operations, continuous delivery, and shared ownership. It describes a culture and a direction rather than a specific job.

SRE is one concrete implementation of those principles, originating at Google and codified in published books, with specific practices: objectives, error budgets, toil limits, and blameless postmortems.

Platform engineering focuses on building internal platforms and developer experience so product teams can ship safely without deep infrastructure knowledge. Many organisations run platform and SRE functions together, or use the titles interchangeably.

Traditional operations emphasises maintaining systems and responding to issues, often without a mandate to write software or set reliability targets.

In practice titles vary widely. The useful questions are whether the role has a mandate to change systems rather than only run them, whether reliability targets exist, and who owns the pager.

Reading SRE job descriptions

Start with one service and one objective. A single meaningful indicator with an agreed target teaches more than a full catalogue of metrics nobody uses.

Measure what users experience. Availability measured at the load balancer can look excellent while users see errors. Objectives belong as close to the user as you can measure.

Agree the consequence in advance. An error budget without an agreed response is a chart. The value comes from deciding, before it is breached, what changes when it is.

Protect the postmortem process. If postmortems become performance reviews, engineers stop writing honestly and the practice dies quietly.

Cap toil deliberately. Track how much time goes to repetitive operational work and treat sustained overrun as a signal to fund automation, not to hire more people to absorb it.

Keep incident records structured. Consistent timelines, impact, contributing causes, and follow-up actions with owners. Patterns across incidents are only visible when records are comparable.

Do not adopt the vocabulary alone. Objectives, budgets, and postmortems without authority to change systems or slow releases produce the reporting overhead of SRE with none of its benefits.