Comparing ITIL and DevOps: Principles, Automation, and Integration Models

Article originally from the public account "Internet Operations Talk".

In today's operations field, the conflict between ITIL and DevOps is still quite evident, both in product aspects and in thinking/philosophy. ITIL designs products with process as the core goal, making it hard to meet automation requirements, while DevOps strongly promotes tools/platforms/self‑service culture; the same applies to philosophy, as ITIL intervenes in an enterprise's IT process with a process‑first approach. Essentially, they are not the same, but focusing on operations, this issue merits comparative discussion.

The latest DevOps framework from EXIN combines many factors, and for the entire product lifecycle it identifies several typical stages such as agile management, continuous delivery, and IT service management.

Of course this article does not simply discuss the superset/subset relationship between DevOps and ITIL, which would allow a straightforward conclusion and end the discussion.

First, let's look at the principles declared by continuous delivery:

Create a repeatable and reliable process for software releases.

Automate almost everything.

Put everything under version control.

Do the painful things early and frequently.

Build quality in.

"DONE" means "released".

The delivery process is the responsibility of every team member.

Continuously improve.

One of these principles – “automate almost everything” – means that continuous delivery covers both the deployment and operations stages of the operational lifecycle. In the past I have emphasized that operations is also a form of delivery. So what is deployment automation? What is operations automation? Deployment automation means using a deployment platform to push changes to development, test, and production environments without relying on a specific person or role. The platform must support all environments—development, testing, production, etc.—and enable techniques such as canary releases and blue‑green deployments. Operations refers to the online running stage, encompassing monitoring, service changes, service optimization, capacity forecasting and planning, and more.

IT operations and product operations share many similarities; the difference lies in the object of focus—IT assets versus product features. Operations involves establishing a service process (including ITIL components), integrating limited internal and external resources to better serve customers. Narrowly, IT operations can be seen as maintenance; broadly, it can include product experience optimization, user satisfaction improvement, application performance management, security, quality control, etc., with quality control being one dimension of IT quality operations.

Since we have discussed automation principles, how should the automation of the operational process be implemented? The following diagram illustrates the approach:

The process can be divided into two parts: an offline, management‑focused task set, and an online, service‑execution set, balancing management and execution. From the current Internet landscape, the influence of ITIL weakens as it moves closer to the application layer, especially in traditional industries where its impact is still limited.

There are three ways to combine the two flows:

Note: the left side represents the management flow, the right side the DevOps execution flow.

Mode One: Every workflow node requires scheduling an execution tool to perform the job.

Advantages: Process efficiency greatly improves, and integration level is high.

Applicable Scenarios: CMDB resource request processes, certain configuration‑change processes, etc. This mode is viewed from the executor’s perspective rather than the approver’s.

Example: A fragment of the CMDB host provisioning process (from a securities company).

Mode Two: The execution flow proceeds only after the approval flow is completed.

Advantages: Process compliance is prioritized while still supporting automation, though overall efficiency does not change significantly.

Applicable Scenarios: Large‑scale changes or release work, or traditional enterprise change processes. This mode balances efficiency and process from a manager’s viewpoint.

Mode Three: A node is added to the execution flow to periodically check the approval status of the management process.

Advantages: Efficiency first, then compliance.

Applicable Scenarios: Internet‑style change‑release processes, continuous delivery pipelines, operational change workflows, etc. This mode is from the executor’s perspective, with efficiency as the primary principle.

Example: In many real‑world customer cases I recommend a similar solution. For instance, when a JIRA system is used for development process management (such as release workflows) and the deployment platform is a separate system, a “Check” node can be added to the change‑upgrade template to inspect the ITIL approval status. If approved, the deployment tool proceeds. This is called the “red‑green‑light mechanism”. It likens ITIL to traffic lights and DevOps execution tools to cars, achieving order, efficiency, and safety simultaneously.

The complexity of the traffic‑light system depends on road congestion, vehicle flow, and other factors, just as enterprise process complexity varies; there is no one‑size‑fits‑all solution.

When evaluating DevOps today, define your IT model by results such as release cycle time and fault‑recovery capability—efficiency must come first. Likewise, when practicing ITIL processes, balance efficiency and simplify workflows with tool‑centric thinking. Both have value in specific scenarios; the three modes above provide reference points for positioning management and execution.

@ITIL focuses on management processes; DevOps focuses on IT operations.

@ITIL is a rule engine; DevOps is an execution engine.

@ITIL emphasizes standards; DevOps emphasizes agility.

@ITIL aims at offline task control; DevOps aims at online service management.

@ITIL does not equal stability pursuit; DevOps does not sacrifice stability for efficiency.

........

Recommended Training

Docker‑Based DevOps Practical Training is a three‑day, closed‑door, paid course taught by instructor Xu Lei in Beijing, scheduled for March 24‑26, 2017. The curriculum combines Xu Lei’s years of DevOps practice with Docker technology, offering strong hands‑on relevance.

Interested participants can call or scan the QR code for more information:

13711264760 (Mr. Li)

For more detailed course information, click “Read Original”.