Skip to content
Knowledge Hub/Article
Article

What Is DevOps? The DevOps Engineer Role and DORA Metrics

We explain where DevOps came from, its core practices, DORA's five delivery metrics, DevSecOps, how it differs from SRE and how AI is changing it.

Oğuzhan Gerçek··9 min read
What Is DevOps? The DevOps Engineer Role and DORA Metrics

Short answer: DevOps is the combination of culture, practices and tools that brings software development (Dev) and IT operations (Ops) together around one goal: delivering and running applications quickly and reliably. In practice it means small, frequent changes, automated testing and deployment through CI/CD, infrastructure managed as code, and continuous monitoring. Delivery performance is measured with DORA's five metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. "DevOps engineer" is a title whose scope varies from one organization to the next; it usually describes the role that builds and runs this delivery pipeline.

What is DevOps?

As AWS defines it, DevOps is the combination of cultural philosophies, practices and tools that increases an organization's ability to deliver applications and services at high velocity. According to Microsoft, it brings formerly siloed roles such as development, IT operations, quality engineering and security together across every phase, from planning to operations. Google's SRE Workbook calls DevOps a loose set of practices, guidelines and culture designed to break down silos in IT development, operations, networking and security.

As the definition in our glossary stresses, DevOps is an operating model, not a tool. DORA's first study, in 2014, described it as a cultural shift, not just a set of technical practices, that drives significant improvements in IT and organizational performance.

Where did DevOps come from?

According to the series' own site, the first devopsdays, a conference series on software development, IT infrastructure operations and the intersection between them, was held in Ghent, Belgium, in 2009; the page lists Patrick Debois as founder. In July 2010, John Willis summed up DevOps with the acronym CAMS in his post What DevOps Means to Me: culture, automation, measurement and sharing.

Culture, automation, measurement and sharing

Culture comes first on Willis's list: people and process first, because without culture all automation attempts will be fruitless. On measurement he is brief: if you can't measure, you can't improve. Sharing is the loopback that closes the cycle.

According to DORA, an organizational culture that is high-trust and emphasizes information flow is predictive of software delivery performance. DORA uses sociologist Ron Westrum's typology of pathological, bureaucratic and generative cultures, and it recommends blameless postmortems. We show how to write down ownership and escalation during an incident in Reliability Friday 03.

Core DevOps practices

  • Small, frequent changes: According to AWS, frequent but small updates make each deployment less risky.
  • CI/CD: Merging code continuously, testing it automatically and keeping it ready for production at any time (CI/CD article, Git article).
  • Infrastructure as code (IaC): In AWS's definition, provisioning and managing infrastructure using code and software development techniques such as version control and continuous integration. We cover drift in our Terraform and Ansible article.
  • Monitoring and observability: According to DORA, monitoring gathers predefined sets of metrics or logs, while observability lets teams actively debug a system by exploring properties and patterns not defined in advance (observability article).
  • Microservices and containers: According to AWS, in a microservices architecture each service runs in its own process and talks to the others through a well-defined interface, typically an HTTP-based API. We cover packaging services in our Docker article and running them in our Kubernetes article.

How is DevOps measured? DORA's five metrics

According to DORA, five metrics measure the outcomes of the software delivery process, and they also predict organizational performance and team members' well-being:

  1. Change lead time: The time it takes for a change to go from committed to version control to deployed in production.
  2. Deployment frequency: The number of deployments over a given period, or the time between deployments.
  3. Failed deployment recovery time: The time it takes to recover from a deployment that fails and requires immediate intervention.
  4. Change fail rate: The ratio of deployments that require immediate intervention.
  5. Deployment rework rate: The ratio of unplanned deployments that happen as a result of an incident in production.

The first three measure throughput; the last two measure instability. According to DORA's history of the metrics, DORA started with four metrics in 2014; mean time to recover (MTTR) was redefined as failed deployment recovery time in 2023, and rework rate became the fifth metric in 2024. DORA recommends applying the metrics at the application or service level. The goal is for each team to improve over time, not to compete with other teams.

DevSecOps: security inside the flow

AWS notes that when security is the focus of everyone on a DevOps team, this is sometimes referred to as DevSecOps. One framework to lean on is NIST's SP 800-218, the Secure Software Development Framework (SSDF) Version 1.1, published in February 2022. According to NIST, few software development life cycle (SDLC) models explicitly address software security in detail. The SSDF sorts high-level practices that can be integrated into any SDLC into four groups, without prescribing how to implement them:

  • Prepare the Organization (PO): People, processes and technology are prepared to perform secure software development.
  • Protect the Software (PS): All components of the software are protected from tampering and unauthorized access.
  • Produce Well-Secured Software (PW): Releases ship with minimal security vulnerabilities.
  • Respond to Vulnerabilities (RV): Residual vulnerabilities are identified, addressed and prevented from recurring (patch management article).

Version 1.2 (SP 800-218 Rev. 1) was released as a draft for public comment in December 2025; on NIST's publication list, the final version is still 1.1.

What does a DevOps engineer do?

The scope of the title varies from one organization to the next. Google's SRE Workbook describes SRE as somewhat closer to a concrete definition of a job or role than "DevOps engineer." O*NET, the occupational database sponsored by the U.S. Department of Labor, lists DevOps Engineer not as a separate occupation but as one of the reported job titles for Software Developers (15-1252.00). In practice the title covers building CI/CD pipelines, defining infrastructure as code, running container platforms, setting up monitoring and alerts, and adding security controls and secret management to the pipeline.

As the work grows, a platform team that offers shared tooling as an internal platform comes into the picture; DORA describes such a platform as an internal product designed specifically for developers (platform engineering article). You can also take this on as a service: we handle the delivery pipeline in our DevOps & CI/CD Enablement service, the internal platform in DevOps & platform engineering, and day-to-day operations in DevOps solutions.

How DevOps differs from SRE

According to Google's SRE book, SRE (site reliability engineering) is what happens when you ask a software engineer to design an operations team; the SRE Workbook credits Ben Treynor Sloss with coining the term. The Workbook sums up the relationship in programmer's terms: "class SRE implements interface DevOps," meaning SRE is one concrete implementation of the DevOps interface. DevOps is a wider philosophy and culture; SRE has relatively narrowly defined responsibilities and is oriented toward the service and the end user.

According to the book, an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response and capacity planning of its services. Google caps the aggregate "ops" work of its SREs (tickets, on-call, manual tasks) at 50%; the remaining time goes to development. The error budget is one minus the availability target, so a service with a 99.9% target has a 0.1% budget (uptime article).

How is AI changing DevOps?

DORA's 2025 report is titled State of AI-assisted Software Development. Its key finding is that AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses. DORA's research summary adds that the greatest returns come from focusing on the underlying sociotechnical systems. The seven AI-tagged capabilities in DORA's capability catalog include familiar topics such as version control, working in small batches, user-centric focus and platform engineering. On a weak delivery pipeline, AI does not fix the problem; it magnifies it.

Frequently asked questions

What does DevOps mean? The name comes from development and operations; it describes the culture, practices and tools that bring the two teams together around one goal.

What is a DevOps engineer, and what do they do? It is the title for the person who builds and runs CI/CD pipelines, infrastructure as code, container platforms and monitoring. Its scope varies from one organization to the next.

What is the difference between DevOps and Agile? According to Microsoft, Agile is a software development approach that emphasizes team collaboration, customer and user feedback, and adaptability to change through short release cycles. DevOps also covers how those changes reach production and are operated.

What are the DORA metrics? Change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.

What is DevSecOps? It is the shift from security as a separate check at the end to security as the responsibility of everyone on the DevOps team.

Sources