Управление инцидентами. урок 3 Управление инцидентами. Фиксация обращений, управление инцидентами и эскалация
 Скачать 124.2 Kb.
|
|
Тема урока: Фиксация обращений, управление инцидентами и эскалация. Задача Процесса Управления Инцидентами это уменьшение или исключение отрицательного воздействия нарушений в предоставлении ИТ-услуг, таким образом обеспечивая наиболее быстрое восстановление работы пользователей. Управление инцидентами (Incident Management) - процесс, отвечающий за управление жизненным циклом всех инцидентов. Основная цель Управления инцидентами - скорейшее восстановление услуги для пользователей. Инцидент (Incident) - незапланированное прерывание услуги или снижение качества услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом. Процесс управления инцидентами имеет основную цель, которая подразумевает быстрое и эффективное устранение неполадок в функционировании инфраструктуры компании, а также в целом снижение рисков возникновения рецидивов. Чтобы достичь эту, так скажем глобальную цель необходимо решить ряд подзадач, которые в совокупности дадут ожидаемый результат. • Налаживание процесса для управления жизненным циклом инцидента от первичного фиксирования до полноценного устранения. • Создание организованного контроля деятельности сотрудников ИТ-отдела с помощью прозрачного мониторинга хода выполнения поставленных задач. • Налаживание оптимального использования ресурсов сотрудников ИТ и в частности подразделения ИТ. • Постоянное ведение статистики и анализа. • Сдача отчетной информации руководителю ИТ-отдела. Как видно из определения процесса, Управление инцидентами предназначено для максимально быстрого восстановления нормальной эксплуатации услуги . Под "нормальной эксплуатацией услуги" здесь понимается эксплуатация в соответствии с SLA. SLA (соглашение об уровне услуг) – формальный договор между заказчиком услуги и поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги. Это соглашение применяется в ИТ сфере и телекоме. Основные положения SLA: - время предоставления услуг - время поддержки услуг -каталог услуг который может включен в соглашение или быть приложением - уровень доступности услуги относительно простоя по причине недоступности инцидентов или регламента перерывов -таблица вычисления приоритета - параметры срочности, влияния, масштабы услуг Пример: возьмем организацию в которой есть айти отдел, к примеру к ним поступает много обращений о неполадках Рамки и условия SLA: - Устраняемые неполадки - категории срочности - сроки и стоимость устранения - время реакции - ответственность при нарушении срока выполнения Процесс инцидента рассматривает все события, которые нарушают или могут нарушить нормальную эксплуатацию услуги. Информация о таких событиях может поступать из разных источников, основными из которых являются звонки пользователей и технического персонала в Service Desk и процесс Управления событиями. При организации процесса управления инцидентами чаще встречается структура, имеющая многоуровневую иерархию технической поддержки. Позиционирование Процесса Управления Инцидентами относительно других функций (подразделений) ИТ-организации Компания, которая занимается обеспечением первого уровня поддержки и называется Service Desk. Реже определение первой линии носит целая дочерняя организация, которая по такому же принципу носит характер диспетчерской. Наличие данного уровня означает, хорошо структурированную и налаженную модель процесса управления инцидентами. Начальная ступень структуры процесса предназначена для единой точки входа и коммуникации с обращающейся в поддержку базой пользователей. Поэтому передовой линией является центр приема и обработки входящих вызовов (Service Desk). Главная задача оператора (диспетчера) зарегистрировать инцидент и предпринять первичную попытку закрыть инцидент, с которым обратился пользователь. .  - Фиксация обращений (Регистрация инцидента) Диспетчер Service Desk обеспечивает заполнение точной входящей информации, которая характеризует инцидент и гарантирует помощь в дальнейшем решении. А для этого составляется точное описание обращения. Далее сотрудником первой линии определяется и присваивается верный приоритет обращения. Это ответственный этап благодаря, которому назначаются сроки решения. После установки приоритета необходимо определить причину возникновения инцидента, зафиксировать контактную информацию обратившегося. Диспетчер также анализирует и определяет негативные последствия оказываемые на бизнес в следствии возникновения данной проблемы. И завершающим шагом на основании проведенного анализа инцидента, выставляет результирующие сроки устранения. Ценность Управления инцидентами для бизнеса более очевидна, чем у других процессов этапа Внедрения. Часто именно этот процесс является основой для формирования обоснования бизнесу о необходимости остальных процессов этапа Внедрения. В частности, Управление инцидентами помогает бизнесу тем, что: быстро находит и разрешает инциденты, в результате чего снижается время простоя услуг, что в целом увеличивает показатели доступности услуг; выравнивает деятельности IT в соответствии с приоритетами бизнеса; увеличивает способность выявления возможностей для улучшения услуг в результате расследования инцидентов; сервис-деск, разрешая инциденты, определяет дополнительные требования IT и бизнеса к услугам и обучению. Время разрешения инцидента обычно формализовано в рамках SLA и других базовых соглашений. Команды поддержки должны быть готовы к соблюдению временных ограничений. Так же есть понятие Модель инцидентов, которая включает в себя: шаги, которые необходимо предпринять для того, чтобы разрешить инцидент; хронологический порядок шагов; распределение ответственностей - кто и что делает; временные рамки и пороговые величины для завершения каждого действия; вопросы того, с кем необходимо связать и на каком этапе; Таким образом, Модель инцидентов описывает последовательность действий при возникновении определенного типа инцидентов. Использование моделей инцидентов позволяет стандартизовать процесс Управления инцидентами и ускорить его. Этот подход применим в отношении часто возникающих "стандартных" инцидентов. "Нестандартные" случаи обрабатываются отдельно, например, инциденты, связанные с информационной безопасностью. Для того чтобы разрешить инцидент, его необходимо сначала обнаружить, то есть идентифицировать. С точки зрения непрерывности бизнеса неприемлемо ждать обращений пользователей или технического персонала в Service Desk. Все ключевые компоненты должны контролироваться, чтобы своевременно обнаруживать сбои или возможности их возникновения. После того, как инцидент обнаружен, информацию о нем необходимо занести в лог. В логе должно быть отображено время обнаружения инцидента, вне зависимости от того, как он был обнаружен - по звонку в Service Desk или в результате работы автоматических агентов. В логе ( журнале) также необходимо записать всю связанную с инцидентом информацию. Запись об инциденте должна послужить базой для его разрешения соответствующей командой поддержки. Запись об инциденте должна включать: уникальный идентификатор инцидента; категорию инцидента; срочность инцидента. Срочность (Urgency) - мера того, насколько быстро с момента своего появления инцидент, проблема или изменение приобретет существенное влияние на бизнес. Например, инцидент с высоким уровнем влияния может иметь низкую срочность до тех пор, пока это влияние не затрагивает бизнес в период закрытия финансового года. Влияние и срочность используются для назначения приоритета[1]. влияние инцидента; приоритет инцидента; дата и время записи; Имя/ID человека или группы, сделавшей запись об инциденте; метод уведомления; имя/отдел/номер/расположение пользователя; метод обратной связи; описание симптомов; статус инцидента; связанные конфигурационные единицы; группа поддержки/сотрудник, к кому переадресован инцидент; связанная с инцидентом проблема/известная ошибка; деятельности, осуществленные для разрешения инцидента; время и дата разрешения инцидента; категория закрытия; время и дата закрытия Следующий этап разрешения инцидента - категорирование. Оно необходимо для дальнейших работ, в частности, поиска известных ошибок и проблем, которые могли послужить причиной для возникновения инцидента. Обычно используется три-четыре уровня категорирования (рис. 1).  Рис. 1. Варианты категорирования инцидентов Нет стандартных методов для категорирования инцидентов, каждая организация сама определяет, какие категории будет использовать. Приоритет инцидента определяется исходя из двух понятий - срочности и влияния. Влияние в отношении инцидентов чаще всего определяется на основе количества пользователей, которые он затронул. Тем не менее, этот показатель не всегда является объективным. В некоторых случаях влияние инцидента даже на одного единственного пользователя может оказать значительное негативное влияние на бизнес в целом. Другие факторы, которые можно использовать для оценки влияния: риск для жизни или сегмента; количество услуг, которые затрагивает инцидент; уровень финансовых потерь; влияние на бизнес-репутацию; возникновение нарушений законодательства и требований регуляторов. Для персонала поддержки необходимо разработать четкие инструкции определения приоритета инцидента на основе срочности и влияния на бизнес. Необходимо отметить, что приоритет инцидента может меняться в зависимости от изменения окружающих условий и требований бизнеса. Для объективной оценки приоритета в диалоге с пользователем употребляются следующие критерии: - степень воздействия инцидента: степень отклонения от нормального уровня предоставления услуги, выражающаяся в количестве пользователей или бизнес-процессов, подвергшихся воздействию инцидента; - срочность инцидента: приемлемая задержка разрешения инцидента для пользователя или бизнес-процесса. Степень воздействия и срочность могут быть объединены в матрицу
Таблица Пример системы кодирования приоритетов Далее следует этап начальной диагностики. В первую очередь он относится к инцидентам, поступившим в Service Desk. Специалист службы Service Desk должен попытаться найти причину, вызвавшую инцидент, понять, что именно работает некорректно и выявить максимальное количество характеристик инцидента во время связи с пользователем, например, по телефону. Другими словами, специалист должен попытаться решить инцидент и закрыть его. Если это невозможно, он сообщает пользователю идентификационный номер инцидента. Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. То дальше переходим на уровень эскалации. Эскалация (Escalation) - деятельность, направленная на получение дополнительных ресурсов, когда это необходимо для достижения Целевых показателей уровня услуги или ожиданий заказчиков. Эскалация может потребоваться в рамках любого процесса Управления услугами, но наиболее часто ассоциируется с Управлением инцидентами, Управлением проблемами и управлением жалобами заказчика. Существует два типа эскалации: функциональная эскалация и Иерархическая эскалация. Функциональная эскалация подразумевает передачу инцидента в группу поддержки с более высокой квалификацией и компетенцией. При этом если очевидно, что второй уровень поддержки не сможет разрешить инцидент, его можно сразу передать на третий уровень поддержки. Третий уровень поддержки может включать в себя не только сотрудников организации, но и поставщиков. При этом ответственность за уведомление пользователя о ходе разрешения инцидента остается на Service Desk, вне зависимости от того, где инцидент рассматривается на данный момент. Иерархическая эскалация подразумевает вовлечение или просто информирование руководителей более высокого уровня о возникновении инцидента. Она способствует своевременному принятию решений относительно выделения дополнительных ресурсов и вовлечения внешних организаций в процесс разрешения инцидента. Следующий этап разрешения инцидентов называется исследование и диагностика. В случаях, когда пользователи обращаются только для поиском информации, Service Desk должен предоставить ее в минимальные сроки. Но если сообщается о наличии сбоя, это требует определенных действий по исследованию и диагностике инцидента. При этом все предпринятые действия должны быть отображены в записи об инциденте. Действия чаще всего включают в себя: установление того, что именно не работает или что именно ищет пользователь; определение хронологии событий; оценка влияния инцидента, в том числе количества пользователей, которых он затронул; поиск в базе знаний аналогичных случаев в прошлом. Когда потенциальное разрешение инцидента определено, необходимо провести тестирование того, что действия по восстановлению завершены, и услуга полностью восстановлена для пользователей. Группа, разрешившая инцидент, должна передать его на закрытие в Service Desk. Service Desk, в свою очередь проверяет, что все действия, необходимые для разрешения инцидента, выполнены, пользователи удовлетворены и согласны закрыть инцидент. Это включает в себя следующее: закрытие категорирования - производится проверка корректности изначально установленной категории инцидента. Если она оказалось неправильной, ее исправление и занесение изменений в запись об инциденте; опрос удовлетворенности пользователей - - осуществляется по звонку или электронной почте для статистики и отображения эффективности работы Service Desk; проверка полноты записи об инциденте; определение того, какая проблема вызвала инцидент, является она постоянной или периодически повторяющейся. Сюда относится также определение проактивных действий по предотвращению инцидентов этого типа в дальнейшем и формирование записи о проблеме, если она новая; формальное закрытие инцидента - формальное закрытие записи об инциденте. Метриками эффективности процесса Управления инцидентами могут быть: общее количество инцидентов; количество инцидентов, находящихся на разных стадиях - закрыт, в работе, передан и т.п. размер текущего лога об инцидентах; количество значительных инцидентов; среднее время разрешения инцидентов; процент инцидентов, разрешенных в согласованное время разрешения инцидентов; средние затраты на инцидент; количество повторно открытых инцидентов и их процентное соотношение к общему количеству инцидентов; количество инцидентов, неправильно назначенных в команды поддержки; количество инцидентов, для которых были неправильно определены категории; количество удаленно разрешенных инцидентов ( без персонального присутствия); количество инцидентов, разрешенных с использованием каждой Модели инцидентов; количество инцидентов в разрезе определенных интервалов дня. Для эффективного Управления инцидентами необходимо обеспечить следующее: способность обнаруживать инциденты как можно раньше. Это включает в себя обучение пользователей немедленно сообщать об инцидентах и конфигурирование инструментов Управления событиями; убедить персонал в том, что все инциденты должны быть занесены в журнал; доступность информации об известных проблемах и ошибках. Это позволит персоналу использовать опыт предыдущих инцидентов; взаимодействие с CMS для определения взаимосвязей конфигурационных единиц и обращения к их истории для поддержки первого уровня; взаимодействие с SLM для корректной оценки инцидентов, расстановки приоритетов и выполнения процедур Эскалации. SLM в свою очередь может использовать информацию от Управления инцидентами для определения того, что целевые уровни производительности реалистичны и могут быть достигнуты. Основные риски для процесса Управления инцидентами: большое количество инцидентов, которые не могут быть разрешены в установленные сроки в связи с недостатком ресурсов или их недостаточной подготовкой; приостановка разрешения инцидентов из-за некорректной работы поддерживающих инструментов; недостаточность или несвоевременность информации из-за некорректной работы поддерживающих инструментов или плохой взаимосвязи с другими процессами; несоответствия с основными контрактами и соглашениями, которые возникают вследствие их плохой проработки и не реалистичности согласованных целевых показателей. Планирование и дальнейшее использование процесса управления инцидентами трудоемкий этап в организации бесперебойного способа работы, как для внешних пользователей, так и внутри предприятия. Но, соблюдая порядок структурирования, можно облегчить внедрение. Для того, чтобы совсем упростить внедрение процесса управления инцидентами необходимо использовать специализированное программное обеспечение. Контрольные вопросы: Что такое инцидент? Зачем организации нужен Service Desk? Цель управления инцидентами? Навыки сотрудников Service Desk? Являются ли Service Desk и управления инцидентами одним и тем же? Если нет, то чем они отличаются? |