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

Вопрос из зала: как классифицировать инциденты по ИТ-услугам?

calibratПосетитель нашего портала Дмитрий задаёт следующий вопрос:


Коллеги, добрый день. Интересует как правильно связывать инциденты с затронутыми ими бизнес-сервисами.

Пример 1: клиент не смог перевести средства на счет телефона через интернет-банк и обратился в поддержку -> зарегестрировали инцидент с привязкой к бизнес сервису "Платежи и переводы в ИБ". Тут всё понятно.

Пример 2: Ответсвенный специалист обнаружил сбой в процессинговой системе (либо пришел алерт от системы мониторинга). Этот сбой влияет / может влиять не только на проведение платежей в ИБ, но на операции в банкоматах / ТСП / интернете и т.п. 

– В данном случае, первая линия должна связять инцидент со всеми затронутыми / потенциально затронутыми бизнес-сервисами или каким-то одним, возможно самым важным?

– Реально ли первой линии понимать все взаимосвязи систем и бизнес-сервисов? 

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

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

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

  • Пример 2: Ответсвенный специалист обнаружил сбой в процессинговой системе (либо пришел алерт от системы мониторинга). Этот сбой влияет / может влиять не только на проведение платежей в ИБ, но на операции в банкоматах / ТСП / интернете и т.п. 

    — В данном случае, первая линия должна связять инцидент со всеми затронутыми / потенциально затронутыми бизнес-сервисами или каким-то одним, возможно самым важным?

    Заводим инфраструктурный инцидент, связываем с "пострадавшими" ИТ-услугами. "Потенциально затронутые" – это какие? С отложенным влиянием? Классификацией инфраструктурных инцидентов у вас первая линия занимается?

    — Реально ли первой линии понимать все взаимосвязи систем и бизнес-сервисов? 

    Это зависит: квалификация, объём обращений, количество ИТ-услуг. Но на мой взгляд, скорее нет, чем да.

    — Если представить, что пример 1 и пример 2 случились в одно время, то что делать с пользовательскими инцидентами (в которых выбраны конкретные затронутые бизнес-сервисы) и инцидентом, который был зарегестрирован ответсвенным / алертом (в котором выбрано несколько затронутых бизнес-сервисов). Их нужно связять? Какой делать главным? Как учитывать выбранные бизнес-сервисы во всех инцидентах?

    По пользовательскому инциденту нельзя однозначно сказать, что у нас за ситуация: произошёл локальный отказ у пользователя или глобальный в нашей инфраструктуре. Основным источником информации об отказах в инфраструктуре являются средства мониторинга, в т.ч. мониторинга бизнес-операций. Обращения пользователей служат определённым подтверждением произошедшего события, но не являются главным каналом получения информации об отказах услуг. А вот если мониторинга нет…

    что делать с пользовательскими инцидентами

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

    Как учитывать выбранные бизнес-сервисы во всех инцидентах?

    В том смысле, как получить картинку по всем затронутым ИТ-услугам? После привязки инфраструктурных инцидентов к ИТ-услугам вывести общий список затронутых услуг в разбивке по каждому инфраструктурному инциденту.

  • Павел Солопов

    Чтобы первая линия понимала связь между инфраструктурой и бизнес-сервисами и нужна CMDB, которая им в этом поможет.

  • Павел Солопов

    Как говорил, Денис, по хорошему, надо различать пользовательский инцидент (можно его ещё назвать обращением) и инфраструктурный. Причём, желательно чтобы каждый ПИ был закрыт ИИ. Почему так? Потому что ПИ по сути симптом который указывает на какой-то ИИ, который и надо устранить, чтгбы снять симптомы в виде ПИ.

    • Дмитрий

      ИИ в таком случае – это неизвестная проблема / известная ошибка?

      Т.е. уже подключается problem managment? 

      • Павел Солопов

        Не совсем так. Тут есть несколько ситуаций:

        1. Есть ПИ, после диагностики выяснили, что его причиной стал ИИ. ИИ устранили, устранился ПИ.

        2. Есть ПИ, разбираться не стали или не смогли разобраться. "Вышли и вошли", ПИ устранился.

        3. Есть ПИ, в результате диагностики определили ИИ, но как его устранить не знаем или не можем, но чтобы устранить ПИ применяем некую временную схему или как-то иначе снимаем симптомы.

        В первом случае, ИИ может быть (стать) известной ошибкой, а может и не быть (стать), зависит от того, как мы организуем управление проблемами.

        Во втором случае, можно ИИ назвать "Неизвестной проблемой", ну или как минимум это предмет для размышлений на этот счёт со стороны управления проблемами.

        В третьем случае, ИИ вполне может стать Известной ошибкой.

         

        Не могу сказать, что Problem Management прямо уж подключается, но, как минимум, мы имеем интерфейс для его подключения.

  • Alexey Yusov

    Не сочтите за рекламу, но курс OSA очень сильно поможет. Там всё прозрачно разбирали.

  • Anton Lebedev

    — В данном случае, первая линия должна связять инцидент со всеми затронутыми / потенциально затронутыми бизнес-сервисами или каким-то одним, возможно самым важным?

    Первая линия у вас занимается процессом Incident Management, в нем свои задачи – скорейшее восстановление услуги любым способом. И инцидент они относят к услуге, по которой обратился клиент.

    Вторая линия решает уже не инцидент, а проблему (в случае если все так, как вы описали, с влиянием на процессинговую систему). Т.е. инцидент переводится в плоскость Problem Management и решается в рамках этого процесса. 

     

    — Реально ли первой линии понимать все взаимосвязи систем и бизнес-сервисов? 

    Нет и не нужно этого 

    — Если представить, что пример 1 и пример 2 случились в одно время, то что делать с пользовательскими инцидентами (в которых выбраны конкретные затронутые бизнес-сервисы) и инцидентом, который был зарегестрирован ответсвенным / алертом (в котором выбрано несколько затронутых бизнес-сервисов). Их нужно связять? Какой делать главным? 

    Если 2-я линия начала решать проблему – 1-я линия должна быть в курсе. 1-я линия в таком случае может завести массовый инцидент и ассоциировать все последующие инциденты с массовым. В зависимости от того, что позваляет ваш Service Desk


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM