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

Вопрос из зала: что делать с взаимосвязанными инцидентами?

Эльдар спрашивает у авторов и читателей нашего портала:

long-listЕсли пользователи начинают плодить заявки относящиеся к одной общей проблеме, будет ли правильным объединять их в одну?  Или же правильнее создание отдельной "главной" заявки и работать по ней, а по результатам закрывать заявки полученные от пользователей? 

Поделитесь опытом, коллеги?

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

  • Кирилл

    Не принципиально и во многом определяется вашим средством автоматизации и связанными активностями. Варианты:

    1) Умение средства автоматизации связывать или группировать инциденты

    2) Пользовательские обращения крепятся к инциденту

    3) Пользовательские инциденты крепятся к инфраструктурному инциденту

    4) ...

  • Кирилл

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

  • Альберт

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

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

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

  • Андрей

    Я не понял, чем "объединение заявок в одну", отличается от"создание отдельной "главной" заявки". Возможно, в первом случае речь идет о присоединении новых к уже ранее открытой, а во втором случае — об открытии нового инцидента и прикреплении всех обращений к нему. Особой разницы нет, при условии, как было сказано выше, способности вашего инструментария корректно обрабатывать оба случая — рассылать оповещение всем пользователям о решении инцидента и его закрытии.

  • Вадим Бекетов

    Привязка к проблеме или массовому инциденту подразумевает автоматическое закрытие подчиненных (связанных) инцидентов при закрытии проблемы.

    Насколько я помню, этот путь реомендован в ITIL. Наша проектная практика подверждает эффективность приема.

    • Привязка к проблеме или массовому инциденту подразумевает автоматическое закрытие подчиненных (связанных) инцидентов при закрытии проблемы. Насколько я помню, этот путь реомендован в ITIL.

      Приведите, пжл, ссылку на первоисточник, потому что мне такая рекомендация ITIL неизвестна.

      Наша проектная практика подверждает эффективность приема.

      А я бы, пожалуй, не согласился. Сколько угодно случаев, когда устранение инфраструктурного инцидента (например, подняли сервер БД) требует последующих работ прикладников, направленных на восстановление услуги, причем разных работ для разных систем / приложений (восстановление баз из бэкапов да и банально запуск / перезапуск сервисов). Поэтому автоматическое закрытие обращений, на наш вгляд, весьма спорная практика.

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

      • Евгений Хон

        Сколько угодно случаев, когда устранение инфраструктурного инцидента (например, подняли сервер БД) требует последующих работ прикладников, направленных на восстановление услуги, причем разных работ для разных систем / приложений (восстановление баз из бэкапов да и банально запуск / перезапуск сервисов). Поэтому автоматическое закрытие обращений, на наш вгляд, весьма спорная практика.

        Соглашусь с тем, что глобальное решение "главного" инцидента не всегда может являться решением всех связанных обращений. Приведу пример проще: упал/уронили DHCP сервер. Пользователи перестали получать корректные IP — адреса внутри локальной сети. Зарегистрировали major incident (MI). Все обращения а-ля (например, 100 шт, то бишь от 100 пользователей): не работает гугл, не приходит почта, не могу твитнуть пост и т.д. прикрепляются к MI. Далее, устранили неисправность с DHCP сервером. 90 пользователей из 100 получили корректные IP-адреса и вернулись в рабочий ритм. Оставшиеся 10 пользователей продолжают потягивать кофе и наслаждаться форс-мажором, так как их ПК/ноутбуки не получают IP адреса в виду того, что например, нужно локально на ПК/ноутбуке перезапустить службу DHCP, а для этого саппорту нужно либо позвонить пользователю и проинструктировать, как перезапустить DHCP службу на ПК или попросить банально перезагрузить рабочую станцию. В крайнем случае (если возможно) прийти в гости к пользователю.

        У себя в компании стараемся все таки "плодить" обращения в тикетовой системе в зависимости от категории обращения, чтобы в дальнейшем быть уверенными, что услуга полноценна вернулась ко всем обратившимся в саппорт.

        • Евгений Хон

          Понятно, что скорость обработки обращений падает в разы в связи с "множением" всех обращений по одному major incident'у, но решили, что на первых порах уж лучше медленней, но эффективно, а уж позднее быстро и эффективно

  • Дэн

     

    Соглашусь с вышесказанным, все зависит от инструментария, в servicenow например есть фишка outage для привязки инцидентов.


Добавить комментарий для Вадим БекетовОтменить ответ

Ваш адрес email не будет опубликован.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM