--- title: "ITOps" slug: itops category: cloud term_status: established evidence_status: verified summary: "ITOps (IT operations) is the function that keeps an organisation's IT services running: it handles requests and incidents, removes the causes of repeat failures, controls changes and keeps an accurate map of the estate, often through ITIL-style ITSM practices." audience: [IT operations managers, Service-desk leads, Change managers, ITSM process owners, Engineers, Beginners] last_verified: 2026-10-17 key_takeaways: - "ITOps is an established function. Vendors draw the lines between ITOps, ITSM and ITOM differently; this page treats ITSM practices as its process backbone and ITOM tools as its instruments." - "ITIL is the usual reference framework. ITIL 4 (2019) and ITIL (Version 5), introduced in early 2026, coexist; ISO/IEC 20000-1 is the certifiable standard." - "Route changes by risk: pre-authorised standard changes, an authority sized to the risk, an emergency path. DORA research found no evidence that external approval lowers change fail rates; EU DORA's technical standard still requires most EU financial entities (not those on its simplified framework) to keep approving functions independent of requesting and implementing ones." - "An SLA number is only as honest as its clock: the calendar, the pause rules and the priority matrix decide what it means." - "Build the CMDB around the services people consume and measure its health. A CMDB nobody consults for impact or change decisions is cost without value." - "Write down which events may open, update or close an incident, bind every alert to a CI and a service, and take maintenance windows from the change schedule." - "Do not impose heavyweight ITSM on one team that builds and runs one service; keep the light core of incident, change and problem records." related: [serviceops, incidentops, devops, aiops, sre, sysops, patchops, endpointops, knowledgeops, supportops] --- ## What ITOps is ### In 30 seconds **ITOps (IT operations) is the function that keeps an organisation's IT services running day to day.** It gives users one front door for requests and problems, restores service when something breaks, removes the causes of failures that keep coming back, controls changes to live systems, and keeps an accurate map of what the estate contains and what depends on what. Many organisations organise this work with **IT service management (ITSM)** practices, often adapted from ITIL, run on an ITSM platform fed by monitoring, discovery and automation tools (often called **ITOM**, IT operations management). IBM describes ITOps as "the process of implementing, managing, delivering and supporting IT services" for internal and external users;[^ibm-itops] Atlassian's shorter version is "the management and maintenance of IT infrastructure within a business".[^atl-itops] This page follows the service view: users experience services, not servers, and the hardest ITOps decisions (what to fix first, which change is too risky, what an outage affects) are answered in terms of services. **Who this page is for.** IT operations managers, service-desk leads, change managers, ITSM process owners, engineers who connect pipelines and monitoring to ITSM, and beginners; routes by role are in the [learning path](#learning-path). Last verified: 2026-10-17. ### At a glance | Aspect | Summary | |---|---| | Goals | Stable, recoverable IT services; controlled change; measured service levels; evidence for audit as a by-product | | Users | Employees and customers of IT services; service owners; resolver teams; auditors and regulators | | Scope | Service desk, incidents, service requests, problems, change enablement, monitoring and event management, configuration (CMDB), service levels, knowledge inside the ITSM tool | | Prerequisites | None. Basic familiarity with how servers, networks and applications fail helps ([SysOps](../sysops/)) | | Key outputs | Ticket records and queues, a priority matrix, SLA and OLA targets, change models and a change schedule, problem and known-error records, a CMDB, service reports | | Term status | **Established.** IT operations is a long-standing function described by ITIL (since 1989) and ISO/IEC 20000 (since 2005);[^wiki-itil][^wiki-20000] IBM notes it is "more commonly referred to as IT operations or ITOps"[^ibm-itops] | ### The problem ITOps solves Picture an IT department without it. Requests arrive by email, chat and in the corridor, so nobody knows how many are open. The loudest user is served first. An outage is fixed by whoever knows the system and returns three weeks later, because nobody owned the cause. Two teams change the same database on the same evening. When a core switch fails, nobody can say which services sit behind it. The cost is not only downtime. Google's site reliability engineering (SRE) book reports that "roughly 70% of outages are due to changes in a live system",[^sre-intro] so uncontrolled change is a direct reliability risk. Unrecorded assets cannot be patched or protected: the CIS Controls start with an inventory so that an organisation knows "the totality of assets that need to be monitored and protected".[^cis-1] In regulated sectors missing records are themselves a finding: the EU Digital Operational Resilience Act (EU DORA, unrelated to DORA, the DevOps Research and Assessment programme; see the [glossary](#glossary-and-mental-model)) requires financial entities to keep documented ICT change-management controls and to record all ICT-related incidents.[^eu-dora] | Without ITOps practices | With them | |---|---| | Requests scattered over channels; no queue, no age | One front door, a request catalogue, visible queues | | First come or loudest first | Priority from impact and urgency, the same for everyone | | Same incident returns; heroics | Problems, known errors and workarounds; causes removed through change | | Changes collide; outages follow releases | Change types sized to risk, one schedule, post-change checks | | "What does this switch affect?" answered by memory | A CMDB that answers impact questions in minutes | | Contracted SLAs with no measurement | Agreed clocks and reports both sides trust | ### What ITOps is not: boundaries and naming **The naming is genuinely inconsistent.** Three vendor pages, three boundaries: - IBM treats ITOM as a subset of ITOps: "ITOM refers to the management processes and tools used to maintain the technology components", while "ITOps refers to the people, roles and tasks related to IT service management".[^ibm-itops] - Atlassian's ITOps page states that "ITOps and ITOM are interchangeable terms".[^atl-itops] - Atlassian's ITOM page says "ITOM is a subset of IT Service Management".[^atl-itom] ::: note Editorial distinction used on this page **ITOps** is the *function* (people, roles, responsibilities). **ITSM** is the set of *practices* it uses to manage services. **ITOM** is the *technical operations layer and its tools* (monitoring, event management, discovery, automation). This is the Atlas's choice for clarity, not an industry standard; check which boundary any vendor page uses. ::: What belongs elsewhere: - **Not ITIL.** ITIL is a framework you adapt; ITOps is the work. ISO/IEC 20000 or FitSM can serve as the reference instead. - **Not live incident technique.** Commanding and communicating during a major incident is on [IncidentOps](../incidentops/); this page covers incident records, priorities, routing and the problem and change work that follows. - **Not the service model.** Service ownership, the catalogue as a product and service maps are on [ServiceOps](../serviceops/). - **Not DevOps, but it must fit it.** CI/CD and the DORA delivery metrics are on [DevOps](../devops/); ITOps owns the change-enablement interface that pipelines pass through. - **Not AIOps.** Alert deduplication, inhibition and machine-learning correlation belong to [AIOps](../aiops/). Beware the collision: Atlassian's ITOps page uses "AIOps" for an AI virtual agent that triages tickets.[^atl-itops] - **Not customer support.** Support for external customers is [SupportOps](../supportops/); the internal IT service desk is here. Common misconceptions: "ITIL requires a change advisory board (CAB) for every change" (standard changes are pre-authorised, see [change enablement](#change-enablement-in-depth)); "ITSM is the ticketing tool" (the tool records the practice); "a CMDB must contain everything" (it must contain what decisions need, see the [judgement call](#a-judgement-call-discover-everything-or-model-the-critical-services-first)). ## Where ITOps comes from and where it sits ### Origins and evolution The codified form of IT operations comes from the UK government. The Central Computer and Telecommunications Agency (CCTA) developed the recommendations in the 1980s; ITIL was released in 1989 and grew into a series of 30 books.[^wiki-itil] | Year | Milestone | Why it matters for ITOps | |---|---|---| | 1989 | ITIL released by the CCTA (it later grew to 30 books) | A shared vocabulary for IT service processes | | 2005 | ISO/IEC 20000, based on BSI's BS 15000[^wiki-20000] | A certifiable standard for service management systems | | 2007 | ITIL version 3 (service lifecycle) | Operations work sits in the "Service Operation" stage[^atl-itom]; incidents and service requests are separated[^atl-problem] | | 2013 | ITIL acquired by AXELOS (Capita and the UK Cabinet Office) | Commercial stewardship | | 2018 | ISO/IEC 20000-1:2018 (amended 2024) | Current edition of the requirements standard;[^wiki-20000] Amendment 1:2024 adds "Climate action changes"[^iso-amd1] | | 2019 | ITIL 4 | Lifecycle replaced by a set of **practices**[^atl-itom] | | 2021 | PeopleCert completes its acquisition of AXELOS | Current owner of ITIL | | 2026 | PeopleCert announces ITIL (Version 5) in January[^wiki-itil] | Products and services in one lifecycle; ITIL 4 remains available[^pc-v5] | IBM still describes IT operations as one of four ITIL functions;[^ibm-itops] ITIL 4 organises the same work into practices,[^atl-itom] so older job descriptions and newer syllabi name it differently. [DevOps](../devops/) and SRE then challenged approval-heavy change, and DORA's research found that heavyweight change approval hurts delivery performance.[^dora-cab] Wikipedia lists newer ISO guidance parts on SIAM (Part 14, 2023) and on Agile and DevOps (Part 15, 2024).[^wiki-20000] **ITIL (Version 5), as of October 2026.** PeopleCert says it covers "integrated products and services", is "AI-native by design" and is "being introduced through a gradual, phased release"; "ITIL 4 remains available for those who wish to continue their current certification journey".[^pc-v5] The Foundation syllabus keeps the four dimensions of service management.[^pc-found] ITSM.tools reports 34 practices (22 product and service management, 12 general management), that "In ITIL (Version 5), there are no longer any technical management practices", and practice guides due in the second half of 2026.[^itsmtools-v5] This page uses practice names common to both versions. ### Glossary and mental model | Term | Meaning | Example | |---|---|---| | Service | Something IT provides that users value, with an owner and agreed levels | "Payroll", "VPN access", "Intranet" | | Configuration item (CI) | Anything that must be managed to deliver a service: hardware, software, cloud resource, document | A database cluster, a firewall, a SaaS tenant | | CMDB | Database of CIs and their relationships; ITSM effectiveness "depends on the CMDB's data quality"[^wiki-cmdb] | "Payroll depends on payroll-api, which runs on two servers" | | Incident | An unplanned interruption to a service or a reduction in its quality (paraphrasing the ITIL definition Atlassian quotes)[^atl-problem] | Users cannot log in to the VPN | | Service request | A formal user request for something to be provided, such as information, access or equipment[^atl-problem] | Laptop for a new starter | | Problem | "a cause, or potential cause, of one or more incidents" (ITIL, as quoted by Atlassian)[^atl-problem] | A memory leak behind weekly restarts | | Known error | A problem analysed but not yet resolved[^splunk-problem] | Root cause known, fix scheduled; workaround documented | | Workaround | A short-term measure that reduces impact or recurrence while the fix is pending[^splunk-problem] | Restart the service nightly | | Change | Adding, modifying or removing anything that could affect services[^ipm-change] | A firewall rule, a schema migration, a new release | | Standard / normal / emergency change | Pre-authorised low-risk change / assessed and authorised change / urgent change on an expedited path[^snow-change-types] | Certificate renewal / schema migration / patch for an active exploit | | Change authority | The person or body that authorises a given type of change, defined in the change policy[^ipm-change] | Peer reviewer, service owner, CAB | | CAB, ECAB | Change advisory board: "A group of people that advises the Change Manager in the assessment, prioritization and scheduling of Changes"; the emergency CAB is its subset for urgent changes[^ipm-change] | Weekly review of high-risk normal changes | | Event, alert | Event: a change of state that matters for managing a CI or service[^ipm-event]; an alert is the deduplicated record people act on | 300 "host unreachable" events become one alert | | SLA, OLA, UC | Agreement with the customer; internal agreement between teams that supports it; contract with a third-party supplier[^wiki-ola][^ipm-uc] | 8-hour resolution for P2 incidents | | ITSM, ITOM, ITAM | Service management practices; technical operations tooling; IT asset management (financial and contractual life of assets) | ServiceNow ITSM; discovery; licence records | | DORA (research), EU DORA (law) | DevOps Research and Assessment, acquired by Google in 2018, now "a program run by Google Cloud";[^dora-google] versus the EU's Digital Operational Resilience Act, binding on financial entities[^eu-dora] | "DORA found…" is evidence; "EU DORA requires…" is law | | SRE, SLO, error budget | Site reliability engineering; a service level objective (an internal reliability target); the unreliability an SLO tolerates, which a team can spend on change ([SRE](../sre/)) | SLO 99.9% of requests succeed in 30 days; budget 0.1% | **The mental model: four flows over one map, governed by agreements.** *Demand* flows in as requests. *Disruption* flows in as incidents and is drained by problems. *Change* flows out to the estate, sized to its risk. *Signals* flow in from monitoring as events. All four refer to the same *map* (the CMDB and service model), so every ticket, change and alert names its service. *Agreements* (SLA, OLA, UC) set the clocks. Most ITOps failures are a broken link: changes without the map, incidents without problems, alerts without a service, clocks without agreement. ### How ITOps relates to other Ops ::: figure Where ITOps sits among its neighbours ```mermaid flowchart TB OBS["ObservabilityOps"] -->|"telemetry"| ITO AIO["AIOps"] -->|"correlated alerts"| ITO DEV["DevOps"] -->|"change records"| ITO ITO["ITOps: practices and controls"] ITO -->|"major incidents"| INC["IncidentOps"] ITO <-->|"service model"| SVC["ServiceOps"] ITO -->|"change approval"| PAT["PatchOps, EndpointOps"] ITO ---|"SLOs, toil"| SRE["SRE"] classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 class ITO core class OBS,AIO,DEV,INC,SVC,PAT,SRE neutral ``` Text equivalent: ObservabilityOps supplies telemetry, AIOps correlated alerts and DevOps pipelines change records, all flowing into ITOps, which owns the practices and controls (requests, incidents, problems, change, the CMDB and service levels). ITOps hands major incidents to IncidentOps, exchanges the service model with ServiceOps, approves the changes that PatchOps and EndpointOps programmes need, and works alongside SRE on SLOs and toil. ::: | Neighbour | Shared scope | ITOps focus | Go there for | |---|---|---|---| | [ServiceOps](../serviceops/) | Services, SLAs, CMDB | The practices that run services | Service ownership, catalogue design, service maps | | [IncidentOps](../incidentops/) | Incidents | Records, priority, routing, problem follow-up | Declaring, commanding and communicating live | | [DevOps](../devops/) | Change, deployment | Change enablement, CAB policy, change records | CI/CD, DORA metrics, delivery culture | | [SRE](../sre/) | Service levels, toil | SLAs and OLAs as agreements | SLOs, error budgets, reliability engineering | | [AIOps](../aiops/) | Event noise | Which alerts may open, update or close incidents; CI binding; maintenance windows from the change schedule | Deduplication, grouping, inhibition, ML correlation and its evaluation | | [SupportOps](../supportops/) | Ticket queues | Internal IT service desk | External customer support, staffing maths | | [KnowledgeOps](../knowledgeops/) | Knowledge articles | Linking articles to incidents and known errors | KCS method, ownership, freshness | | [PatchOps](../patchops/), [EndpointOps](../endpointops/) | Change, assets | Change authority and CMDB records | Patch programmes, device management | | [SysOps](../sysops/) | Servers, routine operations | Records for host incidents and changes | Host-level diagnosis and administration | | [CloudOps](../cloudops/) | Cloud change and incidents | ITIL practices applied to cloud | Provider control plane, guardrails | ## Principles and operating model ### A proposed charter and principles ITIL's seven guiding principles, such as "Focus on value" and "Keep it simple and practical",[^wiki-itil] are deliberately general. The charter below is **this Atlas's proposal**, written to be testable. > **Mission.** Keep IT services available, recoverable and changeable at the pace the business needs, and prove it with records > rather than assurances. > > **Measurable goals (set the numbers locally).** Every production service has an owner and a CMDB entry; P1 and P2 targets met for > the agreed share of tickets; repeat incidents fall quarter on quarter; at least half of changes run as standard changes with a > post-change check; every emergency change is reviewed within five working days. > > **Non-goals.** Running every change through one meeting; recording every attribute of every asset; certifying people instead of > improving services. Six invariants follow: 1. **Every live service has an owner and a place on the map.** A CI that cannot be linked to a service means the CI or the map is wrong. 2. **Restore first, then remove causes.** Incident management minimises impact; problem management removes causes. 3. **Control in proportion to risk.** DORA lists "Treating all changes equally." among change-approval pitfalls.[^dora-cab] 4. **Measure what users experience, with clocks both sides agreed.** 5. **One record per thing:** one ticket per incident, one change record per change, one CI per asset; audits fail on shadow spreadsheets. 6. **Automate the routine, keep people for judgement, and capture evidence as a by-product.** ### Fundamentals: the practice chain The practices are not a list; they hand work to each other. The figure shows the main handoffs. ::: figure The ITOps practice chain: how work moves between practices ```mermaid flowchart TB EV["Monitoring: events"] -->|"deduplicate"| AL["Alert"] AL -->|"actionable"| IN["Incident"] US["User report"] --> SD["Service desk"] SD --> IN SD --> RQ["Service request"] RQ --> FU["Fulfilment, often automated"] IN -->|"recurring or major"| PR["Problem"] PR --> KE["Known error and workaround"] KE -->|"workaround"| SD KE -->|"permanent fix"| CH["Change"] CH --> DP["Deployment"] DP -.->|"failed change"| IN CM[("CMDB and service model")] -.-> IN CM -.-> CH classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 class SD,IN,RQ,PR,KE,CH core class EV,AL,US,FU,DP,CM neutral ``` Text equivalent: monitoring events are deduplicated into alerts, and actionable alerts become incidents. Users reach the service desk, which opens incidents or service requests; requests go to fulfilment, often automated. Recurring or major incidents open a problem, which produces a known error with a workaround; the workaround goes back to the service desk and the permanent fix becomes a change, then a deployment. A failed change loops back as a new incident. The CMDB and service model inform both incidents (impact) and changes (risk). ::: ### Roles, ownership and RACI ITIL describes practices, not an organisation chart, so role names vary. The roles that matter: the **service owner** (accountable end to end, including the SLA and accepted risks); one **practice owner** per practice (policy, metrics, improvement); the **service desk**; **resolver groups** (often product teams); a **problem coordinator**; the **change manager** and the **change authorities** per risk class; the **configuration manager** and **CI owners**; and the **ITSM platform owner**. | Activity | Service desk | Resolver group | Service owner | Practice owner | Change authority | |---|---|---|---|---|---| | Log, classify and prioritise a ticket | R/A | C | I | C (rules) | — | | Restore service for an incident | R (first contact) | R/A | I | — | — | | Open and analyse a problem | C | R | A | C | — | | Propose and maintain a standard change model | — | R | C | A (model catalogue) | C | | Authorise a standard change model | — | I | C | C | A | | Authorise a normal change | — | R (requests) | C | I | A | | Keep CI records accurate | — | R | A (for its CIs) | C (data rules) | — | | Set SLA targets and report on them | I | C | A | R (reporting) | — | R = responsible, A = accountable, C = consulted, I = informed. Authorising a model pre-authorises every change that follows it, so it sits with a change authority outside the team that runs the procedure. **Team patterns** (compared under [Deep comparisons](#deep-comparisons)): a *central model* (desk in front of specialist resolver groups), a *product model* (tickets go to the team that builds and runs the service) and a *multi-supplier model* (SIAM; guidance in ISO/IEC 20000-14).[^wiki-20000] Intelligent Swarming, from the Consortium for Service Innovation, replaces tiered escalation by routing work to the people best placed to help: "Traditional tiered support structures cannot keep up with the demand of complex work in knowledge-intensive environments".[^swarming] ### Lifecycle of a service in ITOps | Stage | ITOps work | Exit evidence | |---|---|---| | Day 0: design for operability | Register the service, CIs and owners; agree SLA and OLAs; define request types and standard change models; alert routing; runbooks | Acceptance checklist signed by the service owner and operations lead | | Day 1: transition | Go-live as a planned change; early life support (extra monitoring, a named contact); knowledge articles; desk briefed | No open P1/P2 from the launch; desk resolves the top five expected contacts | | Day 2: operate and improve | Incidents, requests, problems, changes; monthly service review; quarterly review of standard change models and CMDB quality | Service report against targets; improvement backlog with owners | | Retirement | Decommission as a change; remove CIs, accounts, licences and monitoring; archive records per retention policy | No orphan CIs or active licences left behind | ### Operating model and governance Governance in ITOps is mostly cadence: the same few forums, held reliably, each with a defined input and output. | Cadence | Forum | Input | Output | |---|---|---|---| | Daily | Queue triage (desk lead plus resolver leads) | Tickets at risk of breach, unassigned, bouncing between groups | Owners and escalations | | Weekly | Change review | Normal changes above the delegated tier, the forward schedule, last week's failed and emergency changes | Authorisations, schedule conflicts resolved, lessons | | Weekly | Problem triage | New problem candidates, ageing known errors | Prioritised problems, owners | | Monthly | Service review with each major customer | SLA report, top incidents and problems, upcoming changes | Agreed actions; SLA disputes resolved | | Quarterly | Practice review | Metrics per practice; standard change model failure rates; CMDB health | Policy changes; models added or suspended | | Annually | Agreement and audit cycle | SLAs, OLAs, supplier contracts; internal audit (ISO/IEC 20000 if certified) | Renewed agreements; audit findings closed | **Escalation** is *functional* (to a more capable team) or *hierarchical* (to managers, when a target or customer relationship is at risk). Write both into the policy with triggers ("P2 at 75% of its clock without an owner"), not names. ## Architecture and workflow ### Reference architecture ITOps architecture is about records and the integrations that keep them current. The design is vendor-neutral: most ITSM suites implement every box; open-source stacks combine several products. ::: figure Reference architecture: one system of record behind two trust boundaries ```mermaid flowchart TB U["Users: portal, chat"] --> IDP["Trust boundary: identity provider (SSO, roles)"] M["Monitoring"] --> EM["Event rules"] P["CI/CD pipelines"] -->|"create changes, never approve"| API D["Discovery, cloud APIs"] -->|"write CIs"| API EM -->|"open, update, close"| API API["Trust boundary: API, one least-privilege account per integration"] IDP --> ITSM API --> ITSM["ITSM platform: tickets, approvals, SLA clocks"] API --> CMDB[("CMDB and service model")] ITSM <--> CMDB ITSM --> ONC["On-call"] ITSM --> KB["Knowledge base"] ITSM --> RPT["Reports"] classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 class ITSM,CMDB,EM core class U,M,P,D,ONC,KB,RPT neutral class IDP,API risk ``` Text equivalent: two nodes labelled "Trust boundary" (outlined in red) guard the system of record. People reach the ITSM platform through the identity provider (single sign-on, roles). Machines reach it through the API, one least-privilege account per integration: CI/CD pipelines create change records but never approve them, discovery and cloud APIs write CIs into the CMDB, and event rules fed by monitoring open, update and close incidents. The ITSM platform (tickets, approvals, SLA clocks) exchanges data with the CMDB and drives on-call paging, the knowledge base and reports. ::: | Component | Responsibility | Design choice and trade-off | |---|---|---| | ITSM platform | System of record for tickets and changes; workflow, approvals, SLA clocks | One suite simplifies reporting; tools per team keep autonomy but need shared IDs | | CMDB and service model | CIs, relationships, owners, service membership | Discovery and integrations; manual entry only for what machines cannot see (owners, contracts) | | Event management | Turn events into a small number of actionable alerts and incidents | ITOps writes the event-to-incident policy; deduplication, inhibition and ML correlation are [AIOps](../aiops/) mechanics | | Identity and access (the two trust boundaries) | SSO, roles, integration accounts | One least-privilege account per integration; a pipeline that can create *and* approve changes defeats segregation of duties | Treat the event-management layer as a production dependency: if it fails silently, the service desk learns about outages from users. ### End-to-end workflow The happy path below follows one recurring fault from the first user report to the permanent fix. The exception paths are described after it. ::: figure From a user report to a permanent fix ```mermaid sequenceDiagram participant U as User participant SD as Desk participant RT as Resolver participant PC as Problem and change U->>SD: VPN drops (portal) SD->>SD: Prioritise, check known errors SD->>RT: Assign P3 incident RT->>SD: Workaround applied SD->>U: Service restored RT->>PC: Third time: open problem PC->>PC: Cause found, known error PC->>PC: Firmware change authorised PC->>RT: Fix deployed RT->>SD: Fix verified, problem closed SD->>U: Linked incidents closed ``` Text equivalent: a user reports VPN drops through the portal. The desk prioritises the ticket, checks known errors and assigns a P3 incident to the resolver team, whose workaround restores service. On the third occurrence the resolver opens a problem; the cause is found and recorded as a known error, a firmware change is authorised and deployed, the resolver verifies the fix, and the desk closes the linked incidents. ::: The decisions are classification, priority, routing, whether to open a problem and which change type the fix needs; the monthly service review checks whether incidents of this kind stopped. **Exception paths.** - **Clock at risk.** At a set share of the SLA clock (for example 75%) without progress, the ticket escalates functionally to a more capable group and hierarchically to the desk lead. - **Major incident.** If impact crosses the declared threshold, the ticket becomes a major incident and live command follows [IncidentOps](../incidentops/); ITOps keeps the record, links child incidents and opens the problem afterwards. - **Misrouting.** A ticket that changes group more than twice goes to daily triage. - **No fix is economic.** The problem stays a known error with a documented workaround, an owner and a review date. ## Practices, frameworks and tools ### Core practices and playbooks The practice definitions quoted here are ITIL wording as reported by ITSM.tools; the full texts are in licensed ITIL publications.[^itsmtools-v5] | Practice | Goal | Trigger | Owner | Output | Verification | |---|---|---|---|---|---| | Service desk | "the entry point and single point of contact" for users | Any user contact | Desk lead | Classified, prioritised ticket | First-contact resolution, reassignment rate | | Incident management | "minimizing the negative impact of incidents by restoring normal service operation as quickly as possible" | Report or alert | Incident practice owner | Restored service, incident record | Resolution within the SLA clock; reopen rate | | Service request management | Deliver agreed, predefined requests | Catalogue request | Request practice owner | Fulfilled request | Fulfilment time; automation share | | Problem management | "reducing the likelihood and impact of incidents by identifying actual and potential causes" | Recurring or major incident; trend | Problem practice owner | Known error, workaround, fix via change | Repeat-incident rate | | Change enablement | "ensuring that risks are properly assessed, authorizing changes to proceed" and managing the schedule | Change request | Change manager | Authorised, scheduled, reviewed change | Change success rate; emergency share | | Monitoring and event management | "systematically observing services and service components" and acting on significant events | Event | Monitoring owner | Alert, incident or automated action | Actionable-alert share | | Service configuration management | "accurate and reliable information about the configuration of services" | Any change to the estate | Configuration manager | Current CMDB | Completeness, staleness, duplicates | | Service level management | Agree, measure and review service levels | Service onboarding; review cycle | Service owner | SLA, OLAs, reports | Attainment; disputes | Knowledge inside the ITSM tool (linking articles to incidents and known errors) belongs here; the knowledge method itself (KCS, article ownership, freshness) is taught on [KnowledgeOps](../knowledgeops/). **Operations control.** In ITIL V3 (2007), as the IT Process Wiki summarises it, IT operations management "executes day-to-day routine tasks related to the operation of infrastructure components and applications"; IT operators' typical responsibilities include "Performing backups, ensuring that scheduled jobs are performed".[^ipm-itom][^ipm-roles] The work remains: an operations bridge or network operations centre (NOC), job scheduling, backup and restore runs, routine maintenance, shift handover. ITOps owns the records (a failed job or restore test is an incident, routine maintenance a standard change); the technique is on [SysOps](../sysops/), [BackupOps](../backupops/), [AutomationOps](../automationops/) and [PatchOps](../patchops/). **Other ITIL practices and where the Atlas covers them.** Of the 22 product and service management practices in ITIL (Version 5),[^wiki-itil] the eight above are taught here. Availability, capacity and performance → [SRE](../sre/) and [CloudOps](../cloudops/); service continuity → [DisasterRecoveryOps](../disasterrecoveryops/); IT asset management → [EndpointOps](../endpointops/) for devices and [FinOps](../finops/) for cost; deployment and release → [DevOps](../devops/) and [ReleaseOps](../releaseops/); infrastructure and platform management → [InfraOps](../infraops/) and [PlatformOps](../platformops/); information security → [SecOps](../secops/); service catalogue and service design → [ServiceOps](../serviceops/). #### Playbook: service requests 1. **Catalogue what is asked for most:** the top 20 recurring requests become items whose forms collect what fulfilment needs. 2. **Define fulfilment per item:** approval (manager, budget or data owner), fulfilment group, target time. 3. **Automate deterministic steps** (application access, approved software, a mailbox) behind the approval; access requests also need the identity controls on [AccessOps](../accessops/). 4. **Accept** an item when a test request completes end to end; **roll back** a misfiring automation to manual fulfilment. #### Playbook: problem management Problem management is commonly taught in three phases: problem identification, problem control and error control (for example in Splunk's ITIL guide).[^splunk-problem] In practice: *identify* candidates from trends, major incidents and supplier advisories (ask "what came back?" in weekly triage); *control* by giving each problem an owner who can get engineering time and publishing a workaround early; in *error control* choose between a permanent fix through change and accepting the known error, reviewed quarterly. Atlassian warns that a heavy, siloed process becomes a "dumping ground of problems";[^atl-problem] keep a short active list with owners and next actions. #### Playbook: monitoring and event management Splunk's summary of ITIL 4 sorts events into *informational* (no action needed), *warning* (unusual; act before users feel it) and *exception* (failure or degradation that affects the business), noting that "what is a warning to one team may be an exception to another";[^splunk-event] agree them per service. The event layer deduplicates, groups and inhibits alerts ([AIOps](../aiops/#lab-1-beginner-group-and-inhibit-with-alertmanager) owns those mechanics); ITOps writes the policy for what reaches the incident queue: 1. **Bind every alert to a CI and a service** from the CMDB, so priority follows the service's impact. An alert with no CI still opens an incident at a default priority, flagged as a CMDB gap: never drop an exception silently. 2. **Act by category.** Informational events go to logs; warnings notify the owning team or trigger automation; exceptions open an incident, or update the one already open for the same alert. 3. **Take maintenance windows from the change schedule.** Alerts on CIs inside an approved change's window attach to the change instead of paging anyone; when the window ends, re-check alerts still open before opening incidents. 4. **Close by rule.** A clear event resolves an incident nobody has worked on; on a worked incident it only adds a note. 5. **Accept** the policy when a replay of last month's alerts gives one incident per real disruption and no duplicates; **roll back** if a real fault goes unreported. [Lab 4](#lab-4-advanced-decide-which-alerts-open-update-or-close-incidents) runs it. ### Change enablement in depth ITIL 4 first called this practice "change control" and later renamed it "change enablement":[^ipm-change] the aim is change at the speed the business needs, with its risk visible. Three change types are common: - **Standard change:** "a pre-authorized change that is low risk, relatively common and follows a specified procedure or work instruction" (ServiceNow's definition); no per-change approval is needed.[^snow-change-types] - **Normal change:** "Any service change that is not a standard change or an emergency change"; ServiceNow's default model needs assessment, peer or technical approval and CAB authorisation.[^snow-change-types] Atlassian notes that low-risk normal changes can be approved "by a designated change authority or through automated checks and peer review".[^atl-change-types] - **Emergency change:** "A high-priority change implemented immediately to resolve a major incident or apply a security patch"; in ServiceNow's model it skips group and peer review and goes straight to CAB authorisation.[^snow-change-types] The design question is who the **change authority** is for each class. ITIL leaves it to the organisation, which defines "the required Change Authorities in their Change Policy".[^ipm-change] DORA's research favours delegating as far as risk allows: it found no evidence that a more formal, external review process was associated with lower change fail rates, recommends peer review to meet segregation of duties, and describes the CAB's new role as a transition "from gatekeeper to process architect and information beacon".[^dora-cab] The [DevOps judgement call](../devops/#a-judgement-call-keep-the-change-advisory-board-or-replace-it) works through re-chartering a CAB; this page gives the mechanics. ::: caution Two DORAs: peer review meets "independence of the functions" For EU financial entities, Article 17(1) of Delegated Regulation (EU) 2024/1774, EU DORA's technical standard on ICT risk management, requires change procedures to include "mechanisms to ensure the independence of the functions that approve changes and the functions responsible for requesting and implementing those changes", and "procedures to document, re-evaluate, assess, and approve emergency changes after their implementation, including workarounds and patches".[^eu-rts-1774] DORA *research* supports peer review;[^dora-cab] whether a same-team peer counts as an independent *function* is for the entity and its supervisor to settle. A risk-tiered design can satisfy both: standard change models authorised by a change authority outside the implementing team, low-risk changes reviewed by someone other than the author (the pipeline cannot approve), high-risk changes approved outside the team, and every emergency change approved and recorded afterwards. Firms on EU DORA's simplified framework (its Article 16(1)) have a shorter requirement (Article 38 of the same standard). ::: ::: figure Routing a change to the right authority ```mermaid flowchart TB S["Change request"] --> E{"Outage or active threat?"} E -- "Yes" --> EM["Emergency: authorise now, review within days"] E -- "No" --> M{"Standard model fits?"} M -- "Yes" --> H{"Model healthy?"} H -- "Yes" --> ST["Standard: pre-authorised, logged, post-check"] H -- "No" --> R["Assess as normal change"] M -- "No" --> R R --> SC{"Risk score"} SC -- "Low" --> PR["Peer review and automated checks"] SC -- "Medium" --> SO["Service owner approves"] SC -- "High" --> CAB["CAB review"] classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 class ST,PR,SO core class E,M,H,SC decision class EM,CAB,R risk ``` Text equivalent: a change for an outage or active threat goes to the emergency authority now and is reviewed within days. Otherwise, if a standard change model fits and is healthy (recent failures within its limit), it runs pre-authorised with a log entry and a post-change check. Everything else is assessed as a normal change and routed by risk score: low to peer review and automated checks, medium to the service owner, high to the CAB. ::: Five mechanics make this work: 1. **Change models with a health limit.** A standard change model is an approved procedure, its scope (services, CIs) and a failure limit; above the limit, suspend it and assess its changes as normal ([Lab 2](#lab-2-intermediate-route-changes-by-risk)). 2. **A written risk score** from observable factors (service tier, tested rollback, data change, security controls, first time, outside the maintenance window), with weights reviewed against failed changes each quarter. 3. **One forward schedule** with freeze windows and automatic conflict detection on the same CI or service. 4. **Evidence from the pipeline.** The pipeline creates the change record, attaches test and review evidence and records the result ([reference implementation](#reference-implementation)); Jira Service Management documents the same pattern with deployment gates.[^atl-itsm-guide] 5. **Close the loop.** Review every failed and emergency change; send repeated failures to problem management rather than adding approval layers (DORA lists "Responding to problems by adding more process." as a pitfall).[^dora-cab] **Unauthorised change** (a change without a record) is detected, not prevented, by comparing discovery and drift with change records ([InfraOps](../infraops/), [GitOps](../gitops/)); treat each first as a sign that the approved path was too slow. ### Service levels: SLAs, OLAs and underpinning contracts A **service level agreement (SLA)** is "a documented agreement between a service provider and a customer that defines the expected service", including metrics such as response and resolution time and what happens when targets are missed.[^atl-sla] An **operational level agreement (OLA)** "defines interdependent relationships in support of a service-level agreement"; it is an internal agreement between teams, and "OLA is not a substitute for an SLA".[^wiki-ola] An **underpinning contract (UC)** is "a contract between an IT service provider and a third party" whose services the provider needs to deliver its own.[^ipm-uc] ::: figure How internal and supplier agreements must fit inside the customer SLA ```mermaid flowchart TB C["Customer: P2 resolved in 8 business hours (SLA)"] --> SD["Service desk: triage and assign in 30 min (OLA)"] SD --> NW["Network team: diagnose in 2 h (OLA)"] NW --> V["Carrier: circuit repair in 4 h (UC)"] V --> B["Buffer for verification and closure: 1.5 h"] classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 class C core class SD,NW neutral class V,B risk ``` Text equivalent: an illustrative chain. The customer SLA promises P2 resolution in 8 business hours. Inside it, the service desk has an OLA to triage and assign within 30 minutes, the network team an OLA to diagnose within 2 hours, and the carrier an underpinning contract to repair a circuit within 4 hours, leaving 1.5 hours for verification and closure. ::: The arithmetic is the core skill: 0.5 + 2 + 4 + 1.5 = 8 hours. If the carrier contract says "next business day", the SLA is unachievable for any carrier fault; change the SLA, the contract or the architecture (a second circuit), not the desk's report. **Designing the clock.** Three decisions turn a target into a number: 1. **Priority.** ServiceNow, for example, derives priority from impact, "a measure of the effect of an incident, problem, or change on business processes", and urgency, "a measure of how long the resolution can be delayed"; its sample lookup table is below.[^snow-priority] 2. **Calendar.** Which hours count (for example 24x7 for P1, business hours for the rest), with public holidays. 3. **Start, pause and stop.** Jira Service Management Cloud, for example, sets conditions under "Start counting time when", an optional "Pause counting time when" (such as waiting for a customer) and "Finish counting time when"; measurement stops when any finish condition is met.[^jsm-sla-cond] | Impact ↓ / Urgency → | 1 - High | 2 - Medium | 3 - Low | |---|---|---|---| | **1 - High** | 1 - Critical | 2 - High | 3 - Moderate | | **2 - Medium** | 2 - High | 3 - Moderate | 4 - Low | | **3 - Low** | 3 - Moderate | 4 - Low | 5 - Planning | In this sample table, priority equals impact plus urgency minus one. Define impact in business terms users recognise (users affected, a named critical process, money or safety). [Lab 1](#lab-1-beginner-build-an-honest-sla-clock) shows how a pause turns a breach into a pass. An SLA for an engineered service is often backed by an internal SLO ([SRE](../sre/)). ### Methods, standards and frameworks | Framework | Type | What it gives ITOps | Mandatory? | |---|---|---|---| | ITIL 4 and ITIL (Version 5) | Proprietary guidance framework (PeopleCert) | Vocabulary, 34 practices, guiding principles, four dimensions[^wiki-itil][^pc-found] | No; adopt and adapt | | ISO/IEC 20000-1:2018 (amended 2024) | International standard, certifiable | Requirements for "establishing, implementing, maintaining, and continually improving a service management system"[^wiki-20000] | Only if you seek or are contractually required to hold certification | | COBIT 2019 (ISACA) | Governance framework | ISACA calls it "the premier framework for the governance and management of enterprise IT", with 40 governance and management objectives in its core model[^cobit] | No; often used by auditors | | FitSM | Free, lightweight ITSM standard | "The Free, Lightweight ITSM Standard", first developed in the EU-funded FedSM project (2012–2015)[^fitsm] | No; good for small or federated providers | | DORA research (Google Cloud) | Research findings | Evidence on change approval and delivery performance[^dora-cab] | No | | EU DORA, Regulation (EU) 2022/2554 | Law (EU financial sector) | Documented ICT change management; incident management, classification and reporting; applies since 17 January 2025[^eu-dora][^eiopa-dora] | Yes, for in-scope financial entities | | EU DORA technical standards: Delegated Regulations (EU) 2024/1774 and 2025/301 | Law (EU financial sector) | Change procedures with approval independent of requesting and implementing functions and post-implementation approval of emergency changes (2024/1774, Art. 17);[^eu-rts-1774] major-incident report time limits (2025/301, Art. 5)[^eu-rts-301] | Yes, for in-scope financial entities | | NIS2, Directive (EU) 2022/2555 | Law (EU essential and important entities) | Significant-incident reporting: early warning within 24 hours, notification within 72 hours, final report within one month[^nis2] | Yes, as transposed nationally | | CIS Controls v8.1, Control 1 | Security baseline | Asset inventory as the first control[^cis-1] | No; widely referenced | Law and contractual certification are mandatory for those in scope; ITIL, COBIT and FitSM are choices, although Atlassian calls ITIL "the most widely used framework for ITSM".[^atl-itom] EU DORA requires "documented policies, procedures and controls for ICT change management", "based on a risk assessment approach", so that changes are "recorded, tested, assessed, approved, implemented and verified" in a controlled manner.[^eu-dora] Neither it nor its technical standard requires a weekly CAB; the risk-based wording fits risk-tiered authorities, and the independence requirement constrains who they can be ([two DORAs](#change-enablement-in-depth)). ### Tooling landscape (as of October 2026) | Tool category | Job | Representative options (verified on vendor pages, October 2026) | Selection criteria | Lock-in and risks | |---|---|---|---|---| | ITSM platform | Tickets, workflows, approvals, SLA clocks, portal | ServiceNow; Jira Service Management (part of Atlassian's "Service Collection")[^atl-itsm-guide]; GLPI (open source; GLPI 12 advertised as the new major version)[^glpi]; iTop (open-source ITSM and CMDB, 3.3 dated 2026-09-15)[^itop] | Data model, API quality, per-agent licensing, admin effort | Custom workflows become migration debt | | CMDB, assets and discovery | CIs, relationships, health | ServiceNow CMDB with health KPIs;[^snow-cmdb-health] Atlassian Assets[^atl-itsm-guide]; iTop | Discovery coverage (cloud, network, SaaS), reconciliation rules, relationship model | Discovery agents need privileged credentials | | Event management | Deduplicate, group, suppress, route | Prometheus Alertmanager (open source)[^alertmanager]; ServiceNow Event Management;[^snow-events] JSM alert grouping[^atl-itsm-guide] | Rule expressiveness, maintenance windows, CI binding | A silent failure here hides outages | | On-call and paging | Reach a human | Compared, with dated product exits, on [IncidentOps](../incidentops/#tooling-landscape-as-of-october-2026). For ITSM buyers: Atlassian says Opsgenie shuts down on 2027-04-05, deleting unmigrated data, and most of its features are now in Jira Service Management[^atl-opsgenie] | Service-model integration, escalation policies | Plan migrations before end-of-support dates | | Pipeline integration | Change records from CI/CD | ServiceNow Change Management API;[^snow-chg-api] JSM deployment gating[^atl-itsm-guide] | Standard change model support, evidence fields | Over-broad API credentials | | Runbook automation | Scripted fulfilment and remediation | See [AutomationOps](../automationops/) | Approval and audit | Unreviewed scripts with admin rights | Vendor-neutral first: decide practices, data model and integrations, then trial tools on three real request types, one pipeline-fed standard change model and one CMDB impact query. ### Automation and AI Automation pays first where work is frequent, deterministic and well understood: catalogue fulfilment, pipeline-fed standard changes, closing incidents whose alerts clear. The SRE book's definition of toil (manual, repetitive, automatable, tactical, without enduring value) is a good test.[^sre-toil] Generative AI is now built into the major ITSM platforms. ServiceNow's documentation (Zurich release, updated 2025-07-31) lists skills such as incident summarisation, resolution-notes generation, knowledge article generation and change request risk explanation.[^snow-ai] Atlassian describes "Rovo Ops" investigating likely root causes and drafting post-incident reviews, and AI-assisted change risk assessment.[^atl-itsm-guide] These are vendor descriptions, not measured outcomes. Published evidence is thin. A preprint by authors at Royal Bank of Canada and RBC Borealis (SENTRY, arXiv, August 2026; work done in the RBC Amplify programme; not peer reviewed) reports a gradient-boosted model that flagged 63% of the changes that later caused major incidents (its *recall*), against about 20% for the bank's questionnaire, with a *precision* (share of flags that were real) of 0.55 on a 203-change test set;[^sentry] both terms are defined on [AIOps](../aiops/#glossary-and-mental-model). Mind the base rate: 35 of those 203 changes had caused major incidents, far more than in everyday traffic. *Illustrative calculation:* apply the same recall (0.63) and false-alarm rate (18 of 168) to 10,000 changes of which 1% fail, and the model flags about 63 + 1,061 changes: only about 6% of flags are real. Test any model on your own history. Where it goes wrong: - **Confident summaries of wrong facts.** A generated resolution note becomes the record auditors rely on: the agent confirms it, and notes are sampled against the work log. - **Misrouting at scale.** A classifier right 90% of the time misroutes one ticket in ten while its clock runs; watch reassignments. - **Unexplainable risk scores.** The policy says how a human challenges a score that routes changes, and misses are reviewed. - **Data exposure.** Tickets hold personal data and pasted secrets; check what the feature sends where ([PrivacyOps](../privacyops/)). ## ITOps in practice ### Reference implementation **Context (illustrative scenario).** About 800 employees, a central IT team of 25, a hybrid estate, three product teams deploying through CI/CD, one ITSM platform, no budget for new tools, an external auditor who tests change and access controls, and a payroll service with a monthly freeze. The artefacts: a policy file the platform is configured from (in Git, so every rule change has a record, a reviewer and a date), two pipeline steps, the [RACI](#roles-ownership-and-raci) and a rollout plan. _Example status: syntax-checked (YAML parsed), not executed against a platform. Values are illustrative._ ```yaml # itops-policy.yaml: one reviewed source for priority, clocks, change routing # and CMDB rules. Illustrative values; the ITSM platform is configured from # this file (by hand or by script). version: 3 owner: itsm-practice-owners@example.com review_cycle: quarterly priority: method: impact_plus_urgency_minus_one # the sample matrix shown on this page impact: 1: >- A critical business process is stopped, more than 100 users are affected, or there is safety or regulatory exposure 2: "A department or a named important process is degraded" 3: "One user is affected, or a workaround exists" urgency: 1: "Damage grows within hours" 2: "Damage grows within days" 3: "Can wait for planned work" calendars: always: {days: [mon, tue, wed, thu, fri, sat, sun], hours: "00:00-24:00"} business: days: [mon, tue, wed, thu, fri] hours: "09:00-17:00" holidays: corporate-holidays-2026 incident_resolution_sla: P1: {target_hours: 4, calendar: always} P2: {target_hours: 8, calendar: business} P3: {target_hours: 24, calendar: business} P4: {target_hours: 40, calendar: business} P5: {target_hours: null, calendar: business} # planning: no resolution target sla_clock: start: [ticket_created] pause: [waiting_for_customer, waiting_for_supplier] # comment required stop: [resolved, cancelled] pause_audit: "monthly sample of 20 paused tickets, reviewed by the desk lead" olas: service_desk: {triage_and_assign_minutes: 30} network_team: {diagnose_hours: 2} change: standard_models: - id: STD-WEB-DEPLOY scope: {services: [intranet]} procedure: runbooks/intranet-deploy.md requires: [peer_review, pipeline_tests_passed, automated_post_check] failure_limit: {max_failed: 1, of_last: 20} # above this, suspend the model - id: STD-CERT-RENEW scope: {services: [intranet, payroll, vpn]} procedure: runbooks/certificate-renewal.md requires: [automated_post_check] failure_limit: {max_failed: 0, of_last: 20} risk_weights: tier1_service: 3 no_tested_rollback: 3 schema_or_data_change: 2 touches_security_controls: 2 first_time_change: 1 outside_maintenance_window: 1 authorities: - {max_score: 2, authority: peer_review_and_automated_checks} - {max_score: 5, authority: service_owner} - {max_score: 99, authority: change_advisory_board} emergency: {authority: emergency_change_authority, review_within_working_days: 5} freeze_windows: - services: [payroll] start: "2026-10-26T00:00" end: "2026-10-31T23:59" reason: month-end payroll run events: # event-to-incident policy (Lab 4); deduplication and by_category: # inhibition are configured in the event layer informational: log warning: notify_owning_team exception: open_or_update_incident urgency_for_exception: 2 # impact comes from the service tier in the CMDB unbound_ci: {priority: 3, group: service-desk, flag: cmdb_gap} in_change_window: attach_to_change window_end_with_open_alerts: recheck_then_open_linked_incident on_clear: {not_worked: auto_resolve, worked: add_note} cmdb: required_attributes: default: [name, owner, environment] server: [serial] network_switch: [serial] require_path_to_service: true # checked as "orphans" in Lab 3 stale_after_days: 60 health_review: quarterly ``` The first pipeline step opens a standard change through ServiceNow's Change Management API: `POST` to `/sn_chg_rest/change/standard/` plus the template's sys_id creates "one standard change request based on an existing standard change template", with template fields as query parameters.[^snow-chg-api] _Example status (both steps): `bash -n` syntax-checked, not executed against ServiceNow (requires an instance, a template and an integration account). On 2026-10-17 both ran against a local mock server (curl 7.68, so `--fail-with-body` was swapped for `--fail`; the option needs curl 7.76 or later): credentials arrived in the Authorization header, the documented response layout parsed, the outcome arrived as a JSON body, and an HTTP 400 or a malformed sys_id stopped the step with a non-zero exit._ ```bash #!/usr/bin/env bash # CI step: open a pre-authorised standard change from an approved template # before a deploy. Needs bash, curl 7.76+ and python3. # Environment (from the CI secret store and the pipeline): # SN_BASE_URL https:// # SN_STD_TEMPLATE sys_id of the approved standard change template # SN_USER, SN_PASSWORD integration account with the itil role only # GIT_SHA commit being deployed set -euo pipefail : "${SN_BASE_URL:?}" "${SN_USER:?}" "${SN_PASSWORD:?}" : "${SN_STD_TEMPLATE:?}" "${GIT_SHA:?}" urlencode() { python3 -I -c 'import sys, urllib.parse print(urllib.parse.quote(sys.argv[1], safe=""))' "$1" } summary="Deploy intranet ${GIT_SHA:0:12}" endpoint="${SN_BASE_URL}/api/sn_chg_rest/change/standard/${SN_STD_TEMPLATE}" url="${endpoint}?short_description=$(urlencode "$summary")" # Credentials go to curl on stdin (--config -), not on the command line, # so other processes on a shared runner cannot read them from the process list. response=$(curl --silent --show-error --fail-with-body --request POST \ --header "Accept: application/json" --config - "$url" \ <<<"user = \"${SN_USER}:${SN_PASSWORD}\"") # The documented example wraps the record in a "result" array and each field # in {value, display_value}; accept a plain object too. Check one real # response in your instance's REST API Explorer first. parse_change() { python3 -I -c 'import json, sys r = json.load(sys.stdin).get("result") r = r[0] if isinstance(r, list) and r else r def val(field): v = r.get(field) if isinstance(r, dict) else None return v.get("value") if isinstance(v, dict) else v print(val("sys_id") or "-", val("number") or "-")' } if ! read -r change_sys_id change_number < <(parse_change <<<"$response") \ || [[ "$change_sys_id" == "-" ]]; then echo "No change record created; stopping the deploy." >&2 exit 1 fi echo "Standard change ${change_number} (${change_sys_id}) opened for ${GIT_SHA}" printf 'change_sys_id=%s\n' "$change_sys_id" >> "${CI_OUTPUT_FILE:-/dev/null}" ``` The second step records the result, on which change success rate, model failure limits and assurance sampling depend: `PATCH` on the same path plus the change's sys_id "Updates the standard change request identified by the specified sys_id with the parameters in the request body or in the URL".[^snow-chg-api] ```bash #!/usr/bin/env bash # CI step after the deploy and its automated post-check: record the outcome # on the standard change opened before the deploy. Run it whether the deploy # passed or failed ("always" in most CI systems). Needs bash, curl 7.76+, python3. # Environment: SN_BASE_URL, SN_USER, SN_PASSWORD as in the first step, plus # CHANGE_SYS_ID the change_sys_id written by the first step # CLOSE_CODE a value from your instance's close_code choice list # RESULT_NOTE deploy and post-check result with a link to the CI run set -euo pipefail : "${SN_BASE_URL:?}" "${SN_USER:?}" "${SN_PASSWORD:?}" : "${CHANGE_SYS_ID:?}" "${CLOSE_CODE:?}" "${RESULT_NOTE:?}" if [[ ! "$CHANGE_SYS_ID" =~ ^[0-9a-f]{32}$ ]]; then echo "CHANGE_SYS_ID is not a sys_id; outcome not recorded." >&2 exit 1 fi body=$(python3 -I -c 'import json, sys print(json.dumps({"close_code": sys.argv[1], "close_notes": sys.argv[2]}))' \ "$CLOSE_CODE" "$RESULT_NOTE") curl --silent --show-error --fail-with-body --request PATCH \ --header "Accept: application/json" \ --header "Content-Type: application/json" --data "$body" --config - \ "${SN_BASE_URL}/api/sn_chg_rest/change/standard/${CHANGE_SYS_ID}" \ <<<"user = \"${SN_USER}:${SN_PASSWORD}\"" >/dev/null echo "Outcome recorded on change ${CHANGE_SYS_ID}: ${CLOSE_CODE}" ``` Moving the record to Review and Closed follows your instance's state model (the API's `nextstates` endpoint lists the available states; the documented example of a change record shows close code `successful`).[^snow-chg-api] A failed outcome also opens or links an incident and counts against the model's failure limit. Security notes: these steps are only as safe as their preconditions. (1) ServiceNow's API reference lists the roles that may call the Change Management endpoints, "PATCH/POST: change_manager, itil, or admin".[^snow-chg-api] Give the integration account only the narrowest, `itil`, never `change_manager` or `admin`; put it in no approval, CAB or template-owner group; and give it no right to edit standard change templates, or the pipeline could make any change "standard" or approve its own. Confirm in your instance what `itil` plus group membership can approve. (2) The CI system exposes the credential only to the deploy job on protected branches or a protected environment, with no administrator bypass; anyone who can merge there can deploy, so branch protection with recorded review is part of the control. (3) The password never appears on the command line (escape double quotes or backslashes in it); where your instance supports OAuth for inbound REST, short-lived tokens are better. | Implementation step | Prerequisite | Action | Expected output | Rollback | |---|---|---|---|---| | 1. Agree the policy file | Practice owners named | Review `itops-policy.yaml` with service owners and audit | Signed-off v1 | Keep current settings | | 2. Configure priority and clocks | Policy v1 | Set the matrix, calendars (with holidays) and pause rules | Test tickets show correct targets | Restore previous SLA definitions | | 3. First standard change model | One deploy runbook with a rollback | Template plus the pipeline step for one service | Deploys create standard changes automatically | Disable the step; use normal changes | | 4. CMDB for two critical services | Discovery running | Model services, CIs, owners; run the health check | Impact query answers for both services | Mark records as draft | | 5. Event-to-incident policy | Alert inventory; CIs bound to services | Category actions, CI binding, change-window attachment, close rules (Lab 4) | A replay opens one incident per real disruption | Revert to previous routing | ### Hands-on labs The four labs use Python 3.8 or later and the standard library only: no account, no network, no cost. Each lab works in a new empty directory; save the data block and the script under the names given. Data is invented. #### Lab 1 (beginner): build an honest SLA clock - **Objective:** derive priority from impact and urgency, measure resolution time on the right calendar, and see what pauses and holidays do to SLA results. - **Prerequisites:** Python 3.8+; a terminal. Risk and cost: none. - **Steps:** (1) create `tickets.csv` from the block below; (2) save the script as `sla_clock.py`; (3) run `python3 -I sla_clock.py tickets.csv`. ```text id,impact,urgency,created,resolved,paused INC-201,1,1,2026-09-04T16:30,2026-09-04T19:10, INC-202,1,2,2026-09-04T15:00,2026-09-08T11:30, INC-203,2,2,2026-09-07T10:00,2026-09-08T15:00, INC-204,2,3,2026-09-08T09:15,2026-09-14T16:00,2026-09-09T10:00/2026-09-11T12:00 INC-205,3,2,2026-09-10T16:45,2026-09-11T10:30, INC-206,2,1,2026-09-11T08:00,2026-09-14T13:20, INC-207,3,3,2026-09-11T11:00,2026-09-25T09:00, INC-208,2,2,2026-09-14T09:00,2026-09-18T09:30,2026-09-14T11:00/2026-09-16T11:00 INC-209,1,1,2026-09-12T02:00,2026-09-12T07:30, ``` _Example status: verified by execution on 2026-10-16 with Python 3.8.10; the expected output below is copied from that run._ ```python """Priority and SLA clock for service-desk tickets (Python 3.8+, standard library only). Usage: python3 sla_clock.py tickets.csv Priority = impact + urgency - 1 (the sample impact x urgency matrix). P1 runs on a 24x7 clock; P2-P4 run on business hours (Mon-Fri 09:00-17:00, minus holidays). Paused periods do not count. """ import csv import sys from datetime import datetime, time, timedelta TARGET_HOURS = {1: 4, 2: 8, 3: 24, 4: 40} # P5 (planning) has no resolution target DAY_START, DAY_END = time(9, 0), time(17, 0) HOLIDAYS = {datetime(2026, 9, 7).date()} # illustrative public holiday def counted_hours(start, end, priority): """Hours between start and end that count towards the SLA clock.""" if priority == 1: return max(0.0, (end - start).total_seconds() / 3600) total, day = 0.0, start.date() while day <= end.date(): if day.weekday() < 5 and day not in HOLIDAYS: opens = max(start, datetime.combine(day, DAY_START)) closes = min(end, datetime.combine(day, DAY_END)) if closes > opens: total += (closes - opens).total_seconds() / 3600 day += timedelta(days=1) return total def main(path): due, met, rows = {}, {}, [] with open(path, newline="") as f: for r in csv.DictReader(f): p = int(r["impact"]) + int(r["urgency"]) - 1 created = datetime.fromisoformat(r["created"]) resolved = datetime.fromisoformat(r["resolved"]) wall = (resolved - created).total_seconds() / 3600 clock = counted_hours(created, resolved, p) paused = 0.0 for span in filter(None, (r["paused"] or "").split(";")): a, b = (datetime.fromisoformat(x) for x in span.split("/")) paused += counted_hours(a, b, p) target = TARGET_HOURS.get(p) ok = None if target is None else clock - paused <= target if target is not None: due[p] = due.get(p, 0) + 1 met[p] = met.get(p, 0) + int(ok) rows.append((r["id"], p, wall, clock, clock - paused, target, ok)) print("ticket P wall h clock h SLA h target result") for tid, p, wall, clock, sla, target, ok in rows: result = "no target" if ok is None else ("met" if ok else "BREACHED") print(f"{tid:<8} {p} {wall:>7.1f} {clock:>8.1f} {sla:>6.1f} " f"{target or '-':>7} {result}") for p in sorted(due): print(f"P{p}: {met[p]}/{due[p]} met") print(f"SLA attainment: {sum(met.values())}/{sum(due.values())} = " f"{100 * sum(met.values()) / sum(due.values()):.1f}%") if __name__ == "__main__": main(sys.argv[1]) ``` **Expected output:** ```text ticket P wall h clock h SLA h target result INC-201 1 2.7 2.7 2.7 4 met INC-202 2 92.5 4.5 4.5 8 met INC-203 3 29.0 6.0 6.0 24 met INC-204 4 150.8 38.8 20.8 40 met INC-205 4 17.8 1.8 1.8 40 met INC-206 2 77.3 12.3 12.3 8 BREACHED INC-207 5 334.0 78.0 78.0 - no target INC-208 3 96.5 32.5 16.5 24 met INC-209 1 5.5 5.5 5.5 4 BREACHED P1: 1/2 met P2: 1/2 met P3: 2/2 met P4: 2/2 met SLA attainment: 6/8 = 75.0% ``` - **Validation:** INC-202 was open for 92.5 wall-clock hours but only 4.5 counted hours (the weekend and the Monday holiday do not count). INC-209 breached on the 24x7 clock on a Saturday. INC-208 meets its target only because 16 business hours were paused. - **Exercise:** delete the pause period on INC-208 (the last field) and rerun. Expected: INC-208 shows `BREACHED` (32.5 counted hours) and attainment falls to `5/8 = 62.5%`. Was that pause a genuine wait for the customer? Your pause audit should answer from the ticket comments. - **Troubleshooting:** `ValueError: Invalid isoformat string` means a timestamp is not `YYYY-MM-DDTHH:MM`. A pause outside business hours subtracts nothing on the business calendar, which is correct. - **Teardown:** delete the directory. #### Lab 2 (intermediate): route changes by risk - **Objective:** apply a written change policy: standard models with a failure limit, a risk score, change authorities, freeze windows and conflict detection. - **Prerequisites:** Python 3.8+. Risk and cost: none. - **Steps:** save `policy.json`, `changes.json` and `route_changes.py`; run `python3 -I route_changes.py policy.json changes.json`. ```json { "standard_models": { "STD-WEB-DEPLOY": {"services": ["intranet"], "max_failures_last_20": 1}, "STD-CERT-RENEW": {"services": ["intranet", "payroll", "vpn"], "max_failures_last_20": 0} }, "risk_weights": { "tier1_service": 3, "no_tested_rollback": 3, "schema_or_data_change": 2, "touches_security_controls": 2, "first_time_change": 1, "outside_maintenance_window": 1 }, "authorities": [ {"max_score": 2, "route": "peer review + automated checks"}, {"max_score": 5, "route": "service owner approval"}, {"max_score": 99, "route": "change advisory board (CAB)"} ], "freeze_windows": [ {"services": ["payroll"], "start": "2026-10-26T00:00", "end": "2026-10-31T23:59"} ] } ``` ```json [ {"id": "CHG-301", "service": "intranet", "ci": "web-01", "model": "STD-WEB-DEPLOY", "model_failures_last_20": 0, "start": "2026-10-20T10:00", "end": "2026-10-20T10:30", "flags": []}, {"id": "CHG-302", "service": "payroll", "ci": "db-02", "model": null, "start": "2026-10-27T20:00", "end": "2026-10-27T22:00", "flags": ["tier1_service", "schema_or_data_change", "outside_maintenance_window"]}, {"id": "CHG-303", "service": "vpn", "ci": "fw-01", "model": null, "start": "2026-10-21T19:00", "end": "2026-10-21T20:00", "flags": ["touches_security_controls", "first_time_change"]}, {"id": "CHG-304", "service": "intranet", "ci": "web-01", "model": "STD-WEB-DEPLOY", "model_failures_last_20": 3, "start": "2026-10-20T10:15", "end": "2026-10-20T10:45", "flags": []}, {"id": "CHG-305", "service": "payroll", "ci": "app-07", "model": null, "emergency": true, "start": "2026-10-28T03:00", "end": "2026-10-28T03:30", "flags": ["tier1_service", "no_tested_rollback"]} ] ``` _Example status: verified by execution on 2026-10-16 with Python 3.8.10; output copied from that run._ ```python """Route change requests to a change authority from a written policy (Python 3.8+). Usage: python3 route_changes.py policy.json changes.json """ import json import sys from datetime import datetime def parse(ts): return datetime.fromisoformat(ts) def route(change, policy): """Return (change type, authority, list of notes).""" notes = [] model = policy["standard_models"].get(change.get("model") or "") if change.get("emergency"): return "emergency", "emergency change authority, then review", notes if model: if change["service"] not in model["services"]: notes.append("model not approved for this service") elif change.get("model_failures_last_20", 0) > model["max_failures_last_20"]: notes.append("model failure history above limit: " "suspend model, assess as normal") else: return "standard", "pre-authorised (model)", notes score = sum(policy["risk_weights"].get(f, 0) for f in change["flags"]) for level in policy["authorities"]: if score <= level["max_score"]: return "normal", f"{level['route']} (risk score {score})", notes raise ValueError("no authority level matched") def conflicts(change, changes, policy): found = [] s, e = parse(change["start"]), parse(change["end"]) for w in policy["freeze_windows"]: overlaps = s < parse(w["end"]) and parse(w["start"]) < e if change["service"] in w["services"] and overlaps: found.append("inside freeze window") for other in changes: if other["id"] != change["id"] and other["ci"] == change["ci"]: if s < parse(other["end"]) and parse(other["start"]) < e: found.append(f"overlaps {other['id']} on {change['ci']}") return found def main(policy_path, changes_path): with open(policy_path) as f: policy = json.load(f) with open(changes_path) as f: changes = json.load(f) for c in changes: kind, authority, notes = route(c, policy) notes += conflicts(c, changes, policy) print(f"{c['id']} {kind:<9} -> {authority}") for n in notes: print(f" ! {n}") if __name__ == "__main__": main(sys.argv[1], sys.argv[2]) ``` **Expected output:** ```text CHG-301 standard -> pre-authorised (model) ! overlaps CHG-304 on web-01 CHG-302 normal -> change advisory board (CAB) (risk score 6) ! inside freeze window CHG-303 normal -> service owner approval (risk score 3) CHG-304 normal -> peer review + automated checks (risk score 0) ! model failure history above limit: suspend model, assess as normal ! overlaps CHG-301 on web-01 CHG-305 emergency -> emergency change authority, then review ! inside freeze window ``` - **Validation:** CHG-302 scores 3 + 2 + 1 = 6, goes to the CAB and falls in the payroll freeze. CHG-301 and CHG-304 overlap on `web-01`. CHG-305 is an emergency in the freeze: allowed, but reviewed. - **Spot the flaw:** CHG-304's model is failing (3 failures in the last 20 runs, limit 1), yet the change lands in the *lowest* tier because it has no other risk flags. Add `"failing_model": 3` to `risk_weights`, add `"failing_model"` to CHG-304's flags and rerun. Expected: `CHG-304 normal -> service owner approval (risk score 3)`. Policies need the same testing as code. - **Troubleshooting:** `json.decoder.JSONDecodeError` usually means a trailing comma; `KeyError: 'flags'` means a change without a `flags` list (use `[]`). - **Teardown:** delete the directory. #### Lab 3 (intermediate): measure CMDB health and run an impact query - **Objective:** compute completeness, staleness, orphans and possible duplicates (the kinds of checks ServiceNow groups under completeness and correctness, with a 60-day staleness default[^snow-cmdb-health]), then ask what a failing CI affects. Service membership is checked as "orphans" (no path to a business service), not as a field, as `require_path_to_service` in the policy file says. - **Prerequisites:** Python 3.8+. Risk and cost: none. - **Steps:** save `cis.csv`, `rels.csv` and `cmdb_health.py`; run `python3 -I cmdb_health.py cis.csv rels.csv 2026-10-16 sw-core-1`, then the same command with `db-02` as the last argument. ```text id,class,name,owner,environment,serial,last_seen svc-payroll,business_service,Payroll,hr-it,prod,,2026-10-15 svc-intranet,business_service,Intranet,comms-it,prod,,2026-10-15 app-07,application,payroll-api,hr-it,prod,,2026-10-14 app-09,application,intranet-cms,,prod,,2026-10-14 db-02,database,payroll-db,dba,prod,,2026-10-15 srv-11,server,lnx-pay-11,infra,prod,SN-4471,2026-10-15 srv-12,server,lnx-pay-12,infra,prod,SN-4472,2026-07-30 srv-13,server,lnx-web-13,infra,prod,SN-4471,2026-10-15 srv-20,server,lnx-old-20,infra,prod,SN-9001,2026-05-02 sw-core-1,network_switch,core-switch-1,network,prod,SN-7710,2026-10-15 ``` ```text parent,type,child svc-payroll,depends_on,app-07 svc-intranet,depends_on,app-09 app-07,depends_on,db-02 app-07,runs_on,srv-11 app-09,runs_on,srv-13 db-02,runs_on,srv-12 srv-11,connected_to,sw-core-1 srv-12,connected_to,sw-core-1 srv-13,connected_to,sw-core-1 ``` _Example status: verified by execution on 2026-10-16 with Python 3.8.10; output copied from that run._ ```python """CMDB health checks and impact analysis (Python 3.8+, standard library only). Usage: python3 cmdb_health.py cis.csv rels.csv AS_OF_DATE CI_ID """ import csv import sys from collections import defaultdict from datetime import date REQUIRED = {"default": ["name", "owner", "environment"], "server": ["serial"], "network_switch": ["serial"]} STALE_AFTER_DAYS = 60 def load(cis_path, rels_path): with open(cis_path, newline="") as f: cis = {r["id"]: r for r in csv.DictReader(f)} parents = defaultdict(set) # child -> parents (who depends on it) with open(rels_path, newline="") as f: for r in csv.DictReader(f): parents[r["child"]].add(r["parent"]) return cis, parents def services_above(ci, cis, parents): """Business services reached by walking 'up' the dependency graph from ci.""" seen, stack, found = set(), [ci], set() while stack: node = stack.pop() if node in seen: continue seen.add(node) if cis.get(node, {}).get("class") == "business_service": found.add(node) stack.extend(parents.get(node, ())) return found def main(cis_path, rels_path, as_of, ci): cis, parents = load(cis_path, rels_path) today = date.fromisoformat(as_of) incomplete, stale, orphans, serials = [], [], [], defaultdict(list) for cid, r in cis.items(): fields = REQUIRED["default"] + REQUIRED.get(r["class"], []) missing = [f for f in fields if not r[f]] if missing: incomplete.append(f"{cid} (missing {', '.join(missing)})") age = (today - date.fromisoformat(r["last_seen"])).days if age > STALE_AFTER_DAYS: stale.append(f"{cid} ({age} days)") if r["class"] != "business_service" and not services_above(cid, cis, parents): orphans.append(cid) if r["serial"]: serials[(r["class"], r["serial"])].append(cid) dupes = [ids for ids in serials.values() if len(ids) > 1] n = len(cis) print(f"CIs: {n}") print(f"Completeness: {n - len(incomplete)}/{n} complete; incomplete: {incomplete}") print(f"Staleness (> {STALE_AFTER_DAYS} days): {stale}") print(f"Orphans (no path to a business service): {orphans}") print(f"Possible duplicates (same class and serial): {dupes}") print(f"Impact of {ci}: {sorted(services_above(ci, cis, parents))}") if __name__ == "__main__": main(*sys.argv[1:5]) ``` **Expected output** (first command, then the last line of the second): ```text CIs: 10 Completeness: 9/10 complete; incomplete: ['app-09 (missing owner)'] Staleness (> 60 days): ['srv-12 (78 days)', 'srv-20 (167 days)'] Orphans (no path to a business service): ['srv-20'] Possible duplicates (same class and serial): [['srv-11', 'srv-13']] Impact of sw-core-1: ['svc-intranet', 'svc-payroll'] Impact of db-02: ['svc-payroll'] ``` - **Validation:** `srv-12` is stale (78 days) yet hosts the payroll database, so impact answers through it may be wrong: stale CIs on a critical path are fixed first. `srv-20` belongs to no service: decommission it or find its owner. `srv-11` and `srv-13` share a serial number: a duplicate or a data-entry error; investigate before merging. - **Troubleshooting:** a CI that appears as an orphan although it is in use usually lacks one relationship; fix the relationship at its source (discovery or integration), not by hand. - **Teardown:** delete the directory. #### Lab 4 (advanced): decide which alerts open, update or close incidents - **Objective:** apply the [monitoring playbook](#playbook-monitoring-and-event-management)'s event-to-incident policy (CI binding, category actions, change windows, update instead of duplicate, close by rule) and see what happens when a window ends while alerts that never cleared are still open. - **Background:** alerts arrive already deduplicated, each with a stable key. In ServiceNow that is the message key; when it is empty, ServiceNow generates it from "the Source, Node, Type, Resource, and Metric Name field values".[^snow-events] Deduplication and inhibition are [AIOps](../aiops/#lab-1-beginner-group-and-inhibit-with-alertmanager) labs. Priority reuses Lab 1's matrix (impact from the service tier, urgency 2). - **Prerequisites:** Python 3.8+. Risk and cost: none. - **Steps:** save `alerts.csv`, `cmdb.json`, `changes.json` and `event_policy.py`; run `python3 -I event_policy.py alerts.csv cmdb.json changes.json 2026-10-16T08:20`, then the same with `2026-10-16T08:40`. A row with state `worked` stands for an agent's work note on the incident for that alert. ```text ts,key,ci,category,state 2026-10-16T07:41,snmp|sw-core-1|port-48,sw-core-1,exception,open 2026-10-16T07:42,ping|srv-11,srv-11,exception,open 2026-10-16T07:42,ping|srv-12,srv-12,exception,open 2026-10-16T07:42,ping|srv-13,srv-13,exception,open 2026-10-16T07:45,backup|db-02|nightly,db-02,informational,open 2026-10-16T07:50,disk|db-02|/data,db-02,exception,open 2026-10-16T07:55,apm|app-09|latency,app-09,warning,open 2026-10-16T08:05,disk|db-02|/data,db-02,exception,open 2026-10-16T08:10,snmp|sw-core-1|port-48,sw-core-1,exception,clear 2026-10-16T08:12,temp|ups-7,ups-7,exception,open 2026-10-16T08:15,disk|db-02|/data,db-02,exception,worked 2026-10-16T08:16,temp|ups-7,ups-7,exception,clear 2026-10-16T08:18,disk|db-02|/data,db-02,exception,clear ``` ```json {"sw-core-1": {"service": "network", "tier": 1}, "srv-11": {"service": "payroll", "tier": 1}, "srv-12": {"service": "payroll", "tier": 1}, "srv-13": {"service": "intranet", "tier": 2}, "db-02": {"service": "payroll", "tier": 1}, "app-09": {"service": "intranet", "tier": 2}} ``` ```json [{"id": "CHG-410", "cis": ["sw-core-1", "srv-11", "srv-12", "srv-13"], "start": "2026-10-16T07:30", "end": "2026-10-16T08:30"}] ``` _Example status: verified by execution on 2026-10-17 with Python 3.8.10; output copied from that run._ ```python """Event-to-incident policy on the ITSM side (Python 3.8+, standard library only). Usage: python3 event_policy.py alerts.csv cmdb.json changes.json AS_OF Alerts arrive deduplicated (one stable key per condition). Rows with state "worked" stand for an agent's work note on the incident for that key. """ import csv import json import sys from datetime import datetime URGENCY = 2 # alerts cannot know user urgency; the desk can raise it UNBOUND_PRIORITY = 3 # CI missing from the CMDB: open anyway, flag the gap def parse(ts): return datetime.fromisoformat(ts) def main(alerts_path, cmdb_path, changes_path, as_of): with open(cmdb_path) as f: cmdb = json.load(f) with open(changes_path) as f: changes = json.load(f) now = parse(as_of) timeline = [] # (time, order, kind, item) with open(alerts_path, newline="") as f: for r in csv.DictReader(f): if parse(r["ts"]) <= now: timeline.append((parse(r["ts"]), 0, "alert", r)) for c in changes: if parse(c["end"]) <= now: timeline.append((parse(c["end"]), 1, "window_end", c)) timeline.sort(key=lambda t: (t[0], t[1])) incidents, on_change, opened, resolved = {}, {}, [], 0 def open_incident(key, ci, link=""): if ci in cmdb: prio, label = cmdb[ci]["tier"] + URGENCY - 1, cmdb[ci]["service"] else: prio, label = UNBOUND_PRIORITY, "CI not in CMDB: fix the CMDB" number = f"INC-{len(opened) + 1}" incidents[key] = {"id": number, "worked": False} opened.append(number) return f"open {number} P{prio} ({label}){link}" def window_for(ci, ts): for c in changes: if ci in c["cis"] and parse(c["start"]) <= ts < parse(c["end"]): return c["id"] return None for ts, _, kind, item in timeline: if kind == "window_end": still = [k for k, (cid, _ci, live) in on_change.items() if cid == item["id"] and live] print(f"{ts:%H:%M} {item['id']:<10} window ended; " f"{len(still)} alert(s) still open") for k in still: ci = on_change[k][1] on_change[k] = (item["id"], ci, False) link = f", linked to {item['id']}" print(f"{ts:%H:%M} {ci:<10} -> {open_incident(k, ci, link)}") continue key, ci, cat, state = item["key"], item["ci"], item["category"], item["state"] inc = incidents.get(key) if state == "worked": if inc: inc["worked"] = True action = f"{inc['id']} worked by an agent" if inc else "no incident: ignored" elif cat == "informational": action = "log only" elif cat == "warning": action = "notify the owning team; no incident" elif state == "clear": if key in on_change: on_change[key] = (on_change[key][0], ci, False) action = f"alert closed on {on_change[key][0]}" elif inc is None: action = "nothing open: log" elif inc["worked"]: action = f"note on {inc['id']}: monitor cleared, agent verifies" else: action = f"auto-resolve {inc['id']} (nobody worked on it)" resolved += 1 del incidents[key] elif key in on_change and on_change[key][2]: action = f"update alert on {on_change[key][0]}" elif inc: action = f"update {inc['id']}" else: change = window_for(ci, ts) if change: on_change[key] = (change, ci, True) action = f"attach to {change} (approved window)" else: action = open_incident(key, ci) print(f"{ts:%H:%M} {ci:<10} {cat:<13} {state:<6} -> {action}") print(f"incidents opened: {len(opened)}; auto-resolved: {resolved}") if __name__ == "__main__": main(*sys.argv[1:5]) ``` **Expected output at 08:20** (inside the switch maintenance window): ```text 07:41 sw-core-1 exception open -> attach to CHG-410 (approved window) 07:42 srv-11 exception open -> attach to CHG-410 (approved window) 07:42 srv-12 exception open -> attach to CHG-410 (approved window) 07:42 srv-13 exception open -> attach to CHG-410 (approved window) 07:45 db-02 informational open -> log only 07:50 db-02 exception open -> open INC-1 P2 (payroll) 07:55 app-09 warning open -> notify the owning team; no incident 08:05 db-02 exception open -> update INC-1 08:10 sw-core-1 exception clear -> alert closed on CHG-410 08:12 ups-7 exception open -> open INC-2 P3 (CI not in CMDB: fix the CMDB) 08:15 db-02 exception worked -> INC-1 worked by an agent 08:16 ups-7 exception clear -> auto-resolve INC-2 (nobody worked on it) 08:18 db-02 exception clear -> note on INC-1: monitor cleared, agent verifies incidents opened: 2; auto-resolved: 1 ``` **Expected output at 08:40** (the window ended at 08:30; last lines): ```text 08:30 CHG-410 window ended; 3 alert(s) still open 08:30 srv-11 -> open INC-3 P2 (payroll), linked to CHG-410 08:30 srv-12 -> open INC-4 P2 (payroll), linked to CHG-410 08:30 srv-13 -> open INC-5 P3 (intranet), linked to CHG-410 incidents opened: 5; auto-resolved: 1 ``` - **Validation:** at 08:20, 13 alert rows open two incidents. The switch work pages nobody because CHG-410 lists the switch and the servers behind it (affected CIs from the CMDB). The repeated `db-02` alert updates INC-1, and its clear only adds a note because an agent worked on it. The UPS alert opens INC-2 although its CI is missing, and auto-resolves because nobody touched it. - **The failure the lab reveals:** at 08:30 the window ends, and three server alerts that never sent a clear become incidents linked to CHG-410, probably for healthy servers (the switch cleared at 08:10). CHG-410 now counts as a failed change and the desk works three phantom tickets. Fixes: every monitor sends clear events; at window end, re-check before opening incidents; the post-implementation check confirms CI health. - **Exercise:** append `2026-10-16T08:20,ping|srv-11,srv-11,exception,clear` to `alerts.csv` and rerun at 08:40. Expected: `window ended; 2 alert(s) still open`, with incidents on `srv-12` and `srv-13` only. - **Troubleshooting:** `ValueError: Invalid isoformat string` means a timestamp is not `YYYY-MM-DDTHH:MM`. A CI that keeps opening "CI not in CMDB" incidents needs a CMDB record, not a filter. - **Teardown:** delete the directory. ### Use cases and scenarios All three are **illustrative scenarios**, not documented case studies. Event noise across many monitoring tools is a fourth, worked through in [Lab 4](#lab-4-advanced-decide-which-alerts-open-update-or-close-incidents) and the [runbook](#worked-runbook-the-event-flood-that-buried-the-service-desk). | Scenario | Context | Approach | Trade-offs | Success measure | |---|---|---|---|---| | Employee requests at scale | 2,000 staff; 60% of tickets are requests | Catalogue the top 20 requests; automate access and software items behind approvals | Up-front effort; access automation needs identity controls | Median fulfilment time; automation share; reopen rate | | Regulated bank under EU DORA | Pipelines deploy daily; regulator expects change and incident records | Pipeline-created standard changes from models authorised outside the delivery teams; ICT incident classification built into the priority scheme | Must convince audit and supervisor that automated evidence and model authorisation meet the independence requirement | No findings on change; major-incident reports within the four-hour, 72-hour and one-month limits | | Managed service provider | 30 client contracts with different SLAs; carriers and cloud suppliers | SLA, OLA and UC chains per contract; one platform with per-client calendars | Clock configuration becomes complex | SLA disputes per month; breach root causes attributed correctly | Notes on each. **Requests:** the difficulty is variety, not volume; retire catalogue items unused for six months, and watch reopens (automation that reopens tickets has moved work, not removed it). **Bank:** EU DORA requires an ICT-related incident management process that ensures "root causes are identified, documented and addressed";[^eu-dora] map that to the problem records the tools already produce rather than a parallel "compliance" process. **Provider:** decompose every client SLA as in the [agreements figure](#service-levels-slas-olas-and-underpinning-contracts); never accept one tighter than the carrier's contract. ## Measure, govern, pay ### Metrics and KPIs Every metric below is computed from records the practices already produce. The definitions are this Atlas's; write yours into the policy so that a number means the same thing every month. | KPI | Definition and formula | Data source | Pitfall | Cadence | |---|---|---|---|---| | SLA attainment (per priority) | Tickets resolved within target ÷ tickets with a target closed in the period | ITSM SLA records | Pauses and re-prioritisation inflate it; report paused share too | Monthly | | Resolution time | Median and 90th percentile of counted hours, per priority | ITSM | Means hide the long tail; "MTTR" has several meanings ([IncidentOps](../incidentops/)) | Monthly | | First-contact resolution | Resolved by the desk at first contact ÷ resolved by the desk | ITSM | Early closure shows up as reopens | Monthly | | Reopen rate | Tickets reopened within 7 days ÷ tickets resolved | ITSM | New tickets instead of reopens; check duplicates | Monthly | | Reassignment rate | Tickets touched by 3 or more groups ÷ tickets resolved | ITSM | Signals poor categories or unclear ownership | Weekly | | Backlog age | 90th percentile age of open tickets, in calendar days | ITSM | Bulk closure "improves" it | Weekly | | Request automation share | Requests fulfilled with no manual fulfilment step ÷ requests fulfilled | ITSM workflow logs | Approvals are not fulfilment steps | Quarterly | | Change success rate | Changes implemented without an incident, rollback or emergency fix within 7 days ÷ changes implemented | Change and incident records | Unlinked failures look like success | Monthly | | Standard and emergency change share | Standard changes ÷ all changes; emergency changes ÷ all changes | Change records | Reclassifying risky work as "standard" to look fast | Monthly | | Change-induced incident share | P1–P3 incidents linked to a change ÷ P1–P3 incidents | Incident records | Under-linking; phantom incidents from alerts that never cleared ([Lab 4](#lab-4-advanced-decide-which-alerts-open-update-or-close-incidents)) | Monthly | | Repeat-incident rate | Incidents matching a known error or a cause seen in the last 90 days ÷ incidents | Problem and incident records | Requires disciplined linking | Quarterly | | CMDB health | Completeness, staleness, duplicates, orphans ([Lab 3](#lab-3-intermediate-measure-cmdb-health-and-run-an-impact-query)) | CMDB | Counting CIs is not health | Monthly | | Actionable-alert share | Alerts that led to an incident or automated action ÷ alerts | Event management | Auto-closing alerts can hide real faults | Weekly | Change success rate covers all changes; DORA's change fail rate is narrower, "The ratio of deployments that require immediate intervention following a deployment",[^dora-metrics] and its deployment rework rate is the delivery-side cousin of the emergency change share ([DevOps](../devops/)). Report both if you have both; never mix their denominators. **Worked calculation (illustrative month).** A desk resolved 1,200 tickets: 700 incidents and 500 requests. Of 690 incidents with a resolution target, 641 met it, and 96 of those 690 were paused at some point. The desk resolved 540 tickets at first contact; 42 tickets were reopened within 7 days. IT implemented 180 changes: 110 standard, 58 normal, 12 emergency; 9 caused an incident, a rollback or an emergency fix within 7 days; 140 of the 700 incidents were P1–P3, and 21 of those were linked to a change. Monitoring raised 2,400 alerts, 520 of them actionable. | Measure | Calculation | Result | |---|---|---| | SLA attainment | 641 ÷ 690 | 92.9% | | Paused share (report with attainment) | 96 ÷ 690 | 13.9% | | First-contact resolution | 540 ÷ 1,200 | 45.0% | | Reopen rate | 42 ÷ 1,200 | 3.5% | | Standard / emergency change share | 110 ÷ 180; 12 ÷ 180 | 61.1%; 6.7% | | Change success rate | (180 − 9) ÷ 180 | 95.0% | | Change-induced incident share (P1–P3) | 21 ÷ 140 | 15.0% | | Actionable-alert share | 520 ÷ 2,400 | 21.7% | Reading it: 92.9% looks healthy, but one ticket in seven was paused, so audit the pauses (Lab 1). Nearly four alerts in five led to no action: the alert rules, not the desk, are the target. Break the 6.7% emergency share down by cause: if most repair failed standard changes, a model is unhealthy. **Leading and lagging.** Reassignment rate, backlog age, paused share, standard-model failure rate and stale tier-1 CIs move before users feel anything (review weekly); attainment, repeat incidents and change-induced incidents confirm what happened (monthly). **Vanity traps:** tickets closed per agent (rewards splitting and premature closure); a green SLA report while users complain (the "watermelon" report); CAB approval counts; CI counts. **Targets:** baseline three months, then set per priority through the service review. **Data limits:** timestamps record when someone touched the record, not when users were affected, and categories drift; state the limits on every report. ### Quality, security, privacy and compliance - **The ITSM platform is a privileged system.** It holds approvals, audit trails and access requests. Separate requester, agent, approver and administrator roles; prevent self-approval; keep administrators few, named and reviewed; put the platform's own configuration under change control (the [policy file](#reference-implementation) helps). - **Integration accounts** get minimum roles: the pipeline creates but cannot approve changes (see the reference implementation's security notes), discovery writes only its CMDB tables, credentials sit in a secret store with rotation. - **Personal data.** Tickets contain names, contact details and whatever users paste, sometimes passwords. Restrict sensitive categories (HR, security, legal), purge pasted secrets and set retention by record type ([PrivacyOps](../privacyops/)). - **Security incidents.** Define when an IT incident becomes a security incident and who takes over ([ResponseOps](../responseops/); the security–IT collaboration model is on [SecOps](../secops/)). Where NIS2 applies, significant incidents carry deadlines of 24 hours (early warning), 72 hours (notification) and one month (final report).[^nis2] In-scope EU financial entities classify and report major ICT-related incidents under EU DORA instead (NIS2 recital 28):[^eu-dora][^nis2] the initial notification "within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours" after becoming aware of it (if it is classified as major only after those 24 hours, within four hours of that classification), the intermediate report within 72 hours of the initial notification, and the final report within one month of the latest intermediate report (Delegated Regulation (EU) 2025/301, Article 5, which also sets weekend rules).[^eu-rts-301] Put the classification questions in the incident form so the clock is not discovered late. - **Evidence retention.** Keep change records with approvals, tests and outcomes as long as regulators, contracts or auditors require, agreed in writing ([ComplianceOps](../complianceops/)); ISO/IEC 20000-1 certification bodies work under Part 6 of the series.[^wiki-20000] Jurisdiction caveat: these are EU texts, applied through national law (NIS2) or directly (EU DORA); check other jurisdictions with your compliance function. ### Cost, capacity and sustainability **Cost drivers** are people (desk and resolver time), platform licences (priced per agent, they quietly decide who gets access), integration and administration effort, and discovery coverage. *Cost per resolved ticket* = (desk + platform cost for the period) ÷ tickets resolved; use it by channel and ticket type to find where automation pays, never as an agent target (the cheapest ticket is the one never raised, which the metric cannot see). **Capacity.** Desk staffing uses the queueing maths on [SupportOps](../supportops/). For resolver teams, track the share of time on unplanned work. Google's SRE organisation aims to keep "operational work (i.e., toil) below 50% of each SRE's time";[^sre-toil] that is Google's goal for its own SREs, not a benchmark, but a written cap protects improvement time for any team. **Sustainability.** ITOps affects the footprint through the asset lifecycle: decommissioning orphan servers (Lab 3's `srv-20`), right-sizing, and extending device refresh cycles where support allows. A certified service management system now has a formal hook: Amendment 1:2024 to ISO/IEC 20000-1, "Climate action changes",[^iso-amd1] adds the requirement that "The organization shall determine whether climate change is a relevant issue" to clause 4.1, and a note to clause 4.2 that interested parties can have climate-related requirements; the certification body DNV lists ISO/IEC 20000 among the "Type A" management system standards that received this wording.[^dnv-climate] Guidance, not requirements, is in ISO/IEC TS 20000-16:2025, which treats sustainability as "three interdependent dimensions, which are environmental, social and economic".[^iso-20000-16] Carbon accounting is on [GreenOps](../greenops/); cost allocation on [FinOps](../finops/). ### Assurance of the operating model How do you know the practices work as written? Sample and compare, monthly: - **Ten standard changes:** did each match its model's scope, with the post-change check recorded? - **Twenty paused tickets:** was each pause backed by a comment asking the user or supplier for something? - **Five closed problems:** was the fix verified by the absence of repeat incidents, or only by the change closing? - **Two services' CMDB records:** does an impact query match what the service owner believes? - **All emergency changes:** reviewed within the policy period? Key risk indicators for the practice owner: emergency change share above threshold for two months, a standard model above its failure limit, stale tier-1 CIs, rising paused share, and integrations that stopped sending data (a silent discovery or event feed is arguably the most dangerous). Quarterly practice reviews turn findings into policy changes, under the same change control. ## When things go wrong ### Common failures and troubleshooting | Symptom | Likely cause | Diagnosis | Remediation | Prevention | |---|---|---|---|---| | Tickets bounce between groups | Categories do not map to owners; no default owner | Reassignment report by category | Map each category to one owner; desk triage for unknowns | Review categories quarterly | | SLA breaches after every holiday | Holidays missing from the calendar | Breaches clustered on holiday dates | Add holidays; recompute the period | Annual calendar update as a standard change | | SLA green, users angry | Pauses or re-prioritisation hide waiting time | Paused share; priority changes after creation | Audit pauses; lock priority after triage except via a reason | Report paused share with attainment | | Same incident every week | No problem record, or problem without engineering time | Repeat-incident report | Open a problem with an owner and a deadline | Weekly "what came back" in triage | | Changes collide | No single schedule; changes outside the record | Overlapping changes on one CI | One calendar with conflict detection | Unauthorised-change detection from discovery | | Emergency changes rising | Normal path too slow, or failing standard models | Emergency changes by reason and team | Fix the slow step or suspend the model | Track model failure rates | | Impact analysis wrong during an outage | Stale or missing CMDB relationships | Last-seen dates on the path | Fix discovery and relationship sources | CMDB health review | | Service desk flooded during an outage | Integration opens an incident per event | Many tickets with the same CI and minute | The runbook below | Event-to-incident policy (Lab 4); event rules ([AIOps](../aiops/)) | ### Worked runbook: the event flood that buried the service desk **Illustrative scenario.** At 08:00 a core switch loses an uplink. Within ten minutes monitoring has sent 3,000 events and the ITSM integration has opened 400 incidents, one per server and check. The desk cannot find user calls in the queue, and on-call engineers are paged for every server. ::: figure Runbook: stop the flood, find the cause, fix the rules ```mermaid flowchart TB A["Ticket flood detected"] --> B["Declare a major incident"] B --> C["Pause auto-ticketing for the affected source"] C --> D["Group alerts by CI and minute"] D --> E{"Common upstream CI?"} E -- "Yes" --> F["One parent incident on that CI"] E -- "No" --> G["Triage the largest groups"] F --> H["Link child tickets; close duplicates"] G --> H H --> I["Restore service"] I --> J["Re-enable auto-ticketing"] J --> K["Problem: why the rules failed"] K --> L["Fix ticketing policy and event rules via reviewed change"] classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 class A,B risk class E decision class C,D,F,G,H,I,J,K,L core ``` Text equivalent: declare a major incident and pause automatic ticket creation for the noisy source. Group alerts by configuration item and minute; if they share an upstream CI, open one parent incident on it, otherwise triage the largest groups. Link child tickets, close duplicates, restore service and re-enable automatic ticketing. A problem record asks why the rules failed, and the corrected policy and event rules ship as a reviewed change. ::: 1. **Declare.** Live command follows [IncidentOps](../incidentops/); name an ITOps lead for the ticket clean-up. 2. **Stop the bleeding.** Pause auto-ticketing for the noisy source; events keep flowing to the event console, which someone now watches. Expected: the incident count stops rising within minutes. 3. **Find the common cause.** Walk the CMDB upstream from the largest alert group; here every group leads to the core switch. If the CMDB is stale on that path, use the network team's topology ([NetOps](../netops/)). 4. **One parent, many children.** Link the server incidents to one parent on the switch; close duplicates with a distinct resolution code so reports can exclude them. 5. **Restore and verify.** Fix the switch (an emergency change if needed) and re-check child alerts that do not clear rather than assuming them healthy (the window-end failure in Lab 4). Re-enable auto-ticketing and watch it for an hour. 6. **Learn.** Open a problem: why did 3,000 events become 400 incidents? ITSM side: an integration that opens a new incident instead of updating the open one, or warnings allowed to open incidents. Event layer, with its owner: a timestamp in the deduplication key, missing inhibition ([AIOps](../aiops/)). Ship the fixes as reviewed changes, tested by replaying the exported alert log. ### Anti-patterns and myths | Anti-pattern or myth | Why it seems good | Warning signal | Do instead | |---|---|---|---| | Every change goes to the CAB | Looks like maximum control | Long approval waits; incidents still follow approved changes | Risk-tiered authorities; DORA's evidence on approval[^dora-cab] | | CMDB as a data lake | "More data is better" | Millions of CIs, nobody trusts impact queries | Model the services that decisions need; measure health | | Tiered escalation as a relay race | Clear responsibilities | Tickets bounce; specialists rediscover what the desk knew | Swarming or direct routing for complex work;[^swarming] knowledge capture | | SLA as a weapon | Accountability | Disputes about clocks, not service | Agreed clocks; OLAs and supplier contracts that add up | | Problem backlog as a graveyard | Nothing is forgotten | Hundreds of open problems, none moving | A short active list with owners; accept or close the rest | | Platform team as a ticket vending machine | Control over infrastructure | Queues for routine provisioning | Self-service with guardrails; DORA calls this the "Ticket-ops" trap[^dora-platform] | | Certification as the goal | Visible progress | Certificates rise, metrics flat | Measure services, not syllabi | | "ITIL is incompatible with DevOps" | Seems true of heavyweight ITIL | Two parallel change processes | Pipeline-generated standard changes; ISO/IEC 20000-15 gives Agile and DevOps guidance[^wiki-20000] | | Buying a tool to fix the process | Tools are tangible | A new tool with the old categories | Fix policies and data first | ## Deciding and adopting ### When to use and when not to use ITOps as a function exists in every organisation that runs IT; the question is how much formal ITSM structure to put around it. **Formal ITSM practices pay off when:** - many users depend on shared services they do not run themselves (an internal IT department, a managed service provider); - several teams or suppliers change the same estate, so collisions and finger-pointing are real risks; - contracts or regulations require service levels, change records or incident reporting (EU DORA, NIS2, customer SLAs); - the estate is large enough that nobody can hold the dependency map in their head; - failures recur and nobody owns the causes. **Keep it light, or do not adopt heavyweight ITSM, when:** - one product team builds and runs one service with automated delivery: use the DevOps and SRE practices ([DevOps](../devops/), [SRE](../sre/)) plus three ITSM habits (an incident record, a change record generated by the pipeline, and follow-up of recurring causes); - a shared channel and a simple ticket queue still cover requests (add more as users and teams grow); - a managed provider runs the service under contract: your job is supplier management and the SLA chain, not a parallel process; - the only motivation is "audit wants ITIL": audits test controls and their evidence, so design the controls first. **Hidden responsibilities.** Every practice needs an owner, data upkeep and a review cadence; a change process nobody reviews, or a CMDB without CI owners, costs effort and returns false confidence. ### Decision framework ::: figure How much formal ITSM structure to adopt ```mermaid flowchart TB Q1{"Shared services used by people who do not run them?"} Q1 -- "No" --> L1["Light: product team practices plus incident, change and problem records"] Q1 -- "Yes" --> Q2{"Regulated, contractual SLAs, or many teams and suppliers?"} Q2 -- "No" --> L2["Core ITSM: desk, incidents, requests, standard changes"] Q2 -- "Yes" --> Q3{"Can you name owners for practices and CI data?"} Q3 -- "No" --> L3["Fix ownership first; do not buy a platform yet"] Q3 -- "Yes" --> L4["Full ITSM: change authorities, CMDB, SLA and OLA chains, audits"] classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 class Q1,Q2,Q3 decision class L1,L2,L4 core class L3 risk ``` Text equivalent: without shared services used by people who do not run them, stay light (product-team practices plus incident, change and problem records). With shared services but no regulation, contractual SLAs or many teams, adopt core ITSM (desk, incidents, requests, standard changes). With any of those, check that owners can be named for practices and CI data: if not, fix ownership before buying a platform; if so, adopt full ITSM (change authorities, CMDB, SLA and OLA chains, audits). ::: For a sharper answer, score each factor from 0 to 3 and multiply by its weight. The weights are this Atlas's starting assumption; change them to reflect your context. | Factor | Weight | 0 | 3 | |---|---|---|---| | Users who depend on services they do not run | 3 | Only the team itself | Thousands of employees or customers | | Teams and suppliers changing the shared estate | 3 | One team | Many teams and several suppliers | | Regulatory or contractual obligations | 3 | None | Sector regulation plus contractual SLAs | | Estate size and coupling | 2 | A few services, loosely coupled | Hundreds of services with shared infrastructure | | Recurring failures without owners | 2 | Rare | Weekly | | Delivery automation maturity | 1 | Fully automated with evidence | Manual deployments | The maximum is 3 × (3 + 3 + 3 + 2 + 2 + 1) = 42. Rule of thumb: below 12, stay light; 12 to 25, core ITSM; above 25, full ITSM, automated as far as delivery maturity allows. Worked example: an internal IT department serving 1,500 employees (3), four teams and two suppliers (2), an ISO/IEC 20000 commitment in a key contract (2), about 150 services (2), monthly recurring outages (2) and partly automated delivery (2) scores 9 + 6 + 6 + 4 + 4 + 2 = 31: full ITSM, starting with ownership and the policy file, not a tool. ### Maturity model No official ITOps maturity model is assumed here; ITIL and ISO/IEC 20000 offer their own assessment approaches. The five levels below are **this Atlas's model**, written so that each exit criterion can be checked from records. | Level | Observable behaviour | Evidence needed to claim the level | Typical constraint | Next step | |---|---|---|---|---| | 1 Reactive | Requests by email and chat; fixes by whoever knows | Starting point | No shared record | One queue, one priority matrix | | 2 Recorded | All contacts become tickets; priorities from impact and urgency; basic SLA reports | 95% of contacts recorded; SLA clocks documented | Records but no learning | Problem practice; first change models | | 3 Managed | Weekly problem triage; standard and normal changes with authorities; CMDB for tier-1 services | Repeat-incident rate tracked; at least 30% standard changes; tier-1 CMDB health checked monthly | Manual data entry; CAB overload | Pipeline and discovery integration | | 4 Integrated | Pipelines create changes with evidence; discovery maintains CIs; alerts bound to CIs open, update and close incidents by policy | Over 80% of deployments carry automatic change records; stale CIs on tier-1 below 5%; actionable-alert share tracked | Integration upkeep; data quality limits automation | Risk scoring reviewed against failures | | 5 Adaptive | Change routing and alert rules tuned from outcome data; standard models suspended automatically on failure | Quarterly evidence that routing rules predict failures better than before; no audit findings on change | Patience; skills | Sustain | A level is a description, not a goal. For many services level 3 is enough; reach level 4 where change volume or regulation justifies the integration work. ### Adoption roadmap: 30/60/90 days | Period | Actions | Owners | Milestone and metric | |---|---|---|---| | Days 1–30 | Name practice owners; baseline three months of tickets and changes; agree the priority matrix and SLA clock rules (with holidays and pause rules); pick two critical services for the pilot; inventory alert sources | IT operations manager, desk lead, change manager | Policy file v1 signed; baseline report with paused share, reassignment rate and emergency change share | | Days 31–60 | Catalogue the top 10 requests; automate two; publish the change policy with authorities; first standard change model fed by a pipeline; model the two pilot services in the CMDB and run the health check; weekly problem triage starts | Practice owners, one product team, configuration manager | First pipeline-created standard change; tier-1 CMDB health measured; five problems with owners | | Days 61–90 | Event-to-incident policy for the pilot services (with event rules from the monitoring owner); first monthly service review with customers; review failed and emergency changes; adjust risk weights; plan the next services | Monitoring owner, service owners, change manager | Actionable-alert share measured; first service review held; decision record on scaling up | Quick wins in the first month: the quick-start checklist below, and no more incidents from warning-level events. ## Toolkit ### Checklists **Quick start (first two weeks)** - [ ] Practice owners named for incident, request, problem, change, configuration and service levels - [ ] Priority matrix written with business definitions of impact and urgency - [ ] SLA calendars include public holidays; pause rules require a comment - [ ] Every ticket category maps to exactly one owning group - [ ] Baseline report: volumes, attainment, paused share, reassignment rate, emergency change share **Service go-live readiness (Day 0 to Day 1)** - [ ] Service registered with an owner, a tier and its CIs and relationships - [ ] SLA agreed; OLAs and supplier contracts checked to fit inside it - [ ] Monitoring sends alerts with a stable deduplication key and clear events - [ ] Request types and at least one standard change model defined - [ ] Desk briefed; top five expected contacts have knowledge articles - [ ] Go-live run as a planned change with a rollback and early life support **Change preflight (per normal change)** - [ ] Affected services and CIs identified from the CMDB, not from memory - [ ] Risk factors answered; authority matches the score - [ ] Rollback tested or the absence of rollback accepted by the service owner - [ ] No conflict with the change schedule or a freeze window - [ ] Post-change verification defined (what proves success, who checks, when) **ITSM platform security and governance audit (quarterly)** - [ ] Administrator accounts named, few and reviewed - [ ] No role can both request and approve the same change - [ ] Integration accounts least-privileged; credentials rotated - [ ] Sensitive ticket categories restricted; retention applied - [ ] Platform configuration changes recorded through change control ### Templates **Standard change model proposal** ```text Model ID and name: STD-____ ______________________ Scope: services ________ CI classes ________ envs ________ Procedure: link to runbook (steps, expected durations) Preconditions: tests passed / peer review / maintenance window / other ___ Post-change check: what proves success, automated or manual, who checks Rollback: steps and expected time; tested on ____-__-__ Evidence of low risk: last N runs as normal changes: __ of __ successful Failure limit: suspend if more than __ failures in the last __ runs Owner: __________ Review date: ____-__-__ Change authority: __________ Approved on: ____-__-__ ``` **Problem record** ```text Problem ID: PRB-____ Owner: __________ Priority: __ Linked incidents: INC-____, INC-____ (first seen ____-__-__, count __) Services and CIs: ______________________ Impact statement: users / business process / cost per occurrence (an estimate, with its basis) Workaround: steps; published to the desk on ____-__-__ Contributing causes: 1. ______ 2. ______ 3. ______ Decision: fix via change CHG-____ / accept the known error (reason, review date) Closure criterion: no linked incidents for __ days after the fix ``` **SLA one-pager with its supporting chain** ```text Service: __________ Owner: __________ Customer: __________ Hours of service: __________ Calendar: ________ (holidays: ______) Priority definitions: impact 1-3 and urgency 1-3 in business terms (matrix) Targets: P1 __ h (24x7) P2 __ h P3 __ h P4 __ h (business h) Clock rules: start ______ pause ______ (comment required) stop ___ Supporting OLAs: team ______ target ______ ; team ______ target ______ Supplier contracts: supplier ______ target ______ (fits inside SLA? y / n) Reporting: monthly report; review meeting ______; exclusions ___ Breach handling: escalation path; service credits if contractual ______ ``` **Monthly service review agenda (60 minutes)** ```text 1. Actions from last review (5 min) 2. Service levels: attainment, paused share, breaches by cause (15 min) 3. Top incidents and repeat incidents; problem status (15 min) 4. Changes: next month's schedule, failed and emergency changes (10 min) 5. Requests and user feedback (5 min) 6. Risks, improvements, decisions; new actions with owners (10 min) ``` **Post-implementation review (failed or emergency change)** ```text Change: CHG-____ Type: standard / normal / emergency Model: ______ (if standard) What was intended: ______________________ What happened: timeline with times; detected by alert / user / check Impact: services, users, duration; linked incidents INC-____ Why controls missed: risk score, tests, review, schedule, CMDB data Decisions: model suspended? weights changed? problem PRB-____? Actions: owner and due date for each ______________________ ``` ### Deep comparisons | Operating model | Who resolves | Change control | Main measures | Best fit | Main risk | |---|---|---|---|---|---| | Central ITSM function | Desk plus specialist resolver groups | Change manager and authorities; CAB for high risk | SLA attainment, first-contact resolution, change success | Shared internal services, many users | Slow handoffs; process for its own sake | | Product team "you build it, you run it" | The team that builds the service | Pipeline evidence, peer review, standard changes | DORA delivery metrics, SLOs ([DevOps](../devops/), [SRE](../sre/)) | Software products with automated delivery | Inconsistent records across teams | | SRE team for critical services | Engineers with error budgets | Error-budget policy plus pipeline controls | SLOs, toil share | High-scale services | Hard to staff; drift into a renamed ops team | | Managed service or multi-supplier (SIAM) | Providers under contract | Contractual change processes; integrator coordinates | SLA chain attainment, supplier performance | Outsourced or multi-vendor estates | Gaps between contracts; slow cross-supplier fixes | Many organisations run a mix. The ITOps job is then one set of definitions (priority, change types, service names) across all models, so a service owner sees every incident and change for a service whichever team handled it. Tools mirror this: one suite gives one data model but brings licence cost and customisation debt; developer tools fit product teams but split the records; open-source ITSM avoids per-agent licences, but you run and secure it. ### FAQ **Is ITOps the same as ITSM?** Not on this page: ITOps is the function, ITSM the practices it uses, ITOM the technical tooling layer. Vendors draw the lines differently ([naming](#what-itops-is-not-boundaries-and-naming)), so check the definition in any document you rely on. **Do we need ITIL certification to run ITOps well?** No. Certification gives teams and suppliers a shared vocabulary; the practices work when they have owners, data and review cadences, none of which needs a certificate. **Can product teams skip the ITSM tool?** They can skip working in it, not the records: pipelines write change records and incident tools sync, so service owners and auditors see one history per service. **Do regulators require a CAB?** The texts we checked do not. EU DORA requires risk-based, documented change controls;[^eu-dora] its technical standard adds approving functions independent of requesting and implementing ones and approval of emergency changes after implementation, except for firms on its simplified framework ([two DORAs](#change-enablement-in-depth)).[^eu-rts-1774] Within those limits, how approval is organised is your design, agreed with auditors and supervisors. **What is the difference between an SLA and an SLO?** An SLA is an agreement with a customer, often with consequences. An SLO is an internal reliability target, usually stricter, so the team reacts before the agreement is breached ([SRE](../sre/)). **Is a password reset an incident or a request?** A forgotten password is a request (the ITIL service request definition that Atlassian quotes gives resetting a password as an example);[^atl-problem] a broken reset service is an incident. The two flows have different targets and different automation. ## Going further ### Advanced topics and emerging direction - **ITIL (Version 5) in practice (emerging).** Until the official practice guides appear (reported as due in the second half of 2026[^itsmtools-v5]), treat claims about how Version 5 changes day-to-day practice as provisional. - **Experience and AI in the ISO 20000 series (in development).** Wikipedia lists parts on experience management (Part 18, expected 2026) and artificial intelligence (Part 19) as under development;[^wiki-20000] check ISO's catalogue before citing them. - **Change risk prediction (vendor capability; early evidence).** ITSM platforms offer AI-assisted change risk assessment;[^atl-itsm-guide][^snow-ai] the one study found is a single-bank preprint, tested at a failure rate far above everyday traffic ([Automation and AI](#automation-and-ai)). - **CMDB from declared state (established technique).** Infrastructure as code and cloud APIs can feed the CMDB ([InfraOps](../infraops/), [CloudOps](../cloudops/)). - **Enterprise service management (established).** Applying ITSM to HR, facilities and other functions "is often called enterprise service management";[^wiki-itsm] see [PeopleOps](../peopleops/) for the HR side. - **Agentic automation (speculative to emerging).** Tools that act on tickets need scope, approval, audit trail and rollback: govern them like a standard change model with a failure limit. ### Learning path | Stage | What to do | Outcome | |---|---|---| | Prerequisites | Operating systems, networking, how web applications fail ([SysOps](../sysops/), [NetOps](../netops/)) | Describe a failure in user and technical terms | | 1 day | Read the first three parts; classify 20 of your tickets; draw one service's dependency map | Shared vocabulary; one service map | | 1 week | Labs 1 to 4; rewrite your priority matrix in business terms; audit 20 paused tickets | An honest view of your SLA clock and CMDB | | 30 days | One standard change model end to end; one problem to a verified fix; one service review | One working instance of each core practice | | Advanced | ITIL Foundation then a practice module; ISO/IEC 20000 internal auditing; pipeline and discovery integration | Design and audit the operating model | | Portfolio | A policy file for a real service; change rules tested on last quarter's failures; event rules replayed on an export | Evidence of practical skill | **By role.** *Beginner:* "What ITOps is", the glossary, Lab 1, the FAQ. *Practitioner:* practices, change enablement, service levels, all labs, the runbook, the templates. *Leader or architect:* the problem section, decision framework, maturity model, judgement call and metrics worked example. ## Wrap-up ### Executive recap and cheat sheet | Topic | Remember | |---|---| | What it is | The function that keeps IT services running; ITSM practices are its backbone, ITOM tools its instruments | | Key decisions | How much formal structure; who authorises which changes; what the CMDB must answer; how SLA clocks work | | Essential practices | Service desk, incidents, requests, problems, change enablement, event management, configuration, service levels | | Metrics that matter | Attainment with paused share; reassignment; repeat incidents; change success and emergency share; CMDB health; actionable-alert share | | Tool classes | ITSM platform; CMDB and discovery; event management; on-call; pipeline integration | | Watch-outs | CAB for everything; CMDB as a data lake; gamed pauses; one incident per event; AI notes nobody checks | | Next actions | Policy file v1; holidays and pause rules; one pipeline-fed standard change; two services modelled and health-checked | ### A judgement call: discover everything, or model the critical services first? **Situation (illustrative).** A university IT department has licensed a discovery tool that could load about 40,000 devices, servers and cloud resources into the CMDB within a month. The CIO wants "a complete CMDB by year end"; the change manager wants reliable impact analysis. The CMDB team is two people. **Option 1: discover everything first,** then build service models on top; the CI count rises fast. **Option 2: model the critical services first:** agree the 12 most important services with their owners, model each top-down (service, applications, hosting, network path), point discovery at those CIs, and expand only when health checks pass. **Assumptions.** Owners exist for the critical services; discovery credentials are available; security needs a complete asset inventory whatever the CMDB decision. **Evidence.** CMDB effectiveness "depends on the CMDB's data quality, which requires maintenance", and automatic discovery is a key success factor.[^wiki-cmdb] Staleness (60 days by default in ServiceNow), duplicates and orphans are what an unowned mass load produces.[^snow-cmdb-health] ServiceNow's data model ties technology services to impact in incident, problem and change management,[^snow-csdm] so impact quality depends on relationships, not CI count. But the CIS Controls put a complete asset inventory first, so that unauthorised and unmanaged assets can be removed or remediated.[^cis-1] Both needs are real. **Why the attractive choice can be wrong.** Option 1 yields an impressive number and an untrusted database: orphans, duplicates, impact queries that list everything or nothing, change risk scores fed by bad data; two people cannot clean 40,000 records. **Why the other can also be wrong.** Option 2 leaves unknown assets unmanaged for months, which security will rightly reject, and top-down modelling can stall in workshops. **Decision process.** Separate the two needs. Run discovery broadly into an *asset inventory* (broad and shallow, owned with security) from the start. Promote records into the *service model* (deep, with relationships and owners) one critical service at a time, gated by health: required fields complete, no stale CIs on the service path, an impact query the owner confirms. Measure the time to answer "what does this CI affect?" in real incidents before and after. **Expected result, with uncertainty.** The inventory meets the security control early; the first services' models become trusted within a quarter, but expansion pace depends on owner availability, the real and least predictable constraint. If owners cannot confirm their maps, stop expanding and fix ownership: no tool supplies it. ### Learning objectives and mastery check After this page you should be able to **explain** how ITOps, ITSM and ITOM relate and where neighbouring pages take over; **classify** work into incidents, requests, problems and changes; **design** a priority matrix, an SLA clock and an SLA chain that adds up; **route** changes to the right authority with standard models that carry a failure limit; **evaluate** CMDB health and event rules; and **decide** how much formal ITSM an organisation needs. ::: answer 1. Classify: a user cannot print; a new starter needs a laptop; the VPN drops every Monday for many users; a firewall rule must be added. Incident; service request; a problem opened alongside the recurring incidents, because a common cause is likely; change (a standard change if it follows an approved low-risk procedure). ::: ::: answer 2. Using the sample matrix, what priority does impact 2 with urgency 1 give, and why define impact in business terms? P2 (2 + 1 − 1). Business terms (users affected, a named critical process, money or safety) let the desk and users agree on priority quickly; "database down" does not say how much the business is hurt. ::: ::: answer 3. An SLA promises P2 resolution in 8 business hours; the desk OLA is 30 minutes, the network OLA 2 hours, and the carrier contract says "next business day". What is wrong, and what are three honest fixes? The chain does not fit, so any P2 needing the carrier breaches. Renegotiate the carrier contract (for example a 4-hour repair), change the SLA for carrier-dependent faults, or add a second circuit. Blaming the desk is not a fix. ::: ::: answer 4. A standard change model has failed 3 of its last 20 runs against a limit of 1. What happens to the next change that uses it? Suspend the model and assess the change as normal, counting the failure history as a risk factor (without it, Lab 2 puts the change in the lowest tier). Fix the procedure, then reinstate the model. ::: ::: answer 5. After all normal changes are sent to a twice-weekly CAB, the emergency change share rises from 3% to 12%. Interpret it. Teams are routing around a slow path by labelling non-urgent work as emergency, so risk is less visible, not more: the DORA pitfall of answering problems with more process ([change enablement](#change-enablement-in-depth)). Restore risk tiers and delegated authorities, and review emergency changes by reason. ::: ::: answer 6. During a planned switch upgrade, 2,000 events become 300 incidents. Which ITSM-side rules are missing, and which belong to the event layer? ITSM side: alerts on the change's CIs attach to the approved change; a repeated alert updates its open incident; only exceptions open incidents; at window end, open alerts are re-checked first. Event layer ([AIOps](../aiops/)): a stable deduplication key without timestamps, and inhibition of symptoms below the switch. Clear events from every monitor serve both. ::: ::: answer 7. An auditor asks for CAB minutes for every production change. How do you respond? Ask which control objective is tested (usually authorisation and segregation of duties) and show how the process meets it: risk-tiered authorities, standard change models authorised outside the implementing team, recorded review of low-risk changes by someone other than the author, CAB minutes for high-risk changes. DORA's research supports peer review for segregation of duties;[^dora-cab] an EU financial entity outside the simplified framework must also show approving functions independent of requesting and implementing ones ([two DORAs](#change-enablement-in-depth)).[^eu-rts-1774] Agree the evidence model in advance. ::: ::: answer 8. A vendor offers AI change-risk scoring. How do you evaluate it before it routes approvals? Run it in shadow mode and compare scores with outcomes: how many failed changes did it rate high (recall), and what share of its high ratings were real failures at *your* failure rate (precision falls as failures get rarer)? Require reasons a human can challenge, a named override, and a quarterly review of misses. ::: ### Conclusion ITOps is rarely glamorous and always consequential: it is where an organisation's promises about IT (this will work, this will be fixed, this change is safe, this is what we own) are either backed by records or quietly broken. Its frameworks are mature, and on the evidence available in October 2026 ITIL's Version 5 regroups the practices rather than replacing them. The hard parts lie outside the frameworks: honest clocks, change authority sized to risk and independent of the implementer, a map of the estate that someone owns, and event rules that send people one problem instead of four hundred symptoms. The practices also cost time and attention, so keep only those that earn it. This page's advice reduces to two habits: put every rule where it can be reviewed and changed (a policy, a model, a weight, a key), and check those rules against outcomes. Do that, and the frameworks become tools rather than rituals. ## Sources and further reading Every source below was opened on the date in its footnote (2026-10-16 or 2026-10-17). Vendor capabilities, release names and dates change: recheck them before relying on them. ITIL's own publications are licensed and were not opened; ITIL wording here is quoted from the secondary sources named in the text. [^ibm-itops]: [What is IT operations (ITOps)?](https://www.ibm.com/topics/it-operations) — IBM, n.d. Checked 2026-10-16. [^atl-itops]: [What is IT Operations? ITOps roles and responsibilities](https://www.atlassian.com/itsm/it-operations) — Atlassian, n.d. Checked 2026-10-16. [^atl-itom]: [What is IT operations management (ITOM)?](https://www.atlassian.com/itsm/it-operations-management) — Atlassian, n.d. Checked 2026-10-16. [^wiki-itil]: [ITIL](https://en.wikipedia.org/wiki/ITIL) — Wikipedia, live article. Checked 2026-10-16. [^pc-v5]: [New ITIL explained for certified professionals: ITIL (Version 5)](https://www.peoplecert.org/news-and-announcements/itil-version-5-explained) — PeopleCert, n.d. (© 2026). Checked 2026-10-16. [^pc-found]: [ITIL Foundation (Version 5)](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154) — PeopleCert, n.d. (© 2026). Checked 2026-10-16. [^itsmtools-v5]: [ITIL Version 5 management practices explained: complete list and definitions](https://itsm.tools/itil-version-5-management-practices/) — ITSM.tools (Stephen Mann), 2026-02-11. Checked 2026-10-16. [^wiki-20000]: [ISO/IEC 20000](https://en.wikipedia.org/wiki/ISO/IEC_20000) — Wikipedia, live article. Checked 2026-10-17. [^wiki-itsm]: [IT service management](https://en.wikipedia.org/wiki/IT_service_management) — Wikipedia, live article. Checked 2026-10-16. [^dora-cab]: [Capabilities: Streamlining change approval](https://dora.dev/capabilities/streamlining-change-approval/) — DORA, updated 2025-10-30. Checked 2026-10-16. [^dora-metrics]: [DORA's software delivery performance metrics](https://dora.dev/guides/dora-metrics/) — DORA, updated 2026-01-05. Checked 2026-10-16. [^dora-platform]: [Capabilities: Platform engineering](https://dora.dev/capabilities/platform-engineering/) — DORA, updated 2026-01-12. Checked 2026-10-16. [^sre-intro]: [Introduction](https://sre.google/sre-book/introduction/) — Benjamin Treynor Sloss, in *Site Reliability Engineering*, Google / O'Reilly, 2017. Checked 2026-10-16. [^sre-toil]: [Eliminating Toil](https://sre.google/sre-book/eliminating-toil/) — Vivek Rau, in *Site Reliability Engineering*, Google / O'Reilly, 2017. Checked 2026-10-16. [^atl-change-types]: [Types of change management for ITSM teams](https://www.atlassian.com/itsm/change-management/types) — Atlassian, n.d. Checked 2026-10-16. [^snow-change-types]: [Change types](https://www.servicenow.com/docs/r/MlbQAgTiiiMOLOw9T36wJg/0mfA2AyAdGPOssbbVgOLLQ) — ServiceNow documentation, Zurich release, updated 2026-09-10. Checked 2026-10-16. [^snow-chg-api]: [Change Management API](https://www.servicenow.com/docs/r/api-reference/rest-apis/change-management-api.html) — ServiceNow documentation, Brazil release, updated 2026-09-10. Checked 2026-10-16. [^ipm-change]: [Change Management](https://wiki.en.it-processmaps.com/index.php/Change_Management) — IT Process Wiki (Stefan Kempter, IT Process Maps), last edited 2023-12-31. Checked 2026-10-16. [^ipm-event]: [Event Management](https://wiki.en.it-processmaps.com/index.php/Event_Management) — IT Process Wiki (IT Process Maps), last edited 2023-12-31. Checked 2026-10-16. [^ipm-uc]: [Checklist Underpinning Contract (UC)](https://wiki.en.it-processmaps.com/index.php/Checklist_Underpinning_Contract_(UC)) — IT Process Wiki (IT Process Maps), last edited 2023-12-31. Checked 2026-10-16. [^wiki-ola]: [Operational-level agreement](https://en.wikipedia.org/wiki/Operational-level_agreement) — Wikipedia, live article. Checked 2026-10-16. [^atl-sla]: [What is an SLA? Service level agreement explained](https://www.atlassian.com/itsm/service-request-management/slas) — Atlassian, n.d. Checked 2026-10-16. [^jsm-sla-cond]: [Set up SLA conditions](https://support.atlassian.com/jira-service-management-cloud/docs/set-up-sla-conditions/) — Atlassian Support, Jira Service Management Cloud, n.d. Checked 2026-10-16. [^snow-priority]: [Define priority lookup rules](https://www.servicenow.com/docs/r/zurich/it-service-management/incident-management/def-prio-lookup-rules.html) — ServiceNow documentation, Zurich release, updated 2025-01-30. Checked 2026-10-16. [^atl-problem]: [What is problem management?](https://www.atlassian.com/itsm/problem-management) — Atlassian, n.d. Checked 2026-10-16. [^splunk-problem]: [IT/ITIL Problem Management](https://www.splunk.com/en_us/blog/learn/problem-management.html) — Splunk (Joseph Nduhiu), 2025-01-03. Checked 2026-10-16. [^splunk-event]: [IT Event Management Explained: Detecting, Categorizing, and Responding to IT Events](https://www.splunk.com/en_us/blog/learn/it-event-management.html) — Splunk (Joseph Nduhiu), 2024-06-10. Checked 2026-10-16. [^snow-cmdb-health]: [CMDB Health KPIs and metrics](https://www.servicenow.com/docs/r/GCPjp~ldPTNRN99oH1DYFg/LJdK4ZKD0ozmnz0eLhmUog) — ServiceNow documentation, Xanadu release, updated 2024-08-01. Checked 2026-10-16. [^snow-csdm]: [CSDM data domains](https://www.servicenow.com/docs/r/zS6yb8e~gR8BPjeviYdV9g/YO9~nS73A2CUXGgC7Mjz6g) — ServiceNow documentation, Zurich release, updated 2025-08-29. Checked 2026-10-16. [^wiki-cmdb]: [Configuration management database](https://en.wikipedia.org/wiki/Configuration_management_database) — Wikipedia, live article. Checked 2026-10-16. [^cis-1]: [CIS Control 1: Inventory and Control of Enterprise Assets](https://www.cisecurity.org/controls/inventory-and-control-of-enterprise-assets) — Center for Internet Security, CIS Controls v8.1, n.d. Checked 2026-10-16. [^alertmanager]: [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) — Prometheus documentation, n.d. Checked 2026-10-16. [^snow-events]: [View events](https://www.servicenow.com/docs/r/Tm19yM2Ui3~uN9XFBacppg/d33yx8zWZNZb0i41Pcwutw) — ServiceNow documentation, Yokohama release, updated 2025-01-30. Checked 2026-10-16. [^atl-itsm-guide]: [IT Service Management (ITSM) Guide](https://www.atlassian.com/collections/service/guides/it-service-management) — Atlassian, n.d. Checked 2026-10-16. [^atl-opsgenie]: [Opsgenie migration](https://www.atlassian.com/software/opsgenie/migration) — Atlassian, n.d. Checked 2026-10-16. [^snow-ai]: [Using ServiceNow Otto for IT Service Management (ITSM) Generative AI skills](https://www.servicenow.com/docs/r/MlbQAgTiiiMOLOw9T36wJg/PG9dW1aXEHkr~eX6UYbPxg) — ServiceNow documentation, Zurich release, updated 2025-07-31. Checked 2026-10-16. [^glpi]: [GLPI](https://glpi-project.org/) — GLPI project, n.d. Checked 2026-10-16. [^itop]: [iTop](https://www.combodo.com/itop) — Combodo, n.d. Checked 2026-10-16. [^fitsm]: [FitSM: the free, lightweight ITSM standard](https://www.fitsm.eu/) — FitSM e.V., n.d. (© 2024). Checked 2026-10-16. [^cobit]: [COBIT](https://www.isaca.org/resources/cobit) — ISACA, n.d. Checked 2026-10-16. [^eu-dora]: [Regulation (EU) 2022/2554 (Digital Operational Resilience Act), Articles 9(4)(e), 16, 17 and 19](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554) — European Union, 2022-12-14. Checked 2026-10-16. [^eiopa-dora]: [Digital Operational Resilience Act (DORA)](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en) — EIOPA, n.d. Checked 2026-10-16. [^nis2]: [Directive (EU) 2022/2555 (NIS2), Article 23 and recital 28](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022L2555) — European Union, 2022-12-14. Checked 2026-10-16. [^swarming]: [Intelligent Swarming](https://www.serviceinnovation.org/intelligent-swarming/) — Consortium for Service Innovation, n.d. Checked 2026-10-16. [^sentry]: [SENTRY: Deterministic, Intelligent Risk Assessment for IT Change Management](https://arxiv.org/abs/2608.21203) — D. Arulpragasam, C. Henrysson, E. Ly, D. Anbalagan and L. Feng (Royal Bank of Canada, RBC Borealis; work completed at Royal Bank of Canada in the RBC Amplify program), arXiv preprint 2608.21203v1, 2026-08-21. Checked 2026-10-16. [^eu-rts-1774]: [Commission Delegated Regulation (EU) 2024/1774 (regulatory technical standards on ICT risk management), Articles 17 and 38](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R1774) — European Union, adopted 2024-03-13, published 2024-06-25. Checked 2026-10-17. [^eu-rts-301]: [Commission Delegated Regulation (EU) 2025/301 (content and time limits of major ICT-related incident reports), Article 5](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32025R0301) — European Union, adopted 2024-10-23, published 2025-02-20. Checked 2026-10-17. [^dora-google]: [DORA Joins Google Cloud](https://dora.dev/news/dora-joins-google-cloud/) — DORA, 2018-12-20. Checked 2026-10-17. [^iso-amd1]: [ISO/IEC 20000-1:2018/Amd 1:2024, Amendment 1: Climate action changes](https://committee.iso.org/standard/88434.html) — ISO, published 2024-02 (catalogue entry). Checked 2026-10-17. [^iso-20000-16]: [ISO/IEC TS 20000-16:2025, Part 16: Guidance on sustainability within a service management system based on ISO/IEC 20000-1](https://committee.iso.org/standard/87192.html) — ISO, published 2025-02 (catalogue entry and abstract). Checked 2026-10-17. [^dnv-climate]: [ISO Climate Change Amendment for Management Systems Standards](https://www.dnv.us/assurance/Management-Systems/addition-of-climate-change-to-the-iso-management-system-standards4/) — DNV, n.d. (© 2025). Checked 2026-10-17. [^ipm-itom]: [IT Operations Management](https://wiki.en.it-processmaps.com/index.php/IT_Operations_Management) — IT Process Wiki (IT Process Maps), last edited 2017-04-28. Checked 2026-10-17. [^ipm-roles]: [ITIL Roles](https://wiki.en.it-processmaps.com/index.php/ITIL_Roles) — IT Process Wiki (IT Process Maps), last edited 2023-12-31. Checked 2026-10-17. **Further reading.** The neighbour table in [How ITOps relates to other Ops](#how-itops-relates-to-other-ops) lists which Atlas page owns each adjacent topic. **Changelog.** 2026-10-16: first edition (research, draft, nine diagrams, four labs executed with Python 3.8.10). 2026-10-16 (revision): all sources reopened; event-management playbook added; ITIL, Opsgenie and EU DORA wording corrected; the pipeline step parses the documented response (mock-tested); Lab 1 hardened. 2026-10-17 (review round 1): EU DORA technical standards added (approval independence, emergency changes, report time limits); deduplication and inhibition handed to AIOps and Lab 4 rebuilt around the event-to-incident policy; ServiceNow API roles named and an outcome-recording step added; ISO/IEC 20000-1 amendment, operations control, practice routing, glossary, RACI, KPI denominator, trust boundaries and SENTRY attribution corrected; page cut back into the length band (maturity chain figure removed). 2026-10-17, post-score polish: late-classification rule of RTS 2025/301 Art. 5(2) added; takeaway, FAQ and mastery answer 7 scoped to firms outside EU DORA's simplified framework; ISO/IEC TS 20000-16:2025 added to sustainability; repeated quotes trimmed.