Сведения об Инциденте, поступающие от Службы Service Desk или систем управления событиями, представляют собой входные данные для процесса Управления инцидентами. На основании этих данных происходят следующие действия:.
■ запись основных сведений об Инциденте;.
■ сигнал специализированной группе (группам) поддержки при необходимости;.
■ начало процедур обработки запроса на обслуживание.
Выходные данные процесса:.
■ обновленные сведения об Инциденте;.
■ выявление любых ошибок в CMDB;.
■ уведомление Заказчиков о том, что Инцидент был разрешен.
Все Инциденты следует регистрировать: автоматическое создание средствами системного мониторинга «скелета записи об Инциденте» в базе данных Инцидентов - идеальное решение для удовлетворения этого требования. Симптомы, основные данные для диагностики и информация о связанном с ними Учетном элементе должны быть включены в записи об Инциденте во время его обнаружения и записи. В Приложении 5В показаны данные, которые необходимо фиксировать в записях об Инцидентах во время всего процесса Управления инцидентами. Эти данные нужны как для разрешения Инцидента и последующего восстановления, так и для управленческой информации по типам Инцидентов и статистике их возникновения.
В прошлом было общепринято сообщать обо всех Инцидентах в Службу Service Desk, где персонал вручную создавал учетную запись в базе данных Инцидентов. Там, где это было нецелесообразно или невозможно, группам поддержки разрешалось фиксировать Инциденты вручную; в этом случае в Службу Service Desk поступали сигналы, информирующие о возможной деградации уровня услуг. Однако с использованием современных технологий Инциденты могут быть записаны различными методами, включая предоставление возможности Пользователям регистрировать Инциденты непосредственно в системе. Но основное требование остается - все эти Инциденты должны попасть в Базу данных Управления инцидентами, и Служба Service Desk должна получить соответствующие сигналы и осуществлять общий контроль - за мониторинг Инцидентов ответственность по-прежнему несет Служба Service Desk.
В случае серьезного снижения уровня обслуживания, если необходимо предпринять специальные действия, нужно предупредить Менеджера услуг.
Инцидент должен обрабатываться в соответствии со стандартными процедурами SLM. Эти специальные процедуры не входят в рамки процесса Управления инцидентами.
5.6.2 Классификация и первичная поддержка.
Входные данные:.
■ записанные сведения об Инциденте;.
■ сведения о конфигурации из Конфигурационной Базы данных учетных элементов (CMDB);.
■ результат привязки Инцидента к Проблемам и Известным ошибкам.
Чтобы отыскать причину Инцидента, анализируются записи об Инцидентах, возникавших в прошлом. Инцидент должен также быть классифицирован; это процесс, на котором основываются последующие действия по разрешению этого Инцидента. В Приложении 5А приведено несколько примеров классификационных кодов.
Действия:.
■ классификация Инцидентов;.
■ привязка к Проблемам и Известным ошибкам;.
■ информирование процесса Управления проблемами об обнаружении новых Проблем, о цепочках Инцидентов или об Инцидентах, для которых не было найдено аналогов;.
■ присвоение степени влияния и срочности и, как следствие, определение приоритета;.
■ оценка сведений о связанных конфигурациях;.
■ предоставление первичной поддержки (оценка сведений об Инциденте, нахождение быстрого разрешения);.
■ закрытие Инцидента или маршрутизация его на специализированную группу поддержки, а также информирование Пользователя(ей).
Выходные данные:.
■ RFC для разрешения Инцидента;.
■ обновленные сведения об Инциденте;.
■ Обходные решения для Инцидента или маршрутизация Инцидента на вторую или третью линию поддержки.
Классификация - это процесс определения причины Инцидента и, как следствие, соответствующих действий по его разрешению. Многие Инциденты возникают регулярно, и необходимые действия по их разрешению хорошо известны. Тем не менее, так происходит не всегда; нужна процедура привязки классификационных данных Инцидента к Проблемам и Известным ошибкам. В случае успеха есть возможность использовать проверенные действия для разрешения Инцидента, благодаря чему не требуется дополнительных усилий по его расследованию.
Классификация - одна из наиболее важных составляющих процесса Управления инцидентами (и провести ее правильно часто сложнее всего). Классификация используется для того, чтобы:.
■ определить услугу, с которой связан Инцидент;.
■ связать ее с SLA, если это необходимо;.
■ выбрать/определить специалистов или группы специалистов, которые наилучшим образом справятся с обработкой Инцидента;.
■ определить приоритет исходя из влияния на бизнес;.
■ определить, какие вопросы должны быть заданы, или какая информация должна быть проверена;.
■ определить основную матрицу отчетности для управленческой информации;.
■ определить наличие связей с Известными ошибками или решениями.
Окончательная классификация может отличаться от заявленной вначале, поскольку конечные пользователи способны заявить только о симптомах Инцидента, а не о его истинной причине. Уровни классификации могут быть различны в зависимости от требуемого уровня детализации. Для общего обзора может быть достаточно определить класс первого уровня, например «Обработка текстов» или «Начисление заработной платы»; однако может потребоваться и более детальная классификация:.
■ номер версии (используемого приложения);.
■ поставщик;.
■ модуль программного обеспечения (например, печать);.
■ группировка (например, бизнес-приложения).
При классификации Инцидентов необходимо предоставить максимальное количество информации. Классификационные данные, которые используются в процессе привязки, включают:.
■ сведения о симптомах Инцидента;.
■ начальное определение категории Инцидента;.
■ сведения о связанных Учетных элементах (УЭ);.
■ степень влияния на бизнес.
Процесс классификации и привязки позволяет ускорить выполнение процесса Управления инцидентами и минимизировать количество обращений за помощью. Этот процесс классификации и привязки - идеальная область применения так называемых «экспертных приложений».
Служба Service Desk собирает информацию о затронутых Учетных элементах и, следовательно, должна иметь возможность определять несоответствия с данными в CMDB, спрашивая у Пользователя идентификатор конфигурации, серийный номер, и т.д. Если несоответствия обнаружены, то оформляется отчет о несоответствии, который направляется в процесс Управления конфигурациями. Это можно проводить автоматически с помощью ПО для Управления инцидентами или на основе ежедневных отчетов.
Один из наиболее важных аспектов управления Инцидентом - определение его приоритета: насколько важен этот Инцидент и каково его влияние на бизнес. Ответственность за определение приоритета лежит на процессе Управления уровнем обслуживания, действующем в рамках набора параметров, указанных в SLA. Приоритеты, с которыми обрабатываются Инциденты, и, следовательно, трудозатраты на их разрешение и восстановление после них зависят от следующих факторов:.
■ влияние на бизнес;.
■ срочность для бизнеса;.
■ размеры, границы и сложность Инцидента;.
■ доступность ресурсов для того, чтобы справиться с нагрузкой и чтобы устранить неисправность.
«Влияние» - это мера критичности для бизнеса Инцидента или Проблемы, часто приравниваемая к величине возникшей по причине Инцидента деградации согласованных уровней обслуживания. Влияние часто измеряется количеством затронутых людей или систем. Критерии для определения степени влияния должны быть установлены при консультации с руководством и четко прописаны в соглашениях SLA.
При определении степени влияния необходим доступ к информации в CMDB, чтобы установить количество Пользователей, которых затрагивает технический сбой, например, в компоненте аппаратного обеспечения. Служба Service Desk должна иметь доступ к средствам для быстрого выполнения следующих действий:.
■ оценить степень влияния серьезных отказов оборудования на Пользователей;.
■ определить Пользователей, которых затронул отказ оборудования;.
■ установить контакт с ними, чтобы сообщить им о Проблеме;.
■ составить прогноз;.
■ предупредить (специализированные) группы второй линии поддержки.
Под «Срочностью» понимается скорость, с которой необходимо разрешить Инцидент, имеющий определенную степень влияния. Инцидент с высокой степенью влияния необязательно должен быть устранен немедленно. Например, неисправность, вызывающая у Пользователя сложности при работе на своей рабочей станции (степень влияния «высокая»), может быть зарегистрирована, как имеющая «низкую» срочность, если Пользователь покидает офис сразу же после сообщения об Инциденте и на следующий день уходит в отпуск.
«Приоритет» определяется ожидаемыми усилиями. Инцидент с низкой степенью влияния и средней срочностью, который может быть разрешен с небольшими затратами, будет разрешен сразу же в большинстве организаций (например, восстановление пароля).
Первичная поддержка включает разрешение Инцидента Службой Service Desk, что приводит к решению проблемы Заказчика. Разрешение Инцидента может проводиться, в числе прочего, с помощью:.
■ идентификации Инцидента как Известной ошибки;.
■ использования опыта персонала Службы Service Desk;.
■ поиска в базе знаний (по возможности, с помощью экспертных приложений).
После этого со стороны Службы Service Desk потребуются лишь незначительные действия, такие как запись сведений о разрешении Инцидента, классификации Инцидента и об удовлетворенности Заказчика обслуживанием.
Совет:.
Количество запросов, разрешаемых непосредственно Службой Service Desk, является важным показателем мониторинга предоставления услуг. Чем выше этот показатель, тем больше степень удовлетворенности Пользователей.
В случае неудачной классификации и привязки, или в случае, если процесс разрешения слишком сложен, следующим шагом будет расследование и диагностика группой поддержки.
Несмотря на то, что ответственность за разрешение Инцидента передается другой группе поддержки, Служба Service Desk должна сохранять владение Инцидентом и управлять им до его разрешения и удовлетворения Заказчика.
5.6.3 Расследование и диагностика.
Входные данные:.
■ обновленные сведения об Инциденте;.
■ сведения о конфигурации из Конфигурационной Базы данных учетных элементов (CMDB).
Действия:.
■ анализ сведений об Инциденте;.
■ сбор и анализ всей информации, связанной с Инцидентом, и его разрешение;.
■ (включая все Обходные решения) или маршрутизация на N-ю линию поддержки.
Выходные данные:.
■ повторно обновленные сведения об Инциденте, определение необходимого Обходного решения или его выбора.
По возможности, всем Пользователям, имеющим отношение к Инциденту, необходимо обеспечить продолжение работы, вероятно, предоставляя услуги более низкого качества. Например, неисправность принтера может привести к необходимости печати документов на другом, более удаленном принтере. Результат такого Обходного решения - минимизация влияния Инцидента на бизнес, чтобы предоставить больше времени для расследования и разработки структурного разрешения. Временные Обходные решения можно предложить и другим Пользователям.
После того, как Инцидент был передан группе поддержки, она должна:.
■ взять на себя обработку Инцидента, указать дату и время (предпочтительно автоматически), обеспечив:.
регулярное обновление статуса Инцидента и его истории;.
информирование Заказчика о ходе работ по разрешению Инцидента через Службу Service Desk;.
отображение текущего статуса Инцидента (например, «в работе» и т.д.);.
■ предоставить рекомендации Службе Service Desk/Заказчику по всем найденным Обходным решениям, если эта информация доступна сразу после поступления запроса;.
■ сопоставить Инцидент с Известными ошибками, Проблемами, решениями, планируемыми изменениями или информацией из баз знаний;.
■ если необходимо, сделать запрос в Службу Service Desk о пересмотре присвоенной степени влияния на бизнес и приоритета, приведя их в соответствие с бизнес-нуждами, основанными на согласованных уровнях обслуживания;.
■ записать все сведения, применимые к данному этапу жизненного цикла Инцидента:.
решение;.
изменение классификации;.
обновление всех связанных с ним Инцидентов;.
затраты времени;.
■ передать Инцидент обратно Службе Service Desk для его закрытия.
Процесс расследования и диагностики может циклически повторяться каждой следующей специализированной группой поддержки, которой передается.
Инцидент после устранения предыдущей причины его возникновения. В этот процесс могут быть вовлечены географически разделенные группы поддержки и персонал поддержки различных поставщиков. Он может продолжаться персоналом следующей смены, заступающим на следующий день. Все это требует жесткого дисциплинированного подхода и полной записи предпринимаемых действий и их результатов.
Совет:.
Если непонятно, какая группа поддержки должна расследовать и разрешать какой-либо связанный с Пользователем Инцидент,.
Служба Service Desk, как владелец всех Инцидентов, должна координировать процесс Управления инцидентами. Если есть различные мнения или возникает ряд других вопросов, тогда Служба Service Desk должна провести эскалацию Инцидента группе Управления проблемами.
В Приложении 5Г показан типичный процесс расследования Инцидента. Запись об Инциденте постоянно расширяется за счет регистрации действий, предпринимаемых на каждом этапе выполнения.
5.6.4 Разрешение и восстановление.
Входные данные:.
■ обновленные сведения об Инциденте;.
■ все возможные ответы на RFC, приводящие к разрешению Инцидента(ов);.
■ все полученные Обходные решения и способы разрешения.
Действия:.
■ разрешить Инцидент, используя способ разрешения/Обходное решение или оформить RFC (сюда входит проверка, приведет ли этот RFC к разрешению Инцидента);.
■ выполнить действия по восстановлению.
Выходные данные:.
■ RFC для последующего разрешения Инцидента;.
■ разрешенный Инцидент, включая сведения о восстановлении;.
■ обновленные сведения об Инциденте.
После успешного разрешения или выполнения действий, подразумеваемых Обходным решением, можно приступить к действиям по восстановлению услуги, что часто выполняется специализированным персоналом (второй или третей линии поддержки). Система автоматизации процесса Управления инцидентами должна предоставлять возможность регистрации событий и действий во время разрешения и восстановления.
Входные данные:.
■ обновленные сведения об Инциденте;.
■ разрешенный Инцидент.
Действия:.
■ подтверждение разрешения Инцидента Заказчиком или заявителем Инцидента;.
■ присвоение категории «закрыт»;.
■ Инцидент.
Выходные данные:.
■ обновленные сведения об Инциденте;.
■ закрытая запись об Инциденте.
После того как Инцидент был разрешен, Служба Service Desk должна удостовериться в том, что:.
■ сведения о действиях по разрешению Инцидента лаконичны и понятны;.
■ существует полная и четкая классификация исходной причины Инцидента;.
■ разрешение/действия согласованы с Заказчиком - устно, по электронной почте (что предпочтительно) или письменно;.
■ выполнены все действия, применимые к данному этапу контроля Инцидентов, а именно:.
обеспечена удовлетворенность Заказчика.
определены коды проектов-источников затрат.
записано время, потраченное на Инцидент.
записана информация о том, кто закрыл Инцидент, а также о дате и времени закрытия.
Советы:.
Этот процесс необходим для разрешения споров между поставщиком услуг и Заказчиком по поводу обоснования закрытия Инцидента.
Важно наличие ограничения доступа к процедуре закрытия Инцидента, которое должно контролироваться Менеджером Службы Service Desk.
Инциденты должны быть соотнесены с соответствующей учетной записью Проблемы/Известной ошибки, если она существует.
Если закрытый Инцидент открывается повторно, важно записать причину этого и скорректировать ранее указанное время загрузки персонала, если требуются дополнительные работы; если нет, то следует оформить новую запись об Инциденте и связать ее с предыдущей.
5.6.6 Владение, мониторинг, отслеживание и коммуникации.
Входные данные:.
■ записи об Инцидентах.
Действия:.
■ мониторинг Инцидентов.
■ эскалация Инцидентов.
■ информирование Пользователей.
Выходные данные:.
■ управленческие отчеты о ходе разрешения Инцидента.
■ сведения об эскалации Инцидента.
■ отчеты и коммуникация с Заказчиком.
Служба Service Desk несет ответственность за владение и наблюдение за разрешением всех открытых Инцидентов, независимо от их источника. Для этого необходимо выполнять следующие действия:.
■ регулярно отслеживать статус и ход разрешения всех открытых Инцидентов и проверять, насколько они соответствуют уровням обслуживания;.
■ отмечать Инциденты, передаваемые между специализированными группами поддержки, поскольку это может означать неясность или разногласия среди персонала поддержки (при значительных разногласиях Инциденты могут быть направлены на рассмотрение процессу Управления проблемами);.
■ отдавать приоритет мониторингу Инцидентов с высокой степенью влияния;.
■ информировать Пользователей, затронутых Инцидентом, о ходе работ;.
■ проверять наличие похожих Инцидентов.
Если следовать этим шагам, это поможет обеспечить разрешение каждого Инцидента в согласованные сроки или, по крайней мере, максимально быстро. Большие Службы Service Desk должны рассмотреть возможность создания отдельной группы для мониторинга и отслеживания Инцидентов.
В случае, если работа по разрешению Инцидента завершается неудачно, Служба Service Desk должна действовать в соответствии с хорошо продуманными процедурами эскалации. Эти процедуры должны быть согласованы со всеми группами поддержки. На практике важно понимать, что персонал службы поддержки может чересчур увлечься каким-либо Инцидентом, затрачивая значительное время на диагностику и сбор информации, что приведет к потере внимания к неотложным нуждам Пользователей; при любых обстоятельствах, когда происходит превышение согласованных пороговых значений для эскалации (определенных в соглашениях SLA), необходимо предпринять действия по эскалации независимо от мнения персонала службы поддержки.
Советы:.
■ Выявляйте Инциденты, для которых существует вероятность нарушения согласованных целевых показателей уровней обслуживания, и сообщайте об этом людям, отвечающим за разрешение этих Инцидентов.
■ Сообщайте людям, с которыми вы будете контактировать в процессе эскалации, об Инцидентах, для которых существует вероятность нарушения уровней обслуживания.
■ Записывайте всю информацию об эскалации Инцидента в истории Инцидента и доводите ее до сведения людей, с которыми вы будете контактировать в процессе эскалации.
■ Добейтесь соглашения о процессах эскалации и о пороговых значениях, при которых выполняются действия, связанные с эскалацией. Например:.
когда проходит 75% времени, отведенного для разрешения, а запрос все еще не разрешен, Служба Service Desk должна выяснить ситуацию у человека, ответственного за разрешение Инцидента;.
когда проходит 90% времени, отведенного для разрешения, а запрос все еще не разрешен, Служба Service Desk должна выяснить ситуацию у руководителя человека, ответственного за разрешение Инцидента.