ITIL Explained for IT Operations and DevOps Teams: v2/v3 Processes, Lifecycle, and Practical Templates

ITIL (Information Technology Infrastructure Library) is a service management framework used by IT operations, support, and platform teams to deliver reliable services with clear accountability. This revised guide helps you understand the core ITIL concepts from the original article, how the major processes connect, and what practical artifacts teams should standardize.

Originally published on 2010-07-06; fully revised and updated.

Source: original DevOpsSchool article.

What ITIL is and why teams adopt it

In the original post, ITIL is presented as a set of best-practice concepts for IT Service Management (ITSM), IT development, and IT operations. A key theme is that ITIL emphasizes what should be controlled to deliver quality service, while leaving room for each organization to decide how to implement the controls.

• Service quality is managed explicitly, not ad hoc.
• IT services are treated as customer-facing services with measurable outcomes.
• Change and release activities are handled with governance and risk awareness.
• Reporting and auditable performance measures are built into operations.
• Implementation is staged and improved continuously over time.

ITIL v2 and ITIL v3 in context

The original guide describes a shift from process-centric ITIL v2 to lifecycle-oriented ITIL v3, with more emphasis on business integration.

ITIL v3 lifecycle volumes listed in the original guide

• ITIL Service Strategy
• ITIL Service Design
• ITIL Service Transition
• ITIL Service Operation
• ITIL Continual Service Improvement

ITIL v2 process groups from the original guide

The post groups ITIL v2 service management into two areas: Service Support and Service Delivery.

How core ITSM processes connect in day-to-day operations

A practical way to read ITIL is as a connected flow: incidents are restored fast, recurring issues become problems, and permanent fixes move through change and release governance.

flowchart LR
    A[User reports issue] --> B[Service desk logs incident]
    B --> C[Classify impact and urgency]
    C --> D{Quick fix available}
    D -- yes --> E[Restore service and close]
    D -- no --> F[Escalate to resolver team]
    F --> G[Investigate and workaround]
    G --> H{Recurring or unknown root cause}
    H -- yes --> I[Open problem record]
    I --> J[Create RFC for permanent fix]
    J --> K[Plan release under change control]
    H -- no --> E
    K --> E

Standard terms to define in your operating model

• Incident: Unplanned interruption or reduction in service quality.
• Problem: Unknown root cause of one or more incidents.
• Known Error: Root cause understood, with a workaround or permanent fix path identified.
• Workaround: Temporary method to reduce incident impact while permanent remediation is pending.
• Configuration Item (CI): Managed component required to deliver a service.
• CMDB: Repository of CI details and relationships.
• Request for Change (RFC): Formal request to add, modify, or remove a controlled item.
• Forward Schedule of Changes (FSC): Calendar of approved changes and planned implementation windows.

Practical templates you can adapt

ITIL does not prescribe one tool or schema. What matters is consistent, auditable records. The examples below are implementation templates you can adapt to your ticketing system.

incident_record:
  id: INC-2026-00421
  service: payments-api
  ci_reference: app-node-17
  impact: high
  urgency: high
  priority: p1
  symptom: "API latency and timeouts"
  workaround: "Route traffic to standby node"
  opened_by: service-desk
  assigned_group: platform-ops
  status: in_progress
  sla_target_restore_minutes: 60Code language: JavaScript (javascript)

change_request:
  id: RFC-2026-00112
  title: "Patch load balancer TLS library"
  related_problem: PRB-2026-00019
  affected_services:
    - customer-portal
    - payments-api
  risk_level: medium
  implementation_window: "2026-10-18T02:00:00Z"
  test_evidence: "staging validation complete"
  backout_plan: "Rollback to previous package version"
  approval:
    cab_required: true
    approved_by: change-managerCode language: JavaScript (javascript)

availability_percent = ((agreed_service_hours - downtime_hours) / agreed_service_hours) * 100

The availability formula above mirrors the simplified method described in the original post and is useful for basic SLA reporting.

Service desk model comparison

Best practices and common pitfalls

• Start small: implement incident, problem, change, and CMDB controls first, then expand.
• Define priority rules early: impact and urgency must map to a shared priority matrix.
• Treat CMDB quality as a product: stale CI relationships weaken incident triage and change risk analysis.
• Require backout plans: every non-trivial change should have tested rollback steps.
• Separate quick restoration from root-cause elimination: incident and problem management are complementary, not interchangeable.
• Report consistently: daily operational reviews and periodic management reviews are essential for continual improvement.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.