Checklist: 7 шагов по работе с major-инцидентами

Тема major-инцидентов уже поднималась на нашем портале, и неоднократно. Однако после недавней встречи с одним из заказчиков я решил вернуться к ней еще раз. Теперь в виде короткого чек-листа, который можно использовать для проверки дизайна и исполнения процессов управления инцидентами и непрерывностью. Итак:

  1. alarmО возникновении major-инцидента в первую очередь, как правило, узнают профильные специалисты – сетевые инженеры, администраторы СУБД и прикладных систем. Нужно позаботиться о том, чтобы информация о major-инцидентах как можно быстрее достигла первой линии поддержки. Эта информация должна включать в себя:

     

     

    • описание инцидента (что и когда произошло, когда ожидается решение) чтобы первая линия имела ответы на вопросы пользователей;
    • ID инцидента – для установки связей с поступающими обращениями пользователей;
    • оценку влияния на ИТ-услуги (в этом может очень помочь CMDB) для понимания того, на каких пользователей оказывается влияние и какова его критичность.
  2. Для сокращения резко возросшего потока входящих обращений и информирования пользователей желательно опубликовать для них информационное сообщение. Для этого можно записать голосовое сообщение и включить автоинформатор средствами АТС, выполнить рассылку по e-mail или sms, опубликовать текстовый анонс на сервисном портале.
  3. Для общей координации действий и своевременного информирования всех заинтересованных лиц рекомендуется назначить менеджера major-инцидента (major incident manager). Обычно это или старший группы, ответственной за устранение инцидента, или менеджер процесса. На наш взгляд, второе – предпочтительнее, поскольку у менеджера процесса шире процессные полномочия по привлечению ресурсов, а также более полная картина влияния major-инцидента на ИТ-услуги и их потребителей.
  4. Вновь поступающие обращения пользователей, предположительно вызванные major-инцидентом, рекомендуется связывать с ним, чтобы быстрее завершить их обработку по факту устранения инцидента. При этом поступающие обращения следует назначать в группы специалистов, ответственных за поддержку по соответствующим ИТ-услугам, а не в группу, устраняющую major-инцидент. Это позволит:

     

     

    • снизить число ошибок при установлении привязок;
    • там, где это возможно, решать инциденты, поступившие от пользователей, посредством обходных решений, не дожидаясь окончательного устранения major-инцидента;
    • корректно проверить / обеспечить восстановление ИТ-услуги по факту устранения инфраструктурного инцидента.
  5. Менеджер major-инцидента должен знать правила и порядок активации аварийного плана восстановления (disaster recovery plan) и если устранение инцидента не происходит в установленный срок, своевременно активировать этот план.
  6. Об устранении major-инцидента необходимо оперативно оповестить и ИТ-специалистов (им нужно завершать обработку обращений, вызванных major-инцидентом, проверять восстановление ИТ-услуг), и конечных пользователей.
  7. После устранения major-инцидента рекомендуется провести мини-расследование (major incident review), по его результатам сформировать и обсудить отчет, направленный на предотвращение повторения данного инцидента, и оценку действий по его обработке. При необходимости выполняется регистрация проблемы / известной ошибки, возможна регистрация новых мероприятий по совершенствованию ИТ-услуг (service improvement plan или реестр CSI – кто какие названия использует).

В пунктах 1-2 и 4-6 существенную поддержку может оказать система автоматизации, проверьте наличие у неё соответствующих функциональных возможностей. Но, как обычно, решающее влияние на результативность перечисленных мер оказывают не столько средства автоматизации, сколько разумная организация работ и грамотный менеджмент.

Верно?

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Rafhat Osmonov

    Дмитрий, спасибо за checklist!

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

    Особенно важен п.5. Из опыта, все очень заняты устранением инцидента и только "светлая" голова готова сформулировать мысль о активации DRP.

  2. Андрей

    Итак, пройдемся по пунктам:)))

    1. Как профильный инженер узнает, что произошел именно мажорный инцидент, а не просто инцидент? Массовость охваченных пользователей? Это не показатель критического воздействия на бизнес. С момента появления самого термина Major Incident остается нерешенным вопрос —  как при регистрации инцидента по формальным признакам можно определить, что он мажорный? А никак! Потому что любой мажорный инцидент начинает свою жизнь как обычный и только если ИТ не может решить его в сроки, принятые бизнесом как допустимые, и последствия нарушения сроков решения создают неприемлемый для бизнеса риск, вот только тогда ему присваивают почетное звание мажора.

    2. справедливо для любого инцидента, связанного с массовым обращением в службу поддержки.

    3. Менеджер нужен, но требования к нему мне кажутся не совсем правильными. Раз инцидент стал мажорным, то ИТ уже показало свою неспособность решить его внутри себя, а правильная процедура решения инцидента и так должна подразумевать привлечение всех возможных ресурсов. И тут нужен менеджер, который способен оперативно согласовывать с бизнесом возможные/ допустимые для бизнеса обходные решения(переход на частично ручную обработку и т.д.).

    4., 5. Да. Единственное — на счет активации плана восстановления. Есть неприятный момент, когда его могут активировать в силу отчаяния, а не в силу разумного принятия решения. Но тут остается полагаться толко на опыт и квалификацию, формирующие профессиональное чутьё.

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

    7. Да. Вопрос лишь в том, кто такое расследование должен проводить. Инциден по-сути есть симптом, сообщающий о проблеме или совокупности проблем. И тут логичнее, на мой взгляд, всё это отправлять в процесс управления проблемами.

     

     

    1. Nargiza Suleymanova

      Мои комментарии тоже по пунктам 🙂

      1. Как профильный инженер узнает, что произошел именно мажорный инцидент, а не просто инцидент? Массовость охваченных пользователей? Это не показатель критического воздействия на бизнес.

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

      2. справедливо для любого инцидента, связанного с массовым обращением в службу поддержки.

      Автор и не говорил вроде, что это надо делать исключительно для major incidents 🙂 Для плановых работ подобные оповещения тоже делаются.

      3. И тут нужен менеджер, который способен оперативно согласовывать с бизнесом возможные/ допустимые для бизнеса обходные решения(переход на частично ручную обработку и т.д.).

      Таким опытом и полномочиями в обычной практике обладает как раз менеджер инцидентов. Или у вас не так?

       

      1. Андрей

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

        По поводу менеджера инцидентов — у нас по-разному. Но принципиально отличие просто менеджера инцидентов от менеджера мажорных инцидентов состоит в том, что менеджер инцидентов оперириует внутри ИТ и его прямое взаимодействие с бизнесом сведено к минимуму, для этого есть business relations. Менеджер же мажорных инцидентов выходит на сцену когда ИТ уже обделались по полной и внутри службы ситуацию не разрулить без привлечения бизнеса. Как-то так.

        1. Nargiza Suleymanova

          Профильный инженер не может и не должен определять степень воздействия инцидента на бизнес. Не его это задача.

          Зачем же так категорично. В реальной жизни опытный профильный инженер как раз понимает как может аукнуться тот или иной инцидент.

          идеальный вариант, это когда не инженер, а правильно настроенная система мониторинга сообщает о сбоях в системах.

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

Добавить комментарий

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

Empty