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

ITIL описывает значительные/критические (major) инциденты, как события, которые сильно влияют на бизнес и ведут к большим финансовым потерям. Подобное событие получает наивысший приоритет и минимальное время реакции. Негативные последствия тут есть всегда и речь может идти только о том, чтобы свести их к минимуму. Значительные инциденты выделяются из общего управления инцидентами, т.к. обычные процедуры в таких случаях не работают. Управление инцидентами ориентировано на то, чтобы устранять множество различных инцидентов в короткий срок с вовлечением минимального количества ресурсов. В случае критического инцидента придется вовлекать все возможные ресурсы, включая дорогостоящих сторонних экспертов, чтобы только справиться с ситуацией в рамках вашего SLA. Причем, если в SLA вы не учитывали риск подобных ситуаций, то выполнить его просто не возможно.
В случае значительных инцидентов должна действовать специальная процедура, которая:
- Ускорит разрешение инцидента, обладающего значительным воздействием на бизнес. Поможет максимально быстро привлечь к разрешению инцидента все возможные ресурсы в обход стандартных процедур управления инцидентами.
- Обеспечит коммуникацию с затронутыми инцидентом пользователями и с руководством компании.
При разработке процедур управления значительными инцидентами необходимо особое внимание уделить тому:
- Когда должна быть задействована подобным процедура.
- Какие действия должны быть предприняты и кто ответственен за них.
Решение о том, чтобы задействовать подобную процедуру сложнее, чем это кажется на первый взгляд. На самом деле, ежемесячно может быть множество инцидентов с высоким приоритетом и довольно значительным воздействием на бизнес, но при этом далеко не все из них действительно можно отнести к критическим. Тут можно, как формально определить ситуации, в которых критическая процедура должна быть задействована. Или можно предоставить большую свободу службе Service Desk, ограничившись лишь общим руководством и критериями, которые они могут оценивать самостоятельно.
Критериями могут служить инциденты, в которых:
- Быстрое или обходное решение недоступно.
- Велика вероятность существенного воздействия на бизнес, и связанных с ним потерь.
- Большой шанс не выполнения SLA.
- Необходимо задействовать специальные ресурсы, особые планы ликвидации инцидента.
При этом, чтобы особые процедуры разрешения значительных инцидентов работали необходимо сделать их простыми и понятными для служб Service Desk. Руководство по критическим инцидентам не должно быть длиннее двух страниц. Его задача не в том, чтобы дать инструкции по разрешению всех возможных ситуаций. Главное описать кого и в каких ситуациях необходимо вызывать в любое время дня и ночи.
Недавно в одной их групп Linkedin, о том какие события можно считать значительными или критическими инцидентами. Вот несколько примеров:
Потеря одного или нескольких серверов, на которых работают ваши виртуальные машины, что ведет к потере сотен виртуальных машин.
- Недоступность важных для бизнеса систем
- Недоступность корпоративной сети и ИТ-сервисов для всех, или для значительной части пользователей
- Недоступность систем используемых руководством компании
- Повреждение интернет кабеля, обеспечивающего связь с провайдером
- Отключение электричества и невозможность задействовать резервные источники питания
- Потеря хранилища SAN
- DDOS – атака на критические веб приложения и сервисы
- Вирусное заражение компьютеров с критическими приложениями и сервисами
- Потеря внутренних DNS, контролера домена и других базовых серверов
- Потеря критических баз данных, например с POS транзакциями
А какие примеры критических инцидентов можете привести вы?
Дополнительные материалы
- События, которые могут перерасти в инциденты
- Принципы оптимальной классификации инцидентов
- О плане реагирования на инциденты ИТ-безопасности
- Чему ИТ-шников может научить авария на АЭС «Фукусима-1»
- Кто должен платить, если сломалось то, что не трогали? Итоги обсуждения
- Определяем приоритеты и сроки устранения инцидентов. Запись вебинара
Комментарии (1)
Комментировать[sozimov], 28 июня 2014, 10:03