An organizational principle where the focus is on understanding system failures rather than assigning individual blame. Essential for honest post-incident reviews and continuous learning.
Glossary
Key Terms & Definitions
Essential terminology for IT Major Incident Management, drawn from ITIL, Agile/SRE, and industry best practices.
The scope of impact of an incident or a change, meaning how many users, services, or systems are affected.
A conference call or virtual meeting room where the incident response team collaborates in real-time during a major incident. Also called a War Room.
The ITIL process that controls changes to the IT environment. Critical during incidents because most incidents are caused by changes.
The discipline of deliberately introducing controlled failures into a system to test its resilience and identify weaknesses before they cause real incidents.
A database that stores information about IT assets and their relationships. Used during incidents to understand service dependencies and blast radius.
The process of involving additional or more senior resources. Functional escalation involves technical experts; hierarchical escalation involves management.
A software technique that allows features to be toggled on/off without deploying new code. Useful during incidents for quick rollback of problematic features.
A planned exercise where a team simulates a major incident to practice the response process, test runbooks, and identify gaps in a safe environment.
A database of known errors and their workarounds. Checked during incidents to see if the issue has a known solution.
An incident with significant business impact that requires an emergency response beyond the normal incident management process. Typically involves multiple teams and executive visibility.
The designated person who takes ownership of the major incident response, coordinating teams, driving communications, and ensuring the process is followed. Also known as Incident Commander.
The average time between incidents for a given service. Measures reliability over time.
The average time between when an alert is triggered and when a responder acknowledges and begins working on it.
The average time between when an incident begins and when it is detected by monitoring or reported by users.
The average time from incident detection to full service restoration. The primary metric for measuring incident management effectiveness.
A structured, blameless meeting held after a major incident to analyze what happened, identify root causes, and define improvement actions. Also called a Retrospective or Post-Mortem.
The ITIL process responsible for identifying root causes and driving permanent fixes to prevent incident recurrence. Takes over from incident management after service is restored.
A responsibility assignment tool: Responsible (does the work), Accountable (owns the outcome), Consulted (provides input), Informed (kept up to date).
A systematic process for identifying the underlying cause(s) of an incident. Common techniques include 5 Whys, Fishbone Diagram, and Fault Tree Analysis.
A documented set of step-by-step procedures for handling specific operational scenarios. Used during incidents to ensure consistent response.
A classification level indicating the impact and urgency of an incident. Typically ranges from SEV-1 (most critical) to SEV-4 (lowest). Used to determine response speed and communication cadence.
A formal agreement between a service provider and customer defining expected service levels (availability, response time, etc.) and penalties for non-compliance.
An internal target for service reliability. More flexible than SLAs. Used by SRE teams to balance reliability investment with feature development.
An Agile-inspired approach where multiple experts are brought together immediately to work on an incident collaboratively, rather than following a tiered escalation path.
A temporary solution that restores service or reduces impact while a permanent fix is developed. Not the same as a resolution.