Что считать значительным инцидентом

ITIL описывает значительные/критические (major) инциденты, как события, которые сильно влияют на бизнес и ведут к большим финансовым потерям. Подобное событие получает наивысший приоритет и минимальное время реакции. Негативные последствия тут есть всегда и речь может идти только о том, чтобы свести их к минимуму. Значительные инциденты выделяются из общего управления инцидентами, т.к. обычные процедуры в таких случаях не работают. Управление инцидентами ориентировано на то, чтобы устранять множество различных инцидентов в короткий срок с вовлечением минимального количества ресурсов. В случае критического инцидента придется вовлекать все возможные ресурсы, включая дорогостоящих сторонних экспертов, чтобы только справиться с ситуацией в рамках вашего SLA. Причем, если в SLA вы не учитывали риск подобных ситуаций, то выполнить его просто не возможно.

В случае значительных инцидентов должна действовать специальная процедура, которая:

Ускорит разрешение инцидента, обладающего значительным воздействием на бизнес. Поможет максимально быстро привлечь к разрешению инцидента все возможные ресурсы в обход стандартных процедур управления инцидентами.
Обеспечит коммуникацию с затронутыми инцидентом пользователями и с руководством компании.

При разработке процедур управления значительными инцидентами необходимо особое внимание уделить тому:

Когда должна быть задействована подобным процедура.
Какие действия должны быть предприняты и кто ответственен за них.

Решение о том, чтобы задействовать подобную процедуру сложнее, чем это кажется на первый взгляд. На самом деле, ежемесячно может быть множество инцидентов с высоким приоритетом и довольно значительным воздействием на бизнес, но при этом далеко не все из них действительно можно отнести к критическим. Тут можно, как формально определить ситуации, в которых критическая процедура должна быть задействована. Или можно предоставить большую свободу службе Service Desk, ограничившись лишь общим руководством и критериями, которые они могут оценивать самостоятельно.

Критериями могут служить инциденты, в которых:

Быстрое или обходное решение недоступно.
Велика вероятность существенного воздействия на бизнес, и связанных с ним потерь.
Большой шанс не выполнения SLA.
Необходимо задействовать специальные ресурсы, особые планы ликвидации инцидента.

При этом, чтобы особые процедуры разрешения значительных инцидентов работали необходимо сделать их простыми и понятными для служб Service Desk. Руководство по критическим инцидентам не должно быть длиннее двух страниц. Его задача не в том, чтобы дать инструкции по разрешению всех возможных ситуаций. Главное описать кого и в каких ситуациях необходимо вызывать в любое время дня и ночи.

Недавно в одной их групп Linkedin, о том какие события можно считать значительными или критическими инцидентами. Вот несколько примеров:

Потеря одного или нескольких серверов, на которых работают ваши виртуальные машины, что ведет к потере сотен виртуальных машин.

Недоступность важных для бизнеса систем
Недоступность корпоративной сети и ИТ-сервисов для всех, или для значительной части пользователей
Недоступность систем используемых руководством компании
Повреждение интернет кабеля, обеспечивающего связь с провайдером
Отключение электричества и невозможность задействовать резервные источники питания
Потеря хранилища SAN
DDOS – атака на критические веб приложения и сервисы
Вирусное заражение компьютеров с критическими приложениями и сервисами
Потеря внутренних DNS, контролера домена и других базовых серверов
Потеря критических баз данных, например с POS транзакциями

А какие примеры критических инцидентов можете привести вы?

Дополнительные материалы