ITOps

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;^[1] Atlassian’s shorter version is “the management and maintenance of IT infrastructure within a business”.^[2] 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. Last verified: 2026-10-17.

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”,^[5] 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”.^[6] 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) requires financial entities to keep documented ICT change-management controls and to record all ICT-related incidents.^[7]

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”.^[1]
• Atlassian’s ITOps page states that “ITOps and ITOM are interchangeable terms”.^[2]
• Atlassian’s ITOM page says “ITOM is a subset of IT Service Management”.^[8]

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; 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.
• Not DevOps, but it must fit it. CI/CD and the DORA delivery metrics are on DevOps; ITOps owns the change-enablement interface that pipelines pass through.
• Not AIOps. Alert deduplication, inhibition and machine-learning correlation belong to AIOps. Beware the collision: Atlassian’s ITOps page uses “AIOps” for an AI virtual agent that triages tickets.^[2]
• Not customer support. Support for external customers is 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); “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).

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.^[3]

IBM still describes IT operations as one of four ITIL functions;^[1] ITIL 4 organises the same work into practices,^[8] so older job descriptions and newer syllabi name it differently. DevOps and SRE then challenged approval-heavy change, and DORA’s research found that heavyweight change approval hurts delivery performance.^[12] Wikipedia lists newer ISO guidance parts on SIAM (Part 14, 2023) and on Agile and DevOps (Part 15, 2024).^[4]

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”.^[11] The Foundation syllabus keeps the four dimensions of service management.^[13] 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.^[14] This page uses practice names common to both versions.

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.

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

ITIL’s seven guiding principles, such as “Focus on value” and “Keep it simple and practical”,^[3] 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.^[12]
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.

The practices are not a list; they hand work to each other. The figure shows the main handoffs.

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

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.

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): 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).^[4] 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”.^[23]

Governance in ITOps is mostly cadence: the same few forums, held reliably, each with a defined input and output.

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.

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.

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

Treat the event-management layer as a production dependency: if it fails silently, the service desk learns about outages from users.

The happy path below follows one recurring fault from the first user report to the permanent fix. The exception paths are described after it.

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

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; 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.

The practice definitions quoted here are ITIL wording as reported by ITSM.tools; the full texts are in licensed ITIL publications.^[14]

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.

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”.^[24][25] 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, BackupOps, AutomationOps and PatchOps.

Other ITIL practices and where the Atlas covers them. Of the 22 product and service management practices in ITIL (Version 5),^[3] the eight above are taught here. Availability, capacity and performance → SRE and CloudOps; service continuity → DisasterRecoveryOps; IT asset management → EndpointOps for devices and FinOps for cost; deployment and release → DevOps and ReleaseOps; infrastructure and platform management → InfraOps and PlatformOps; information security → SecOps; service catalogue and service design → ServiceOps.

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.
4. Accept an item when a test request completes end to end; roll back a misfiring automation to manual fulfilment.

Problem management is commonly taught in three phases: problem identification, problem control and error control (for example in Splunk’s ITIL guide).^[16] 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”;^[9] keep a short active list with owners and next actions.

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”;^[26] agree them per service. The event layer deduplicates, groups and inhibits alerts (AIOps 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 runs it.

ITIL 4 first called this practice “change control” and later renamed it “change enablement”:^[17] 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.^[18]
• 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.^[18] Atlassian notes that low-risk normal changes can be approved “by a designated change authority or through automated checks and peer review”.^[27]
• 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.^[18]

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”.^[17] 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”.^[12] The DevOps judgement call works through re-chartering a CAB; this page gives the mechanics.

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

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).
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); Jira Service Management documents the same pattern with deployment gates.^[29]
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).^[12]

Unauthorised change (a change without a record) is detected, not prevented, by comparing discovery and drift with change records (InfraOps, GitOps); treat each first as a sign that the approved path was too slow.

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.^[30] 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”.^[20] 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.^[21]

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

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.^[31]
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.^[32]

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 shows how a pause turns a breach into a pass. An SLA for an engineered service is often backed by an internal SLO (SRE).

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”.^[8] 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.^[7] 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).

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 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.^[45]

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.^[46] Atlassian describes “Rovo Ops” investigating likely root causes and drafting post-incident reviews, and AI-assisted change risk assessment.^[29] 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;^[47] both terms are defined on AIOps. 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).

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 and a rollout plan.

Example status: syntax-checked (YAML parsed), not executed against a platform. Values are illustrative.

# 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.^[44]

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.

#!/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://<your-instance-host>
#   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”.^[44]

#!/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).^[44] 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”.^[44] 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.

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.

• 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.

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.

"""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:

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.

• 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.

{
  "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"}
  ]
}

[
  {"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.

"""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:

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.

• Objective: compute completeness, staleness, orphans and possible duplicates (the kinds of checks ServiceNow groups under completeness and correctness, with a 60-day staleness default^[40]), 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.

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

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.

"""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):

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.

• Objective: apply the monitoring playbook’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”.^[42] Deduplication and inhibition are AIOps 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.

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

{"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}}

[{"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.

"""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):

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):

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.

All three are illustrative scenarios, not documented case studies. Event noise across many monitoring tools is a fourth, worked through in Lab 4 and the runbook.

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”;^[7] 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; never accept one tighter than the carrier’s contract.

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.

Change success rate covers all changes; DORA’s change fail rate is narrower, “The ratio of deployments that require immediate intervention following a deployment”,^[48] and its deployment rework rate is the delivery-side cousin of the emergency change share (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.

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.

• 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 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).
• Security incidents. Define when an IT incident becomes a security incident and who takes over (ResponseOps; the security–IT collaboration model is on SecOps). Where NIS2 applies, significant incidents carry deadlines of 24 hours (early warning), 72 hours (notification) and one month (final report).^[37] In-scope EU financial entities classify and report major ICT-related incidents under EU DORA instead (NIS2 recital 28):^[7][37] 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).^[36] 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); ISO/IEC 20000-1 certification bodies work under Part 6 of the series.^[4]

Jurisdiction caveat: these are EU texts, applied through national law (NIS2) or directly (EU DORA); check other jurisdictions with your compliance function.

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. 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”;^[45] 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”,^[10] 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.^[49] Guidance, not requirements, is in ISO/IEC TS 20000-16:2025, which treats sustainability as “three interdependent dimensions, which are environmental, social and economic”.^[50] Carbon accounting is on GreenOps; cost allocation on FinOps.

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.

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.

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

1. Declare. Live command follows 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).
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). Ship the fixes as reviewed changes, tested by replaying the exported alert log.

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, 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.

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

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.

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.

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.

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.

Quick wins in the first month: the quick-start checklist below, and no more incidents from warning-level events.

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

Standard change model proposal

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

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

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)

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)

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 ______________________

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.

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), 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;^[7] 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).^[28] 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).

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);^[9] a broken reset service is an incident. The two flows have different targets and different automation.

• ITIL (Version 5) in practice (emerging). Until the official practice guides appear (reported as due in the second half of 2026^[14]), 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;^[4] check ISO’s catalogue before citing them.
• Change risk prediction (vendor capability; early evidence). ITSM platforms offer AI-assisted change risk assessment;^[29][46] the one study found is a single-bank preprint, tested at a failure rate far above everyday traffic (Automation and AI).
• CMDB from declared state (established technique). Infrastructure as code and cloud APIs can feed the CMDB (InfraOps, CloudOps).
• Enterprise service management (established). Applying ITSM to HR, facilities and other functions “is often called enterprise service management”;^[52] see 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.

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.

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.^[15] Staleness (60 days by default in ServiceNow), duplicates and orphans are what an unowned mass load produces.^[40] ServiceNow’s data model ties technology services to impact in incident, problem and change management,^[53] 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.^[6] 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.

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.

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.

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.

Further reading. The neighbour table in 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.