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

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

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

  • Рубрики

  •  
  • Авторы

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

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT