major incident

Крупный инцидент — это инцидент, который затрагивает критически важные для организации результаты и быстро приводит к ощутимым последствиям: остановке ключевых операций, существенным финансовым потерям, рискам соответствия требованиям или репутационному ущербу. В отличие от «обычных» инцидентов, для крупного инцидента характерны повышенная срочность и необходимость координации нескольких команд поддержки и заинтересованных сторон, а также усиленные коммуникации с заказчиком и пользователями. На практике крупный инцидент обычно обрабатывается через управление инцидентами по отдельной процедуре: быстрое подтверждение масштаба, назначение лидера, организация совместной диагностики, согласование обходного решения, частые обновления статуса и контроль восстановления услуги в рабочей среде. Критерии «крупности» часто привязывают к влиянию и срочности, критическому фактору успеха, KPI, а также к обязательствам по SLA и риску нарушения уровня услуги. При этом термин не означает «самый сложный технически»: крупным может быть и относительно простой сбой, если он затрагивает важную ИТ-услугу или много пользователей. Вне области термина находятся плановые работы и изменения как таковые, а также долгосрочное устранение первопричины, которое обычно относится к управлению проблемами.

Частая ошибка — считать крупный инцидент синонимом «катастрофы». Катастрофа обычно подразумевает необходимость восстановления по плану восстановления после катастрофы и задействование управления непрерывностью услуг; крупный инцидент может быть разрешён в рамках операционного управления инцидентами без переключения на восстановление. Другая путаница возникает между крупным инцидентом и проблемой: крупный инцидент — это острое прерывание или деградация услуги, требующая немедленного восстановления, а проблема — причина одного или нескольких инцидентов и объект анализа и предотвращения повторения. Нередко организации чрезмерно расширяют критерии и объявляют «крупным» почти любой инцидент высокой срочности, перегружая коммуникации и отвлекая команды поддержки; наоборот, занижение критериев приводит к запоздалой эскалации и нарушению SLA. Ещё один риск — смешивать разрешение с изменением: для восстановления может потребоваться изменение, иногда экстренное изменение, но управление крупным инцидентом не подменяет управление изменениями. Также важно не путать обходное решение с окончательным разрешением: обходное решение восстанавливает предоставление услуги, но может оставить известную ошибку и технический долг, которые должны быть прозрачно зафиксированы и переданы в управление проблемами и последующее совершенствование.