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

1. О возникновении 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 существенную поддержку может оказать система автоматизации, проверьте наличие у неё соответствующих функциональных возможностей. Но, как обычно, решающее влияние на результативность перечисленных мер оказывают не столько средства автоматизации, сколько разумная организация работ и грамотный менеджмент.

Верно?

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую