Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии (1)

  • Аватар

    [sozimov], 28 июня 2014, 10:03

    0
    Значительный инцедент - когда на Smartsourcing перестают писать, и он рискует кануть в небытие! ;)