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

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

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


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

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

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

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

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

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

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

Комментариев: 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-командам следует использовать метрики 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