Смотрим на инциденты расширенными глазами

Хочу написать про еще одну технику управления рисками, незаслуженно забытую в книгах ITIL V3 2007 года, но восстановленную ("по чертежам" ITIL V2) в прошлогоднем обновлении.

Я говорю о расширенном жизненном цикле инцидента (the Expanded Incident Lifecycle). Это раздел в описании процесса управления доступностью (Availability Management), где предлагается разделять каждый инцидент (незапланированный перерыв в нормальном предоставлении ИТ-услуг) на обязательные последовательные этапы.

  • Момент возникновения инцидента, то есть, момент, когда пользователь ощутил снижение качества ИТ-услуги
    • Обнаружение, то есть промежуток времени от возникновения до момента получения поставщиком ИТ-услуг информации об инциденте
    • Диагностика, то есть время на поиск причины инцидента
    • Исправление, то есть время на исправление сбоя или замену сбоящего ИТ-компонента
    • Восстановление, то есть время на завершение ремонтных работ в инфраструктуре
    • Возобновление, то есть время от момента "восстановления" до начала нормальной работы пользователя.
  • Момент закрытия инцидента, то есть момент завершения возобновления.

Позволю себе немного арифметики:

Момент закрытия – Момент возникновения =

Обнаружение + Диагностика + Ремонт + Восстановление + Возобновление

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

Например, услуга была недоступна для пользователей 1 час, но при этом, работы по исправлению ошибки продолжались 5 минут. Куда делись остальные 55?

При первом прочтении меня больше всего заинтересовал в ITIL V3 пассаж про диагностику. Примерно такой:

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

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

Диагностика "сбой услуги" — "сбой компонента" должна осуществляться, чтобы определить, что именно следует чинить\менять для восстановления нормальной работы пользователей. Более глубокая диагностика, направленная на постоянное устранение причин сбоев уже должна осуществляться в управлении проблемами. Так на уровне определения процессов разделяется управление инцидентами и проблемами.

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

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

ITIL ITIL Intermediate: Operational Support and Analysis

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

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

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

  1. Pavel Solopov

    Господа, мы ведь не зря составляем какие-то SLA и согласовываем их с потребителями-пользователями. По хорошему в это SLA мы должны в том числе закладываться и временем на диагностику. Почему мы должны решать всё как можно быстрее? Не установив сути иницдента нельзя его решить. Не всё решается перезагрузкой сервера/компьютера.

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

    А решение отдельного инцидента, не должно выполдняться под этим лозунгом.

    Поспешишь, Людей посмешишь, говорит русский эпос.

    1. Константин Нарыжный Автор

      У меня есть сомнения до сих пор, даже после отличного отзыва Павла 😉

      Мне кажется что диагностика инцидентов (прежде всего сервисных, от пользователей) заключается в том, что мы «находим» сбоящий компонент той услуги, на которую пожаловались. Этот сбой надо увидеть, и быстро придумать, можно ли его «подлатать», «взбодрить» или лучше поменять на новый.

      А диагностика проблем — это как раз исследование того, почему компонент засбоил, и как этого избежать в дальнейшем (реактивная часть управления проблемами).

      Так вот, в расширенном ЖЦ инцидента, эта фраза и говорит, как мне кажется, о том, что часть диагностики проблем нужно выполнять менеджеру процесса УИ, чтобы потом не заниматься диагностикой инцидентов повторно.

      Вот.

  2. Grigory Kornilov

    Какова цель — «помочь бизнесу зарабатывать» или «создать всегда хорошо работающий IT»?

    Разный инцидент пораждает разные потери для бизнеса.

    А бизнес не любит терять, даже если обещают «рай после смерти».

    Если «повторно заниматься диагностикой» возможно технически и стоит только дополнительных админчасов, то часто ответ бизнеса будет таковым — «латайте течь, мы тонем — потом будете выяснять почему тонем, ресурсы выделим».

    Остается «немного» — добиться от бизнеса исполнения 2-й части, ведь корабль уже плывет, течи нет и накал страстей забыт.

  3. Андрей Капустин

    У меня вопрос-комментарий в связи с данной темой, не имел возможности заглянуть в ITIL.

    На практике приходится сталкиваться со следующими этапами обработки инцидентов:

    1. уточнение описания инцидента

    2. уточнение влияния инцидента на бизнес

    3. Уточнение приоритета инцидента

    Эти шаги в нашем проекте происходят где-то между Обнаружением и Диагностикой, а нередко выполняются в рамках Диагностики.

    Для меня очевидно, что п.1 конкретно в нашем проекте проистекает от недостаточной развитости SL1 в опыте «допроса пользователя с пристрастием - а что у вас болит», с другой стороны сами пользователи не всегда способны( или не обучены) давать сразу понятное описание проблемы в технических терминах без лишнего эмоционального вклада «все пропало!».

    П.2 порожден в том числе не формализованным подходом к определению Business Impact'а

    П.3 вытекает на мой взгляд из п.2 и привычке пользователей назначать максимальный приоритет своей локальной проблеме. (Смена приоритета заявки руками IT считается исключительной мерой, определения приоритетов даны , но в очень общей форме, что дает простор пользователям в выборе максимально возможного).

    Вопросы:

    — насколько описанная ситуация является типичной/нетипичной, насколько описанный процесс часто встречается?

    — обозначенные шаги в работе на инцидентом выделены у вас отдельно, или они являются частью других шагов?

    — как проводились в жизнь изменения, при которых указанные мною п.1-3 не оказывались отдельными фазами в жизненном цикле инцидента?

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

СЕН
27