Портал №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-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT