Эльдар спрашивает у авторов и читателей нашего портала:
Если пользователи начинают плодить заявки относящиеся к одной общей проблеме, будет ли правильным объединять их в одну? Или же правильнее создание отдельной "главной" заявки и работать по ней, а по результатам закрывать заявки полученные от пользователей?
Поделитесь опытом, коллеги?
Впрочем, в вопросе присутствует слово "проблема", что в корне меняет дело, если, конечно, вы о проблеме, которая Problem. Тогда инциденты обязательно должны ассоциироваться существующей проблемой.
Если в системе есть модуль управления проблемами и инциденты относятся к существующей проблеме, то логично будет делать такую привязку.
Если в системе нет модуля проблемами или регистрируемые инциденты не являются следствием проблемы, то можно делать привязку к основному инциденту. Затем закрывать привязанные инциденты после решения основного инцидента.
Если видно, что есть массовый сбой, нужно постараться уведомить пользователей, это частично предотвратит новые обращения в службу поддержки.
Я не понял, чем "объединение заявок в одну", отличается от"создание отдельной "главной" заявки". Возможно, в первом случае речь идет о присоединении новых к уже ранее открытой, а во втором случае – об открытии нового инцидента и прикреплении всех обращений к нему. Особой разницы нет, при условии, как было сказано выше, способности вашего инструментария корректно обрабатывать оба случая – рассылать оповещение всем пользователям о решении инцидента и его закрытии.
Привязка к проблеме или массовому инциденту подразумевает автоматическое закрытие подчиненных (связанных) инцидентов при закрытии проблемы.
Насколько я помню, этот путь реомендован в ITIL. Наша проектная практика подверждает эффективность приема.
Привязка к проблеме или массовому инциденту подразумевает автоматическое закрытие подчиненных (связанных) инцидентов при закрытии проблемы. Насколько я помню, этот путь реомендован в ITIL.
Приведите, пжл, ссылку на первоисточник, потому что мне такая рекомендация ITIL неизвестна.
Наша проектная практика подверждает эффективность приема.
А я бы, пожалуй, не согласился. Сколько угодно случаев, когда устранение инфраструктурного инцидента (например, подняли сервер БД) требует последующих работ прикладников, направленных на восстановление услуги, причем разных работ для разных систем / приложений (восстановление баз из бэкапов да и банально запуск / перезапуск сервисов). Поэтому автоматическое закрытие обращений, на наш вгляд, весьма спорная практика.
Хотя соглашусь с тем, что привязка предполагает возможность какой-то массовой обработки связанных объектов, но далеко не обязательно эта обработка полностью автоматизирована.
Сколько угодно случаев, когда устранение инфраструктурного инцидента (например, подняли сервер БД) требует последующих работ прикладников, направленных на восстановление услуги, причем разных работ для разных систем / приложений (восстановление баз из бэкапов да и банально запуск / перезапуск сервисов). Поэтому автоматическое закрытие обращений, на наш вгляд, весьма спорная практика.
Соглашусь с тем, что глобальное решение "главного" инцидента не всегда может являться решением всех связанных обращений. Приведу пример проще: упал/уронили DHCP сервер. Пользователи перестали получать корректные IP – адреса внутри локальной сети. Зарегистрировали major incident (MI). Все обращения а-ля (например, 100 шт, то бишь от 100 пользователей): не работает гугл, не приходит почта, не могу твитнуть пост и т.д. прикрепляются к MI. Далее, устранили неисправность с DHCP сервером. 90 пользователей из 100 получили корректные IP-адреса и вернулись в рабочий ритм. Оставшиеся 10 пользователей продолжают потягивать кофе и наслаждаться форс-мажором, так как их ПК/ноутбуки не получают IP адреса в виду того, что например, нужно локально на ПК/ноутбуке перезапустить службу DHCP, а для этого саппорту нужно либо позвонить пользователю и проинструктировать, как перезапустить DHCP службу на ПК или попросить банально перезагрузить рабочую станцию. В крайнем случае (если возможно) прийти в гости к пользователю.
У себя в компании стараемся все таки "плодить" обращения в тикетовой системе в зависимости от категории обращения, чтобы в дальнейшем быть уверенными, что услуга полноценна вернулась ко всем обратившимся в саппорт.
Понятно, что скорость обработки обращений падает в разы в связи с "множением" всех обращений по одному major incident'у, но решили, что на первых порах уж лучше медленней, но эффективно, а уж позднее быстро и эффективно
Соглашусь с вышесказанным, все зависит от инструментария, в servicenow например есть фишка outage для привязки инцидентов.
Не принципиально и во многом определяется вашим средством автоматизации и связанными активностями. Варианты:
1) Умение средства автоматизации связывать или группировать инциденты
2) Пользовательские обращения крепятся к инциденту
3) Пользовательские инциденты крепятся к инфраструктурному инциденту
4) …