A framework is just a named way of working. Pick the lightest one that answers the question you have today. Each card below says what it is, when to use it, how a DevOps engineer or SRE might apply it, what goes wrong, and where to read more.
Cards start folded. Expand one at a time. The open card fills the width and the rest move below.
Delivery performance
DORA
Four key metrics: deployment frequency, lead time for changes, change fail rate, and failed deployment recovery time.
When to use it
Need evidence that delivery health is improving
Debating speed versus stability with execs
Justifying platform and CI/CD investment
Example for a DevOps / SRE
Report DORA trends alongside RAG and SLO burn. Use them to show whether pace is real flow or pressure, and to challenge scope that worsens change fail rate.
Things that go wrong
Gaming metrics with empty deploys
Ignoring user outcomes while charts look green
Applying raw DORA to non-deployable work without adaptation
Reliability
SLO / error budgets (SRE)
Service Level Indicators and Objectives with an error budget that governs how much unreliability you can spend on change.
When to use it
Reliability debates are opinion-only
Feature pressure repeatedly wins over stability
Need a shared policy between product and engineering
Example for a DevOps / SRE
Define journey-based SLIs, agree SLOs with the Product Owner, and write burn policies for 50%, 25% and 0% remaining budget. Review burn in roadmap forums.
Things that go wrong
SLO posters without policy
Internal metrics that users do not feel
Punishing teams for burn instead of changing systems
Delivery practice
Continuous Delivery
Keep software in a releasable state through small batches, comprehensive automation and fast feedback from commit to production.
When to use it
Releases are events or weekends
Lead time is dominated by wait and fear
Rollback is theoretical
Example for a DevOps / SRE
Make the pipeline the only path to production. Shrink batch size, automate verification, and rehearse rollback. Treat war-room releases as a defect in the delivery system.
Things that go wrong
Automating a broken process without shrinking batches
Manual prod steps as culture
Flags and dark launches without cleanup
Platform
Infrastructure as Code
Define and manage infrastructure through versioned code and automated apply, enabling review, repeatability and policy.
When to use it
Environments drift or are snowflakes
Need auditability of infrastructure change
Scaling platform capabilities across teams
Example for a DevOps / SRE
Put infrastructure changes through the same review and pipeline discipline as application code. Add policy-as-code for high-risk misconfigurations.
Things that go wrong
Click-ops alongside IaC creating drift
Giant modules nobody understands
Secrets embedded in state or repos
Operate
Observability
Understand system behaviour from outputs using high-cardinality events, metrics, logs and traces so you can debug novel failures.
When to use it
Incidents stall on missing context
Alerts are noisy or irrelevant
Microservices or distributed systems obscure cause
Example for a DevOps / SRE
Instrument user journeys, correlate with trace IDs, and page only on actionable user impact with runbooks. Delete alerts that never drive action.
Things that go wrong
Dashboard sprawl without owners
Paging on causes instead of symptoms users feel
Collecting everything, querying nothing
Incidents
Incident Command
Structured roles and communications for coordinating restoration during an incident, often adapted from ICS practices.
When to use it
Multi-person incidents become chaotic
Stakeholder updates conflict with technical work
Need clearer tempo and decision rights
Example for a DevOps / SRE
Declare incidents explicitly. Assign commander, technical lead and comms. Keep a timeline. Run blameless reviews with system-level actions.
Things that go wrong
Everyone deep-diving, nobody coordinating
Blame-oriented reviews that silence reporting
Actions without owners or verification
Service management
ITIL change enablement
Risk-appropriate change practices that enable, rather than freeze, delivery when adapted for continuous delivery.
When to use it
CAB has become a status meeting
Need shared language with service management
High-risk changes need human review without blocking standard changes
Example for a DevOps / SRE
Classify standard changes to flow through pipeline evidence. Reserve CAB-like review for truly high-risk changes. Align records with deploy reality.
Things that go wrong
Every change treated as high risk
Change tickets that disagree with production
No learning from incidents into change models
Org design
Team Topologies
Model for aligning team types and interaction modes (stream-aligned, platform, enabling, complicated-subsystem) to reduce cognitive load.
When to use it
Platform team has become a ticket sink
Stream teams blocked on cross-cutting concerns
Need clearer interaction modes (collaborate / X-as-a-service / facilitate)
Example for a DevOps / SRE
Recast DevOps/SRE as platform and enabling work with golden paths as the product. Prefer X-as-a-service over endless collaboration for mature paths.
Things that go wrong
Renaming teams without changing interaction modes
Platform mandates without self-service
Enabling work that never leaves the team stronger
Civil Service / UK cyber
NCSC CAF
NCSC Cyber Assessment Framework for outcomes-based cyber resilience assessment widely used in UK government contexts.
When to use it
UK government cyber assurance conversations
Need to map pipeline and runtime controls to outcomes
Preparing for departmental cyber assessment
Example for a DevOps / SRE
Map CAF outcomes to operated pipeline, identity, logging and incident controls. Keep evidence in the flow so assessment is not a screenshot week.
Things that go wrong
Paper conformance without resilience
Duplicate CAF and ISO stories that disagree
Leaving Detect/Respond outcomes until last
Secure delivery
SLSA / supply chain security
Supply-chain Levels for Software Artifacts: a framework for increasing integrity of build and provenance.
When to use it
Need stronger artefact trust
Build systems are a soft target
Regulated or high-assurance delivery paths
Example for a DevOps / SRE
Raise provenance step by step: known builders, signed artefacts, protected build integrity. Pair with dependency scanning and least-privilege deploy identities.
Things that go wrong
Chasing levels without threat model
Unsigned laptop-built prod artefacts
SBOM generation without using it in response
Reliability validation
Chaos engineering
Experiment on a system to build confidence in its ability to withstand turbulent conditions in production-like environments.
When to use it
Failover and degradation paths are untested
Game days needed before peak events
Error budget allows safe experimentation
Example for a DevOps / SRE
Run controlled experiments against hypotheses (for example, dependency loss). Start in non-prod, then limited prod with abort criteria and strong observability.
Things that go wrong
Chaos without hypothesis or abort
Breaking prod to look advanced
No follow-up fixes after findings
Civil Service standard
GDS Service Standard
Fourteen points for UK public services, including technology, security, performance and iteration expectations that touch operability.
When to use it
UK public service build or iteration
Service assessment preparation
Need reliability and security evidence joined to product quality
Example for a DevOps / SRE
Put operability, performance and security evidence into continuous readiness with Delivery Manager and Product Owner. Avoid assessment-week load tests as your first proof.
Things that go wrong
Paperwork-only assessment prep
Leaving performance and access reviews to the end
Treating operability as optional ops work outside Done
Team methodology
Kanban (for ops / platform)
Visualise work, limit WIP and manage flow. Strong fit for interrupt-driven reliability and platform demand.
When to use it
Interrupt-driven on-call and platform tickets dominate
Need flow metrics more than Sprint theatre
Classes of service must separate expedite from planned work
Example for a DevOps / SRE
Run platform and reliability work on Kanban with WIP limits and explicit expedite policy. Report aging WIP and toil next to DORA.
Things that go wrong
Board without WIP limits
Expedite as the default class
Ignoring blocked age until everything is red
Architecture review
Well-Architected (cloud)
Cloud provider frameworks (AWS, Azure, GCP) for reviewing reliability, security, cost, performance and operational excellence.
When to use it
Cloud estate reviews or new platform designs
Need a structured lens beyond a single team's habits
Cost and reliability trade-offs need a shared checklist
Example for a DevOps / SRE
Run lightweight well-architected reviews on critical services. Turn findings into owned backlog items tied to SLOs and secure pipeline gaps.