SRE, Other Frameworks, The Future
SRE, Other Frameworks
SRE and DevOps
DevOps is a broad cultural and professional movement - often summarised as CALMS (culture, automation, lean, measurement, sharing) - aiming to remove the wall between development and operations. SRE is one prescriptive implementation of those ideas: the specific mechanisms (SLOs, error budgets, the 50% rule, blameless postmortems, toil budgets) are what SRE adds. The two are not rivals; SRE extends DevOps with concrete engineering practices.
SRE and ITIL / ITSM
ITIL provides processes for incident, problem, change and service-level management. SRE overlaps but reframes them: SLOs replace document-heavy service levels, postmortems replace problem records in spirit, and change management is replaced by automated, peer-reviewed, reversible deployment pipelines. A well-run SRE organisation can still satisfy ITSM controls if they are automated and low-friction; the trap is layering slow manual change advisory boards on top of a fast pipeline, which adds delay without adding safety.
SRE and Lean / Agile
Lean's waste categories map neatly onto toil, and value-stream thinking exposes queues and handoffs. Agile supplies the cadence; SRE supplies the reliability guardrails (error budgets) that let teams move fast without gambling the service.
Traps
- Presenting DevOps and SRE as an either/or choice, or claiming SRE ‘replaces’ ITIL entirely.
- Assuming any framework automatically provides reliability metrics; only a defined SLI/SLO pair does.
- Treating change management as inherently opposed to velocity - the issue is friction, not the existence of controls.
Rule of thumb
Use the framework test: does the practice produce a measurable, owned commitment and a feedback loop? If it produces paperwork instead, it is ceremony, not reliability engineering.
The Future of SRE
Where the discipline is heading
SRE is expanding along several credible fronts. Platform engineering and internal developer platforms push the paved road further: SRE thinking is embedded into golden paths, templates and self-service so reliability comes by default rather than by review. AIOps and ML-assisted operations help correlate telemetry, detect anomalies and draft incident summaries, but they do not remove the need for explicit SLIs, SLOs and error budgets - models still need a definition of ‘good’.
Cloud-native and edge environments increase the number of moving parts and the rate of change, making automated rollout control and dependency-aware SLOs more important. Security is merging into the reliability conversation (supply-chain integrity, secure defaults, incident response shared between security and SRE). Cost and sustainability are becoming first-class signals alongside latency and errors, which fits naturally into the SLI/SLO frame.
Expect the definition of toil to shift rather than vanish: as routine automation grows, the residual manual work becomes more judgement-heavy, and the 50% rule becomes a discussion about which human work is worth keeping.
Traps
- Assuming AI removes the need for SLOs, ownership or postmortems.
- Treating platform engineering as purely a tooling project rather than a socio-technical one.
- Adopting new technology without revisiting the operational model, toil budget or on-call load.
Rule of thumb
When evaluating any new capability, ask the same three questions SRE has always asked: does it reduce toil, does it make failure more observable and recoverable, and does it improve the reliability users actually experience?