Site Reliability Engineering: What It Is, Why It Matters, and How It Connects to ITSM

# Site Reliability Engineering: What It Is, Why It Matters, and How It Connects to ITSM

## A Practitioner’s Guide to SRE Principles and Practice

In today’s rapidly evolving digital landscape, the pressure on IT teams to deliver services that are not just functional but reliable at scale has never been greater. Site Reliability Engineering — SRE — has emerged as a discipline that bridges the historical gap between software development and operations. If you’ve heard the term thrown around in DevOps conversations and wondered what it actually means in practice, this post is for you.

-----

## 1. What Is SRE?

SRE was pioneered by Google in the early 2000s and is often credited to Ben Treynor Sloss, who famously defined it as:

“What happens when you ask a software engineer to design an operations function.” — Ben Treynor Sloss, VP Engineering, Google

In practical terms, SRE is an approach to running production services that applies software engineering principles to operations work. Rather than relying on manual processes, tribal knowledge, and reactive firefighting, SRE teams use code, automation, and data-driven decision-making to build and sustain reliable systems.

The discipline is often described as a concrete implementation of DevOps — it shares the same cultural goals but provides specific practices, metrics, and structures to operationalise them.

-----

## 2. The Core Concepts

### Service Level Objectives (SLOs)

At the heart of SRE is the idea that reliability should be defined and measured, not assumed. Service Level Objectives are internal targets for how reliable a system should be — expressed as a percentage of successful requests, latency thresholds, or availability windows over a rolling time period.

• SLI (Service Level Indicator): The actual measured metric — e.g., the proportion of requests served in under 200ms.
• SLO (Service Level Objective): The target for that metric — e.g., 99.9% of requests in under 200ms over a 30-day window.
• SLA (Service Level Agreement): The contractual commitment to customers — typically less ambitious than the internal SLO, providing headroom.

My preference is always to set SLOs that are genuinely achievable but that still require discipline to meet. Setting them too high creates burnout and technical debt; too low and you’ve lost the point entirely.

### Error Budgets

This is where SRE gets genuinely clever. If your SLO is 99.9% availability, that means you have permission to be unavailable for 0.1% of the time — approximately 43 minutes per month. That allowance is your error budget.

• If you’re well within budget, you can move fast, ship features, and take on risk.
• If you’ve exhausted your budget, the focus shifts entirely to reliability and stability until it recovers.

This creates a rational, data-driven conversation between product and engineering — not an adversarial one.

### Toil Reduction

SRE explicitly measures and limits toil — manual, repetitive operational work that scales linearly with service growth and provides no lasting value. The principle is that SRE engineers should spend no more than 50% of their time on toil; the remainder goes to engineering work that reduces future toil.

If your team spends all day resetting passwords, restarting services, and manually scaling infrastructure, SRE has something to say about that.

### Blameless Post-Mortems

When things go wrong — and they will — SRE organisations conduct blameless post-mortems. The goal is systemic learning, not individual blame. A well-run post-mortem identifies:

• What happened and the timeline of events
• Contributing causes (not a single root cause — rarely does one exist)
• Action items to prevent recurrence or reduce impact

This is one of the most culturally significant aspects of SRE, and one of the hardest to embed in traditional IT organisations where blame culture runs deep.

-----

## 3. How SRE Connects to ITSM

This is the question I’m most often asked, and it’s a good one.

SRE and ITIL®-based ITSM are not competitors — they are complementary. ITSM provides the governance framework: structured processes for Incident Management, Change Management, Problem Management, and Service Request Fulfilment. SRE provides the engineering discipline to make those processes faster, more automated, and more responsive.

Here’s how the concepts map across:

• SRE Incident Response ↔ ITSM Incident Management: SRE brings on-call rotations, runbooks, and defined escalation paths — all consistent with ITSM principles but operationalised through code and tooling.
• Error Budgets ↔ SLA Management: Both define acceptable service thresholds; SRE’s error budget model is arguably more agile and actionable than traditional SLA management.
• Toil Reduction ↔ Continual Improvement: SRE’s explicit war on toil is a concrete mechanism for what ITIL® describes more broadly as Continual Service Improvement.
• Blameless Post-Mortems ↔ Problem Management: The post-mortem is SRE’s version of Problem Management, with a cultural overlay that prioritises learning over accountability theatre.

In my view, organisations that have adopted ITIL® should see SRE as the engineering engine that powers their ITSM processes — not a replacement, but a force multiplier.

-----

## 4. SRE Organisational Models

There are several ways organisations structure SRE capability:

• Embedded SRE: Reliability engineers sit within product teams and own the reliability of specific services. High autonomy, tightly coupled to development.
• Central SRE Team: A shared function that consults and supports multiple product teams. Better for establishing standards and tooling across the estate.
• CRE (Customer Reliability Engineering): A Google-invented model where SREs work directly with enterprise customers to improve their reliability practices. Less common internally but worth knowing about.

Which model you choose will depend on your organisational maturity, the size of your engineering estate, and how embedded your DevOps culture already is.

-----

## 5. Getting Started with SRE

If you’re considering introducing SRE practices into your organisation, here’s a practical starting point:

• Define your SLIs first. What does “reliable” actually mean for your critical services? Start there before touching SLOs or error budgets.
• Audit your toil. Ask your operations team to log everything they do for two weeks. The results are usually illuminating — and sobering.
• Run your first blameless post-mortem. Pick a recent incident and facilitate it as a learning exercise, not a review. Frame every question around systems and processes, not people.
• Don’t try to do everything at once. SRE is a cultural and engineering transformation. Start with one service, one team, and prove the model before scaling.

-----

## Conclusion

SRE is one of the most significant shifts in how IT organisations think about operations in the last two decades. It takes the best instincts of software engineering — automation, measurement, iteration — and applies them to the reliability challenges that keep operations teams awake at night.

For those of us working within ITSM frameworks, SRE isn’t a disruption — it’s an evolution. The language is different, the tooling is modern, and the cultural expectations are higher. But the goal is the same: services that work, teams that learn, and organisations that improve.

Hopefully this has been useful to you and I wish you well on your ITSM journey — wherever SRE fits into it.