Неописуемые инциденты

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

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

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

А вы что думаете?

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

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

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

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

  1. Роман Журавлёв

    «т.к. сложно замотивировать людей не просто решать инцидент, но еще и привязывать его к изменению.»

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

    0
    0
  2. Дмитрий Исайченко

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

    Пример 1: служба заказчика и аутсорсер. В случае с каптивным аутсорсером (а таких примеров хватает) он вполне может работать в той же системе автоматизации, что и оценивающая его услуги (и в частности, качество реализации изменений) служба заказчика.

    Пример 2: инфраструктурщики и подразделение ДИТ, отвечающее за автоматизацию некоторого направления бизнеса. Инфраструктурщики часто что-то шевелят, последствия оценить не могут, а они случаются. И бьют по тем, кто обеспечивает работу бизнес ПО.

    Ну и так далее.

    0
    0
      1. Евгений Шилов Автор

        Мне кажется, что проблема не только в мотивации, но и в сложности отслеживания причинно-следственной связи изменение — инцидент. Специалист, восстанавливающий работу, скажем, почтового клиента, скорее просто его переустановит или изменит настройки, чем будет разбираться в том, что явилось причиной этого инцидента. Не его это дело, по процессу ему надо быстро починить, он быстро чинит.

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

        Акцент правда сместится. Но ведь ошибки в инфраструктуре по итогам изменения — тоже весьма неприятный побочный эффект. Мне кажется стоит об этом подумать ...

        0
        0
        1. Анатолий Павлюченко

          Полностью поддерживаю идею привязывания неудачных изменений к проблемам.

          Кстати, в документации по Microsoft Operations Framework «Failed Change» упоминается как один из триггеров для возникновения проблемы.

          0
          0
        2. Шилов Андрей

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

          0
          0
  3. Андрей Радосельский

    А если посмотреть на это под другим углом.

    Если инцидент вызван изменением, то для его устранения также надо провести изменение или откат (за исключением случаем недоступности сервиса в момент проведения изменения).

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

    При достаточной зрелости процессов внесения изменений в ключевые элементы ИТ и развитости средств автоматического контроля целостности конфигурации связывание по ключевым изменениям будет идти «по накатанной колее».

    А не по ключевым, оно и не надо.

    0
    0
  4. Руслан

    В качестве сырой идеи:

    1. Все инциденты, произошедшие с сервисом после изменения считаются, пока не будет установлено обратное, следствием изменения;

    2. В рамках PIR ответственный за изменение рассматривает каждый инцидент, последовавший после изменения, и отвязывает его от изменения, если находит достаточную аргументацию для этого;

    3. Оставшиеся привязанные к изменению инциденты считаются следствием изменения;

    Выгоды:

    1. Ответственный специалист больше узнаёт о здоровье своего сервиса;

    2. RIP действительно осуществлён;

    3. Достоверная статистика в связке изменение-инцидент;

    Минусы:

    1. Загрузка ответственного исполнителя;

    2. ?

    На подумать:

    1. Параллельные изменения;

    2. Изменения с высокой частотой.

    Ещё более сырая идея:

    А что если запретить закрывать инцидент не привязанный ни к чему?

    Если ошибся пользователь, его надо учить — проблема;

    Если был серьёзный сбой, его надо серьёзно устранять — изменение;

    И так далее.

    Как всегда встаёт вопрос с «помойкой» (мелкие сбои и «прочее»), для неё можно создать искусственную проблему «Нарушения SLA» и контролировать её размер в SLA, чтобы неповадно было списывать на неё всё подряд.

    0
    0
    1. Георгий

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

      все предложенное интересно, но противоречит основной напарвленности управления инцидентами — закрывать инциденты как можно скорее 🙂 предлагается навязать кучу проверок и перепроверок, а зачем все это инженеру, если инцидент он закрыл. Вон есть управление проблемами — пусть там и думают ) наше дело закрыть быстрее 😉

      0
      0
      1. Руслан

        «направленность» управления инцидентами не «закрывать» скорее, а разрешать скорее. Думаю, разница тут есть 😉 Пусть цель «инженера по инцидентам» — перевести в статус «разрешен», а в статус «закрыто» инцидент может попасть только после того, как и интересы всех остальных функционеров (проблемы, изменения) будут удовлетворены.

        Ибо сказано было: «Incident documentation. Chase any outstanding

        details and ensure that the Incident Record is fully

        documented so that a full historic record at a

        sufficient level of detail is complete.»

        Книга четвёртая. Стих 4.2.5.9 «Закрывающим инциденты».

        0
        0
        1. Георгий

          ну да, что-то похожее делается при подготовке к внедрению проблем менеджмент — мы когда-то меняли классификацию инцидентов, чтобы она более четко указывала на потенциальную причину инцидента (по первым уровням это было кажется Пользователь-Инфраструктура-Документация или что-то похожее), потом сажали спец людей, которые пачками выверяли закрытые инциденты на предмет правильности заполнения разных полей (КЕ, классификация, категория, сервис итп).

          Можно в теории им же поручить и привязку вот инцидента к проблемам, изменениям. Главное чтобы затраты на эту деятельность кратно не превысили пользу от того, что мы узнаем как кто-то неправильно провел чендж.

          0
          0
    2. Вадим

      ответственный за изменение — лицо заинтересованное, конфликт интересов получается однако.

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

      0
      0
      1. Руслан

        ответственный за изменение — лицо заинтересованное, конфликт интересов получается однако.

        Лицо не только заинтересованное, но и подотчётное. С него первого спрос: Зачем после твоего изменения столько инцидентов? На что он аргументированно отчитаться: Это, дескать, не моё, пользователь попутал; иное тоже мимо, тут давно проблема мается; а вот тут нокосячил, да, исправим.

        0
        0
  5. Юрий Ерин

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

    Привязка изменений к проблемам тоже не лучшее решение. Может быть проведено 10 изменений по которым будет зарегистрировано 500 инцидентов и при этом не будет зарегистрировано ни одной проблемы.

    Гораздо продуктивнее думать в сторону планирования и организации проведения PIR, основываясь на ранее проведенном анализе влияния изменения, выборе ответственного за анализ инцидентов (о чем ранее было сказано), планирования методики проведения и пр.

    0
    0
    1. Дмитрий Исайченко

      «Гораздо продуктивнее думать в сторону планирования и организации проведения PIR, основываясь на ранее проведенном анализе влияния изменения, выборе ответственного за анализ инцидентов (о чем ранее было сказано), планирования методики проведения и пр.»

      +93

      0
      0
  6. Александр Жилинский

    Очень жаль, что один мой коллега (из заказчика) не пишет в интернет. Он ловил в отчетах инциденты-изменения-релизы без прямой связки (данных маловато было для точного улова, но метод интересный) — одинаковые классификаторы (услуга, КЕ, etc), диапазон времени вокруг изменения-релиза.

    0
    0

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

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

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

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

НОЯ
27
Учебный курс:
Основы ITIL (очно)