Портал №1 по управлению цифровыми
и информационными технологиями

Major / Critical Incident Management: важная темная область

На прошедшем в начале этой недели курсе мы с его участниками обсуждали инциденты, для которых не очень хорошо работают привычные процедуры, описанные в книжках. Участники называли такие инциденты "критическими", я по привычке "значительными". Что мы в ходе этого обсуждения выяснили: 

Во-первых, годное определение значительного инцидента не так-то просто найти в литературе. Например, словарь ITIL говорит, что 

Major Incident – The highest category of impact for an incident. A major incident results in significant disruption to the business.(Значительный инцидент – Наивысшая категория влияния, применяемая инцидента. Значительный инцидент вызывает существенные потери для бизнеса.)

Если Critical или Major – действительно лишь значение параметра "Impact", то не вполне понятно, зачем ITIL рекомендует обрабатывать такие инциденты по некой специальной процедуре, а стандарт требует (ISO/IEC 20000:2011, раздел 8.1):

The service provider shall document and agree with the customer the definition of a major incident. Major
incidents shall be classified and managed according to a documented procedure. Top management shall be
informed of major incidents. Top management shall ensure that a designated individual responsible for
managing the major incident is appointed. After the agreed service has been restored, major incidents shall be reviewed to identify opportunities for improvement.

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

То есть высокая степень влияния – необходимый, но не достаточный признак для обработки инцидента как значительного. Видимо, дело здесь именно в неэффективности обычных процедур управления инцидентами и потребности в других, необычных процедурах. Этому предположению можно найти подтверждение в специализированных документах, разработанных различными государственными, городскими и другими  подобными службами, откуда, как я подозреваю, авторы ITIL и позаимствовали когда-то и само определение, и процедуры, с ним связанные. Вот, например, что говорится в Major Incident Procedure Manual, разработанном London Emergency Services Liason Panel: 

A major incident is any emergency that requires the implementation of special arrangements by one or more of the emergency services and will generally include the involvement, either directly or indirectly, of large numbers of people.

For example: 

  • The rescue and transportation of a large number of casualties; 
  • The large scale combined resources of Police, London Fire Brigade and London Ambulance Service; 
  • The mobilisation and organisation of the emergency services and support services, for example local authority, to cater for the threat of death, serious injury or homelessness to a large number of people; and 
  • The handling of a large number of enquiries likely to be generated both from the pubic and the news media usually made to the police.

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

  • Восстановление работы большого числа пользователей
  • Масштабные совместные действия Отдела ИТ, Административного отдела, Отдела ИБ, Отдела связи
  • Мобилизация и организация аварийных служб и служб поддержки, например, предоставление большого числа подменных рабочих мест, организация резервных каналов связи и электропитания и т.п. 
  • Обработка большого числа обращений со стороны пользователей и других интересующихся, обычно – через Service Desk. 

Итак, выходит, что признаками Major Incident'ов являются:

  • Существенный ущерб (тут применяются обычные критерии, те же, что при оценке ущерба от обычных инцидентов: влияние на Vital Business Functions, число и статус жертв, финансовые потери, имиджевые потери, влияние на исполнение внешних требований…)
  • Сложность и масштаб работ по управлению инцидентом (необходимость координации множества участников, часто – из смежных подразделений, а также обработка большого числа обращений, выполнение работ с множеством компонентов инфраструктуры…)

Следующий вопрос, неизменно возникающий при обсуждении таких инцидентов, касается их идентификации. Кто и как принимает решение об активации специальных процедур? Вот что говорит об этом то же руководство:

A major incident can be declared by any member of the emergency services which considers that any of the criteria outlined above has been satisfied. In certain circumstances such as flooding the local authority may declare a major incident.
Despite the fact that what is a major incident to one of the emergency services may not be so to another, each of the other emergency services will attend with an appropriate predetermined response. This is so even if they are to be employed in a standby capacity and not directly involved in the incident.

Значительный инцидент может быть объявлен любой из аварийных служб, если она считает, что ситуация соответствует описанным выше критериям. (…)
Несмотря на то, что другие аварийные службы могут не видеть в ситуации признаков значительного инцидента, все они обязаны отреагировать в соответствии с предопределенной процедурой – даже если они не будут принимать активного участия в устранении инцидента. 

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

Характерно, что "an investigation into the cause of the incident, together with the attendant hearings, may be superimposed onto the whole structure" (раздел 2.3.2 того же документа). То есть расследование причин может выполняться одновременно с инцидентом, но параллельно, не являясь частью процедуры управления самим инцидентом. Здравcтвуй, реактивное управление проблемами по ITIL. 

Вот такие наблюдения и аналогии. А что вы делаете со своими значительными инцидентами? В частности, 

  • как вы их определяете?
  • кого вы назначаете ответственным за управление каждым из них?
  • как организуете совместную работу команд?
  • как проводите Major incident review? 

 

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 15

  • Nargiza Suleymanova

    Скажите, а это я так жестоко ошибалась, считая, что major/critical incidents – это про аварии? Потому как отдельный процесс с обязательным оповещением руководства и участием множества команд именно для управления авариями используется обычно.

    • Наргиза, не знаю. Термины они такие термины… Но можно попробовать разобраться.
      Какое определение инцидета вы используете? А какое определение аварии?

      • Nargiza Suleymanova

        Для инцидента использую стандартное определение ITIL. Авария же по сути – это массовый инцидет высокого влияния на бизнес. Вот такое определение аварии использовала в договоре (номера таблиц и приложений удалила :-)):

        "Авария – нештатная ситуация в программном или аппаратном обеспечении, обслуживаемого в рамках настоящего договора, которая привела:

        к остановке работы одного или нескольких технологических процессов

        к полному не предоставлению сервиса из Таблицы №__ Приложения №__ или полной неработоспособности бизнес-процесса Системы из Таблицы __ Приложения №__.

        к потере управления критически важными частями Системы и/или частью Системы, влияющие на возможность предоставления какого-либо  сервиса"

  • Потов Вячеслав

    Имеет место быть 🙂 И задокументирован в отдельный процесс, постевлен на рельсы и очень лихо по ним катится 

    Если кратко. CIM (Как и в предложенном примере, именуем их Critical) – процесс идущий паралельно с IM. Ключевая цель – обеспечение коммуникации по всем уровням ИТ (с целью информирования нужных и потенциально нужных команд) и ключевых пользователей бизнеса, и обеспечения нужного уровня фокуса для выделения требуемых ресурсов на разрешение.

    С установленной периодичностью расходится глобальная коммуникация информирующая о текущем ущербе, проделанных шагах, следующих шагах, вовлечённых командах, и ответственных лицах. Вся эта компания так же периодично собирается для обсуждения апдейтов. Параллельно ведётся так называемый Crisis chat.

    По закрытии такого инцидента всегда открывается проблема. 

    Post-incident review проводится всегда для инцидентов с высоким уроном, так же Service Owner может запросить PIR по любому критическому инциденту. 

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

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

    • Слава, спасибо, исчерпывающий ответ и сам процесс тоже впечатляет.

      А кто обычно выступает в роли Critical Incident Manager'а?

      • Потов Вячеслав

        Можно уточнить, имеется в виду человек отвечающий за конечное решение отдельно взятого критического инцидента (в классике – owner), или в классическом понимании, отвечающий за выполнение процесса в целом?

        Первые – аналитики второй линии ServiceDesk (если помните нашу организацию). 

        Второй – один из супервайзеров этой же группы, если говорить про Responsibility, и менеджер команды, если говорить об Acountability

    • Роман

      Вячеслав, спасибо за подробный ответ! По каким 4 измерениям идет разбор и можете ли поделиться опросником? Очень заинтересовало.

      • Потов Вячеслав

        Доброго дня, Роман.

        К сожалению, в чистом виде опросником поделиться не могу. Но могу указать на творчество господина Ишикавы, как источник вдохновения для создания оного 🙂

        Из 5ти измерений там, мы немного реструктуризировав, оставили 4 – People, Process, Tool, Metrics. 

  • Андрей

    А я вот обратил внимание на целевую аудиторию в опрееделении. Top managemet, не IT Top management, а именно высшее руководство компании. В моем понимании это говорит о том, что major/critical incndent это ситуация, когда ИТ со всеми её службами и процессами уже не достаточно. Понятно смущение многих при определении того относится ли инцидент к major/critical или нет. Дело в том, что при регистрации инцидента почти всегда невозможно это определить. Все формальные признаки не могут однозначно указывать на то, что это major/critical. Охватывает значительное количество пользователей? Ну и что? То, что отвалился интернет еще не означает что компания встала(иногда даже наоборот:))). Major/critical он становится по ходу работы с ним, когда ИТ понимает, что услуга критическая для бизнеса и справится с инцидентом в приемлемые сроки баз катастрофических последствий для бизнеса они уже не могут. Вот тут они и обращаются к руководству бизнеса с радостной вестью, что всё, хана, если не хотите остаться без штанов на нас пока не расчитывайте и запускайте обходные/ручные процедуры. И вот наличие таких не ИТ процедур и наличие механизмов контроля их исполнения как раз и отличает тех, у кого есть процесс для major/critical инцидентов и тех, у кого их нет. Почему задействутеся высшее руководство бизнеса? Потому что ИТ, как правило, " тварь дрожащая и права не имеет". Не имеет права давать распоряжение не ИТ подразделениям о переходе на обходные технологии и уж тем более не может организовать полноценный контроль за их соблюдением. Проиллюстрирую примером из реальной жизни чем кончается отстутвие major/critical incident management. На одном предприятии "упала" система отгрузки. Когда ИТшники поняли, что в обычные, допустимые сроки они её не поднимут, а санкции за нарушение сроков отгрузки весьма ощутимы, они сообщили руководству, что надо срочно переходить к ручному оформлению. Поскольку система уже работала достаточно давно, почти не осталось людей, которые помнили процедуры, используемые до прихода ИТ, и работали как получалось. В результате с предприятия увели три вагона готовой продукции. Один так и не нашли.

    Всё изложенное – чисто моё, сугубо предвзятое личное мнение:)

  • Grigory Kornilov

    Имхо

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

    Но наверное иногда неверно используется кем-то и для "пугания\мотивации" служб поддержки.

  • Менеджер Инцидентов

    Дежурный инженер Service Desk, владея оперативной информацией по ситуации в ИТ-инфраструктуре (показания системы мониторинга, обращения пользователей) обязан незамедлительно предоставлять (по факту поступления) Менеджеру Инцидентов (или лицу его замещающему) информацию об инциденте как потенциально возможном кандидате на классификацию в качестве Значительного инцидента.

    Критерии для подобных кандидатов: 
    •    Массовые обращения-инциденты от пользователей (от 3х обращений от разных пользователей и больше)
    •    Показания системы мониторинга о нештатной ситуации, подтвержденные  результатами ручной проверки недоступности услуги (услуга недоступна полностью, или основная функциональность существенно деградировала).
    •    Значительный охват потребителей затронутой услуги (должна быть большая часть или вся компания, либо услуга недоступна для всего подразделения) 
    •    Важность услуги для бизнес потребителей (например услуги такие то, охватывающие всю или большую часть компании, и имеющие круглосуточное согласованное время поддержки )

    Решение о классификации инцидента как значительного принимает Менеджер Инцидентов. При этом он руководствуется: определением значительного инцидента и своей экспертной оценкой ситуации…

    Далее ставим Impact = Major Incident и автоматически создается собрание по сети с приглашением всех необходимых участников. Идет общение в "прямом эфире" до выработки решения. Проблема после создается конечно же не во всех случаях, а только когда неизвестна причина, и заявка о проблеме удовлетворяет критериям проблемы (это уже тема для другой статьи))

     

    • Grigory Kornilov

      Интересна реализация подобного в субботу в 2 часа ночи с участием ТОП менеджеров. Особенно интересен ранг Менеджера Инцидентов

       

      … ставим Impact = Major Incident и автоматически создается собрание по сети с приглашением всех необходимых участников. Идет общение в "прямом эфире" до выработки решения …

      • Андрей

        Причем первый вопрос, который НЕ ИТ ТОП задаст – а от меня вы что хотите? :))))

  • Тимур

    Лично я определил такое описание:

    Значительный инцидент – инцидент, который может привести к длительному простою работы ИТ-сервиса, негативно влияющий на бизнес или ведущий к большим финансовым потерям

  • Александр

    На мой взгляд обработка значительных инцидентов тесно связана с процессом ITSCM. Соответственно значительные инциденты идентифицируются на основе тех рисков, которые выделены в рамках деятельности процесса ITSCM (аварии о которых уже упоминалось).

    Процедура обработки значительных инцидентов выполняется согласно DRP, который разработан для каждой услуги (их может быть несколько даже в рамках одной услуги). Ответственным является Менеджер услуги (Service Owner). По сути механизм напоминает стандартные изменения, которые передаются в RF для выполнения.

    Каждый подобный инцидент порождает проблему. В результате решения проблемы может быть обновлен или перечень рисков или существующий DRP по услуге.


Добавить комментарий для Nargiza SuleymanovaОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM