Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Диагностика инцидентов «на лету»

Можно предположить, что большинство инцидентов, регистрируемых в Service Desk, являются типовыми. В таком случае представляется как вполне возможным, так и небесполезным, автоматизировать процесс не только регистрации, но и диагностики инцидентов, чтобы Служба поддержки получала не только диагностическую информацию, но и наиболее вероятный диагноз, который осталось бы только подтвердить (или отвергнуть, если система ошиблась).

Эту концепцию – диагностику инцидентов «на лету» – мы и предлагаем вам обсудить.

Архитектура

Диагностика на лету рис 1

Для диагностики инцидентов на лету необходимы:

  • Формальное описание инцидента со стороны пользователя (Снимок Инцидента). Предполагается, что Снимок Инцидента формируется Красной Кнопкой ProLAN.
  • Система мониторинга. Предполагается использование системы мониторинга ProLAN.
  • Агрегатор Информации. Агрегатор Информации должен уметь принимать Снимки Инцидентов, сохранять их в базе данных, в режиме реального времени обрабатывать содержимое базы данных и взаимодействовать с Системой мониторинга, Диагностической базой знаний и Service Desk.
  • Диагностическая база знаний.
  • Service Desk – система.

Диагностическая база знаний

Диагностическая База Знаний – это база данных, содержащая информацию о корневых причинах инцидентов.

Наличие Диагностической базы знаний существенно повысит эффективность Service Desk вне зависимости от того, выполняется диагностика инцидентов «на лету» или как обычно. Многие компании в том или ином виде уже имеют базы знаний, поэтому Диагностическая база знаний может стать дополнением того, что уже есть. В большинстве случаев никакой существенной переделки имеющейся базы знаний не потребуется.

Следует выделить два основных (принципиальных) отличия Диагностической базы знаний от баз знаний, которые обычно используются службами технической поддержки:

    1. Ключевыми элементами для определения диагноза являются описания инцидентов «глазами пользователей». Поэтому задачей №1 является систематизация инцидентов, как их видят пользователи ИТ-Сервисов.
    2. Значимыми параметрами являются Оценки качества компонентов ИТ-инфраструктуры. Поэтому задачей №2 является правильное определение пороговых значений метрик здоровья ИТ-инфраструктуры, которые необходимы для получения Оценок Качества.

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

Алгоритм диагностики инцидентов «на лету»

Шаг 1

На стороне пользователя создаётся формальное описание инцидента (Снимок Инцидента). Сделать это можно вручную (при помощи правильно разработанной веб-формы) или автоматически с использованием Красной Кнопки. Второе, конечно же, лучше, потому что позволяет получить данные более полные и более точные (например, точное время инцидента). Состав Снимка Инцидента в сокращенном виде показан на рисунке (см. ниже).

Диагностика на лету рис 2

Состав Снимка Инцидента в сокращённом виде

Снимок Инцидента принимается Агрегатором Информации и его содержимое записывается в консолидированную базу данных, расположенную там же.

Шаги 2-3

На Агрегаторе Информации работает экспертная система, которая с использованием специальных тестов (Экспертиз) в режиме реального времени анализирует содержимое консолидированной базы данных. Обнаружив появление нового Снимка Инцидента, Экспертиза формирует Запрос оценок качества ИТ-Инфраструктуры, который направляется в Систему мониторинга.

Параметры запроса:

  • Параметры Где и ИТ-Сервис определяют, Оценки качества каких компонентов ИТ-Инфраструктуры необходимо получить из Системы мониторинга (см. рисунок ниже). Например, если Снимок Инцидента поступил от пользователя SAP CRM, находящего в Санкт-Петербурге, то необходимо получить: Оценку качества канала связи «Питер-Москва», Оценку качества сервера приложений SAP CRM, Оценку качества базы данных SAP CRM.
  • Параметр Когда определяет, за какой момент времени необходимо получить Оценки качества компонентов ИТ-инфраструктуры.

Диагностика на лету рис 3

Рисунок 3. Оценки Качества ИТ-инфраструктуры.

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

Оценка метрики – это сравнение её значений с пороговыми значениями.

При использовании Системы мониторинга, поддерживающей сервисно-ресурсную модель, получить Оценки Качества ИТ-Инфраструктуры большого труда не составит. Если сервисно-ресурсная модель не поддерживается, то задача решается добавлением в Агрегатор Информации соответствующего справочника. В любом случае Система мониторинга и Агрегатор Информации должны быть интегрированы друг с другом.

В продуктах ProLAN Оценки качества компонентов ИТ-Инфраструктуры имеют пять значений: хорошо, допустимо, требует внимания, на грани, плохо.

Шаги 4-5

Получив Оценки Качества, Экспертиза формирует запрос в Диагностическую Базу Знаний. В упрощенном виде диагностическую Базу Знаний можно представить в виде таблицы, показанной ниже.

В качестве ключевых элементов используются элементы справочника «Что случилось» (входят в состав Снимка Инцидента). В качестве значимых параметров, определяющих вероятный диагноз, используются, во-первых, параметры окружения пользователя (входят в состав Снимка Инцидента), во-вторых, Оценки качества, получаемые из Системы мониторинга.

Чем полнее определён список значимых параметров, и чем точнее определен диапазон их значений, тем выше вероятность получения единственного, правильного диагноза.

Шаг №6

Получив из Диагностической базы знаний вероятный диагноз (или диагнозы), Экспертиза включает его в состав Агрегированного Снимка Инцидента, который автоматически отправляет в Service Desk. (Кроме диагноза, в состав Агрегированного Снимка Инцидента включаются значения соответствующих значимых параметров и Снимки Инцидентов, инициировавших его появление.)

Внимание, вопрос

Такая вот концепция. Хотелось бы услышать вашу критику, предложения, возражения, указания на возможные применения и т.п. – ?

Комментарии (23)

  • Аватар

    [felexa], 20 марта 2013, 17:40

    0
    На условиях рекламы?)
    • Аватар

      Meshkov Aleksandr [ameshkov], 20 марта 2013, 17:57

      0
      Нет. Мы предлагаем обсудить саму концепцию, а то, что мы рассказываем о ней на примере наших продуктов - это нормально.
      • Аватар

        [felexa], 20 марта 2013, 19:12

        0
        Кстати.Так и не удалось воспользоваться вашей демкой красной кнопки.Оформил заявку,но со мной так никто и не связался..
  • Аватар

    Забелин Максим Анатольевич [stecker], 21 марта 2013, 09:36

    0

    На уровне концепции не ясно как будут выбираться диагнозы для инцидентов. 

    К примеру, описание инцидента ползователем "Не включается ПК". Причин может быть 100500. Все метрики могту быть в порядке. А ПК реально не включается. То ли блок питания выгорел, то ли из розетки выдернули, то ли кнопка сломалась. 

  • Аватар

    Юдицкий Сергей [Sergey.Yuditsky], 21 марта 2013, 11:24

    1
    Область применения метода - поддержка ИТ-Сервисов (бизнес-приложений). Вы правы, если сломался компьютер - это неприменимо.
    • Аватар

      Забелин Максим Анатольевич [stecker], 21 марта 2013, 20:48

      0
      Если так, то пожалуй соглашусь.......но тогда важно чтобы система мониторинга позволяла отследить проблемную точку в структуре сервиса.....иначе опять ни о чем получится.
      • Аватар

        Meshkov Aleksandr [ameshkov], 21 марта 2013, 21:45

        0
        В этом и суть - в связывании инцидента с проблемными компонентами ИТ-инфраструктуры и в них проблемными параметрами.
  • Аватар

    Ланцев Андрей [Sansey], 21 марта 2013, 16:31

    0
    Как и с красной кнопкой. Применимо местами, для избранных и в целом - нафиг надо! Машина может заменить человека только в тупом механическом труде, но там, где надо думать мозгами лучше живого админа ничего нет:)))
  • Аватар

    Юсов Алексей [alexus], 21 марта 2013, 20:27

    0
    Решение выглядит интересно, но что мне оно дает практически? Мне бы, как, например, руководителю, было бы интересно измерить результат в конкретных "попугаях". А именно - снижение затрат на Servicedesk или снижение времени разрешения Инцидента. Без - этого пустая игрушка, артель "Напрасный труд".
    • Аватар

      Юдицкий Сергей [Sergey.Yuditsky], 22 марта 2013, 12:09

      1

      Хочу пояснить, для кого это нужно,  и что это дает. Измерить "в попугаях", рублях или Euro можно будет только после внедрения. Пока это только концепция :-)

      Это должно быть нужно Провайдером ИТ-Сервисов, когда область ответственности провайдера ограничена и ему надо ASAP  понимать, «кто виноват и что делать». Предположим,   Провайдер предоставляет доступ к некому Web-приложению, но  за последнюю милю, каналы передачи данных или хостинг отвечает кто-то другой. В этом случае, при поступлении заявки от пользователя ИТ-Сервиса, Провайдеру нужно ASAP  определить:   КТО ВИНОВАТ, МЫ или НЕ МЫ. Если «НЕ МЫ», то ASAP маршрутизировать тому, кто виноват. Если   «Мы», то маршрутизировать в соответствующую группу поддержки. Я "слышал" это желание от многих, очень зрелых ИТ-компаний.

      Второе. Диагностика «на лету» позволяет оператору сразу увидеть, ЕСТЬ ЛИ ИЗВЕСТНОЕ РЕШЕНИЕ ИЛИ ЕГО НЕТ. И, если его нет, то не париться, и сразу маршрутизировать на вторую линию. Как мне кажется, это должно повысить эффективность соответствующего процесса. Или я ошибаюсь?

      И, наконец, третье. Какое Business Value дает  работающая  База Знаний, думаю ВАМ :-) объяснять не надо. Однако, как показывает мой личный опыт, такие Базы Знаний являются скорее исключением, чем правилом. Причин много, «не доросли», нет ресурсов, не знают как и т.п. Преимущество предлагаемой концепции, на мой взгляд, в том, что она показывает простой и быстрый способ создания и поддержки в «живом состоянии» Диагностической  Базы Знаний, в которой инциденты «глазами пользователя»  увязаны, во-первых, с окружением пользователя, во-вторых, с информацией о здоровье ИТ-Инфраструктуры.  Если такая База Знаний есть, то не так уж важно, делается ли  диагностика «на лету» или не «на лету». При этом я хорошо понимаю, что такая База Знаний объективно нужна не всем и не всегда может быть создана. Если все же речь идет о зрелых провайдерах ИТ-Сервисов, то о необходимости такой Базы Знаний, мне кажется , двух мнений быть не может :-) Или я ошибаюсь?

      • Аватар

        Забелин Максим Анатольевич [stecker], 25 марта 2013, 19:55

        0

        Штука теоретически прикольная может получиться, но вот беда, я например не видел ни одной системы в которой экспертное знание накапливалось бы автоматически в процессе эксплауатации. Всегда это, по факту, ручная работа, причем не самых дешевых, спецов-экспертов (как минимум, они вынуждены описать результаты и логику своего анализа проблемы). 

        Сможете решить эту проблему - станете очень богатыми :)

        • Аватар

          Юдицкий Сергей [Sergey.Yuditsky], 26 марта 2013, 15:33

          1

          Максим, все таки не во время ЭКСПЛУАТАЦИИ, а во время ДИАГНОСТИКИ. Это очень важно :-)).

          У меня есть знакомый в Австралии, который  работает в фирме по ремонту мониторов. Фирма 2,5 человека, а ремонтируют  невообразимое число мониторов в месяц.  Я спрашивал, как им  это удается. Ответ:  База Знаний. Никаких алгоритмов в ней нет, а есть набор признаков и соответствующий каждому набору  «диагноз». Как только обнаруживается новая неисправность, они её сразу заносят в Базу Знаний.  Это, как он говорит Absolutely Must, даже не обсуждается.  За счет этого, как он говорит, в 90% случаев, он неисправность не ищет, а просто проверяет описанные в Базе Знаний признаки. Не знаю, может быть и наши ремонтники делают также.  По моему, это очень разумно.

          Собственно, ровно та же самая идея предлагается и в «Диагностике на лету».  Просто другие признаки и другие диагнозы. Никаких ДРУГИХ спецов, кроме тех, что есть сейчас, не требуется. Нужны другие ПРОЦЕССЫ :-)) и другой менталитет бизнес руководства :-))

  • Аватар

    Яковлев Андрей Михайлович [swtws], 22 марта 2013, 01:53

    0
    Как говорят людоеды "Робот никогда не заменит человека". Просто тут стандартный изъян - сбой самой системы тоже возможен и вот тут будет цирк. Выдаваемая информация будет неверной и затруднит решение проблем. Я такое видел на одной системе мониторинга, совмещенной с SD. Баг привел к фатальным последствиям - недельному простою.
    • Аватар

      Meshkov Aleksandr [ameshkov], 22 марта 2013, 12:20

      0

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

      Но тут есть и обратная сторона медали.

      Во-первых, живой сотрудник и сбоит и ломается. Он болеет, уходит в отпуск, а то и увольняется. Ещё его может съесть людоед.

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

      P.S. Повторюсь, это общие недостатки и преимущества не конкретной диагностической концепции, а вообще автоматизации процессов.

    • Аватар

      Юдицкий Сергей [Sergey.Yuditsky], 22 марта 2013, 12:20

      1
      Андрей, если Вас не затруднит, можно про этот случай немного больше конкретики. Какой именно сбой в системе мониторинга привел к НЕДЕЛЬНОМУ простою. дело в том, что интеграция SD с системами мониторинга - это моя любимая тема :-). Собственно, это главное конкурентное преимущество систем мониторинга ProLAN, поэтому любой опыт на эту тему о-о-о-чень интересен :-).
      • Аватар

        Яковлев Андрей Михайлович [swtws], 26 марта 2013, 05:08

        1
        Детали сказать не могу - так как спросил разрешения, но его не дали. Смысл - система была не доработана. Ошибка ложно выдавала живым неисправный сервер. два дня ушло на выяснение. Объект не имел спецов, сразу скажу он находится в море , но никуда не двигается (понятно, что это?).Полдела сделали - методом опроса по телефону. Потом диагноз был сделан по удаленке. Но тут сложности не кончились. Еще на место надо было попасть - а погода была та еще. Разве у армейских, что-то подходящее есть, только эта страна не содержит мощной армии. Сидели и ждали. 
  • Аватар

    Ланцев Андрей [Sansey], 22 марта 2013, 16:37

    0
    Интересует цена. Это будет "коробочное решение" или какой-то SaaS продукт? Сколько будет стоить поддержка всего этого и сколько будет стоить интеграция/настройка под задачи конкретного заказчика? Т.е. проще говоря - по чем TCO?
    • Аватар

      Юдицкий Сергей [Sergey.Yuditsky], 22 марта 2013, 19:04

      0

      Андрей, вопрос на засыпку :-)

      Думаю, что «диагностика на лету», это должен быть не НАШ продукт, а ВАШ продукт.  Мы же, ничего большего, чем мы продаем сейчас, продать не сможем. Я вижу следующую бизнес-модель.

      Есть сервисная компания (например, Вы :-)))), которая хочет расширить спектр предлагаемых услуг, в частности, выйти на рынок услуг для крупного бизнеса. Почему нет :-)), Think Big :-)).  Приходит эта компания к крупному клиенту и говорит: «Хочешь,  я помогу тебе в решении такой-то задачи?» (см. коммент выше). Они говорят «Хотим, задача интересная, но у самих руки не дойдут». Тогда сервисная компания приобретает  (для перепродажи клиенту) лицензии на использование продуктов ProLAN, техническую поддержку ProLAN, после чего совместно с клиентом делает ему Экспертную Систему. Какую платформу она будет использовать для Базы Знаний – не знаю, скорее всего, Service Desk, который уже есть у клиента. Ну а больше ничего, кроме драйва и профессионализма, вроде и не надо.

      В чем Business Value для аутсорсера? Он получает возможность  оказывать услуги клиентам, у которых есть своя ИТ-Служба. Это другой рынок и другие деньги :-)

      • Аватар

        Ланцев Андрей [Sansey], 25 марта 2013, 12:11

        0

        Встречный вопрос. Что мешает ProLANу самостоятельно выходить на рынок и искать клиентов, вместо того, чтобы пиариться среди аутсорсеров на ресурсах подобных этому?

        Что помешает ИТ-службе клиента напрямую выйти на вас и купить ваше ПО, а аутсорсера тихонечко подвинуть, сказав большое спасибо за идею?

        • Аватар

          Юдицкий Сергей [Sergey.Yuditsky], 25 марта 2013, 19:19

          1

          Андрей, для информации - мы на рынке с 1991 года. Поэтому на вопрос: «Что нам мешает выходить на рынок …»  ответить затрудняюсь :-). Возможно, Вы хотели спросить, почему мы не ищем клиентов НА ОКАЗАНИЕ УСЛУГ самостоятельно. Отвечу. Несколько лет назад мы приняли стратегическое решение – оказывать услуги только через партнеров. Поэтому все внедрения и аудиты мы делаем исключительно СОВМЕСТНО с партнерами. Если хотите, это наше кредо.

          По поводу того,  «Зачем мы пиаримся на смартсорсинге» … . Правильный вопрос. Отвечаю. Сегодня нашими клиентами являются только очень крупные компании, а нашими партнерами, только  крупные системные интеграторы. Мы хотим работать на рынке среднего бизнеса, мы видим здесь большие возможности для наших технологий. Однако данный рынок нашим нынешним партнерам не интересен. Поэтому нам нужны другие партнеры, - небольшие компании, которые хотели бы использовать наши продукты и технологии для оказания с их помощью услуг на рынке среднего бизнеса. Мы надеемся найти таких партнеров на данном ресурсе. Именно поэтому мы здесь :-)).

          «Что помешает ИТ-службе клиента напрямую выйти на вас и купить ваше ПО, а аутсорсера тихонечко подвинуть, сказав большое спасибо за идею?» Купить наше ПО ИТ-Службе не мешает ничего. Только  ИТ-Службе обычно нужно не ПО, а Решение определенных проблем. А Решение, это всегда профессиональные услуги. Сегодня на рынке катастрофически не хватает профессионалов, поэтому отодвигать профессионалов – это, как минимум, глупо. А поскольку наши решения покупают, в большинстве случаев, только  умные компании, это маловероятно :-).

           

          • Аватар

            Ланцев Андрей [Sansey], 26 марта 2013, 07:21

            0

            Мы имеем кучу салонов по продаже Порше во всех крупных городах, а теперь приняли стратегическое решение открывать салоны и продавать Порше в деревнях и селах. Ведь там люди тоже как-то передвигаются:)) Примерно так я вас услышал.

            Я никогда не понимал и видимо не пойму, чем руководствуются товарищи принимающие решение продавать свой продукт только через партнеров. Кроме как желанием "закрыться" от клиента и выставить перед собой партнера, который будет с конечным клиентом разруливать глючность продукта (это не про вас именно, это я в приницпе обобщил). Скажу на примере своего опыта. Являюсь я партнером одного международного производителя софта. Продал я его софт своему клиенту (т.к. мы реально видели пользу от его использования). Так мало того, что софт безбожно глючит и не выполняет своих прямых функций, так еще и техподдержка этого самого софтопроизводителя, партнером которых я являюсь, просто "ложит" на наши проблемы отмазываясь стандартным: "Выйдет следующее обновление, там все исправят". Про то, как устанавливаются эти обновления я лучше промолчу. А клиент ессно выносит мозг нам... Купил то он ПО у нас.

            И, как я понял, по вашему мнению в ИТ-подразделениях крупных (и не только) клиентов работают одни лохи, которые без стороннего профессионального интегратора сами нихрена не умеют ни думать ни внедрять, так?