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

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

Опубликовано 2 мая 2012
Рубрики: ITIL, Защищаем ITIL, Источники знаний, Постоянное улучшение, Практика и опыт, Управление доступностью, Управление инцидентами, Управление проблемами
Комментарии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Также по теме:

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • Pavel Solopov

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

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

    • Константин Нарыжный

      У меня есть сомнения до сих пор, даже после отличного отзыва Павла 😉
      Мне кажется что диагностика инцидентов (прежде всего сервисных, от пользователей) заключается в том, что мы “находим” сбоящий компонент той услуги, на которую пожаловались. Этот сбой надо увидеть, и быстро придумать, можно ли его “подлатать”, “взбодрить” или лучше поменять на новый.
      А диагностика проблем – это как раз исследование того, почему компонент засбоил, и как этого избежать в дальнейшем (реактивная часть управления проблемами).
      Так вот, в расширенном ЖЦ инцидента, эта фраза и говорит, как мне кажется, о том, что часть диагностики проблем нужно выполнять менеджеру процесса УИ, чтобы потом не заниматься диагностикой инцидентов повторно.
      Вот.

  • Grigory Kornilov

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

    Разный инцидент пораждает разные потери для бизнеса.
    А бизнес не любит терять, даже если обещают “рай после смерти”.

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

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

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

    У меня вопрос-комментарий в связи с данной темой, не имел возможности заглянуть в ITIL.
    На практике приходится сталкиваться со следующими этапами обработки инцидентов:
    1. уточнение описания инцидента
    2. уточнение влияния инцидента на бизнес
    3. Уточнение приоритета инцидента
    Эти шаги в нашем проекте происходят где-то между Обнаружением и Диагностикой, а нередко выполняются в рамках Диагностики.
    Для меня очевидно, что п.1 конкретно в нашем проекте проистекает от недостаточной развитости SL1 в опыте “допроса пользователя с пристрастием – а что у вас болит”, с другой стороны сами пользователи не всегда способны( или не обучены) давать сразу понятное описание проблемы в технических терминах без лишнего эмоционального вклада “все пропало!”.
    П.2 порожден в том числе не формализованным подходом к определению Business Impact’а
    П.3 вытекает на мой взгляд из п.2 и привычке пользователей назначать максимальный приоритет своей локальной проблеме. (Смена приоритета заявки руками IT считается исключительной мерой, определения приоритетов даны , но в очень общей форме, что дает простор пользователям в выборе максимально возможного).

    Вопросы:
    – насколько описанная ситуация является типичной/нетипичной, насколько описанный процесс часто встречается?
    – обозначенные шаги в работе на инцидентом выделены у вас отдельно, или они являются частью других шагов?
    – как проводились в жизнь изменения, при которых указанные мною п.1-3 не оказывались отдельными фазами в жизненном цикле инцидента?

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.
;