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

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

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

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

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. Кирилл

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

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

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

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

    4) ...

    0
    0
  2. Кирилл

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

    0
    0
  3. Альберт

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

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

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

    0
    0
  4. Андрей

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

    0
    0
  5. Вадим Бекетов

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

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

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

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

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

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

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

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

      0
      0
      1. Евгений Хон

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

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

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

        0
        0
        1. Евгений Хон

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

          0
          0

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

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

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

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

ЯНВ
29