If this trail's ITIL section teaches you nothing else, let it be this post. Incident, problem, and change are the three load-bearing words of IT operations; they are related, constantly confused, and absolutely not interchangeable. Mixing them up marks you as green faster than any technical gap — and one analogy fixes them forever.
The fire, the wiring, the rewiring
A building keeps having small electrical fires.
- Each fire is an incident — an unplanned interruption or degradation of service. Users are affected now. The goal of incident management is simple and ruthless: restore service fast. Extinguish the fire. Root causes are not the priority while the building burns; getting people working again is.
- The faulty wiring causing the fires is the problem — the underlying cause (or potential cause) of one or more incidents. Problem management's goal is diagnosis and elimination: find the wiring, understand it, plan its removal. Slower, investigative, and deliberately separate from firefighting.
- The rewiring work is the change — the controlled addition, modification or removal of anything that could affect services. Fixing the wiring means altering the live environment, and alterations are precisely how new fires start; so changes get assessed, authorised and scheduled rather than freelanced. That's change enablement, and it gets its own waypoint.
One story, three disciplines: incidents restore, problems diagnose, changes alter — carefully.
Two more words that complete the set
A workaround is a temporary way of reducing an incident's impact without fixing the cause — "reboot it and it's fine for a week." Workarounds are legitimate and often smart triage, with one professional obligation attached: a workaround should always raise or feed a problem record, because a workaround without an investigation is how organisations end up rebooting a server weekly for four years. A problem that's been diagnosed — cause understood, workaround documented, permanent fix perhaps awaiting budget — is a known error. Known-error databases are the institutional memory that lets a service desk resolve in minutes what once took days.
Why organisations are strict about the vocabulary: the three words route work to different machinery with different clocks. Incidents get urgency, escalation and SLA timers. Problems get analytical time and patience. Changes get risk assessment and scheduling. Log a recurring fault only as incidents and the cause is never hunted; treat every incident as a research project and users wait days for fires to be studied instead of extinguished. The labels aren't pedantry — they're dispatch.
Test yourself: the email server crashes Monday (incident — restore it), crashes again Thursday (incident — restore it, and someone should now open a problem), investigation finds a memory leak in a driver (problem diagnosed → known error; workaround: scheduled weekly restart), and the driver update is deployed next Tuesday at 7am with a rollback plan (change). If that paragraph reads as obvious, congratulations — you now speak operations.