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

Major incident — когда становится горячо...

На курсе ITIL Foundation слушатели часто задают вопрос о значительных инцидентах (major incident). Иногда потому, что 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: важная темная область»

major INC 1

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

  • Alexander

    "В теории значительный  инцидент – это инцидент с самым высоким влиянием и высокой срочностью."

    Верно.

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

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

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

    "Команда, занимающая решением значительного инцидента, сосредоточена на восстановлении услуги, и поэтому это задача Service Desk — регулярно получать информацию о динамике процесса восстановления, и формально оповещать заказчика."

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

    Как-то так, ИМХО.


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

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT