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

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

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

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

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

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

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

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

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

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

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

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

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

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

• События, которые могут перерасти в инциденты
• Принципы оптимальной классификации инцидентов
• О плане реагирования на инциденты ИТ-безопасности
• Чему ИТ-шников может научить авария на АЭС «Фукусима-1»
• Кто должен платить, если сломалось то, что не трогали? Итоги обсуждения
• Определяем приоритеты и сроки устранения инцидентов. Запись вебинара