Mayday, Mayday, Mayday – What’s a Major Incident?
A situation when in the opinion of the master, the vessel, vehicle, aircraft or person is in grave and imminent danger and requires immediate assistance.
International conventions (SOLAS, COLREG) clearly establish when a distress signal (such as a “Mayday” call) may be made. These same conventions bind those that receive a distress signal to respond in a particular way.
Our major incident process bears striking similarity to this but, thankfully, life and limb are not usually at risk!
In the Opinion of the Master…
Someone needs to make a judgement call that the situation is a Major Incident. Since we’re not all at sea, that someone is the “Incident Commander”. There isn’t a definitive and exhaustive list of major incidents, rather they can be many and varied, hence the decision as to whether to declare a Major Incident needs to be made by an individual. A list of our incident commanders will be circulated shortly, but mostly it will be a member of the ITIL Team.
As we’re not all in the same boat, the first step will be to inform the Incident Commander that something big is happening, so that they can make that judgement call.
Grave and Imminent Danger…
The Incident Commanders have guidance to inform their decision on what might constitute a Major Incident.
As a rough rule of thumb, the Incident Commander should be contacted if one or more of our Business Services are unavailable or significantly degraded due to an unplanned event. Perhaps the Service Owner or Service Operations Manager becomes aware of a service showing signs of strain, likely to cause degradation or an outage. Or perhaps it is technical monitoring that shows a failing infrastructure component, or a significant cyber-attack in progress. Or perhaps it’s an Estates issue where power, cooling or water supplies could be threatened to one of our buildings.
If in doubt, make the shout! Early invocation of the Major Incident process can minimise the impact on the University, and the Commander will take into account the time of year, the business impact of the incident, the scope and the scale. Even if some of these are unknown, it is better to alert the Incident Commander sooner rather than wait until the vessel has sunk!
Requires immediate assistance…
Once the Incident Commander has declared a Major Incident, they can assemble a team to work on the Incident. You may find that you’re co-opted into the team and tasked to provide assistance – the Incident Commander can requisition resources as required, and you are obligated to assist (SOLAS Chapter V, Regulation 33) . The Commander will release resources as they cease to be required. However, we don’t insist you provide hospitality for those you rescue and since no souls are likely to be lost, the obligation also only extends to working hours, not 24×7!
For those still wanting examples, here are a few!
- Temporary loss of an IS primary building (e.g. the Main Library Building)
- A single day of severe weather resulting in staff shortages
- A “top priority” system is unavailable or significantly degraded (e.g. MyEd)
- A “medium priority” system is unavailable or significantly degraded at a business critical time of year (e.g. Media Hopper Replay during the Examination block)
- Several business services are unavailable or degraded (e.g. due to a fault with the virtual server infrastructure)
- The IS Service Desks are receiving an unmanageable volume of calls
- Temporary loss of an IS satellite building or area (e.g. a single open access computing lab)
- A single business service is degraded or unavailable
- Loss of localised network to a non-business critical building
- Loss of a single component of a business service (e.g. email mailing lists being unavailable)
Service Continuity Events
These go beyond the scope of a Major Incident, although they may begin as such. I’ll leave them beyond the scope of this article, but suffice to say, they are often marked by risks to flesh and blood!