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

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


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

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

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

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

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

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

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. Денис Денисов

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

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

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

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

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

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

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

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

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

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

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

    0
    0
  2. Павел Солопов

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

    0
    0
      1. Павел Солопов

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

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

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

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

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

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

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

         

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

        0
        0
  3. Anton Lebedev

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

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

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

     

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

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

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

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

    0
    0

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

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

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

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

ОКТ
26
Учебный курс:
Основы DevOps
ОКТ
30
Учебный курс:
Основы COBIT 5