What is DevOps?
(And what it isn't.)

DevOps is the practice of running software development and software operations as one continuous workflow instead of two separate teams. The engineers who write the code are responsible for building, deploying, and running it in production. The wall between "Dev" and "Ops" disappears.

That definition fits in two sentences. The reason DevOps still confuses engineering leaders 17 years after the term was coined is that it has three layers stacked on top of each other — a culture, a methodology, and a set of job titles — and most teams adopt one or two and skip the third. The teams that ship reliably are the ones that have all three.

This guide covers the practical version: what DevOps actually is in 2026, the five practices that define it, the signs your team is doing it for real, and the failure modes that produce a team called "DevOps" that doesn't deliver any of the outcomes the term promised.

Where DevOps came from (briefly)

Patrick Debois coined the term in 2009 at the first DevOpsDays conference in Ghent. The cultural movement was a reaction to a specific pain: developers shipping code over a wall to operations, operations refusing to deploy because nothing tested, both sides blaming each other when production broke. Cloud (AWS launched 2006) made it possible to treat infrastructure as code that engineers could write themselves. Continuous Integration tools (Jenkins, then GitHub Actions, GitLab CI, CircleCI) made it possible to test every commit. The two trends collided and DevOps was the name we gave to the resulting working model.

By 2026, the term has eaten the entire profession. The 2024 Stack Overflow Developer Survey found 64% of professional developers self-identify as practising DevOps. The 2026 Accelerate State of DevOps Report (DORA) tracks four metrics — deployment frequency, lead time for changes, mean time to recover, change failure rate — that have become the de-facto industry definition of "elite" software delivery performance.

The five practices that define DevOps in 2026

Strip away the marketing and DevOps in 2026 reduces to five practices. Teams doing all five are doing DevOps. Teams doing fewer are using the title.

1. Continuous Integration and Continuous Delivery (CI/CD). Every commit builds, every build runs tests, and every passing build can be deployed automatically to a non-production environment. Production deploys are gated by approval but not by manual orchestration. Lead time from commit to production is measured in hours or days, not weeks. DevOps consulting usually starts here because the rest depends on it.

2. Infrastructure as Code (IaC). Servers, networks, databases, and cloud resources are defined in version-controlled code (Terraform, Pulumi, CloudFormation, Crossplane) and reconciled by automation. The phrase "I'll just SSH into prod and fix it" is rare and audited when it happens. Reproducible environments and blue-green deploys become possible because the infrastructure itself is reproducible.

3. Observability. Three signals (metrics, logs, traces) for every production service. Dashboards that show user-facing health, not just CPU and memory. SLOs that the engineering team understands. When something breaks, an engineer can find the cause without first finding the dashboard. Read our take on the alert fatigue trap for what observability looks like when it's gone wrong.

4. Shared on-call. The engineers who write the code are on the rotation that gets paged when it breaks. Not a separate ops team. Not "tier-1 support." The author of the change. The honesty principle: if your code wakes you up at 3 AM, you have a strong incentive to make sure it doesn't.

5. Blameless post-mortems. Every significant incident produces a written post-mortem. The post-mortem identifies systemic causes, not individuals. The action items are tracked to completion. The post-mortem is shared organisation-wide as a learning artefact, not buried in a Confluence page nobody reads. Without this, the team relearns the same incidents quarterly.

Signs your team is actually doing DevOps

• Mainline deploys to production at least daily, with automated rollback if probes fail.
• Average lead time from merged PR to production is under 24 hours.
• Mean time to recovery (MTTR) for a Sev-2 is under an hour.
• The on-call rotation is staffed by feature engineers, not a separate ops team.
• The post-mortem template is shorter than the runbook template (because the runbook is doing its job).
• An engineer joining the team can deploy to production within their first week.
• Compliance audits don't require a manual deploy freeze.

Signs your team renamed ops to DevOps and changed nothing

• "DevOps" is a separate team that takes tickets from product engineering.
• Production deploys go through a Tuesday change-advisory-board meeting.
• The on-call rotation is exclusively the "DevOps team" of three engineers.
• Infrastructure changes happen via Jira tickets, not pull requests.
• "We do DevOps" but the same five engineers debug every production issue.
• The DORA metrics aren't measured because nobody can agree on the definitions.

If you recognise more from the second list than the first, the issue isn't that DevOps doesn't work. The issue is that your team adopted the title and the tooling without the cultural shift, and the practices haven't taken hold yet.

DevOps vs SRE vs Platform Engineering

The three terms overlap heavily and engineering leaders ask about the differences constantly. The short version:

• DevOps is the cultural and practice layer: shipping velocity, shared ownership, the five practices above.
• SRE (Site Reliability Engineering) is a specific implementation of those practices, originating at Google, focused on production reliability via SLOs, error budgets, and explicit toil reduction. Read our SRE pillar guide for the full picture.
• Platform Engineering is what you build when DevOps practices need to scale to 100+ engineers: a self-serve internal platform that abstracts the complexity so feature teams don't need to be experts in Kubernetes, Terraform, and observability. See why most internal platforms get bypassed.

For the full breakdown of when to invest in each: DevOps vs SRE vs Platform Engineering →

How to start DevOps from a standing start

If your team is closer to the second list than the first, here's the realistic 12-month sequence we run for clients:

1. Months 1–3: Pick the most-painful service, give it a CI/CD pipeline that runs tests on every commit and ships to staging automatically. Pick a Terraform module for the most-painful piece of infrastructure. Pick three SLIs and instrument them. Don't try to convert the whole estate; pick one slice and do it well.
2. Months 4–6: Move feature engineers onto the on-call rotation for the converted slice. Run blameless post-mortems publicly. Use the runbook the on-call writes after the first incident as the template for the rest.
3. Months 7–9: Expand the pattern across services. Standardise the CI/CD template, the IaC modules, the observability instrumentation. Start measuring the four DORA metrics; the goal at month 9 is a baseline you can improve against.
4. Months 10–12: Promote the most successful patterns into a self-serve platform. Decide whether to invest in a platform engineering function. Calibrate the on-call load and toil-reduction goals.

Pitfalls to avoid: don't buy tools first. Don't rename your existing ops team and call it done. Don't try to do DevOps without engineering leadership backing. Don't measure DORA metrics in month one before there's anything to measure.

If your team is in the messy middle of a DevOps transformation — the tools are in but the culture hasn't caught up — that's exactly where InfraZen earns its fee. We run a free 30-minute architecture review that ends in honest, unbiased advice on what to fix first. Talk to us before you buy your next DevOps tool.

Related: DevOps Engineering services · What is SRE? · DevOps vs SRE vs Platform Engineering · Three Kubernetes migration mistakes