{"id":267,"date":"2026-10-13T05:41:23","date_gmt":"2026-10-13T05:41:23","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2010\/07\/06\/information-technology-infrastructure-library-itil\/"},"modified":"2026-10-13T05:41:23","modified_gmt":"2026-10-13T05:41:23","slug":"information-technology-infrastructure-library-itil","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/information-technology-infrastructure-library-itil\/","title":{"rendered":"ITIL Explained for IT Operations and DevOps Teams: v2\/v3 Processes, Lifecycle, and Practical Templates"},"content":{"rendered":"\n

\"information-technology-infrastructure-library-itil\"<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Originally published on 2010-07-06; fully revised and updated.<\/em><\/p>\n\n\n\n

Source: original DevOpsSchool article<\/a>.<\/p>\n\n\n\n

What ITIL is and why teams adopt it<\/h2>\n\n\n\n

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<\/strong> to deliver quality service, while leaving room for each organization to decide how<\/strong> to implement the controls.<\/p>\n\n\n\n

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

    ITIL v2 and ITIL v3 in context<\/h2>\n\n\n\n

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

    Aspect<\/th>ITIL v2 (released 2001)<\/th>ITIL v3 (published May 2007)<\/th><\/tr><\/thead>
    Primary structure<\/td>Service Support and Service Delivery disciplines<\/td>Service lifecycle model<\/td><\/tr>
    Emphasis in original post<\/td>What should be done to improve service processes<\/td>How to operate across a lifecycle with stronger business alignment<\/td><\/tr>
    Operational impact<\/td>Strong process control foundation<\/td>Better integration across strategy, design, transition, operation, and improvement<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    ITIL v3 lifecycle volumes listed in the original guide<\/h3>\n\n\n\n
    • ITIL Service Strategy<\/li>
    • ITIL Service Design<\/li>
    • ITIL Service Transition<\/li>
    • ITIL Service Operation<\/li>
    • ITIL Continual Service Improvement<\/li><\/ul>\n\n\n\n

      ITIL v2 process groups from the original guide<\/h2>\n\n\n\n

      The post groups ITIL v2 service management into two areas: Service Support<\/strong> and Service Delivery<\/strong>.<\/p>\n\n\n\n

      Group<\/th>Processes called out<\/th>Primary intent<\/th><\/tr><\/thead>
      Service Support<\/td>Configuration Management, Service Desk, Incident Management, Problem Management, Change Management, Release Management<\/td>Restore service quickly, control change risk, and keep configuration records accurate<\/td><\/tr>
      Service Delivery<\/td>Availability Management, IT Service Continuity Management, Capacity Management, Financial Management, Service Level Management<\/td>Plan and govern long-term service quality, resilience, cost, and business alignment<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

      How core ITSM processes connect in day-to-day operations<\/h2>\n\n\n\n

      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.<\/p>\n\n\n\n

      \nflowchart LR\n    A[User reports issue] --> B[Service desk logs incident]\n    B --> C[Classify impact and urgency]\n    C --> D{Quick fix available}\n    D -- yes --> E[Restore service and close]\n    D -- no --> F[Escalate to resolver team]\n    F --> G[Investigate and workaround]\n    G --> H{Recurring or unknown root cause}\n    H -- yes --> I[Open problem record]\n    I --> J[Create RFC for permanent fix]\n    J --> K[Plan release under change control]\n    H -- no --> E\n    K --> E\n<\/pre>\n\n\n\n
      Standard terms to define in your operating model<\/h2>\n\n\n\n
      • Incident:<\/strong> Unplanned interruption or reduction in service quality.<\/li>
      • Problem:<\/strong> Unknown root cause of one or more incidents.<\/li>
      • Known Error:<\/strong> Root cause understood, with a workaround or permanent fix path identified.<\/li>
      • Workaround:<\/strong> Temporary method to reduce incident impact while permanent remediation is pending.<\/li>
      • Configuration Item (CI):<\/strong> Managed component required to deliver a service.<\/li>
      • CMDB:<\/strong> Repository of CI details and relationships.<\/li>
      • Request for Change (RFC):<\/strong> Formal request to add, modify, or remove a controlled item.<\/li>
      • Forward Schedule of Changes (FSC):<\/strong> Calendar of approved changes and planned implementation windows.<\/li><\/ul>\n\n\n\n
        Practical templates you can adapt<\/h2>\n\n\n\n
        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.<\/p>\n\n\n
        incident_record:\n  id: INC-2026<\/span>-00421<\/span>\n  service<\/span>: payments-api\n  ci_reference<\/span>: app-node-17<\/span>\n  impact<\/span>: high\n  urgency<\/span>: high\n  priority<\/span>: p1\n  symptom<\/span>: \"API latency and timeouts\"<\/span>\n  workaround<\/span>: \"Route traffic to standby node\"<\/span>\n  opened_by<\/span>: service-desk\n  assigned_group<\/span>: platform-ops\n  status<\/span>: in_progress\n  sla_target_restore_minutes<\/span>: 60<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n
        change_request:\n  id: RFC-2026<\/span>-00112<\/span>\n  title<\/span>: \"Patch load balancer TLS library\"<\/span>\n  related_problem<\/span>: PRB-2026<\/span>-00019<\/span>\n  affected_services<\/span>:\n    - customer-portal\n    - payments-api\n  risk_level<\/span>: medium\n  implementation_window<\/span>: \"2026-10-18T02:00:00Z\"<\/span>\n  test_evidence<\/span>: \"staging validation complete\"<\/span>\n  backout_plan<\/span>: \"Rollback to previous package version\"<\/span>\n  approval<\/span>:\n    cab_required: true<\/span>\n    approved_by<\/span>: change-manager<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n
        availability_percent = ((agreed_service_hours - downtime_hours) \/ agreed_service_hours) * 100<\/code><\/span><\/pre>\n\n\n
        The availability formula above mirrors the simplified method described in the original post and is useful for basic SLA reporting.<\/p>\n\n\n\n
        Service desk model comparison<\/h2>\n\n\n\n
        Model<\/th>Main focus<\/th>Typical scope<\/th><\/tr><\/thead>
        Call Center<\/td>High-volume call handling<\/td>Transaction handling and routing<\/td><\/tr>
        Help Desk<\/td>Incident resolution coordination<\/td>Restore service as quickly as possible<\/td><\/tr>
        Service Desk<\/td>Business-integrated service interface<\/td>Incidents, requests, communication, and coordination with wider ITSM processes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        Best practices and common pitfalls<\/h2>\n\n\n\n
        • Start small:<\/strong> implement incident, problem, change, and CMDB controls first, then expand.<\/li>
        • Define priority rules early:<\/strong> impact and urgency must map to a shared priority matrix.<\/li>
        • Treat CMDB quality as a product:<\/strong> stale CI relationships weaken incident triage and change risk analysis.<\/li>
        • Require backout plans:<\/strong> every non-trivial change should have tested rollback steps.<\/li>
        • Separate quick restoration from root-cause elimination:<\/strong> incident and problem management are complementary, not interchangeable.<\/li>
        • Report consistently:<\/strong> daily operational reviews and periodic management reviews are essential for continual improvement.<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"
          This guide explains ITIL in clear engineering terms, based on the original post\u2019s v2 and v3 content. You\u2019ll get process relationships, comparison tables, and practical templates you can adapt for incident, problem, change, and release workflows.<\/p>\n","protected":false},"author":1,"featured_media":4441,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[2],"tags":[4306,957,1122,4296,4297,1127,4305,4298,4304,4302,359,4300,4299,213,4301,4303],"class_list":["post-267","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorised","tag-about-information-technology-infrastructure-library","tag-benefits","tag-guide","tag-information-technology","tag-information-technology-infrastructure-library","tag-introduction","tag-it-service-management","tag-itil","tag-itil-overview","tag-itil-v3-library","tag-overview","tag-processes","tag-purpose","tag-tutorial","tag-versions","tag-what-is-itil-process"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/267","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=267"}],"version-history":[{"count":3,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/267\/revisions"}],"predecessor-version":[{"id":79095,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/267\/revisions\/79095"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/4441"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=267"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=267"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=267"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}