На курсе ITIL Foundation слушатели часто задают вопрос о значительных инцидентах (major incident). Иногда потому, что тема управления ИТ-подразделением для них вообще новая и термин «значительный инцидент» слышится впервые, хотя в реальной жизни – это знакомая ситуация, иногда – потому что не совсем ясно, где провести границу между просто инцидентом и значительным инцидентом, и почти всегда – как с ним работать. О ключевых моментах, которые нужно учесть при работе со значительными инцидентами, пишет Neven Zitek в своей статье «Управление значительными инцидентами – когда становится горячо…» 

Что такое значительный инцидент?
В теории значительный  инцидент – это инцидент с самым высоким влиянием и высокой срочностью. Он влияет на большое количество пользователей, лишая бизнес одной или более решающих услуг или критичных бизнес-функций. Относительно значительного инцидента – это один из редких случаев, где библиотека ITIL строга в определении: критерии значительного инцидента должны быть согласованы между бизнесом и ИТ. 
Требования ISO 20000 к управлению значительными инцидентами кратки, но содержательны: соглашение (что есть значительный инцидент), отдельная процедура работы с таким инцидентом, распределение ответственности и обзор после решения инцидента.
В жизни признаки значительного инцидента очевидны: большое количество звонков в Service Desk, нетерпение заказчика, предмет пристального внимания управленцев, паника. В большинстве случаев это будет просто инцидент самого высокого приоритета в матрице влияния/срочности. Поэтому и есть такое строгое требование – определить, что есть значительный инцидент для конкретного заказчика и конкретного вида деятельности (услуги, бизнес-процесса, бизнес-операции, etc) данного заказчика.

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

Итак, о ролях.

Менеджер значительных инцидентов (Major Incident Manager – MIM) – несет ответственность за управление общими процедурами, привлечение необходимых ресурсов для решения инцидента, оповещение заказчика о динамике процесса. Он должен обладать фундаментальными техническими знаниями для понимания характера сбоя. В небольших организациях с более низкой частотой значительных инцидентов эту роль может взять на себя менеджер Service Desk, который зачастую выступает в роли менеджера по управлению инцидентами. В более крупных организациях назначение MIM будет зависеть от специфики области возникновения инцидента. Это может быть специалист по технической поддержке (technical account manager), лучше всех знакомый со спецификой бизнеса; кто-то из функций по управлению технологиями или приложениями (technical management, application management).

Менеджер по управлению проблемами (Problem manager) – роль часто включается в процедуру, так как решение значительного инцидента обычно требует нахождения его корневой причины. Эту роль нельзя объединять с ролью менеджера по управлению инцидентами вследствие конфликта интересов между процессами: задача команды по решению значительного инцидента – как можно быстрее восстановить услугу, а задача людей из управления решения проблем – найти корневую причину, что точно займет некоторое время. 

Менеджер по управлению изменениями (Change manager) – привлекается, если для восстановления услуги необходимо внедрить какие-то изменения в инфраструктуре.

Менеджер управлению уровнем услуг (SLM manager) – должен быть проинформирован, чтобы вести учет времени простоя и коммуницировать с заказчиком, если того требует процедура.

Service Desk -функция ответственна за ведение записей об инциденте в системе, и коммуникацию с заказчиками.

Коммуникация
Мы упомянули  главные роли. А теперь предположите, чья наиболее важная роль, и про кого часто забывают? Заказчик! Это наиболее распространенная ошибка – глубоко погрузиться в решение инцидента, при этом пренебречь коммуникацией с заказчиком.
Зачастую, форма и объем коммуникации с заказчиком должны быть четко указаны в SLA. Заказчик должен всегда знать чего ожидать. Его жизненно важный бизнес-процесс подвергается опасности, он должен в курсе. Краткое оповещение каждые полчаса или, по крайней мере, каждый час должно включать следующую информацию:
• Начало времени простоя
• Краткое описание известной причины времени простоя
• Влияние простоя
• Предполагаемое время для восстановления
• Следующее запланированное информирование
Команда, занимающая решением значительного инцидента, сосредоточена на восстановлении услуги, и поэтому это задача Service Desk – регулярно получать информацию о динамике процесса восстановления, и формально оповещать заказчика.

Afterparty – работа после восстановления
Инцидент решен, услуга восстановлена, и клиент возвращается к своей работе. Но послевкусие остается. Почему это произошло? Что мы сделали, чтобы предотвратить возникновение сбоев в будущем? Есть ли у нас четкое понимание как работать с такими задачами?
Если коротко, наиболее успешная практика – это решить инцидент и продолжить работать над связанной с ним проблемой. То есть составить так называемый отчет о проблеме или, по крайней мере, краткий отчет об анализе корневой причины (RCA). В отчет рекомендуется включать:
• Краткое описание инцидента
• Продолжительность времени простоя
• Влияние на SLA 
• Краткая история инцидента
• Как мы решили инцидент
• Какова корневая причина
• Запланированные действия для предотвращения простоя в будущем
Такой отчет даст понять заказчику, что он имеет дело со зрелым ИТ, который понимает, что такое сервис-менеджмент, каковы нужды бизнеса и делает все необходимое, чтобы защитить бизнес от потерь.
Если бы Вы были заказчиком, чего бы Вы ожидали от ИТ?

p.s. также о значительных инцидентах читайте в статье Романа Журавлева «Major / Critical Incident Management: важная темная область»

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

VAP: Управление уровнем услуг и каталогом услуг

Разработка каталога, SLA, метрик качества, расчёт доступности