ITSM in Practice

The other pages in this topic explain what each idea means. This page is about how it feels on the job: the tools you will open on your first day, being on call, and how ITIL sits next to DevOps, site reliability engineering (SRE), Agile and project management. The examples follow Kestrel Energy, a fictional energy supplier with a customer portal and app, a billing system, a service desk and a network operations center (NOC).

ITSM tools

An ITSM tool is the software platform where service management work is recorded and coordinated: tickets for incidents, requests, problems and changes, the service catalog and self-service portal, the configuration management database (CMDB), the knowledge base, workflows and approvals, and the reports built on all of that. Well-known products include ServiceNow, Jira Service Management, TOPdesk (originally from the Netherlands and common in Dutch organizations), Freshservice, Ivanti and BMC Helix. They differ in price, size of organization they suit, and how much they can be customized, but a person who knows one can find their way in another within days, because the concepts are the same.

A tool does not create a process. If Kestrel buys a new platform without agreeing what an incident priority means or who approves a change, it gets the old confusion in a new interface. The reverse also holds: heavy customization makes upgrades painful, so organizations increasingly adapt their processes to the tool's standard behavior where the difference does not matter.

On-call duty

Services run around the clock; people do not. An on-call rotation is a schedule that makes one or more people responsible, in turns, for responding to urgent alerts and incidents outside normal working hours (and often during them). When monitoring detects a serious problem, a paging tool notifies the person on call by app push, text message or phone call until someone acknowledges it.

• Escalation policies decide what happens when nobody responds: at Kestrel the primary engineer is paged first; if there is no acknowledgment within 10 minutes, the secondary is paged; after 20 minutes, the duty manager.
• Follow-the-sun is the alternative to night shifts for organizations with teams in several time zones: Europe hands over to the Americas, which hand over to Asia-Pacific, so everyone works in their daytime.
• Fair rotas spread the load: enough people in the rotation (a week on call every few weeks, not every other week), compensation and rest after night call-outs as labor rules and agreements require, and an easy way to swap shifts.
• Handover at the end of each shift: open incidents, anything fragile, changes planned for the next shift. A short written note beats a memory.

The healthiest teams treat pages as a cost to reduce. Every page that did not need a human is a reason to tune an alert or automate a fix, because exhausted engineers make worse decisions and leave. On-Call in the Observability & SRE topic shows this escalation policy in a paging tool and how to measure the pager load.

Runbooks

A runbook is a documented, step-by-step procedure for a specific operational task or alert: what to check, what to do, how to verify the result and when to escalate. It lets anyone on the rotation, not only the expert, handle the alert at 03:00 — and steps that are always the same are the first candidates for automation. A runbook covers routine operations; a security playbook covers the response to a type of security incident, with more decision points and roles.

RB-PORTAL-03  Customer portal returns HTTP 503
Alert         portal-availability < 99% for 5 min (synthetic check)
Owner         Web platform team · last tested 2026-09-02

1. Acknowledge the page. Open or link the incident (P2 unless a major
   incident is declared). Post in #ops-portal that you are on it.
2. Check the change schedule: was anything deployed or changed in the
   last 2 hours? If yes, go to step 6.
3. Load balancer: are the web nodes 203.0.113.21 and 203.0.113.22
   healthy? If one is unhealthy, take it out of the pool.
4. Dependencies: check the dashboard for the token service and the
   customer database. If either is down, follow RB-TOKEN-01 or RB-DB-02.
5. Capacity: CPU or connections above 90% on both nodes? Scale out to
   four nodes (approved standard change SC-014).
6. Recent deployment: roll back to the previous version with the
   pipeline's back-out job. Inform the release owner.
7. Verify: synthetic check green for 10 minutes, error rate normal.
8. Update the incident with what you did; leave it for the morning
   review. Escalate to the secondary on call if not fixed in 30 min.

ITIL and DevOps

DevOps is a way of working in which the people who build software also share responsibility for running it, supported by heavy automation such as continuous integration and delivery pipelines. It is sometimes presented as the opposite of ITIL: fast teams versus slow change boards. That picture is mostly about badly applied ITIL. ITIL asks that changes are assessed in proportion to their risk; it does not demand a weekly meeting for every deployment.

In practice, the two fit together like this at Kestrel:

• Automated change approval. A deployment that passes the pipeline's tests, security scans and canary checks is a pre-approved standard change; the pipeline records it in the ITSM tool automatically. See change enablement.
• Human review where it matters. A database schema change on the billing system, or a change during the year-end billing run, still gets a risk assessment by people.
• Shared ownership. The team that builds the portal is on call for it, so it feels the pain of fragile releases and fixes the cause.
• One record. Incidents, changes and deployments are linked, so a post-incident review can see which deployment came right before the outage.

Site reliability engineering

Site reliability engineering (SRE) is an approach to running production systems that applies software engineering to operations: reliability targets are set from the user's point of view, measured precisely, and defended with automation rather than manual effort. It originated at Google in the early 2000s and spread widely after Google published books about it. Many organizations now have SRE teams, or engineers who use SRE practices within ordinary operations teams. This is the short version; What Is SRE? in the Observability & SRE topic covers it in depth.

SLOs and error budgets

SRE starts from a service level objective (SLO): a target for a measured value, such as "the portal is available 99.9% of the time over 30 days". Its key insight is that 100% is the wrong target — it is unaffordable, and users cannot tell the difference above a certain level. The gap between the SLO and 100% is the error budget: the amount of unreliability the service may have in the period. While budget is left, the team can take risks and release often; when it is spent, the team slows down risky changes and works on stability until the budget recovers. This turns the old argument between "ship faster" and "don't touch it" into a shared rule.

SLO = 0.999                  # 99.9% of minutes available
PERIOD_MINUTES = 30 * 24 * 60

budget = PERIOD_MINUTES * (1 - SLO)
print(f"Error budget: {budget:.1f} minutes in 30 days")

incidents = [
    ("INC-21702 portal 503 after deploy", 14),
    ("INC-21759 login errors (token service)", 9),
    ("INC-21811 carrier link down, failover slow", 11),
]

used = 0
for name, minutes in incidents:
    used += minutes
    print(f"{name:<45} {minutes:>3} min")

left = budget - used
print(f"Used: {used} min ({used / budget:.0%} of budget)")
print(f"Left: {left:.1f} min")
if left < budget * 0.25:
    print("Less than 25% left: slow down risky releases")

Error budget: 43.2 minutes in 30 days
INC-21702 portal 503 after deploy              14 min
INC-21759 login errors (token service)          9 min
INC-21811 carrier link down, failover slow     11 min
Used: 34 min (79% of budget)
Left: 9.2 min
Less than 25% left: slow down risky releases

Real SLOs are often measured in requests rather than minutes ("99.9% of requests succeed"), and alerts can be based on how fast the budget is burning; see SLO-based alerting. The 25% rule above is only an illustration; the error budget policy of Kestrel's portal team says what really happens when the budget runs out.

Toil

Toil is operational work that is manual, repetitive, automatable and reactive, and that grows with the size of the service without leaving any lasting improvement behind: restarting the same service by hand every week, copying user data between systems, approving the same safe request again and again. SRE teams measure toil and cap it — Google's guidance is to keep it below half of an engineer's time — so that the rest goes into engineering work that removes it. Toil is not the same as all operational work; a thoughtful incident review is not toil. Measuring toil shows how Kestrel's portal team keeps it under the cap.

ITIL with Agile and PRINCE2

Agile and Scrum

Agile approaches such as Scrum deliver products in short iterations with frequent feedback from users. They overlap with ITIL more than people expect: "progress iteratively with feedback" is one of ITIL's guiding principles, and the continual improvement model works in small steps. In practice, a Scrum team that owns Kestrel's mobile app also receives the incidents and problems for it in its backlog, and its regular releases run as standard changes. The Agile & Scrum topic covers the methods themselves.

PRINCE2 and project management

PRINCE2 (PRojects IN Controlled Environments) is a widely used project management method, built around principles, practices (called themes before PRINCE2 7) and processes, which define how a project is started, directed, controlled stage by stage and closed, with a clear business justification throughout. Like ITIL, it is now owned by PeopleCert; the current edition, PRINCE2 7, appeared in 2023.

Projects and service management need each other. A project delivers a change — Kestrel's new billing platform — and then ends; service management runs the result for years. Most trouble happens at the boundary: a project that goes live without a support team trained, monitoring in place, knowledge articles written or underpinning contracts signed. Involving the service desk, operations and suppliers early, and agreeing acceptance criteria for operations before go-live, prevents the "project is closed, the problems are yours" handover.

Useful metrics for a team

Every metric can be gamed, and each one shows only part of the picture. Use a few together, look at trends rather than single values, and know what each can hide.

The DevOps Research and Assessment (DORA) metrics — at their core deployment frequency, change lead time, change failure rate and failed deployment recovery time — are a useful companion for teams that deliver software; see the DORA metrics.

From ITIL 4 to ITIL (Version 5)

ITIL (Version 5) appeared in early 2026 (training providers report the framework in January and the new Foundation exam in February). Many organizations still work with ITIL 4 vocabulary, and PeopleCert currently plans to retire the ITIL 4 modules at the end of 2027. Most ITIL 4 certificate holders can move over with a short ITIL Foundation Bridge (Version 5) course and exam. The main differences you will meet:

Unchanged: the seven guiding principles; the four dimensions (now called the ITIL Four Dimensions of Product and Service Management) and PESTLE; the 34 practices (with their ITIL 4 names, according to training material); and a Continual Improvement Model with seven steps. Commentators describe the move from six value chain activities to eight lifecycle activities as a replacement. Any one-to-one mapping between the two lists is an interpretation rather than part of the official material, so learn the eight on their own terms.

Your first weeks in an ITSM team

• Learn the priority matrix and what P1 really means here — and who to call when you see one.
• Find the knowledge base, the runbooks and the service catalog; note which articles are outdated and tell the owner.
• Ask how changes are approved: which are standard, who decides on the others, when the maintenance windows and freezes are.
• Look up the main SLAs and the suppliers behind them, so you know what was promised and who to escalate to.
• Read a few recent post-incident reviews: they show how the services really fail.
• Shadow an on-call shift before you take one, and walk through a runbook with its owner.
• Write things down as you learn them. Your fresh questions are exactly what the knowledge base is missing.