Почему так важно Классифицировать Инциденты и Звонки Пользователей

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

Управление инцидентами и изменениями — есть два процесса, которые широко используются в некоторой форме еще до внедрения ITIL в компании. В большинстве организаций должно присутствовать некое простейшее средство для управления здоровьем и производительностью IT инфраструктуры.

ITIL тщательно анализирует внедрение и поддержку процесса управления инцидентами. Одна из тем для обсуждения – это классификация событий (приоритезация и категоризация). Даже организации, которые уже внедрили ITIL, настроили и подогнали все инструменты испытывают определенные трудности при классификации инцидентов. Часто возникают следующие вопросы:

  • Как различать такие определения как Тревога, Инцидент, Событие, Предупреждение, Симптом или Проблема
  • Почему вопрос о категоризации и классификации Инцидентов и событий являетс ятаким важным и как он связан с другими процессами ITIL?
  • Почему теория лучших практик выступает за стандартизацию событийи классификацию инцидентов?

    Различия между такими определениями как Тревога, Инцидент, Событие, Предупреждение, Симптом или Проблема

    Эта терминология используется в разных местах в разное время. Любое изменение состояния ИТ инфраструктуры можно рассудить как Событие, Тревогу или Предупреждение и все это действительно события. Изменения в статусе или увеличение или снижение порога может вылиться в тревогу, событие или предупреждение. Некоторые инструменты контроля используют такие термины как Симптом и Проблема. Там, где симптомы являются событиями, которые могут привести к проблеме, являющейся основной причиной всех симптомов.

    Что касается терминологии ITIL, то все понимают, что является Инцидентом, а что Проблемой, и видят разницу между ними. Широко используются два вида инструментариев, а именно Инструментарий по Отслеживанию Событий, использующий следующие термины: Событие, Тревога, Предупреждение, Инцидент, и Инструментарий по управлению Проблемами и Сервисом, который использует термины Инцидент и Проблема. Мы все знаем, что каждое событие может быть потенциальным Инцидентом, но у многих возникает вопрос, должны ли все события, отслеженные инструментарием трактоваться как Инциденты? Большинство соглашается, что не каждое событие в инфраструктуре должно обязательно становиться Инцидентом.

    Рассмотрим следующий пример; использование CPU на 80% в течение 5 мин можно трактовать как событие, если это событие продолжается 15 мин, то событие перерастает в инцидент, если инцидент закрыт без определения причины или, если он повторяется время от времени, то он может стать потенциальной проблемой. Отсюда вывод, что не все события следует открывать как Инциденты. Помните, что открывать Инциденты следует только тогда, когда вам необходимо предпринимать действия по ним.

    Почему вопрос о категоризации и классификации Инцидентов и событий являетс ятаким важным и как он связан с другими процессами ITIL?

    ITIL направлена на внедрение лучших практик и постоянное улучшение текущего состояния, так чтобы вы могли повышать уровень сервиса и удовлетворение пользователей. Результат процесса улучшения должен помогать в превышении ожиданий пользователей путем соответствия или превышения показателей, заложенных в SLA. Ну а поскольку Работоспособность напрямую связана с SLA и в свою очередь с процессом управления инцидентами, способность категоризировать и классифицировать инциденты становится очень значимой.

    Правильная категоризация инцидентов помогает правильно перенаправить сразу в нужную группу. Правильное перенаправление инцидентов очень важно в процессе управления Инцидентами, поскольку экономит много времени в выявлении причин неисправностей и их устранении. Один из показателей KPI (Key Performance Indicators) Процесса Управления Инцидентами показывает количество перенаправлений между разными группами той или иной проблемы. Это также помогает делать анализ Инцидентов, основанных на классификации, чтобы проводить профилактику управления проблемами, что в сою очередь помогает снижать количество Инцидентов.

    Надлежащая классификация инцидентов очень важна для идентификации и приоритезации для определения, над какими Инцидентами работать в первую очередь. Поскольку это напрямую относится к соответствию SLAs , о классификации Инцидентов стоит задуматься как следует. Если есть 2 идентичных инцидента (ошибок ИТ) в одно и то же время, одно из службы критичной для бизнеса, а другой из службы важной для бизнеса, тогда в соответствии с надлежащей классификацией Аналитик Первого Уровня может работать над инцидентом критичным для бизнеса для предотвращения потери прибыли и нарушение SLA. Поэтому, в каком-то смысле приоритезация инцидентов напрямую привязана к штрафам в SLA.

    Классификация инцидентов в том или ином роде связана с другими процессами, такими как управление Проблемами, Работоспособностью и Сервис-Уровнями.

    Лучшие практике за стандартизацию событий, классификацию инцидентов Для инцидентов существует два типа классификации:

    1. Приоритезация
    2. Категоризация

    Приоритезация обычно осуществляется аналитиками службы поддержки. В случае, если инциденты открыты инструментариями, это (до определенной степени) можно автоматизировать.

    Приоритезация Степень влияния и срочность инцидента вместе образуют степень приоритета. Серьезного внимания требуют события, идентифицированные инструментами контроля. Степень серьезности события можно трактовать как степень «Критичности для бизнеса».

    Очень часто понятия серьезность и приоритет взаимозаменяемы. Обячно используются пять степеней серьезности для приоритезации инцидентов и на основе такой приоритезации подписываются Соглашения об уровнях обслуживания. Первая степень серьезности подразумевает наибольшую критичность, а пятая степень – наименьшую. Некоторые инструментарии используют пять степеней приоритезации. Некоторые системы используют коды приоритезации, такие как Нулевой, Низкий, Средний, Высокий, Критический, Глобальный, и т.п.

    Поскольку понятие Серьезность используется в инструментариях для определения степени Влияния, то лучше пользоваться термином ITIL Приоритеnт для приоритезационной части классификации.

    Какие факторы воздействуют на приоритет?

  • Влияние – Серьезность инцидента. Это есть измерение влияния на бизнес.
  • Срочность – Какое промедление в восстановлении терпимо? Как быстро необходимо восстановить систему?
  • Уровень важности для пользователя – например, звонок от Исполнительного Директора
  • Ресурсы, требуемые для восстановления системы
  • Потенциальная стоимость в случае невозможности своевременного восстановления
  • Сбой в процессе предоставления услуг пользователю

    Важно: Среди прочего следует помнить, что влияние не имеет ничего общего с технической сложностью, но подразумевает влияние на результат бизнес-процесса в случае, если систему не удалось вовремя восстановить.

    Если конечный пользователь звонит по какому-либо поводу, основанному на определенном критерии, аналитик службы поддержки откроет и классифицирует (приоритезирует) Инцидент. Но есть ли возможность автоматизировать процесс для Инцидентов, которые авоматически открываются инструментариями? Это та область, в которой каждая организация с трудом пытается достичь совершенства.

    На самом деле ответ положительный, процесс действительно можно автоматизировать. Ну, может быть, не на все 100%, но основательное понимание системы (окружающей среды) дает возможность приблизиться к цели (что потребует, конечно же, определенных временных затрат).

    Давайте попытаемся отвлечься от той части процесса, которая называется Срочность (как и поступают большинство организаций), и попробуем идентифицировать истинный Приоритет инцидента. Инструментарий управления сконфигурирован так, что он посылает предупреждение в случае, если CPU загружен больше 80%. Тул Мониторинга событий и Тул Упрвления Сервисами сконфигурированы в соответствии друг с другом. И в итоге ставится Критическая степень приоритета (что означает глобальное влияние на бизнес). Вследствие неправильной классификации, если это событие не решается в течение определенного прописанного в Соглашении об обслуживании периода времени, нарушается это самое Соглашение, что, в свою очередь, может привести к штрафам. Вывод отсюда можно сделать следующий: степень Серьезности, определяемая инструментариями, никак не может восприниматься как степень Приоритета события.

    Даже если мы игнорируем Срочность, истинная степень Приоритета должна быть рассчитана с учетом разных аспектов. Например:

  • Серьезность (на основании теста, развития, установки, производства, тренинга и т.п.) механизма (сервера)
  • Часы работы (для уровня сервиса каждого CI)
  • Приложения, размещенные на сервере (насколько они критичны для бизнеса)
  • Наличие или отсутствие кластера (если он в кластере, то инцидент не затрагивает бизнес процесс и степень приоритета снижается)

    Очевидно, что нам необходим многомерный подход к расчету истинного уровня Приоритета. Мы можем достигнуть этого путем правильной конфигурации (в известной степени) тулами управления событиями при помощи правильных кодов серьезности и тогда, до автоматического открытия инцидента в Туле Управления Сервисами, сообщение будет оценено с разных точек зрения до рассчета истинной степени серьезности. Не забывайте, что логика должна основываться на Соглашении об Уровне Услуг.

    Категоризация

    Как мы уже видели, Категоризация помогает правильно перенаправлять инциденты в соответствующую группу поддержки. Некоторые инструментарии могут понимать разницу между Звонком пользователя и Инцидентом. Например, тикет Звонка пользователя открывается в случае наличия вопросов типа «а как» или «а что, если», или в случае, если инцидент приходит напрямую от пользователя. Тикет инцидента открывается автоматически специальными отслеживющими инструментариями. В некоторых приложениях, это два различных модуля, в других это части одного модуля или системы.

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

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

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

    Если Аналитику приходится заполнять 20 различных полей для того, чтобы открыть инцидент, но найдет обходной путь, и вы не получите той информации, для которой собственно и создавалось приложение.

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

    1. Усовершенствование процессов управления проблемами.
    2. Помощь в перенаправлении звонков в нужную группу, отдел или нужному человеку. Все это помогает сократить время разрешения проблемы. Кроме того, правильная категоризация поможет избежать перебрасывания проблемы из группы в группу несколько раз.
    3. Помощь в осуществлении контроля за изменениями.
    4. Создание определенной Информационной базы. Правильный выбор рабочей инструкции для разрешения проблемы.
    5. Соотнесение Инцидентов с документацией или базами данных повторяющихся ошибок.
    6. Правильный автоматический выбор группы помогает правильно перенаправить и зарегистрировать проблему
    7. В конечном счете, все это повышает производительность и снижает затраты

    Итак, как же усовершенствовать категоризацию?

    Некоторые инструментарии имеют такие поля, как Приложение, Объект, Группа сообщений и др. для категоризации событий. Разные инструментарии могут по-разному называть эти поля, но основная идея состоит в том, чтобы выделить три уровня категоризации. Может помочь наличие LOV (Список значений, выпадающее меню с ограниченным количеством вариантов) вместо поля для свободного описания инцидента. Используя выпадающее меню конечный пользователь выбирает подходящее значение, за которым автоматически подтянутся соответствующая Категория, Тип, Item, preventing manual inputs and errors.

    Наилучший способ категоризации включает три уровня:

    1. Категория
    2. Тип
    3. Пункт (Item)

    Категория является верхним уровнем, а Item низшим.

    На практике, верхний уровень не должен включать более 10 категорий. Например, используйте такие понятия, как:

  • Оборудование, ПРиложение, Сеть, Голосовая связь, Хранение, Инструментарий, Операционная система, Безопасность

    Когда вы спускаетесь на следующий уровень категории «Тип», ОС, например, будет иметь следующие значения:

  • UNIX, Windows, Linux

    На последнем уровне «Item,» по типу UNIX значения будут такие:

  • DNS, Backup, FileSystem

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

    Катир [Kathir] более 12 лет работает в сфере ИТ и имеет шестилетний опыт работы с HP Openview/Enterprise management и трехлетний администратора Unix систем.

    Катир имеет степень Masters Degree в Computer Science from University of Bridgeport, Connecticut. Катир получил премию на номинауию лучшего технического консультанта в Азиатском регионе от HP в 2003 году.

    Kathiresan Lakshmanan , 7 ноября 2005. Перевод Виталия Фролова.
    URL: http://www.itsmwatch.com/itil/article.php/3562121

  • Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

    Комментарии закрыты.