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

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

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

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

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

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

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

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

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

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

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

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

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

    • А, забыл правильно закончить. “Ну и так далее” (с) С. Шнуров. 🙂

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

        • Анатолий Павлюченко

          Полностью поддерживаю идею привязывания неудачных изменений к проблемам.
          Кстати, в документации по Microsoft Operations Framework “Failed Change” упоминается как один из триггеров для возникновения проблемы.

        • Шилов Андрей

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

          • А каких систем? Вполне могли менять маршрутизатор где-то далеко и забыть открыть порт, через который иногда идет репликация, из-за чего будет странно сбоить приложение, которое никто и уже давно не менял.

  • Андрей Радосельский

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

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

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

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

  • Руслан

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

    Выгоды:
    1. Ответственный специалист больше узнаёт о здоровье своего сервиса;
    2. RIP действительно осуществлён;
    3. Достоверная статистика в связке изменение-инцидент;

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

    На подумать:
    1. Параллельные изменения;
    2. Изменения с высокой частотой.

    Ещё более сырая идея:
    А что если запретить закрывать инцидент не привязанный ни к чему?
    Если ошибся пользователь, его надо учить – проблема;
    Если был серьёзный сбой, его надо серьёзно устранять – изменение;
    И так далее.
    Как всегда встаёт вопрос с “помойкой” (мелкие сбои и “прочее”), для неё можно создать искусственную проблему “Нарушения SLA” и контролировать её размер в SLA, чтобы неповадно было списывать на неё всё подряд.

    • Георгий

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

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

      • Руслан

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

        Ибо сказано было: “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 “Закрывающим инциденты”.

        • Георгий

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

          • Руслан

            Главное чтобы затраты на эту деятельность кратно не превысили пользу

            В точку.

    • Вадим

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

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

      • Руслан

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

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

  • Юрий Ерин

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

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

      +93

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


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM