004 ITIL V3 Service Operation OK

Функция управления сервисом 1
Управление инцидентами
Функция управления сервисом
Опубликовано: октябрь 2002 г.

Переформатировано: январь 2005 г.
Для получения последней информации обращайтесь на сайт www.microsoft.com/mof
Microsoft®
ii Управление инцидентами
Информация, содержащаяся в настоящей документации, представляет собой текущий взгляд

корпорации Microsoft на проблемы, обсуждаемые на момент публикации. Поскольку
корпорация Microsoft должна реагировать на изменяющееся состояние рынка, эту информацию
не следует интерпретировать как обязательство со стороны Microsoft, и Microsoft не может
гарантировать точность любой информации, представленной после даты публикации.
Настоящий документ приводится исключительно в информационных целях. КОРПОРАЦИЯ

MICROSOFT НЕ ДАЕТ НИКАКИХ ГАРАНТИЙ, ЯВНО ВЫРАЖЕННЫХ, ПОДРАЗУМЕВАЕМЫХ
ИЛИ УСТАНОВЛЕННЫХ ЗАКОНОМ, ОТНОСИТЕЛЬНО ИНФОРМАЦИИ, СОДЕРЖАЩЕЙСЯ В
ЭТОМ ДОКУМЕНТЕ.
Пользователь отвечает за исполнение всех действующих законов об авторском праве.

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

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

имен доменов, адресов электронной почты, логотипов, людей, мест и событий являются
фиктивными без какой-либо связи с любой реальной компанией, организацией, продуктом,
именем домена, адресом электронной почты, логотипом, человеком, местом или событием.
© 2005 Microsoft Corporation. Все права защищены.
Microsoft и Windows являются либо зарегистрированными торговыми марками, либо торговыми

марками корпорации Microsoft в США и/или других странах.
Названия упомянутых здесь фактических компаний и продуктов могут являться торговыми

марками их соответствующих владельцев.
Содержание
Краткая информация по управлению ......................................................................................... 1
Введение .......................................................................................................................................... 3
Краткий обзор управления инцидентами .................................................................................... 5
Задача и цели .............................................................................................................................. 5
Возможности ................................................................................................................................. 6
Ключевые определения ............................................................................................................... 6
Процессы и действия ...................................................................................................................... 9
Краткая информация по схеме процесса ................................................................................. 9
Обнаружение, самообслуживание и регистрация .................................................................... 12
Обнаружение .......................................................................................................................... 13
Самообслуживание ................................................................................................................ 13
Регистрация ............................................................................................................................ 19
Обработка сервисных запросов ..................................................................................................23
Классификация и начальная поддержка ................................................................................... 28
Классификация .......................................................................................................................29
Начальная поддержка ............................................................................................................35
Исследование и диагностика ...................................................................................................... 39
Процедура по серьезным инцидентам ...................................................................................... 50
Разрешение и восстановление ................................................................................................... 56
Закрытие ....................................................................................................................................... 59
Роли и обязанности ......................................................................................................................... 63
Менеджер по инцидентам ............................................................................................................63
Аналитики службы поддержки .................................................................................................... 63
Менеджер по серьезным инцидентам ....................................................................................... 64
Технические специалисты по поддержке ................................................................................. 65
Связь с другими SMF ...................................................................................................................... 71
Служба поддержки ....................................................................................................................... 71
Управление проблемами ............................................................................................................. 71
Управление изменениями ........................................................................................................... 72
Управление конфигурациями .................................................................................................... 72
Управление релизами ................................................................................................................ 72
Управление уровнем сервиса .................................................................................................... 72
Управление мощностью .............................................................................................................. 72
Управление доступностью .......................................................................................................... 73
Управление непрерывностью ИТ сервиса ..................................................................................73
Администрирование безопасности ............................................................................................. 73
Мониторинг и контроль сервисов .............................................................................................. 73

Приложения ...................................................................................................................................... 75
Приложение A: Используемые технологии ................................................................................ 75
Приложение B: Пример шаблона плана восстановления для серьезного инцидента ......... 77
Приложение C: Пример таблицы плана связи для серьезных инцидентов ........................... 85
Резюме для руководства

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

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

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

 Своевременный анализ инцидентов, приводящий к минимальному воздействию на
бизнес.
 Улучшенное использование ресурсов поддержки.
 Лучшее понимание воздействия инцидентов на цели SLA, обеспечивая улучшенное
установление приоритетов.
 Точная информация относительно происходящих инцидентов.
 Устранение "потерянных" инцидентов и сервисных запросов.
 Повышенная доступность управленческой информации.
Настоящий документ иллюстрирует процессы и действия, вовлеченные в управление

инцидентами, а также пути, с помощью которых функция управления сервисом (SMF)
управления инцидентами связывается с другими SMF в модели процесса Microsoft® Operations
Framework (MOF).
2
Введение
В настоящем руководстве приводится подробная информация относительно SMF "Управление
инцидентами" для организаций, которые уже используют или собираются использовать
технологии Microsoft® в центре данных или другом типе вычислительной среды предприятия.
Это - одна из более чем 20 SMF, определяемых и описываемых в Microsoft Operations
Framework (MOF). Руководство предполагает, что читатель знаком с целью, исходными
данными и фундаментальными понятиями MOF, а также обсуждаемыми технологиями
Microsoft.
Краткий обзор MOF и его компаньона, Microsoft Solutions Framework (MSF), доступны в
руководстве Краткий обзор функции управления сервисом MOF. В этом обзорном руководстве
также приводится резюме по каждой из функций управления сервисом, определенных в MOF.
Подробная информация о понятиях и принципах каждого из подходов доступна в технических
статьях на сайте www.microsoft.com/mof.
3
Краткий обзор управления инцидентами
Процесс управления инцидентами стремится гарантировать то, чтобы обнаруживались
инциденты и регистрировались сервисные запросы. Регистрация гарантирует отсутствие
потерянных инцидентов или сервисных запросов, позволяя отслеживать регистрационные
записи, и предоставляет информацию, призванную помочь в действиях по планированию и
управлению проблемами. Процесс включает в себя использование технологии по обеспечению
клиентов средствами самообслуживания, предоставляя им гибкие и удобные интерфейсы к
функции поддержки, также снижая рабочую нагрузку и требования по персоналу для службы
поддержки.
Сервисные запросы (запросына изменение (RFC) или запросы на выполнение пакетных

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

быть исследованы, диагностированы, решены и затем закрыты. Процесс гарантирует, что
инциденты распознаются, отслеживаются и проверяются на всех своих циклах.
Могут иметь место случаи, когда происходят серьезные инциденты, требующие реакции,
выходящей за пределы реакции, предусмотренной процессом для обычного инцидента.
Управление инцидентами включает в себя процесс для обработки таких серьезных инцидентов,
используя иерархическую или функциональную эскалацию, эффективную связь и формальные
планы возврата.
Задача и цели
Первичная задача SMF "Управление инцидентами" заключается в как можно более быстром
восстановлении нормальной работы сервиса и минимизировании неблагоприятного
воздействия на бизнес-операции, гарантируя, таким образом, поддержание возможных
наилучших уровней качества сервиса и доступности. Обычно нормальная работа сервиса
определяется в рамках соглашения об уровне сервиса (SLA).
Цели управления инцидентами:

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

 Недоступность сервиса.
 Сбой программы.
 Отказ аппаратных средств.
 Обнаружение вируса.
Диапазон различных сервисных запросов, полученных ИТ организацией, меняется в

зависимости от организации. Общие сервисные запросы могут включать в себя:
 Запросы на изменение (RFC).
 Запросы на информацию (RFI).
 Запросы на поставку.
 Запросы пакетных заданий для определенной цели.
 Запросы на продление сервиса.
 Переустановка пароля.
В зависимости от размера и структуры организации некоторые из этих запросов будут

полностью обрабатываться службой поддержки, в то время как другие будут обрабатываться
процессами в пределах других SMF или других частей организации. В последнем случае
процесс управления инцидентами действует в качестве интерфейса к соответствующему
процессу. Пример этого - RFC, который можно передать процессу управления изменениями.
Ключевые определения
Ниже приводятся ключевые термины, используемые в рамках процесса управления
инцидентами:
Инцидент. Любое неожиданное событие, которое вызывает или может вызвать прерывание
или снижение качества сервиса.
Группа начальной поддержки. Группа, которая обеспечивает самую первую линию поддержки
для обработки инцидентов и сервисных запросов. Персонал группы начальной поддержки
ответственен за осуществление попыток разрешения инцидентов при первом контакте
посредством идентификации известных обходных путей, используя диагностические сценарии
или свое собственное знание. Во многих организациях служба поддержки действует в качестве
группы начальной поддержки.
Известная ошибка. Инцидент или проблема, для которых известна первопричина и были
идентифицированы временный обходной путь или постоянный альтернативный вариант. Если
существует бизнес-событие, то будет выдан RFC, но в любом случае, если только инцидент не
устраняется изменением, будет иметь место известная ошибка.
Серьезный инцидент. Инцидент с высокой или потенциально высокой степенью воздействия,

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

сервисных запросов, которые не смогла решить группа начальной поддержки. Структура
группы поддержки меняются в зависимости от организации. В одних организациях используется
многоуровневая структура (второй уровень/линия поддержки, третий уровень и т.д.), в то время
как в других организациях приняты комплексные или проблемно-ориентированные группы
(универсальная группа, группа по настольным системам, сетевая группа или группа базы
данных).
Служба поддержки. Функция, которая обеспечивает важную точку ежедневного контакта между
клиентами, пользователями, ИТ сервисами и сторонними организациями. Служба поддержки не
только координирует процесс управления инцидентами, но также обеспечивает интерфейс со
многими другими ИТ процессами.
Сервисный запрос. Запросы о новом или измененном сервисе. Типы сервисных запросов
меняются в зависимости от организации, но общие запросы включают в себя запросы на
изменение (RFC), запросы на информацию (RFI), запросы на поставку и запросы на продление
сервиса.
Решение. Известно также под названием "постоянное устранение проблемы".

Идентифицированное средство решения инцидента или проблемы, которое обеспечивает
устранение его (её) основной причины.
Обходной путь. Идентифицированное средство решения конкретного инцидента, позволяющее

продолжить нормальную работу сервиса, но фактически не устраняющее основную причину,
которая изначально привела к инциденту.
4
Процессы и действия
На приведенном ниже рисунке показан жизненный цикл инцидента от начального его
появления до закрытия инцидента после подтверждения того, что проблема была решена.
Incident
occurs
Normal service
resumed
Detected Investigated Resolved

and Classified and and Closed
recorded diagnosed recovered
End to end ownership, tracking, and monitoring
Подписи к рисунку:
Incident occurs - Инцидент возникает
Detected and recorded - Обнаруживается и регистрируется
Classified - Классифицируется
Investigated and diagnosed - Исследуется и диагностируется
Resolved and recovered - Разрешается и устраняется
Closed - Закрывается
Normal service resumed - Обычный сервис возобновлен
End to end ownership, tracking, and monitoring - Непрерывное владение, отслеживание и контроль
Рисунок 1. Жизненный цикл инцидента
Фундаментальной концепцией в рамках управления инцидентами является непрерывное

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

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

Управление инцидентами может быть графически представлено в виде блок-схемы процесса,
которая идентифицирует действия, необходимые для гарантии того, что реакция на ИТ
инциденты осуществляется надлежащими ресурсами поддержки в пределах периода времени,
требуемого бизнесом.
На приведенном ниже рисунке показана блок-схема процесса для управления инцидентами.
New incidents - Новые инциденты

Detection, self-service, and recording -
New incidents
Обнаружение, самообслуживание и
регистрация
Handling of service requests -
Обработка сервисных запросов
Classification and initial support -
Классификация и начальная
Detection, self-
service, and
Handling of поддержка
service requests Major incident procedure - Процедура
recording
по серьезным инцидентам
Investigation and diagnosis -
Исследование и диагностика
Resolution and recovery - Разрешение
и восстановление
Closure - Закрытие
Classification and Resolved incidents and service requests
initial support - Разрешенные инциденты и
сервисные запросы
Investigation and
diagnosis
Major incident Resolution and

procedure recovery
Closure
Resolved incidents and

service requests
Рисунок 2. Блок-схема процесса управления инцидентами

Главные процессы в рамках управления инцидентами:
 Обнаружение, самообслуживание и регистрация. Этот процесс связан с начальным

обнаружением инцидентов посредством различных сред. Об инцидентах могут сообщать
люди, обращающиеся в службу поддержки по телефону, факсу или электронной почте.
Другие инциденты могут возникать из-за предупреждений, выдаваемых системами
управления событиями.
Пользователи могут использовать средства самообслуживания для оповещения о своих
собственных инцидентах, проверки прогресса по существующим инцидентам и получения
справочной информации для самостоятельного использования.
Каждый инцидент регистрируется для того, чтобы его можно было отследить, проверить и
обновить на всем его жизненном цикле. Эта информация может впоследствии
использоваться для управления проблемами, составления регистрационных записей,
оптимизации процесса и планирования.
 Обработка сервисных запросов. Данный процесс позволяет осуществлять обработку и
распределение сервисных запросов. Разные типы сервисных запросов требуют различной
обработки. Служба поддержки может обрабатывать одни запросы, в то время как другие
запросы необходимо передавать для обработки другим процессам, типа управления
изменениями.
 Классификация и начальная поддержка. Процесс классификации категоризирует
инцидент и использует информацию по воздействию и безотлагательности для определения
приоритета инцидента.
Процесс начальной поддержки направлен на оперативное разрешение инцидентов. Это
может достигаться проверкой инцидентов относительно известных ошибок, существующих
проблем и предыдущих инцидентов для идентификации зарегистрированных обходных
путей.
 Исследование и диагностика. Данный процесс связан с исследованием инцидента и
сбора диагностических данных. Цель процесса состоит в том, чтобы идентифицировать,
каким образом можно разрешить инцидент как можно быстрее.
Этот процесс инициирует функциональную или иерархическую эскалацию, если
необходимо, для соответствия целям SLA.
 Процедура по серьезным инцидентам. Процедура по серьезным инцидентам
существует для того, чтобы обрабатывать такие критические инциденты, которые требуют
реакции, выходящей за рамки, предусмотренные для процесса по обычному инциденту.
Хотя эти инциденты обладают жизненным циклом обычных инцидентов, инициирование
процедуры по серьезным инцидентам обеспечивает повышенную координацию, эскалацию,
связь и ресурсы, которые требуют эти высокоприоритетные события.
 Разрешение и восстановление. Этот процесс охватывает требуемые для разрешения
инцидента шаги, часто посредством связи с процессом управления изменениями для
осуществления действий по восстановлению. После принятия действий проверяется успех
разрешения инцидента.
После разрешения инцидента, например замены неисправного жесткого диска, могут
понадобиться действия по восстановлению, например, восстановление данных и повторный
ввод в действие.
 Закрытие. Данный процесс гарантирует удовлетворение клиента в том, что инцидент
был разрешен до закрытия регистрационной записи инцидента.
Процесс также проверяет, чтобы регистрационная запись инцидента полностью обновилась,
и назначает категорию закрытия.
Обнаружение, самообслуживание и регистрация

На приведенном ниже рисунке показана блок-схема для обнаружения, самообслуживания и
регистрации.
Detection, Self-Service and Recording Подписи к рисунку:
Detection, Self-Service and Recording -
Alerts from event Voice or video Telephone Internet / Browser
management systems
Walk-ins
requests
Faxes
requests
E-mail
requests Обнаружение, самообслуживание и
регистрация
Alerts from event management systems -
Предупреждения от систем управления
событиями
Walk-ins - Личные обращения
Self-Service Voice or video requests - Голосовые или
видео запросы
Faxes - Запросы по факсу
Telephone Contact
Other
Which service
Check progress Telephone requests - Запросы по
method required? телефону
Use
E-mail - Запросы по электронной почте
Alerts automatically E-mail or self-help Internet / Browser requests - Запросы по
generate incident Browser
records интернету / через браузер
Self-Service - Самообслуживание
Access self-help Access self-
Telephone - Телефон
information tracking facility Contact method - Метод контакта
Other - Другое
Which service required? - Какой сервис
требуется?
Initial support
CMDB records basic
Customer records
Return to Check progress - Проверка прогресса
basic details and
details and
acknowledges
gets
previous
menu?
Alerts automatically generate incident
receipt
acknowledgment
records - Предупреждения автоматически
генерируют регистрационные записи
инцидента
End E-mail or Browser - Электронная почта
или браузер
Use self-help - Применение справки для
Further details
Where possible, самостоятельного использования
contact initiator for
or clarification
information or Access self-help information - Доступ к
required? Yes
clarification справочной информации
No Access self-tracking facility - Доступ к
средству самостоятельного
отслеживания
Initial support records basic details and
Service Yes
request? acknowledges receipt - Группа начальной
поддержки регистрирует основные
No детали и подтверждает получение
Customer records basic details and gets
acknowledgement - Клиент регистрирует
основные детали и получает
подтверждение
A J
Return to previous menu? - Возврат в
предыдущее меню?
Classification and
initial support
Handling of End - Конец
service requests
Further details or clarification required? -
Требуются дополнительные детали или
разъяснение?
No - Нет
Yes - Да
Where possible, contact initiator for
information or clarification - Где возможно,
обращайтесь к инициатору для
получения информации или разъяснения
Service request? - Сервисный запрос?
Classification and initial support -
Классификация и начальная поддержка
Handling of service requests - Обработка
сервисных запросов
Рисунок 3. Блок-схема обнаружения, самообслуживания и регистрации
Обнаружение
Для того чтобы инцидентами можно было управлять, их сначала необходимо обнаружить.
Традиционно, о большинстве инцидентов сообщают пользователи, сталкивающиеся с
проблемами при выполнении своих повседневных задач. Служба поддержки играет в этом
ключевую роль, действуя в качестве единственной контактной точки между пользователями и
ИТ. Эта единственная контактная точка помогает гарантировать, чтобы все информируемые
инциденты и сервисные запросы обрабатывались последовательно, сводя к минимуму
задержки в работе персонала по поддержке, таким образом, позволяя ему работать более
эффективно.
Инциденты могут также обнаруживаться ИТ персоналом, партнерами и поставщиками.

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

настоящее время другим источником обнаруженных инцидентов. Эти системы непрерывно
контролируют другие системы и сетевые инфраструктуры и могут идентифицировать, когда
превышаются предварительно заданные пороги, или когда компоненты становятся
недоступными. После этого системы предупреждают процесс управления инцидентами.
Примечание, касающееся технологии. В организациях используется широкий диапазон систем управления событиями. Они
включают в себя внутренние сценарии, разработанные для обеспечения основного контроля отдельных систем и приложений,
коммерческие продукты управления системами, а также комплексные решения для управления предприятиями.
Одни решения нацелены на определенные платформы, в то время как другие предлагают использование многоплатформенных
функциональных возможностей. Выбор надлежащих инструментальных средств является критическим фактором для организации,
поскольку эти инструментальные средства часто представляют собой значительные инвестиции, как в терминах стоимости, так и в
терминах установки. Многие инструментальные средства первоначально были спроектированы для определенной платформы.
Несмотря на то, что сейчас они предлагают многоплатформенную поддержку, качество такой поддержки может оказаться не
сопоставимым с качеством первоначальной платформы.
Для стратегических платформ должны использоваться признанные промышленностью высококачественные системы управления
событиями. Хорошая межплатформенная система управления должна быть в состоянии объединять события от одного или более
продуктов, для того чтобы облегчить работу операторов. После приобретения такой системы они смогут также обеспечить контроль
для систем, которые не считаются достаточно стратегическими для того, чтобы обеспечить собственный заказной контрольный
инструмент.
Контролируемые пороги должны тщательно анализироваться. Для разных целей могут потребоваться различные пороги.
Определенная метрика может иметь порог, который соответствует целям в рамках SLA, так, чтобы нарушения SLA могли быть
идентифицированы. Однако управление инцидентами требует более низкого порога предупреждения, для того чтобы действие
могло быть предпринято прежде нарушения SLA. Часто требуется период настройки для идентификации порогов, которые
предоставляют время на принятие действия, но которые не инициируются слишком часто в течение обычной операции.
Самообслуживание
Средства самообслуживания предоставляют ИТ клиентам повышенную гибкость и управление
при связывании с организацией по поддержке. В среде самообслуживания клиенты могут
обращаться в службу поддержки. Возможные варианты могут включать в себя обычное
телефонное оборудование, беспроводные устройства и обычные клавиатурные устройства,
используя либо технологию браузера, либо доступ к средствам запроса, внедренным в
инструмент службы поддержки. Независимо от используемого метода, должна присутствовать
система управления для гарантии согласующегося уровня качества сервиса. Существуют
отличия, которые должны быть распознаны и запланированы при работе с различными
средами доступа. Для эффективной работы концепции крайне важным фактором является
точный дизайн.
Для того чтобы выполнить эту эффективную стратегию, служба поддержки должна
идентифицировать типы запросов, с которыми они имеют дело, решить, какие типы
удовлетворяют решению самообслуживания, и затем разработать решение. Если эти действия
выполняются успешно, то организации смогут освободить свои технические ресурсы для того,
чтобы сосредоточиться на более сложных или исключительных проблемах.
Например, если 30 процентов от принятых запросов являются запросами на переустановку

пароля, то полезным действием окажется разработка средства, позволяющего пользователям
отвечать на вопросы аутентификации и затем переустанавливать свои собственные пароли.
Если после этого обнаруживается, что большая часть оставшихся запросов имеет вид вопроса
типа "Как мне сделать?”, то может быть разработано средство для часто задаваемых вопросов
(FAQ). Смысл заключается в том, чтобы идентифицировать типы запросов, которые в
настоящее время используют значительные ресурсы группы начальной поддержки, но которые
работали бы хорошо как решение самообслуживания. Это впоследствии может позволить
ресурсам сконцентрироваться на оставшихся типах запросов, например, затруднений,
связанных с сервером или сетью. Необходимо понять профиль получаемых запросов, для того
чтобы решения самообслуживания адресовались надлежащим образом.
Должна быть составлена таблица типа той, что приведена ниже.
Таблица 1. Таблица самообслуживания
Тип запроса Процент от Разрешено Разрешено Разрешено Разрешено

общего самообслуживанием группой группами группами
числа (уровень 0) начальной решения решения
запросов поддержки второго третьего
уровня уровня
Переустанов 30% 0% 25% 5% 0%
ка пароля
Как мне 18% 0% 9% 8% 1%
сделать?
Обновления 17% 0% 15% 2% 0%
прогресса
Вопросы по 13% 0% 5% 5% 3%
офисным
программам
Вопросы по 12% 0% 3% 7% 2%
персональн
ому
компьютеру
Вопросы по 5% 0% 0% 2% 3%
подключени
юк
сервисам
Другое 5% 0% 3% 1% 1%
Всего 100% 0% 60% 30% 10%
Из показанной выше таблицы видно, что решения самообслуживания для переустановки

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

обновленной таблице может быть представлена информация типа той, что приведена в таблице 2.
Таблица 2. Таблица новых средств самообслуживания
Тип запроса Процент от Разрешено Разрешено Разрешено Разрешено
общего самообслуживанием группой группами группами
числа (уровень 0) начальной решения решения
запросов поддержки второго третьего
уровня уровня
Переустанов 30% 28% 2% 0% 0%
ка пароля
Как мне 18% 10% 7% 1% 0%
сделать?
Обновления 17% 15% 2% 0% 0%
прогресса
Вопросы по 13% 0% 10% 3% 0%
офисным
программам
Вопросы по 12% 0% 7% 5% 0%
персональн
ому
компьютеру
Вопросы по 5% 0% 1% 3% 1%
подключени
юк
сервисам
Другое 5% 0% 4% 1% 0%
Всего 100% 53% 33% 13% 1%
Таблица показывает, что средства самообслуживания теперь приняли от персонала по поддержке
большую часть запросов. Это дает для каждого яруса больше времени для сосредоточения на более
стимулирующих инцидентах, в отношении которых ранее была бы предпринята эскалация из-за нехватки
ресурсов. Обратите внимание на то, что процент запросов, разрешаемых группой начальной
поддержкой, уменьшился; это произошло потому, что группа начальной поддержки теперь имеет дело с
типами запросов, выполнение которых занимает больше времени, чем простые обновления прогресса
или переустановки пароля. Доступность времени для работы с более стимулирующими инцидентами
увеличивает для персонала удовлетворение от работы, а также уменьшает ежедневное обращение к
ресурсам более высокого уровня. Это позволяет персоналу концентрироваться на более стратегических
проблемах.
Некоторые типы запросов не удовлетворяют подходу самообслуживания: по причине своего характера,

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

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

самостоятельного использования, более трудно, то в большинстве случаев их содержание должно быть
нацелено на ответ на запросы типа "Как мне сделать?”, а не на решение проблем.
Методы контакта
Для того чтобы решение самообслуживания оказалось успешным, оно должно быть удобным для
использования, так чтобы пользователи чувствовали себя уверенными в его применении и полагали, что
оно предлагает им ценную альтернативу обращению в службу поддержки другими способами.
Независимо от того, как клиенты входят в среду самообслуживания, их вход должен быть подтвержден и
должны быть собраны метрики. Это действие включает в себя анализ трендов сделанных запросов
(успешных и неудачных), объемы установленных контактов, производительность среды
самообслуживания и изменения в методе контакта. Данная информация помогает идентифицировать
улучшения сервиса, а также демонстрирует эффективность сервиса и предоставляет информацию по
рентабельности инвестиций.
К основным получаемым данным относятся:
 Средства или режим входа.
 Дата и время входа.
 Идентификация пользователя.
 Вопросы, которые были заданы, и средства, к которым осуществлялся доступ.
В зависимости от среды могут потребоваться различные проверки авторизации для гарантии

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

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

использованием электронной почты, где предварительно определенные формы могут оказаться
подходящими для регистрации новых сервисных запросов или запросов на обновление прогресса. Этот
метод связи, вероятно, будет менее успешным для условия динамической помощи.
С переустановкой пароля может быть связан типичный запрос, имеющий большой объем, но
являющийся относительно простым. При наличии подготовленного решения самообслуживания,
аналитикам службы поддержки больше не нужно принимать участие в переустановке паролей.
Служащие, нуждающиеся в переустановке своих паролей, могут обратиться к средству
самообслуживания, ответить на несколько вопросов аутентификации и последовательно пройти через
контролируемый процесс для переустановки пароля. При смене пароля всегда рекомендуется
отправлять запрашивающему лицу информационное письмо по электронной почте в качестве
предосторожности относительно безопасности.
Новые запросы, сделанные через средства самообслуживания, должны быть зафиксированы в системе
службы поддержки и, как и для всех других запросов, им должен быть назначен номер инцидента для
обеспечения проверки и возможности последующего контроля прогресса. Такая связь со службой
поддержки особенно важна, когда самообслуживание позволяет запрашивающим лицам изменять
данные или пароли. Также это гарантирует, что запросы самообслуживания автоматически включаются в
анализ тренда. Определенный анализ этих данных позволяет улучшать сервис и выполнять
всесторонний анализ тренда.
Доступная информация зависит от стиля запроса. Если запрос основан на использовании компьютера
или интернета, то возможен доступ к различным источникам данных, включая следующие:
 Отслеживание инцидента и проблемы
 График будущих изменений.
 Примечания по поддержке поставщика.
 Обучающий материал.
 Обновления программного обеспечения.
 FAQ-информация.
 Сервисные каталоги.
 Прейскуранты.
Содержание, точность и своевременность информации должны тщательно поддерживаться. Должны
быть определены и согласованы четкие роли и обязанности, с тем чтобы не возникало никакой
двусмысленности. Информация, доступная через любую форму средства самообслуживания, должна
тщательно контролироваться и проверяться, для того чтобы гарантировать соответствие региональным
инструкциям. При этом особое внимание должно уделяться соглашениям по защите данных и
конфиденциальности.
Примечание, касающееся технологии. Использование технологии браузера для поддержки самообслуживание может увеличить
трафик в сети организации. Поэтому важно контролировать пропускную способность сети и ее компонентов. Технология
распознавания речи постоянно улучшается и, вероятно, будет все больше и больше использоваться в средствах
самообслуживания.
Доступ к справочной информации для самостоятельного использования

Если пользователь выбирает средства справки для самостоятельного использования, то ему необходимо
предоставить все возможности быстрого поиска ответа с минимальным замешательством. Если
пользователи получат неприятное впечатление, то маловероятно, что они будут использовать это
средство в будущем. Точно так же, как и любой другой продукт, пользователи должны "хотеть" его
прежде, чем они "приобретут" его.
Справочные системы обычно представляют собой базу данных с полезной информацией и
практическими данными. Пользователь предоставляет системе небольшое количество информации в
надежде на обнаружение "соответствия" своей проблеме. Эта информация может являться кодом
ошибки, сообщением об ошибке или описанием проблемы в свободном формате.
Если соответствие обнаружено, то информация обычно возвращается в том же самом формате, что и
первоначальный запрос. Возможно, однако, что пользователю может потребоваться напечатанный ответ.
Например, пользователь может захотеть получить копию FAQ, поэтому могут быть предусмотрены опции
ответа, которые включают автоматическую отправку электронной почты запрашивающему лицу.
После возвращения требуемой информации пользователь должен иметь возможность
усовершенствования запроса на основе текущего запроса, выбора дополнительных опций меню или же
инициации нового запроса. При разработке сценариев крайне важно выполнить полную проверку для
того, чтобы гарантировать, что пользователь никогда не остается без правильного или соответствующего
выбора, включая возможность возврата в любой точке к опции несамостоятельного получения справки.
Если у пользователя возникает желание сделать второй запрос, то процесс должен предоставить
пользователю возможность ввода другого запроса без необходимости повторной регистрации. Доступные
здесь опции должны тщательно оцениваться, поскольку может возникать необходимость принятия во
внимание проблем, касающихся безопасности. В то время как автоматизированные системы, как
правило, могут являться более управляемыми по той причине, что проверки правильности, касающиеся
безопасности, должны быть точно соответствующими, может оказаться предпочтительнее обрабатывать
запросы на расширенный доступ к приложениям посредством личного контакта.
Если пользователи не способны найти то, что они ищут, или же достигли конца доступных опций, то им
необходимо задать вопрос, желают ли они обратиться в службу поддержки. Контакт со службой
поддержки может представлять собой от простого оставления сообщения до полного запроса о
требуемой информации. Необходимо принять во внимание методы, посредством которых этот тип связи
контролируется и управляется, при этом обязательно нужно зарегистрировать, что этот запрос уже
являлся неудавшимся запросом самообслуживания, для того чтобы могли быть сделаны
усовершенствования среды самообслуживания, если это возможно.
Здесь требуются тесные рабочие связи с управлением инцидентами и проблемами, в особенности, если
средство самообслуживания нацелено на уменьшение числа простых, обычных обращений за
поддержкой, типа замены картриджа с тонером у принтера. Главной целью должно являться
обеспечение эффективного, ориентированного на клиента, средства запроса, которое дает возможность
обрабатывать обычно задаваемые вопросы без привлечения службы поддержки. Информация должна
постоянно проверяться для того, чтобы гарантировать, что она является точной и отражает текущее
состояние информации, касающейся поддержки (и сервиса).
Масштабируемость
Решение самообслуживания дает возможность очень гибкой реакции в организациях, когда имеет место
быстрый рост. Как правило, на принятие на работу и обучение персонала по поддержке в ответ на
увеличенные требования, например в результате слияния компаний, может уйти несколько недель.
Технология самообслуживания может удовлетворить большую часть требований для расширенного
сервиса без таких ограничений по времени, но для этого необходимо, чтобы используемая система была
способна к масштабированию для удовлетворения будущих требований.
Телефонный сервис с привлечением персонала является самым дорогим методом обеспечения
поддержки по причине требуемого персонала. Технология и оборудование также являются
дорогостоящими для установки и поддержки, но вероятно, потребность в использовании телефонного
сервиса будет существовать всегда для того, чтобы иметь дело с исключениями, в противоположность
стандартным запросам о поддержке. Для автоматизированных ответов метод первичной реакции требует
существенных начальных инвестиций, но при этом он обеспечивает быструю и осуществимую отдачу от
инвестиций. Современные оценки свидетельствуют о том, что стоимость надлежащим образом
разработанного, доступного через интернет самообслуживания может составлять менее 5 процентов от
эквивалентной обычной поддержки.
Большинство научных исследований показывают, что люди предпочитают ограниченное взаимодействие
(в смысле короткой продолжительности) с нечеловеческим интерфейсом, а большинство людей
предпочитает человеческий контакт. Однако, правильно адресованные, спроектированные и
реализуемые решения самообслуживания могут рассматриваться клиентами как выгодные, как имело
место с банкоматами (ATM). Ключевые причины успеха ATM - они удобны и просты, расширяют обычное
время сервиса, будучи доступными круглосуточно 7 дней в неделю, и часто обеспечивают более
быструю альтернативу ожиданию в очереди для оказания сервиса кассиром-человеком.
Организации, вводящие самообслуживание, должны принять во внимание этот пример и стремиться

обеспечивать решения, которые являются простыми и удобными, предлагают расширенный сервис и, по
крайней мере, столь же быстры, как ожидание контакта с человеком.
С продвижением организации к самообслуживанию появляется требование для сложных сервисных
процедур. Если должно быть принято самообслуживание, оно должно реализовываться надлежащим
образом с самого начала.
Регистрация
Все обнаруженные инциденты и сервисные запросы должны быть зарегистрированы с тем, чтобы их
можно было отслеживать для гарантии того, что ни один из них не потерян. Регистрация всех контактов
также предоставляет информацию, необходимую для инициализации действий и уменьшения
определенных типов запросов. Например, служба поддержки может обнаружить, что большой процент от
поступающих запросов приходит от людей, просто спрашивающих номер телефона. Исследование
может показать, что буклеты с внутренним телефонным справочником значительно устарели. После
этого может быть принято решение по публикации внутреннего телефонного справочника в интранете,
где его удобнее поддерживать. Эта инициатива не только уменьшает число телефонных звонков в
службу поддержки, но и увеличивает эффективность бизнеса, предлагая персоналу удобный доступ к
самой последней информации. Если запросы номеров телефонов не регистрировались, то масштаб
проблемы будет установить трудно и, возможно, проблема будет существовать неопределенно долго без
обращения на нее внимания.
Информация об инциденте должна регистрироваться в базе данных в инструменте службы поддержки.
Для каждого инцидента необходимо заполнить регистрационную запись инцидента и ввести следующую
информацию:
 Уникальный регистрационный номер.
 Дата и время регистрации.
 Идентификационные данные о лице, регистрирующем инцидент.
 Идентификационные данные о лице, сообщившем об инциденте (включая фамилию, отдел,
местоположение и контактную информацию).
 Метод контакта.
 Информация о затронутых конфигурационных единицах (CI).
 Описание симптомов и любых кодов ошибок.
 Действия, необходимые для преодоления затруднения.
Для сервисных запросов требуется существенная часть из представленной выше основной информации,
хотя описание симптомов должно быть заменено информацией о требуемом сервисе. Некоторые типы
сервисных запросов могут иметь свой собственный инструмент регистрации запроса, типа системы
управления изменениями для RFC, в то время как другие запросы, типа уникальных запросов пакетного
задания, с меньшей вероятностью будут иметь определенные системы хранения данных и поэтому
должны регистрироваться в виде регистрационных записей инцидента для отслеживания.
Идентификационные данные об инициаторе запроса (типа фамилии, отдела, местоположения и
контактной информации) должны проверяться относительно регистрационных записей, хранящихся в
базе данных клиентов, предпочтительно являющейся частью базы данных управления конфигурациями
(CMDB). Эта процедура позволяет хранить самую последнюю информацию в регистрационных записях,
содержащих данные о клиентах. В зависимости от среды, процедура может также включать вопросы о
коммерческой информации (например, номер контракта) и проверку, связанную с обеспечением
безопасности, для подтверждения подлинности.
Каждому инциденту или сервисному запросу необходимо присвоить уникальный регистрационный
идентификатор. Этот идентификатор должен предоставляться инициатору запроса. Идентификатор
может использоваться для быстрого определения местоположения надлежащей регистрационной
записи, если инициатор обращается снова, для того чтобы обновить регистрационную запись или
отследить прогресс выполнения проверки. Если инциденты произошли из-за события или
предупреждения, полученного от инструмента контроля или управления событиями, то в
регистрационную запись инцидента необходимо включить регистрационный номер события или
предупреждения.
Это позволяет персоналу, исследующему инцидент, идентифицировать и оценивать первоначальное

событие или предупреждение.
Служба поддержки отвечает за первоначальное получение всей необходимой информации от
инициатора запроса. Существуют случаи, когда могут потребоваться некоторые разъяснения или
дополнительная информация. В таких ситуациях служба поддержки должна обратиться к инициатору
запроса для получения информации.
На всем протяжении жизненного цикла инцидента регистрационная запись инцидента может пройти
через множество различных состояний, прежде чем она, наконец, будет закрыта. Для быстрой
идентификации текущего состояния инцидента используется поле состояния в регистрационной записи
инцидента.
Примеры категорий состояния:
 Новый. Инцидент был зарегистрирован, но все еще могут потребоваться разъяснения.
 Принятый. Инцидент был полностью зарегистрирован и подвергнут начальной поддержке.
 Назначенный. Инцидент был назначен в группу решения и теперь ожидает прогресса.
 Активный. Выполняется действие по разрешению инцидента.
 Ожидание сведений. Действие временно приостановилось, ожидая получения дополнительных
сведений.
 Запланированный. Дальнейшие действия не могут быть выполнены до запланированного времени.
 Приостановленный или находящийся в состоянии ожидания. Действие временно приостановлено в
ожидании события или времени.
 Разрешенный. Считается, что инцидент разрешен. Служба поддержки должна подтвердить
разрешение инцидента вместе с инициатором запроса до закрытия инцидента. Если инициатор
запроса не удовлетворен решением, то состояние инцидента переустанавливается в "назначенный"
или "активный".
 Закрытый. Инициатор запроса подтвердил, что инцидент разрешен и таким образом инцидент был
закрыт.
Важно, чтобы в регистрационной записи инцидента на всем протяжении жизненного цикла инцидента
содержалась самая последняя информация, с тем, чтобы весь персонал по поддержке мог видеть то, что
происходит в настоящее время, кто в настоящее время воздействует на инцидент, какие действия были
опробованы ранее, и что было обнаружено. Регистрационная запись с самой последней информацией
позволяет также любому персоналу, с которым осуществляется контакт, предоставлять инициатору
запроса обновление прогресса. Предоставление клиенту самых последних данных относительно
прогресса является важным фактором, который непосредственно влияет на удовлетворение клиента.
Обновления необходимо предоставлять на регулярной основе, в зависимости от приоритета инцидента.
Например, высокоприоритетные инциденты могут требовать ежечасного обновлений, в то время как для
среднеприоритетных инцидентов необходимо ежедневное обновление, а низкоприоритетные,
продолжительные инциденты требуют еженедельного обновления или даже обновления через каждые
две недели.
После процесса регистрации инциденты проходят через процесс классификации и начальной поддержки,
а сервисные запросы подвергаются процессу “обработки сервисных запросов”.
Примечание, касающееся технологии. Регистрационные записи инцидента должны регистрироваться и отслеживаться
инструментом службы поддержки, предпочтительно являющегося частью интегрированного набора инструментальных средств для
управления сервисом. Инструмент должен предоставлять для использования минимальные регистрационные записи по
инцидентам при возникновении новых инцидентов. Для обеспечения эффективности эти инструментальные средства должны
использовать базу данных клиентов, чтобы автоматически заполнять такие поля, как местоположение, отдел и контактная
информация после ввода инициатора запроса. Инструментальные средства могут также использовать интеграцию компьютерной
телефонии (CTI) для автоматического заполнения полей на основе телефонного номера входящего вызова. Даже если
применяются эти технологии, при регистрации инцидента необходимо сверять вместе с клиентом информацию типа контактного
телефонного номера и местоположения. Это позволит выполнять стандартную проверку данных, содержащихся в CMDB, и укажет
на области, которые могут потребовать дальнейшего исследования или проверки.
На приведенном ниже рисунке показан типичный шаблон регистрационной записи инцидента.
Рисунок 4. Типичный шаблон регистрационной записи инцидента

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

представляющего использовалось для регистрации идентификатора предупреждения.
Рисунок 5. Инцидент, сгенерированный предупреждением

На протяжении всего существования инцидента инструмент службы поддержки может автоматически
предупреждать аналитиков службы поддержки о том, когда должны быть выполнены обновления клиента
на основании приоритета инцидента и политики организации по обновлениям. Это предупреждение
может иметь различные формы:
 Пиктограмма часов или восклицательного знака рядом с инцидентом, когда рассматривается очередь
инцидентов.
 Инцидент, выделяемый определенным цветом (например, красным), когда рассматривается очередь.
 Всплывающее диалоговое окно.
 Сообщение или письмо, посылаемое по электронной почте, которые направляются на определенное
имя.
 Регулярный вывод сообщения (два - три раза в день).
Обработка сервисных запросов

На приведенном ниже рисунке показана блок-схема обработки сервисных запросов.
J
Identify and record type of service
request - Идентификация и тип
сервисного запроса
Record details relevant to service
Identify and record request type - Регистрация
Escalation or Yes Contact assigned
type of service информации, относящейся к типу
request chase required? team
Can initial support fulfill the request? -
No
Может ли группа начальной
поддержки удовлетворить запрос?
No - Нет
Record details Update customer Yes - Да
relevant to service according to policy
Monitor progress
for service request
Initial support fulfills the request -
request type
type Группа начальной поддержки
удовлетворяет запрос
Initiate interface
Yes appropriate to service request
type - Начальный интерфейс,
Initiate interface соответствующий сервисному
Can initial No No No
appropriate to Re-assign to Assigned to Believe
support fulfill the
service request appropriate team correct team? resolved? запросу
request?
type Pass details via
appropriate
Yes Yes
interface - Прохождение информации
Yes через соответствующий интерфейс
Monitor progress - Контроль прогресса
Pass details via
Tracking
Update details and Update customer Re-assign to appropriate team -
appropriate notify assigned and confirm
required? Повторное назначение
interface team resolution
соответствующей группе
No Tracking required? - Требуется
No
отслеживание?
Ensure details fully
Customer updated - Гарантия полного
Ensure details fully
updated
confirms обновления информации
Yes resolution?
Close service request - Закрытие
Escalation or chase required? -
Требуется эскалация или
отслеживание?
Initial support Close service
End
Assigned to
fulfills the request request correct team? - Назначен надлежащей
группе?
Update details and
notify assigned
team - Обновление информации и
оповещение назначенной группы
Customer confirms resolution? -
Клиент подтверждает разрешение?
Contact assigned team - Обращение в
назначенную группу
Update customer according to policy
for service request type - Обновление
клиента согласно политике для типа
Believe resolved? - Считается
разрешенным?
Update customer
and confirm resolution - Обновление
клиента и подтверждение
разрешения
End - Конец
Рисунок 6. Блок-схема обработки сервисных запросов
При обработке сервисного запроса первое действие заключается в идентификации и регистрации типа
обрабатываемого сервисного запроса. Как было сказано выше, некоторые типы сервисных запросов
могут иметь свой собственный инструмент для регистрации запроса, например, систему управления
изменениями для RFC.
Другие запросы, например уникальные запросы пакетного задания, с меньшей вероятностью будут
иметь определенные средства хранения данных и должны зарегистрироваться в виде регистрационных
записей инцидента для отслеживания.
В зависимости от типа сервисного запроса, от инициатора запроса требуется различная информация.
Например, информация, требуемая для планирования уникального пакетного задания, будет сильно
отличаться от информации, требуемой для запроса на приобретение. Служба поддержки должна
гарантировать регистрацию всей информации, требуемой для обработки необходимого сервисного
запроса.
Тип получаемых сервисных запросов существенно отличается в разных организациях. Для обработки
каждого сервисного запроса отличного типа в организации должна существовать процедура или
технологический процесс. Это будет гарантировать последовательную обработку всех запросов
определенного типа. Если начинают появляться запросы нового типа, то должна быть составлена,
согласована и распределена соответствующая процедура.
Большинство из этих процедур могут представлять собой простые интерфейсы, описывающие, как
подавать новый запрос в процесс, выполняемый другой SMF или частью бизнеса. Примерами такого
типа запросов могут быть запросы приобретения и RFC. Процедуры сервисных запросов должны
гарантировать регистрацию всей необходимой информации и ее последующую передачу
соответствующему процессу.
Другие сервисные запросы могут потребовать намного более сложных процедур или технологических
процессов. Примером является запрос на установку системы для нового служащего. Процесс может
включать в себя создание новых учетных записей: сетевой и электронной почты, получение служащим
полисов безопасности для подписания, предоставление доступа к приложениям, организацию учебных
занятий по ознакомлению с ИТ и вопросами безопасности, обновление внутреннего телефонного
справочника, обновление CMDB, предоставление и конфигурирование нового оборудования, например,
портативного компьютера и телефона.
Примечание, касающееся технологии. Для таких более сложных запросов полезно использовать систему управления
технологическими процессами, с тем, чтобы разбить запрос и отслеживать индивидуальные рабочие действия, одни из которых
могут происходить параллельно, в то время как другие будут находиться в состоянии ожидания, так как зависят от других действий.
Инструментальные средства управления технологическими процессами могут помочь в разработке процедур технологического
процесса посредством создания блок-схем, которые описывают действия и зависимости, а также в создании группы, требуемой для
выполнения каждого действия и зависимости.
На приведенном ниже рисунке показан пример блок-схемы процедуры технологического процесса.

Business Unit Service Desk Financial Team Desktop Team Подписи к рисунку:
Business Unit - Подразделение организации
Computer software Computer software install request - Запрос на
install request установку программного обеспечения
Obtain authorization - Получение разрешения
Record details, Update service desk - Обновление службы
advise of request поддержки
ID and costs Service Desk - Служба поддержки
Record details, advise of request ID and costs -
Obtain
Регистрация информации, уведомление об
authorization идентификаторе запроса и расходах
Confirm license availability - Подтверждение
наличия лицензии
Confirm license Issue procurement request if required - Выдача
availability запроса на приобретение, если требуется
No - Нет
Raise standard change and assign to desktop team
Yes
Issue procurement
- Стандартный запрос на изменение и
request if required назначение компьютерной группе
Confirm customer satisfaction - Подтверждение
удовлетворения заказчика
Process
No Close service request - Закрытие сервисного
procurement
request запроса
End - Конец
Raise standard
Financial Team - Финансовая группа
Install and test Yes - Да
change and assign
software
to desktop team Process procurement request - Обработка запроса
на приобретение
Update charging information - Обновление
информации о расходах
Update CMDB
Desktop Team - Компьютерная группа
Install and test software - Установка и
тестирование программного обеспечения
Update CMDB - Обновление CMDB
Close standard
change Close standard change - Закрытие стандартного
запроса на изменение
Confirm customer Update charging

satisfaction information
Update service
desk
Close service
request
End
Рисунок 7. Пример блок-схемы процедуры технологического процесса

Некоторые сервисные запросы могут полностью обрабатываться группой начальной поддержки (часто
службой поддержки) без необходимости передачи запроса другому процессу или другой группе.
Примером такого типа запроса является запрос на регистрацию лица в учебном курсе, проводимом ИТ
отделом. Процедура может позволить службе поддержки проверить доступность и выполнить
регистрацию без необходимости обращения в учебный отдел.
В тех случаях, когда группа начальной поддержки полностью обрабатывает сервисный запрос, она
должна выполнить необходимые действия, проинформировать инициатора о том, что запрос был
выполнен, подтвердить, что инициатор удовлетворен решением по запросу, и затем закрыть запрос,
удостоверившись, что регистрационная запись была полностью обновлена.
В тех случаях, когда запрос необходимо передать другому процессу или группе, группа начальной
поддержки отвечает за получение соответствующей информации, необходимой для обработки запроса
для данного специфического типа сервиса, и ее передачу другому процессу или другой группе.
В подавляющем большинстве случаев (даже притом, что служба поддержки передала запрос), служба
поддержки все еще действует в качестве контактной точки, если инициатор запроса желает запросить
информацию о прогрессе или же внести поправки в информацию по запросу. В таких ситуациях служба
поддержки должна назначить запрос соответствующей группе и затем проследить и проконтролировать
прогресс сервисного запроса, играя роль интерфейса между инициатором и другим процессом. Если
прогресс по запросу, как кажется, замедляется, то служба поддержки подтверждает текущую ситуацию,
контактируя с причастной группой и, в случае необходимости, расширяет действия по инциденту для
гарантии удовлетворения целей сервиса. Если запрос должен быть переназначен другой группе, то
служба поддержки снова будет выполнять это действие.
После того, как запрос считается решенным, служба поддержки должна связаться с инициатором и
подтвердить, что он удовлетворен решением, после чего закрыть запрос, убедившись в обновлении
регистрационной записи. Для некоторых запросов может быть приемлемым отправка инициатору письма
по электронной почте с информацией о том, что запрос был решен, и обеспечение контакта в службе
поддержки, если инициатор не удовлетворен решением. Письмо, направленное по электронной почте,
должно сообщить инициатору о том, что решение будет считаться принятым, а запрос закрытым, если
служба поддержки не получит ответ в пределах определенного периода времени (например, трех
недель). В зависимости от инструмента службы поддержки, возможно автоматизирование отправки
инициатору стандартного письма по электронной почте после ввода состояния решенного запроса и
автоматическое закрытие запроса, если в течение заданного периода времени не вводится обновление.
В тех случаях, когда отслеживание группой поддержки не требуется (обычно по причине того, что запрос
был немедленно выполнен, а инициатор уведомлен), служба поддержки будет гарантировать обновление
регистрационной записи запроса и затем закроет запрос.
Примечание, касающееся технологии. Некоторые типы сервисных запросов имеют определенные инструментальные средства, в
которых они регистрируются и отслеживаются. Эти инструментальные средства могут быть решениями внутренней разработки или
сторонними продуктами. Они могут существовать отдельно от инструментов службы поддержки или же быть интегрированы в них.
На приведенном ниже рисунке показан пример такого инструмента, используемого для регистрации и отслеживания запросов на
изменение.
На приведенном ниже рисунке показан пример инструмента по созданию запроса на изменение (RFC).
Рисунок 8. Пример специального инструмента по созданию RFC

Типы сервисных запросов, для которых нет определенного инструмента, должны регистрироваться и
отслеживаться с использованием регистрационных записей инцидента. На приведенном ниже рисунке
показан пример запроса пакетного задания, выполненный в этом формате.
Рисунок 9. Уникальный запрос пакетного задания, зарегистрированный в регистрационной записи

инцидента
Классификация и начальная поддержка

На приведенном ниже рисунке показана блок-схема классификации и начальной поддержки.
A
CIs correct in CMDB? - Верны ли
конфигурационные единицы в
CMDB?
No - Нет
Raise exception Yes - Да
CIs correct in No report for
CMDB? Configuration
Determine category - Определение
Management категории
Yes
Link incident to known error - Связь
инцидента с известной ошибкой
Implement known workaround -
Внедрение известного обходного
Determine Identify services пути
category and SLAs affected Resolved? - Разрешен?
Inform initator of Unlink incident from known error -
Problem
problem reference
and status
Management Выделение инцидента из известной
ошибки
No Raise exception report for
Link incident to
known error
Determine priority Configuration Management -
Implement
Documented Yes
documented
Составление отчета об исключении
workaround? для управления конфигурациями
workaround
Identify services and SLAs affected -
Идентификация затронутых сервисов
и SLA
Provide initial Determine priority - Определение
Implement known
workaround support Link incident to приоритета
problem record
Matches known Provide initial support - Обеспечение
Yes
error? начальной поддержки
Matches known error? - Соответствует
No известной ошибке?
Matches known problem? -
Yes
Resolved? Соответствует известной проблеме?
Matches previous incident? -
Matches known Yes Соответствует предыдущему
No
problem? инциденту?
Can initial support resolve? - Может ли
No Unlink incident начальная поддержка разрешить
No
from problem Resolved? инцидент?
Unlink incident record Investigation and Diagnosis -
from known error
Yes
Matches Review previous
previous incident
Review previous incident resolution
incident? Yes resolution details details - Обзор предыдущей
информации по разрешению
No инцидента
Suspect new problem? -
No Suspect new Yes Notify duty Подозревается новая проблема?
problem? problem manager Inform initiator of problem reference
and status - Уведомление инициатора
запроса о связи с проблемой и о ее
состоянии
Documented workaround? -
Can initial Yes Provide resolution Задокументированный обходной
support
resolve?
advice путь?
Link incident to problem record - Связь
No инцидента с регистрационной
записью проблемы
C B C
Unlink incident from problem record -
Выделение инцидента из
регистрационной записи проблемы
Investigation and
Closure Diagnosis
Closure Notify duty problem manager -
Уведомление дежурного менеджера
по проблемам
Provide resolution advice -
Предоставление консультации по
разрешению инцидента
Problem Management - Управление
проблемами
Implement documented
workaround - Внедрение
задокументированного обходного
пути
Рисунок 10. Блок-схема классификации и начальной поддержки
Классификация
Инциденты должны классифицироваться таким образом, чтобы их можно было обрабатывать
максимально эффективно с соответствующим разрешением. Классификация - это процесс
категоризации инцидента и присваивания ему приоритета. Классификация является очень важной
первой стадией в управлении инцидентами, поскольку она определяет последующее предпринимаемое
действие. Классификация используется для:
 Определения сервиса или оборудования, к которым имеет отношение инцидент.
 Ассоциирования любого соответствующего соглашения об уровне сервиса (SLA), соглашения уровня
эксплуатации (OLA) или подкрепляющего контракта (UC).
 Идентификации соответствующей группы решения.
 Определения приоритета инцидента.
 Идентификации оценки рабочей нагрузки.
 Действия в качестве соответствующего критерия для идентификации предыдущих инцидентов,
известных ошибок или известных проблем.
Большинство инцидентов могут возникать регулярно, например, переустановки пароля, поэтому их
классификация будет известна. Другие инциденты потребуют исследования прежде, чем они могут быть
классифицированы, и для достижения этого могут использоваться различные методы.
 Аналитики службы поддержки могут использовать диагностические сценарии, которые:
 Контролируют полноту собираемой информации.
 Используют логику и проводят опрос по контролируемым параметрам.
 Контролируют терминологию, используемую для соответствия ожиданиям группы поддержки.
 Ссылка на регистрационные записи CMDB:
 Подтверждает технические данные по конфигурации клиента.
 Может идентифицировать предыдущие инциденты, касающиеся оборудования.
 Идентифицирует использование неправомочного программного обеспечения.
 Идентифицирует любые требуемые обновления.
Проверка по CMDB
Если существуют различия, идентифицируемые при проверке по CMDB, то важно составить для
управления конфигурациями отчет об исключении для корректирующего действия, которое будет
предпринято. Факт исключения мог бы указывать на неправомочное изменение или поломку в процессе
изменения. Пример отчета об исключении может иметь следующий вид:
Дата: 01 апреля 2002
Номер регистрационной записи CI: Software1000
Зарегистрированные данные: Excel 2000 версия 8.5
Указанные данные: Excel 2000 версия 7
Примечание, касающееся технологии. Важно, чтобы служба поддержки имела прямой доступ к CMDB, в идеале - посредством
использования интегрированного набора инструментальных средств службы поддержки. Интеграция дает возможность
автоматически заполнять ключевые поля регистрационной записи инцидента из CMDB, когда в регистрационной записи инцидента
зарегистрированы только фамилия клиента или его телефонный номер. Это позволяет запрашивать проверку правильности
данных CMDB и идентификацию любых исключений, не говоря уже о предоставлении возможности службе поддержки
осуществлять контроль и предпринимать активные меры на очень ранней стадии при инциденте (это может повысить
эффективность службы поддержки и увеличить доверие клиента).
В приведенном ниже примере выполняется поиск номера каталога (CI), но конфигурационные единицы могут также выбираться по
имени, владельцу, представляющему, отделу или местоположению.
Рисунок 11. Пример экрана поиска CMDB

Преимущества интеграции с CMDB состоят в том, что она оптимизирует скорость доступа к данным, гарантирует непротиворечивое
использование терминологии и подхода, и, что вероятно наиболее важно, гарантирует единственный источник информации,
обладающий доверием. Использование нескольких или неинтегрированных инструментальных средств вносит определенную долю
риска и неэффективности в ключевую область сервиса.
Диагностические сценарии
Диагностические сценарии, или сценарии поиска и устранения неисправностей, предоставляют помощь
инициатору запроса при разрешении инцидентов и, как правило, используют структурированный процесс
вопрос-ответ-действие. Сценарии могут использоваться для обработки обычных типов инцидентов или, в
случае необходимости, для выполнения первоначальной сортировки и сбора информации до
регистрации запроса и направления его группе второй линии.
Сценарии могут также использоваться для запроса оператора на получение дополнительной
определенной для ошибки информации. Например, для случая “Невозможность печати” можно
автоматически запросить об очереди печати и именах серверов, которые затем регистрируются как часть
информации запроса. Пример сценария “Невозможность печати”:
1. Пользователь регистрирует запрос в службе поддержки. Могут указываться симптомы
“Невозможность печати”, “Сообщения об ошибках принтера" или “Плохое качество печати”.
2. Подтвердите пользователя:
a. Фамилия.
b. Местоположение.
c. Добавочный номер телефона.
3. Запросите информацию о принтере:
a. Название.
b. Местоположение.
c. Инвентарный номер.
d. Тип (сетевой или локальный).
e. Число людей, затронутых ошибкой.
4. Проверьте регистрационную запись CMDB, для того чтобы подтвердить указанную информацию и
составить отчет об исключении, если это требуется.
5. Назначьте категорию “проблемы печати”.
6. Выберите подкатегорию, указывающую тип выполняемой печати (по сети или локально).
7. Идентифицируйте воздействие, безотлагательность, SLA и затронутые сервисы. На основании этой

информации определите приоритет.
8. Сопоставьте с известными ошибками, существующими проблемами и предыдущими подобными
инцидентами.
9. При отсутствии связанных регистрационных записей необходимо задать ряд вопросов с
предлагаемыми действиями в зависимости от ответов на вопросы:
a. Может ли клиент выполнять печать на другом принтере?
b. Может ли клиент выполнять печать с другого приложения?
c. Может ли кто-либо выполнять печать на принтере?
10. Если выполнять печать на принтере никто не может, то:
a. Спросите о любых сообщениях об ошибках.
b. Проверьте, включен ли принтер.
c. Проверьте, имеются ли соединения с электропитанием и сетевые подключения.
d. Проверьте любые коды ошибок фактического принтера.
e. Попробуйте выключить принтер и затем включить его снова.
f. Проверьте состояние очереди печати и попробуйте остановить и запустить планировщик печати.
g. Если инцидент не может быть разрешен, то назначьте обращение в группу, ответственную за
печать и вывод.
11. Если клиент может распечатывать на принтере из других приложений, то:
a. Спросите о любых сообщения об ошибках.
b. Попробуйте закрыть и перезапустить приложение.
c. Проверьте, какой принтер определен по умолчанию для данного приложения.
d. Повторно выберите устройство печати в приложении.
e. Если инцидент не может быть разрешен, то назначьте обращение в группу, ответственную за
приложение.
12. Если клиент не может распечатывать на любом принтере, а другие могут, то:
a. Спросите о любых сообщения об ошибках.
b. Проверьте, какие принтеры установлены для пользователя.
c. Проверьте, подключен ли персональный компьютер к сети.
d. Проверьте состояние очереди печати.
e. Если инцидент не может быть решен, то назначьте обращение в группу, ответственную за
компьютерную поддержку.
Диагностические сценарии не только пассивны. Они могут также использоваться как в качестве
“экспертных инструментальных средств”, когда ответ на вопрос вызывает действие, так, чтобы
процедуры и другие документы автоматически отображались в диагностическом процессе. Например,
если сценарий предполагает, что установки конфигурации пользователя являются неправильными, то из
CMDB можно вывести рисунок с надлежащими установками. Аналогично типу запроса "Как мне сделать
это?”, из онлайнового руководства можно отобразить соответствующую документацию.
Сценарий может запустить другое приложение операционной системы Microsoft Windows®, например,
сценарий “сетевые ошибки” может автоматически запустить набор инструментальных средств по
диагностике сети.
Использование для этих активных сценариев фактически является безграничным: они облегчают
разрешение запроса не-экспертным персоналом, а также уменьшают число обратных вызовов для
получения дополнительной информации.
Категории и приоритеты
Используемые категории классификации отличаются в зависимости от организации, но они всегда
должны согласовываться между ИТ организацией и бизнес-сообществом. Между этими группами может
существовать конфликт, поскольку последняя ИТ организация носит, прежде всего, технический
характер, в то время как бизнес-сообщество таковым, возможно, не является.
Если категории классификации слишком сильно основаны на технической стороне, то аналитики
технической поддержки должны уметь переводить симптомы, описанные бизнес-пользователями, в
технические эквиваленты. При таких обстоятельствах существует большая вероятность возникновения
ошибок и трудностей во время приведения в соответствие, а также могут возникать трудности в переходе
к среде самообслуживания, если бизнес-сообщество не может легко интерпретировать информацию.
Тщательный выбор категорий поможет точному направлению группам решения, если группа начальной
поддержки не может решить инцидент, а согласованность классификации инцидентов облегчает
назначение средств самообслуживания.
Ниже приводятся примеры категорий:
Аппаратные средства
 Процессор
 Память
 Жесткий диск
 DVD ROM
 Монитор
 Клавиатура
Программное обеспечение
 Электронная таблица
 Текстовый процессор
 Офисное приложение
Независимо от выбранных категорий, наиболее важным аспектом является то, что в начальную стадию
разработки должны быть привлечены представители как персонала по поддержке, так и бизнес-
пользователи, поскольку изменять категории станет труднее с увеличением объема связанных с ними
данных.
Примечание, касающееся технологии. При выборе инструмента поддержки необходимо принять во внимание разработку
категорий классификации, поскольку в этом отношении одни инструментальные средства являются менее гибкими, чем другие.
Если используется неадекватный инструмент анализа, то ключевая информация может быть отнесена к полям текста в свободном
формате, который препятствует анализу тренда и развитию самообслуживания. Это особенно важно при отсутствии на месте
CMDB, поэтому весь анализ будет регистрироваться в регистрационной записи инцидента.
Служба поддержки должна определить, какие службы и SLA затронуты сообщенным инцидентом,
поскольку это позволит установить соответствующий приоритет. CMDB должна использоваться в
качестве источника информации при определении затронутых сервисов и SLA.
Установление приоритетов является важным аспектом управления инцидентами, поскольку оно
суммирует характеристики инцидента и определяет полный подход к его разрешению.
Приоритет инцидента обычно определяется отношениями между его воздействием и
безотлагательностью, по которым, в свою очередь, определяется намеченное время разрешения
инцидента. Например, инцидент с высокими степенями воздействия и безотлагательности получит
высокий приоритет, в то время как инцидент с высокой степенью воздействия и низкой
безотлагательностью получит более низкий приоритет, как и инцидент с низким воздействием и высокой
безотлагательностью. Неправильная классификация приоритета не позволит эффективно выполнять
управление инцидентами.
Приоритет инцидента должен основываться на следующем:
 Затронутые или потенциально затронутые сервисы и SLA. Соглашения об уровне сервиса
формализуют отношения между сервис-провайдером и клиентской базой. Для обеспечения
правильной классификации инциденты должны быть связаны с надлежащим SLA. Это позволит
быстро и точно устанавливать безотлагательность инцидента и его воздействия на бизнес, поскольку
SLA идентифицирует затронутый сервис, пользователей этого сервиса и последствия прерывания
сервиса. Оно также регистрирует ожидаемые интервалы времени для возврата в нормальный режим
и договоренности о просьбах планирования непрерывности бизнеса. Любые связанные OLA и UC
также должны приниматься во внимание.
 Любой относительный приоритет, связанный с назначенной категорией. Категории могут
использоваться для определения относительных приоритетов с целью оказания персоналу помощи в
определении приоритета, который необходимо присвоить каждому инциденту. Относительные
приоритеты должны действовать в качестве отправной точки, определяя фактический приоритет,
который будет присвоен инциденту.
Таблица 3. Категории и приоритеты инцидентов

Главная категория Подкатегория Относительный приоритет
Программное Электронная таблица 1
обеспечение
Программное Текстовый процессор 1
Программное Офисное приложение 2
Однако такое представление не делает отличий между областями бизнеса, поэтому для всех
проблем, связанных с электронными таблицами, будет назначен, и возможно неправильно, один и
тот же приоритет.
В приведенной ниже таблице показано альтернативное представление, которое соответствует

классификации более приближенной к областям бизнеса.
Таблица 4. Области бизнеса и приоритеты
Главная категория Подкатегория Относительный приоритет
Бухгалтерский учет Электронная 1
таблица
Текстовый 1
процессор
Офисное 2
приложение
Производство Электронная 3
таблица
процессор
Офисное 2
Распределение Электронная 3
таблица
процессор
Офисное 3
 Воздействие на бизнес и критичность. Воздействие инцидента обычно определяется его влиянием

на бизнес организации и часто носит название “воздействие на бизнес”. Определение воздействия,
таким образом, может эффективно предприниматься только в согласии с бизнес-сообществом во
время разработки SLA. К серьезно влияющим факторам относятся:
 Число затронутых пользователей.
 Степень снижения бизнеса.
 Этап в цикле бизнеса, на котором происходит инцидент.
 Информация о воздействии, полученная во время разработки SLA, может использоваться для
связывания индикационных приоритетов для определенных категорий инцидентов. Эти
приоритетные коды должны действовать в качестве основания для определения приоритета, но
их необходимо изменять по мере необходимости, в зависимости от определенного воздействия
индивидуального инцидента.
 Безотлагательность запроса. Имеет отношение к скорости, с которой должен быть разрешен
инцидент согласно его воздействию. Вероятно, что инцидент с высоким воздействием также будет
являться срочным, но это не всегда происходит на деле. Инцидент может обладать высоким
воздействием на организацию, но низкой безотлагательностью, если организации не требуется,
чтобы приложение было доступным в течение шести месяцев. С другой стороны, инцидент может
иметь высокую безотлагательность, но низкое воздействие, например, в отношении проблем с
персональным компьютером секретаря одного из директоров. Одновременно с этим,
безотлагательность может измениться в течение долгого времени: например, в 1996 г. у проблемы
2000 года было очень высокое воздействие, но невысокая безотлагательность, в 1997 г. у нее было
все еще высокое воздействие и проблема становилось более срочной, в 1998 г. безотлагательность
увеличилась снова, и так далее.
В приведенной ниже таблице показан пример системы кодировки приоритета на основании воздействия
и безотлагательности.
Таблица 5. Система кодировки приоритета на основании воздействия и безотлагательности
Воздействие
Высокое Среднее Низкое
Высокая
Безотлагательность Средняя
Низкая
Запланированное время разрешения

Запланированное время разрешения инцидента - это время, к которому ИТ организация должна решить
инцидент, для того чтобы остаться в пределах согласованных уровней сервиса. Различные приоритеты
инцидентов будут иметь разное запланированное время разрешения.
Назначенный инциденту приоритет может использоваться для определения запланированного времени
разрешения, как это показано в приведенной ниже таблице.
Таблица 6. Пример кодов приоритета и запланированного времени разрешения
Код приоритета Описание Запланированное время
разрешения
0 Серьезный инцидент ---
1 Критический 1 час
2 Высокий 8 часов
3 Средний 24 часа
4 Низкий 48 часов
5 Планирование По графику
Запланированное время разрешения инцидента должно быть тщательно продумано, с тем, чтобы оно
соответствовало согласованным адресатам сервиса. На основе запланированного времени разрешения
может быть задано время автоматической эскалации. Для серьезных инцидентов запланированное
время разрешения не указано, поскольку эти инциденты по своему характеру лежат за рамками
"обычных" инцидентов, поэтому время разрешения инцидента для них существенно изменятся. За
эскалацию во время серьезных инцидентов отвечает менеджер по серьезным инцидентам.
Начальная поддержка
Начальная поддержка - это процесс, с помощью которого служба поддержки может разрешать инцидент
к удовлетворению клиента независимо от любых других областей поддержки. Служба поддержки может
достигать такого результата, сопоставляя сообщаемый ей инцидент с известной ошибкой и предоставляя
клиенту информацию об известном решении или обходном пути. В этом случае регистрационная запись
инцидента должна быть связана с регистрационной записью известной ошибки, с тем, чтобы все
затронутые пользователи могли быть идентифицированы, когда будет доступно постоянное решение, а
также для помощи при обзоре приоритета для решения известных ошибок.
С другой стороны, аналитик службы поддержки может обеспечивать информацию о решении из личного
опыта или специальных знаний, полученных из определенной учебной программы. Если ни один из этих
вариантов не возможен, то аналитик службы поддержки, возможно, должен обратиться к базам знаний
для сопоставления симптомов, описанных клиентом. Если какой-либо источник предлагает решение, то
должна быть обновлена база данных известных ошибок, а в регистрационной записи инцидента должна
быть зарегистрирована подробная информация по решению. Можно также проинформировать
менеджера по конфигурации, с тем, чтобы также была обновлена CMDB.
Известная ошибка - это регистрационная запись предварительно сообщенного и разрешенного
инцидента. Будет иметь место если не полное решение, то, по крайней мере, доступный обходной
способ. Если существует база данных известных ошибок, то она должна быть доступна для всех
аналитиков службы поддержки и должна тщательно поддерживаться. В ряде случаев обходное решение
может примяться временно, в то время как разрабатывается полное решение или же ожидается релиз
новой версии программного обеспечения. Это может занять время, и ошибка может затронуть многих
пользователей. Используя информацию, зарегистрированную в SLA, служба поддержки может
идентифицировать бизнес-пользователей, подвергаемых опасности, и принять превентивные меры,
выдавая предупреждение о потенциальной проблеме и сообщая о существовании обхода.
Примечание, касающееся технологии. Базы знаний могут разрабатываться внутри организации, см. пример на приведенном
ниже рисунке, с возможным использованием базы данных или специальных инструментальных средств CRM, или же
обеспечиваться поставщиками, используя технологию браузера. Для внутренней разработки необходимо включить определение
обязательных полей, использование ключевых слов и методологию поиска. Необходимо установить единственную точку
монопольного использования для управления содержанием. Также должно быть включено отслеживание посетителей, для того
чтобы можно было проверять использование базы. По мере развития базы она будет использоваться чаще, поэтому важно
отслеживать степень и возможности использования, так как это предоставит полезную информацию для анализа тренда.
Рисунок 13. Пример TechNet, базы знаний, доступной от Microsoft

Если имеется доверие к данным, обеспечиваемым поставщиком, то могли бы существовать ограничения по этим критериям, хотя
влиять на содержание было бы возможно.
Информация по группе пользователей должна обрабатываться с вниманием, поскольку она, вероятно, будет включать в себя
вклады, важные для различных версий релизов, и имеется мало контроля над терминологией, структурой или содержанием.
Информация по группе пользователей часто основана на методологии доски объявлений или дискуссионной группы, но может
также являться хорошим источником текущего опыта. Ее использование лучше всего ограничивается группами поддержки и
решения, а не включением в среду самообслуживания.
Использование обходного пути является вполне приемлемым способом при возникновении инцидента.
Обходной путь может представлять собой временный ответ на время разработки более постоянного
решения, или же он сам может стать постоянным решением.
Если обходной путь разрешает инцидент, то аналитик службы поддержки может перейти к закрытию
инцидента. Если это действие не привело к успеху в данном случае, но было успешно раньше, то
инцидент был неправильно сопоставлен, и он должен быть отделен и возвращен группе начальной
поддержки для сопоставления с существующими проблемами, как следующая стадия в процессе
управления инцидентами.
Если инцидент можно сопоставить с существующей проблемой, то выполняется процесс, аналогичный
тому, который используется для известной ошибки. Если обнаруживается соответствие, то инцидент
должен быть связан с регистрационной записью проблемы, и затем необходимо внедрить обходной путь
(если он существует), подтвердить решение и предпринять действие по закрытию. Если разрешение не
достигнуто, то инцидент должен быть отделен и возвращен для дальнейшего исследования.
Если инцидент был связан с существующей проблемой, но управление проблемами все еще работает
над идентификацией обходного пути, то инициатора необходимо проинформировать относительно
ссылки регистрационной записи проблемы и ее состояния. Управление проблемами должно продолжить
работу над проблемой и проинформировать управление инцидентами, когда идентифицируются
обходной путь или решение.
Инциденты, которые не соответствуют известной ошибке или регистрационным записям существующих
проблем, могут сравниваться с предыдущими инцидентами. Регистрационные записи прежних
инцидентов часто являются хорошим источником информации, предоставляя данные о том, как
подобные инциденты были разрешены в прошлом. Здесь главной становится потребность полного
обновления регистрационных записей инцидентов с четким кратким описанием симптомов и
предпринятых действий.
Если инцидент соответствует одному или более предыдущим инцидентам, то это может являться
индикацией того, что в их основе существует проблема. Если возникают сомнения, то об этом
необходимо сообщить управлению проблемами. В этом случае управление проблемами должно решить,
нужно ли создавать новую регистрационную запись проблемы или нет.
Примечание, касающееся технологии. Согласование инцидентов, проблем и ошибок наиболее эффективно можно выполнить,
если используется интегрированный инструмент. Даже если реализован интегрированный инструмент, все преимущества могут
быть потеряны, если этот инструмент не применяется последовательно во всей организации поддержки. Если инциденты,
проблемы и известные ошибки регистрируются и обновляются контролируемым и непротиворечивым способом, то результирующие
данные позволят осуществить намного более продуктивное согласование и регистрацию. Жизненно важно поддерживать
монопольное использование инструмента и осуществлять контроль для гарантии того, что все стороны, обращающиеся к
инструменту, используют его непротиворечивым образом, как определено в задокументированных процедурах. В идеальном
варианте это непротиворечивое и контролируемое использование инструмента должно присутствовать в самом начале его
внедрения, поскольку зачастую очень трудно переустанавливать политику использования после того, как группы начнут применять
инструмент для своих собственных индивидуальных стандартов.
Если организация использует локальные службы поддержки, то согласование часто может выполняться только в локальном
масштабе, ограничивая потенциал для совместного использования накопленного знания, создаваемого в инструментальных
средствах. Глобальные организации будут испытывать большие трудности в достижении интеграции, так как затраты, язык и
инфраструктура могут делать использование единственного инструмента трудным или даже невозможным. Кроме того, некоторые
бизнес-процессы могут концентрироваться в определенных странах/регионах и находиться в ограниченном общем интересе, делая
интеграцию менее ценной.
Персонал группы начальной поддержки мог бы решать инциденты при использовании своего
собственного неявного знания, созданного в течение продолжительного времени. Организации могут
увеличивать уровень неявного знания, доступного в службе поддержки, предоставляя бизнес-персоналу
возможность перехода в организацию поддержки, принося свой опыт бизнес-процессов и приложений
вместе с ними. Формальное обучение также может использоваться для увеличения доли инцидентов,
разрешаемых при первом контакте. Однако здесь проблемой является время, а также знание. Часто
персонал группы начальной поддержки может чувствовать, что он обладает знаниями для дальнейшего
исследования конкретного инцидента, но инцидент нужно передать группе решения из-за давления
поступающих запросов. Принятие решения относительно того, сколько времени должно быть потрачено
на начальную поддержку инцидента, является ключевым вопросом для службы поддержки и имеет
последствия на всей цепочке поддержки.
По возможности персонал должен стараться разрешать инциденты в течение начальной поддержки,
обеспечивая рекомендации по решению, пока это не будет влиять на ответ и обработку поступающих
запросов. “Первый запрос предопределяет успех” - ценная метрика и ключевой компонент
удовлетворения клиента и снижения затрат. Когда решение, как предполагается, достигнуто, инциденты
должны двигаться к процессу закрытия.
В тех случаях, когда группа начальной поддержки не смогла разрешить инцидент, он должен быть
назначен группе решения на основании классификации инцидента. В зависимости от типа инцидента,
группа решения может являться внутренней группой или внешним поставщиком. В любом случае служба
поддержки сохраняет монопольное владение инцидентом и ответственна за контроль и отслеживание
прогресса инцидента.
Начальная группа поддержки должна иметь доступ к деталям любых соглашений о поддержке
предприятия, включая законтрактованные уровни сервиса, детали контракта, время сервиса и
ожидаемое время реакции. Когда инциденты расширяются до внешних поставщиков жизненно важно,
чтобы персонал поддержки, контактирующий с поставщиком, имел всю необходимую информацию. Для
каждого внешнего контракта должен составляться и поддерживаться перечень данных, требуемых при
регистрации запроса. Эта информация обычно включает в себя номер контракта или соглашения,
идентификатор сайта, детали о затронутых продуктах (модель и серийные номера аппаратных средств,
версии программного обеспечения и уровни исправления), а также рекомендацию по уровню
необходимого для поставщика приоритета. Некоторые контракты разрешают регистрировать при
указанных контактах только новые запросы. Если дело обстоит таким образом, то должен быть
современным и доступным перечень указанных контактов.
Примечание, касающееся технологии. Интерфейсы для передачи инцидентов внешним поставщикам являются более
интегрированными, чем обращение к поставщику по телефону или факсу. Два наиболее общих сценария являются следующими:
 Внешние поставщики имеют свою собственную очередь в пределах инструмента поддержки организации и имеют доступ для
обновления регистрационных записей инцидента и принятия по ним решения. Поставщики ответственны за контроль своей
очереди и прогресс любых назначенных ей инцидентов.
 Инструмент поддержки организации имеет интерфейсную связь с инструментом внешнего поставщика. Когда очереди
поставщика назначается инцидент, в инструменте поставщика регистрируется соответствующая регистрационная запись
инцидента. В зависимости от уровня интеграции, первоначальная регистрационная запись инцидента автоматически
обновляется, когда обновляется регистрационная запись поставщика (или через регулярные интервалы времени), или же
организация имеет доступ для чтения в средство самообслуживания поставщика для того, чтобы получать обновления
прогресса.
Ключевые факторы успешного достижения этого уровня интеграции являются следующими:
 Интерфейс для использования персоналом поддержки должен быть максимально автоматизированным и не громоздким.
 Интерфейс должен иметь надлежащие уровни доступности и надежности.
 Интерфейс должен предоставлять обеим сторонам соответствующую безопасность.
 Должны быть четко задокументированы и поняты обязанности по контролю и прогрессу инцидентов.
 Запланированное время разрешения и приоритеты должны быть надлежащим образом определены между организациями и
четко поняты.
 Должны быть поняты обязанности по поддержке интерфейса, включая осведомленность о влиянии изменений в одном
инструменте поддержки на процессы и инструмент другой организации.
На рисунке 14 показана блок-схема процесса исследования и диагностики.
Re-allocate to appropriate team -
Переназначение соответствующей
группе
B Allocate support I Yes - Да
staff Functional escalation required? -
Требуется эскалация
функциональных возможностей?
Re-allocate to
No - Нет
appropriate team Assess incident Malicious Intent suspected? -
details
Ожидается злоумышленное
Yes
намерение?
Allocate support staff - Назначение
Functional CMDB персонала поддержки
No Assess incident details - Оценка
escalation Gather facts
required? информации об инциденте
Gather facts - Сбор фактов
Matches known error? -
Yes Соответствует известной ошибке?
Matches Link incident to Matches existing problem? -
known error? known error Соответствует существующей
проблеме?
No
Investigation and
diagnostic data search - Поиск
Matches
existing
Yes Is there a Yes Link incident to данных исследования и
workaround? problem record диагностики
problem?
Preserve evidence and notify
No No
security team - Сохранение
доказательства и уведомление
Investigation and No Problem Yes Problem
группы безопасности
diagnostic data management
search accept match?
management Management escalation required? -
Требуется эскалация управления?
Perform management
Malicious intent No escalation - Выполнение эскалации
suspected?
управления
Link incident to known error -
Preserve evidence
Yes
and notify security
Workaround or Yes Can it be No Связывание инцидента с
solution identified? tested?
team известной ошибкой
Is there a workaround? -
No Yes Существует обходной путь?
Problem management
Management Test workaround accept match? - Принимает ли
No No
escalation Major incident? or solution управление проблемами
required? соответствие?
Yes Workaround or solution identified? -
Yes
Идентифицированы ли обходной
путь или решение?
Perform Major incident? - Серьезный
No Tested Yes
management
successfully?
инцидент?
escalation
Major incident process - Процесс
серьезного инцидента
G E Link incident to problem record -
H F
Связывание инцидента с
Major incident Resolution регистрационной записью
process and recovery
проблемы
Problem management - Управление
Can it be tested? - Может ли быть
выполнена проверка?
Test workaround or solution -
Проверка обходного пути или
решения
Tested successfully? - Проверка
прошла успешно?
Resolution and recovery -
Разрешение и восстановление
Рисунок 14. Блок-схема процесса исследования и диагностики
Если группа начальной поддержки не смогла разрешить инцидент, то он переходит к процессу

диагностики и исследования. Этот процесс инициализируется, когда инцидент назначается группе
решения. Группы решения могут состоять из широкого диапазона ИТ групп, включая персонал по
поддержке и разработке, другие SMF, другие единицы внутри организации, привлеченных внешних
провайдеров, партнеров и других третьих лиц.
Число и размер групп решения зависит от организации. Как правило, организации поддержки
структурируются с использованием одного из следующих подходов:
 Ярусная структура, включающая группы поддержки первой, второй, третьей и энной линий. Часто
энная линия будет являться либо внешним поставщиком, либо внутренней группой разработки, в
зависимости от поддерживаемых приложений и уровня внутренних экспертных знаний.
 Структура, основанная на платформе и приложении, состоящая из определенных для платформы
групп поддержки, часто с использованием дополнительных групп, сфокусированных на приложениях
передачи сообщений и базы данных.
 Комбинация вышеупомянутых структур. Наиболее общим вариантом является использование группы
поддержки первой линии (в службе поддержки), которая поддерживается платформенной структурой
групп поддержки, состоящих из персонала с различным уровнем навыка, который поддерживается
внешними поставщиками, обеспечивающими поддержку энной линии для своих собственных
продуктов или сложных/серьезных инцидентов. Некоторые службы поддержки управляют структурой
отдела по операциям с клиентами/отдела обработки документации, в действительности создавая два
яруса поддержки внутри непосредственно самой службы поддержки.
Структура должна удовлетворять потребности индивидуальной организации, но следует помнить о том,
что увеличенная сложность приносит увеличенные затраты. Чем выше число индивидуальных групп
поддержки, тем труднее совместно использовать информацию и обеспечивать дублирование навыков, и
наиболее вероятно, что потребуется арбитраж для принятия решения по ответственности в случае
возникновения сложных инцидентов. В тех случаях, когда ответственность за разрешение инцидента
вызывает споры, служба поддержки должна обсудить проблему с вовлеченными сторонами, с тем, чтобы
понять, может ли быть достигнуто соглашение. Если простое соглашение не может быть достигнуто, то
управление проблемами будет ответственно за арбитраж.
Независимо от числа и сложности групп решения, структура должна быть четко задокументирована, для
того чтобы весь персонал понял, какие категории запросов должны назначаться каждой группе и каковы
пути эскалации, если она требуется. Отсутствие четко определенной структуры поддержки приводит к
увеличению расходов, неудовлетворенности и времени решения, снижая удовлетворение клиента.
Инструмент поддержки должен иметь очередь для каждой группы решения. Группа решения
ответственна за контролирование своей очереди и отслеживание прогресса инцидентов, назначенных ей.
Персонал поддержки может регистрироваться в инструменте поддержки и просматривать регулярно
обновляемый список инцидентов в пределах своей очереди.
Примечание, касающееся технологии. Доступно широкое разнообразие технологий для оказания помощи группам решения в их
управлении очередями. Они включают отображение состояния очереди в пределах офисной зоны группы решения с
использованием больших мониторов или специально разработанных электронных дисплейных панелей. Большие электронные
дисплейные панели могут конфигурироваться для отображения ключевых выводов из множества различных систем, включая
системы службы поддержки и системы управления событиями. На приведенном ниже рисунке показан пример очереди группы
решения.
Рисунок 15. Пример очереди группы решения

Персонал поддержки во многих случаях мобилен и нуждается в просмотре своей очереди из различных местоположений. Это
может быть достигнуто путем предоставления возможности персоналу поддержки соединяться с инструментом поддержки через
интернет-браузер с любого персонального компьютера внутри организации. Беспроводные технологии позволяют персоналу
поддержки иметь карманные компьютеры (PDA), которые могут синхронизироваться с системой поддержки для отображения
очереди с самой последней информацией, а также обновления существующих инцидентов. Должны быть приняты меры,
направленные на обеспечение безопасности этих систем.
Если персонал не может постоянно контролировать очередь, то снова может использоваться технология для предоставления им
уведомлений о том, когда очереди назначаются новые инциденты. Уведомления могут иметь форму всплывающих полей,
направляемых по электронной почте писем или мобильных текстовых сообщений.
Когда инцидент помещается в очередь группы решения, он должен быть назначен члену группы для
прогресса. Член группы отвечает за поддержку регистрационной записи инцидента, обновляя ее
последней информацией о состоянии, предпринятых действиях и прогрессе.
Регистрационные записи инцидента должны обновляться со следующей информацией для каждого
предпринятого действия:
 Название/идентификатор группы поддержки и лица, регистрирующего действия.
 Тип действия (переназначение, диагностика, восстановление, разрешение, закрытие и т.д.).
 Дата/время действия.
 Описание и результат действия.
Если на каком-либо этапе предполагается, что инцидент должен быть назначен другой группе решения,
то текущая группа решения должна переназначить инцидент обратно службе поддержки, которая затем
выполнит новое назначение. Это снижает вероятность непрерывного перекидывания запросов между
группами решения и позволяет службе поддержки более эффективно координировать процесс
управления инцидентами, определяя ситуации, когда требуется арбитраж.
Группы решения не могут закрывать инциденты самостоятельно. Если предполагается, что инцидент
разрешен, то его состояние должно быть установлено как разрешенное, и он должен быть назначен
группе поддержки. Перед закрытием аналитики поддержки должны подтвердить, что инициатор
удовлетворен решением.
После того как инцидент был назначен члену персонала группы решения, этот член группы решения
должен оценить информацию об инциденте до этого момента и собрать любые необходимые факты.
Примечание, касающееся технологии. База данных управления конфигурациями (CMDB) может являться важным инструментом
для обнаружения фактов во время исследования инцидента. База данных может использоваться для просмотра информации по
затронутым конфигурационным единицам (CI), например, версий загруженного в них программного обеспечения и хронологии этих
элементов конфигурации, проверки деталей любых гарантий или контрактов на поддержку, которые охватывают конфигурационные
единицы, подтверждая их местоположения.
Ниже показан пример регистрационной записи основной конфигурационной единицы.

Рисунок 16. Пример регистрационной записи основной конфигурационной единицы

На приведенном ниже рисунке показан пример регистрационной записи хронологии основной

конфигурационной единицы.
Рисунок 17. Пример регистрационной записи хронологии конфигурационной единицы

CMDB может также использоваться для идентификации конфигурационных единиц, связанных с затронутыми конфигурационными
единицами, для того, чтобы могли быть приняты меры, направленные на минимизирование воздействия инцидента посредством
изменения маршрута или переконфигурирования соответствующих конфигурационных единиц.
Другое использование CMDB заключается в идентификации других конфигурационных единиц, которые идентичны ошибочным
конфигурационным единицам, с тем, чтобы они могли использоваться для сравнения, выделяя отличия, вызывающие инцидент.
Как только персонал поддержки закончит сбор фактов, он должен проверить, указывает ли собранная
информация на то, что имеется появление известной ошибки. Информация по известной ошибке может
быть получена из различных источников, например, из корпоративных баз данных известных ошибок,
поддерживаемых управлением проблемами, из баз данных известных ошибок, предоставляемых
поставщиком, а также с интернет-сайтов, включая сайты поставщиков и соответствующих сетевых
телеконференций.
Примечание, касающееся технологии. Изобилие информации, доступной в предоставляемых поставщиком базах знаний делает
их жизненно важным инструментом для групп поддержки. Эти базы знаний доступны либо на вэбсайтах поставщиков, либо в виде
CD/DVD пакетов, которые часто можно приобрести вместе с лицензией на использование системы или индивидуальной лицензией.
Базы знаний содержат разнообразную информацию, включая известные ошибки, исправления, обновленные драйверы,
официальные документы, часто задаваемые вопросы (FAQ) и технические статьи.
Большое преимущество предоставляемого поставщиком знания состоит в том, что организации могут извлекать выгоду из
диагностической информации и информации по решению, когда инциденты возникают в других местах, часто приводя к намного
более быстрому устранению проблемы, если организация сталкивается с такими же или подобными инцидентами.
Поставщики также часто предоставляют большой объем справочной информации в своих продуктах в форме онлайновой
справочной документации и с использованием средств поиска. В некоторых случаях из ресурсных наборов, специально созданных
для продукта, можно получить дополнительную документацию и полезные утилиты.
Некоторые инструментальные средства управления системами также содержат базы знаний на тот случай, если будет
сгенерировано предупреждение, чтобы можно было бы обеспечить дополнительную диагностику и/или рекомендацию по решению.
Как это происходит для всех предоставляемых поставщиками баз знаний, на месте должны присутствовать механизмы,
гарантирующие регулярное получение обновлений и их применение, с тем, чтобы предоставляемая информация относительно
известных обходов исправлений оставалась на современном уровне.
Организации могут также создавать свои собственные корпоративные базы знаний. Эти корпоративные базы знаний могут
содержать в себе любую информацию, являющуюся уместной для того, чтобы персонал мог поддерживать ИТ инфраструктуру
организации. Принимая во внимание, что предоставляемые поставщиком базы знаний могут содержать большое количество
материала, который не является значимой для конкретной организации, может также быть создана корпоративная база знаний,
содержащая информацию, относящуюся к ее деятельности. Корпоративные базы знаний могут создаваться при использовании баз
данных или же сторонних инструментальных средств, разработанных для этой цели.
Если инцидент действительно соответствует существующей известной ошибке, то регистрационная
запись инцидента должна быть обновлена, с тем, чтобы связать его с регистрационной записью
известной ошибки. В зависимости от используемых инструментальных средств, это действие может
включить в себя соединение двух регистрационных записей в интегрированный набор инструментальных
средств. Однако при использовании отдельных инструментальных средств это может означать только
включение идентификатора известной ошибки (и всего, что позволяет свободное пространство для
дополнительной информации) в регистрационную запись инцидента и, если возможно, обновление

номера инцидента в регистрационной записи известной ошибки. Затем необходимо подвергнуть
инцидент процессу разрешения и восстановления, если могут быть применены обходной путь или
решение, идентифицируемые в регистрационной записи известной ошибки.
Инциденты, которые нельзя сопоставить с известными ошибками, должны пройти проверку на
существующие проблемы. Существующие проблемы - это проблемы, которые в настоящее время
известны управлению проблемами, но для которых необходимо идентифицировать решение по
первопричине. Существующая проблема может иметь идентифицированный обходной путь, а может и не
иметь его. Если инцидент соответствует существующей проблеме и имеется идентифицированный
обходной путь, то инцидент должен быть объединен с регистрационной записью проблемы (посредством
установления связи или перекрестной ссылки) и подвергнут процессу разрешения и восстановления для
приложения обходного пути.
Если предполагается, что инцидент соответствует существующей проблеме, но никакого обходного пути
идентифицировано не было, то регистрационную запись инцидента нужно передать управлению
проблемами. Управление проблемами отвечает за подтверждение того, действительно ли соответствует
инцидент проблеме, и оно должно либо принять инцидент (назначив ему уместную регистрационную
запись проблемы), либо отклонить его и направить обратно управлению инцидентами, если
обнаруживается, что соответствие является неправильным. Управление проблемами продолжает
работать над существующими проблемами и отвечает за информирование управления инцидентами об
обнаружении обходных путей или решений для проблем, с которыми связаны регистрационные записи
инцидента. После информирования управления инцидентами оно будет отвечать за разрешение,
восстановление и закрытие любых неразрешенных инцидентов.
Процесс сопоставления инцидентов и известных ошибок и проблем продолжается в течение
исследования и диагностики инцидента. По мере получения дополнительных диагностических
доказательств, например новых идентификаторов события или кодов ошибок, эта новая информация
должна быть направлена в соответствующий процесс. В процессе исследования могут также
анализироваться предыдущие регистрационные записи инцидента для определения того, как подобные
инциденты разрешались в прошлом.
Управление инцидентами обычно фокусируется на как можно более быстром восстановлении
нормального сервиса. Исключениями являются случаи, когда подозревается злоумышленное намерение.
В таких случаях персонал поддержки должен работать в тесном контакте с персоналом безопасности в
соответствии с политикой и процедурами группы безопасности для обработки инцидентов безопасности.
Часто очень важно гарантировать сохранение всех доступных доказательств для использования в ходе
юридических или дисциплинарных разбирательств. Группа безопасности должна оказывать помощь в
сборе и хранении доказательств, выдавая инструкции о том, какие доказательства будут приниматься и
какая контекстная информацию (идентификаторы компьютеров, отместки даты и времени) должна быть
включена. В зависимости от воздействия инцидента должно быть принято решение, следует ли
разрешать инцидент в реальном времени, при этом, возможно, перезаписывая важные доказательства,
или же перейти к договоренностям непрерывности резервирования, пока не будет уверенности в том, что
все доступные доказательства были собраны.
Фаза исследования и диагностики включает в себя: первое - получение персоналом поддержки четкой
картины того, каким образом затрагивается нормальный сервис, второе - идентификацию того, что
вызывает это воздействие, и, наконец, третье - определение, как такую ситуацию можно обойти или
разрешить.
При первоначальном информировании об инциденте может иметь место очень ограниченная
информация по характеру, степени и общем воздействии проблемы. Регистрационная запись инцидента
должна включать в себя максимально возможное количество данных, полученных от инициатора, но
зачастую эта информация будет ограничиваться точкой зрения и степенью знаний человека.
Для того чтобы персонал поддержки смог разрешить инцидент, он должен сначала узнать как можно
больше об инциденте. Необходимо сосредоточиться на обнаружении точных сообщений об ошибках или
идентификаторов события, подтверждении любых предпринятых действий, приведших к инциденту, а
также подтверждении зоны влияния инцидента, например, затрагивает ли он только отдельного
пользователя, который сообщил об инциденте, или же всех пользователей сервиса. Персонал поддержки
должен выполнить сбор доказательств, просматривая файлы регистрации и журналы регистрации
событий и, если это выполнимо, попробовать воспроизвести проблему, с тем чтобы он смог испытать ее
на собственном опыте.
Самым простым вариантом было бы реальное посещение пользователей для того, чтобы
проанализировать то, как меняется проблема в зависимости от географического местоположения.
Поскольку посещение даже местных пользователей занимает время, цель должна состоять в том, чтобы
исправить удаленно как можно больше инцидентов. Как было сказано выше, цель управления
инцидентами заключается в как можно более быстром восстановлении нормального сервиса, поэтому
если это может быть сделано удаленно без необходимости затрачивания времени на поездку, то это
соответствует цели. Однако, если на какой-нибудь стадии в течение жизненного цикла инцидента
становится видно, что посещение, несмотря на время поездки, приведет к более быстрому разрешению,
то этот вариант также необходимо принять во внимание. В рассмотрение следует включить оправдание
затрат, связанных с посещением, относительно влияния увеличения времени разрешения инцидента. В
то время как политика должна минимизировать превышение времени, проведенного в пути, организации
должны гарантировать, что они не исключают оправданные посещения и таким образом не продлевают
инциденты.
Необходимо рассмотреть структуру организации поддержки и то, должен ли персонал поддержки
располагаться в центре или же быть распределен по различным местам. Как правило, распределение
увеличивает сложность и, следовательно, затраты организации поддержки. Однако часто структура
должна разрабатываться для того, чтобы удовлетворять согласованным уровням сервиса. Например,
если согласованный уровень сервиса требует локального ответа в течение одного часа, а данное
местоположение удалено от других точек поддержки, то требуется определенная форма местного
присутствия. В зависимости от вовлеченных затрат, использования безопасности, простоты найма и
уровня требуемой поддержки, организации могут рассматривать использование аутсорсинга для
локальной поддержки в протяженных местоположениях.
Примечание, касающееся технологии. Для оказания помощи в минимизировании потребности локальных посещений
доступными являются удаленные инструментальные средства поддержки. Эти инструментальные средства включают в себя
утилиты, позволяющие удаленно просматривать файлы регистрации и запускать административные утилиты на удаленных
компьютерах. Всегда должны приниматься меры, направленные на гарантию безопасности этих систем от неправомочного
использования.
Может иметь место повышение функциональных возможностей при использовании удаленных инструментальных средств,
позволяющих персоналу поддержки просматривать то, что пользователь испытывает на удаленной системе и, в случае
необходимости, переключать на себя систему для исследования инцидента и применять любые действия, связанные с его
разрешением. Эти инструментальные средства являются также необходимыми, когда персонал поддержки ответственен за
системы, расположенные в удаленных или автоматических машинных залах.
После того, как персонал поддержки сможет понять инцидент, он должен идентифицировать, почему этот
инцидент происходит и как можно разрешить проблему или использовать для нее обходной путь.
Управление инцидентами интересуется непосредственной причиной инцидента, а не возможными
основными первопричинами, которыми интересуется управление проблемами. Например, управление
инцидентами может идентифицировать причину инцидента как "заблокированный" или "зависший"
файловый сервер и для решения данной проблемы требуется перезагрузка сервера. Вместе с этим
управление проблемами должно определить, была ли эта проблема изолированным инцидентом или же
в его основе существует проблема, которая вызывает блокировку этого, и возможно других, файловых
серверов.
Несмотря на всесторонние процессы управления изменениями и релизами, вероятно, что некоторые
инциденты будут все еще возникать из-за внесенных изменений. Если происходит инцидент и никакую
непосредственную причину идентифицировать невозможно, то персонал поддержки должен
проконтролировать, какие изменения произошли недавно, для того чтобы проверить, были ли они
уместными. Формальное управление изменениями не только стремится воспрепятствовать
возникновению дальнейших инцидентов из-за изменений, но также гарантирует, что, когда такие
инциденты действительно происходят, будет доступна полная информация о сделанных изменениях.
При диагностировании сложных инцидентов персонал поддержки должен изучить все доступные
доказательства и затем разбить инцидент на более простые модули.
Для гарантии организованного и логического подхода полезно представить проблему в графическом
виде, нарисовав ее на бумаге, белой доске или же с помощью программного инструмента. Это может
быть блок-схема, поток данных или сетевая диаграмма. Подходящее графическое представление может
помочь идентифицировать вовлеченные компоненты и интерфейсы, а, следовательно, и потенциальные
проблемные точки. В этот момент может потребоваться мозговой штурм для идентификации всех
возможных проблемных точек. Если существует несколько потенциальных проблемных точек, то может
быть применено взвешивание, которое оценивает воспринимаемую вероятность каждой проблемной
точки, позволяя определить непосредственную причину инцидента и избавиться от проверки каждой
проблемной точки. Взвешивание может позволить расположить по приоритетам исследовательские
действия.
Для того чтобы персонал поддержки мог воспроизводить инциденты и тестировать обходные пути вдали
от реальной среды, он должен иметь доступ к испытательным средам, отражающим реальную среду (или
ее часть) настолько близко, насколько это возможно. Несмотря на то, что редко можно точно
воспроизвести размер и рабочую нагрузку реальной среды, значительные выгоды можно получить от
масштабированной испытательной среды. Обоснование стоимости испытательных сред может
представлять собой трудную задачу. Однако эти инвестиции должны быть сделаны для того, чтобы
предотвратить постоянный цикл, в котором производятся изменения (используя процессы управления
изменениями и релизами) для разрешения одного инцидента, приводящие к другому инциденту,

поскольку до изменения в реальной среде было выполнено неадекватное тестирование.
На приведенном ниже рисунке показан пример жизненного цикла изменения инцидента.
Start
Start - Начало
Incident Management - Управление инцидентами
Incident - Инцидент
Problem Management - Управление проблемами
Incident
Incident Problem - Проблема
Management Change Management and Release Management -
Управление изменениями и управление релизами
Change - Изменение
Release - Релиз
Problem Break out of the vicious circle by conducting thorough testing
Problem
Management Inadequate testing of changes, resulting in incident closure without causing new
of changes results incidents - Выход из порочного круга посредством
in vicious circle, выполнения всестороннего тестирования изменений,
generating further приводя к закрытию инцидента, не вызывая при этом
new incidents новых инцидентов
Change Inadequate testing of changes results in vicious circle,
Change
generating further new incidents - Неадекватное
Management
тестирование изменений приводит к порочному кругу,
and
генерируя дальнейшие новые инциденты
Release End - Конец
Management
Release
Break out of the vicious circle

by conducting thorough
testing of changes,
resulting in incident closure
without causing new incidents
End
Рисунок 18. Пример жизненного цикла изменения инцидента

Для содействия диагностике инцидентов группы поддержки могут использовать такие методики как
наставничество и собрания сортировки.
Процесс наставничества может проводиться в отношении младшего персонала поддержки более
опытными людьми, возможно из более высоких ярусов структуры поддержки. Более опытный персонал
может давать советы и указания о том, как следует исследовать определенный инцидент и как его
разрешать после диагностирования.
Эта методика приносит пользу, увеличивая знания и опыт младшего персонала, а также снижая число
инцидентов, которые должны быть назначены более опытный персоналу, таким образом предоставляя
им больше времени на обработку более сложных и стратегических проблем. Необходимо приветствовать
такой процесс совместного использования знаний. Однако все еще необходимо осуществлять эскалацию
инцидентов, если персонал чувствует, что это необходимо, для того чтобы удовлетворить сервисные
цели.
Членами группы могут проводиться регулярные неформальные собрания сортировки. Во время этих
занятий могут обсуждаться детали любых нерешенных инцидентов, с тем, чтобы другие члены группы
могли рекомендовать опробование каких-либо вещей, а также предложить преимущества своего
собственного опыта. И снова, это есть форма совместного использования знания, которая применяет
неявное знание членов группы инфраструктуры и среды. Если группы различаются географически, то
для этих собраний могут использоваться средства теле- или видеоконференций.
Иногда применяемая другая форма совместного использования знаний, которая заключается в
использовании для задания вопросов почтовых списков, относящихся к конкретной теме. Если у
человека имеется вопрос относительно определенной темы, то он может послать его по электронной
почте в соответствующий список распределения, для того чтобы кто-либо из списка предложил совет или
решение. Например, может существовать один почтовый список, включающий в себя весь персонал со
знанием базы данных, второй - для продуктов передачи сообщений, и третий - для основных знаний по
операционной системе.
В зависимости от исследуемого инцидента и опыта внутри организации, может оказаться полезным
заняться поиском знаний за пределами организации, отправляя вопрос на соответствующий форум в
интернете. Доступно большое число форумов и они часто нацеливаются на определенную платформу
или приложение, что позволяет обсуждать затруднения и общее знание совместно с персоналом
поддержки из других организаций, которые работают с такими же продуктами.
Примечание, касающееся технологии. Некоторые инструментальные средства группы поддержки позволяют прикреплять к
регистрационным записям инцидентов электронное доказательство типа файлов регистрации, регистрационных записей событий
или журналов заданий. Персонал, работающий с инцидентом, может открывать приложенные документы непосредственно из
регистрационной записи инцидента, вместо того, чтобы искать их.
После того, как возможный обходной путь или решение были идентифицированы, их необходимо
протестировать вдали от реальной среды, если это возможно. В прошлом слишком часто возникала
такая ситуация, когда изменения, реализуемые для решения одного инцидента, приводили к множеству
других инцидентов. Во избежание этого персонал поддержки должен тестировать предложенные обходы
или решения настолько всесторонне, насколько это возможно, и затем передавать любые необходимые
изменения конфигурационной единицы (CI) для реализации через процессы управления изменениями и
управления релизами.
Если тестирование демонстрирует, что предложенное решение работать не будет, то должны
продолжиться процессы исследования и диагностики, которые должны осуществляться до тех пор, пока
не будет идентифицировано успешное решение. Если тестирование прошло успешно, то решение может
быть подвергнуто процессу разрешения и восстановления.
В любое время в течение исследования и диагностики инцидента может возникнуть необходимость
объявления серьезного инцидента. Серьезные инциденты - это инциденты с высокой или потенциально
высокой степенью воздействия, требующие реакции, которая лежит за рамками, установленными для
"обычных" инцидентов. Как правило, такие инциденты требуют координации по всей компании,
эскалации управления, мобилизации дополнительных ресурсов и усиленных связей. Несмотря на то, что
инцидент может подозреваться как "серьезный" при первоначальном его обнаружении, персонал
поддержки должен подтвердить его рамки и степень воздействия прежде, чем будет инициализирована
процедура по серьезным инцидентам. Инциденты, подозреваемые как "серьезные", должны
регистрироваться с высоким приоритетом и уведомлением соответствующей группы решения так, чтобы
она могла как можно быстрее подтвердить рамки и степень воздействия.
Организации должны документировать критерии, в соответствии с которыми они идентифицируют
серьезные инциденты. Например, банк, занимающийся обслуживанием мелкой клиентуры, может
считать, что любой инцидент, воздействующий на нормальный сервис в 20 или более филиалах, должен
классифицироваться как серьезный инцидент. Подозреваемые серьезные инциденты должны
помечаться для дежурного менеджера инцидентов, который отвечает за принятие решения о
необходимости инициализации процедуры по серьезным инцидентам на основании доказательств и
после консультации с соответствующими сторонами.
Во время серьезных инцидентов процесс исследования, диагностики, разрешения, восстановления и
закрытия все еще продолжается. Однако процедура по главным инцидентам следит за этими действиями
и обеспечивает повышенные координацию, ресурсы и связь.
Если инцидент не является серьезным инцидентом, то он может все еще нуждаться в некоторой форме
эскалации. Эскалация - это механизм, помогающий разрешать инцидент в пределах согласованных
целей сервиса. Существуют две формы эскалации: эскалация управления, или иерархическая
эскалация, и эскалация функциональных возможностей.
Эскалация управления, или иерархическая эскалация, может выполняться на любой стадии в течение
жизненного цикла инцидента, если предполагается, что инцидент не будет решен удовлетворительно или
вовремя. Персонал службы поддержки и групп решения отвечает за расширение инцидента до
управления, как только становится вероятным неудовлетворительное или несвоевременное решение.
Эскалация должна инициализироваться как можно скорее, с тем, чтобы у управления оставалось время
на оценку ситуации и осуществление корректирующего действия. Корректирующие действия могут
использоваться для назначения дополнительных ресурсов или поиска специализированных навыков
откуда-либо, как внутри организации, так и вне ее.
На протяжении жизненного цикла инцидента также должна рассматриваться потребность в эскалации
функциональных возможностей. Эскалация функциональных возможностей касается передачи
инцидента другому персоналу поддержки, который лучше оснащен для продвижения инцидента и
достижения разрешения в пределах согласованных целей сервиса. В ярусной структуре поддержки это
действие может включать в себя передачу инцидента от группы второй линии группе третьей линии; а в
структуре на основе платформы это может являться назначением более опытному персоналу в пределах
группы или же назначения другой группе, поскольку категория инцидента отличается от категории,
предполагаемой вначале. Эскалация функциональных возможностей также включает в себя
рассмотрение инцидента с внешними ресурсами поддержки и поставщиками.
Все действия по эскалации должны регистрироваться в регистрационной записи инцидента.
Примечание, касающееся технологии. Инструментальные средства группы поддержки позволяют осуществлять автоматическую
эскалацию на основе затраченного или оставшегося времени, пока не будут достигнуты цели сервиса. Время эскалации должно
быть тщательно спланировано, так, чтобы не были превышены цели уровня сервиса. Нижним ярусам поддержки необходимо
предоставить разумное время для разрешения инцидентов, с тем, чтобы уменьшить воздействие на более дорогостоящие ресурсы
“верхнего яруса”.
Организации могут принимать решение по внедрению автоматического управления и эскалации функциональных возможностей,
основываясь на факторах времени. Автоматические действия во многих случаях могут просто включать в себя уведомление
соответствующих лиц о том, что для определенного инцидента должна осуществляться эскалация, с тем, чтобы они могли
предпринять соответствующие действия. Инструментальные средства могут остановить “часы эскалации”, если инцидент
находится в определенном состоянии, например, “ожидает доказательства”, если персонал поддержки запросил дополнительную
информацию и ожидает контакта для ее предоставления, или же "разрешен", когда инцидент считается разрешенным, но
аналитики поддержки ожидают подтверждения этого от инициатора перед закрытием запроса. В таких случаях, когда прогресс
зависит от инициатора, “часы эскалации” могут быть остановлены. Однако менеджер по инцидентам должен следить за тем, что
персонал поддержки не “использует систему”, запрашивая дополнительные "трудные для получения" доказательства, с тем, чтобы
увеличить время, в течении которого он должен исследовать проблему.
На приведенном ниже рисунке показан пример регистрационной записи инцидента со значениями

времени эскалации и запланированного разрешения.
Рисунок 19. Пример регистрационной записи инцидента со значениями времени эскалации и

запланированного разрешения
Процедура по серьезным инцидентам

На приведенном ниже рисунке показана блок-схема процедуры по серьезным инцидентам.
G
New major incident? - Новый серьезный инцидент?
Existing major incident - Существующий серьезный
инцидент?
Yes - Да
New major Yes Flag to duty No - Нет
incident? Incident Manager
Restoration team review due? - Необходима
проверка группой восстановления?
No
Existing Perform management review - Выполнение
major incident
управлением проверки
Assess suspected Perform management escalation - Выполнение
Restoration Yes major incident
team review
Restoration team управлением эскалации
review meeting
due? Issue agreed progress statements - Составление
согласованных заявлений по прогрессу
No
Duty Incident
Management team review due? - Необходима
Is this a major No Manager to проверка группой управления?
Perform Yes
incident monitor situation at Management escalation? - Эскалация управления?
Management regular intervals
management
team review
Review and Update communications plan and agree progress
review update restoration
due?
plan
Yes statements - Обновление плана связей и
согласование заявлений по прогрессу
No
H Change allocated resources? - Изменение
Issue initial
notifications назначенных ресурсов?
Perform
Investigation and Investigation and Diagnosis - Исследование и
Management Diagnosis
management
escalation? Issue restoration диагностика
escalation
Yes team progress Restoration team review meeting - Обзорное
report
собрание группы восстановления
No Assign major Confirm facts and Review and update restoration
incident manager build team
plan - Обзор и обновление плана восстановления
Update Issue restoration team progress
communications report - Составление отчета о прогрессе группы
plan and agree
progress восстановления
statements Agree
Hold planning Allocate /direct required resources - Распределение
communication
plan
meeting требуемых ресурсов и управление ими
Flag to duty Incident Manager - Уведомление
дежурного менеджера по инцидентам
Issue agreed Change Yes Allocate / direct Assess suspected major incident - Оценка
progress allocated
statements resources?
required resources сомнительного серьезного инцидента
Agree restoration
plan Is this a major incident - Это серьезный инцидент?
No Issue initial notifications - Выдача начальных
уведомлений
I Assign major incident manager - Назначение
менеджера по серьезным инцидентам
Investigation and Agree communication plan - Согласование плана
Diagnosis связей
Agree restoration plan - Согласование плана
восстановления
Duty Incident Manager to monitor situation at regular
intervals - Менеджер по инцидентам должен
регулярно контролировать ситуацию
Investigation and Diagnosis - Исследование и
диагностика
Confirm facts and build team - Подтверждение
фактов и создание группы
Hold planning meeting - Проведение собрания по
планированию
Рисунок 20. Блок-схема процедуры по серьезным инцидентам
Процедура по серьезным инцидентам предлагает дополнительно координацию по всей компании,
ресурсы, вовлечение управления и связь в тех случаях, когда воздействие или потенциальное
воздействие инцидента требует реакции, выходящей за рамки той, которая обеспечивается процедурами
управления обычными инцидентами.
Решение о том, гарантирует ли инцидент инициирование процедуры по серьезным инцидентам,

принимает менеджер по инциденту, хотя до принятия решения должна быть проведена консультация со
всеми вовлеченными сторонами. Возможно, необходимо обратиться к персоналу поддержки, сервисным
менеджерам, бизнес-менеджерам, партнерам и другим ИТ менеджерам, вовлеченным в инцидент, для
гарантии того, что менеджер инцидента полностью понимает ситуацию и потенциальные последствия.
Организации следует задокументировать ряд критериев, играющих роль рекомендации для вынесения
решения о том, что должно считаться главным инцидентом. Критерии будут зависеть от конкретного
бизнеса, но могут включать в себя:
 Финансовое воздействие. Любой инцидент, при котором потенциальное воздействие может
превысить установленную цифру.
 Основанные на сервисе. Любой простой ключевых сервисов, критических для бизнеса, когда быстрое
разрешение не кажется вероятным.
 Основанные на месте или пользователе. Любой инцидент, затрагивающий больше установленного
числа мест или пользователей, когда быстрое разрешение не кажется вероятным.
 Основанные на адресатах. Любой инцидент, который, вероятно, приведет к нарушениям в
отношении определенных адресатов уровня сервиса, в особенности, когда могут налагаться
существенные финансовые штрафы.
 Основанные на здоровье и безопасности. Любой инцидент, при котором считается, что здоровье и
безопасность будут находиться в непосредственной опасности до достижения разрешения.
 Основанные на безопасности. Любой инцидент, связанный с безопасностью, при котором считается,
что имеются серьезные ущерб или воздействие, или при котором возникает серьезная проблема,
связанная с безопасностью.
 Основанные на репутации. Любой инцидент, на который нужно отреагировать очень быстро и/или
эффективно, для того чтобы сдержать или минимизировать воздействие на репутацию организации
или ее брэнда.
Критерии должны гарантировать, что процедура по серьезным инцидентам инициируется при
существенном воздействии на бизнес, предотвращая слишком много ненужных и дорогостоящих
процедур, в которых ситуации не гарантируют такого уровня реакции. Данные критерии должны
использоваться только в качестве рекомендаций. Решение о необходимости инициализации процесса
всегда принимается по усмотрению дежурного менеджера по инцидентам. Дежурный менеджер по
инцидентам должен основывать решение на гибком подходе здравого смысла, рассматривая
индивидуальные характеристики инцидента и гарантируя, что критерии, характеризующие инцидент как
серьезный, были не слишком строгими. Инициализация процедуры по серьезным инцидентам обычно
будет иметь воздействие в терминах нарушений и стоимости мобилизации дополнительных ресурсов,
поэтому необходимо соблюдать осторожность и использовать ее только тогда, когда это строго
необходимо.
Любое лицо организации должно обладать возможностью связи с дежурным менеджером по инцидентам
в отношении инцидента, который, как оно считает, должен рассматриваться серьезным инцидентом.
Несмотря на то, что во многих случаях такой контакт будет исходить из службы поддержки или группы
решения, не должно существовать никаких препятствий для связи с дежурным менеджером по
инциденту у другого персонала, типа сервисных менеджеров или бизнес-менеджеров, которые зачастую
обладают большим пониманием потенциальных воздействий. Для обеспечения такой возможности
необходимо оговорить процедуру по серьезным инцидентам, а также способы контакта с дежурным
менеджером по инцидентам.
Если дежурный менеджер по инцидентам решает, что инцидент не гарантирует инициализацию
процедуры по серьезным инцидентам в настоящее время, то вовлеченным сторонам нужно объяснить
причины этого, после чего должна быть проверена ситуация, а прогресс инцидента происходил обычным
образом. После того, как об инциденте было сообщено дежурному менеджеру по инцидентам, даже если
он в настоящее время не считает этот инцидент серьезным, дежурный менеджер по инцидентам должен
регулярно контролировать инцидент на случай, если ситуация изменится.
Если инцидент был идентифицирован как серьезный, то дежурный менеджер по инцидентам должен
немедленно уведомить все заинтересованные стороны: управление проблемами, управление
доступностью, управление уровнем сервиса, управление непрерывностью ИТ сервиса, ИТ управление,
менеджеров затронутого бизнеса, а также дежурного менеджера службы поддержки.
Кто-то должен взять на себя функцию менеджера по серьезным инцидентам, ответственного за

координацию планирования, ресурсы и связь в течение серьезного инцидента. В зависимости от размера
организации, потенциальных угроз и воздействий, а также числа произошедших серьезных инцидентов,
эта должность может быть постоянной или же занимаемой соответствующим персоналом когда это
требуется. В сервисных организациях, обеспечивающих поддержку многочисленным клиентам, может
потребоваться ряд постоянных менеджеров по серьезным инцидентам. Если по инциденту необходимо
работать круглосуточно, то для отдельного инцидента, возможно, необходимо назначить нескольких
менеджеров по серьезным инцидентам.
Если должность менеджера по серьезным инцидентам должна будет должностью с частичной
занятостью, то, в зависимости от организации, эту функцию может взять на себя менеджер по
проблемам, менеджер по доступности или сервисный менеджер.
Персонал, выполняющий функции менеджера по серьезным инцидентам, должен соответствовать
следующим критериям:
 Должен обладать способностью совладать со стрессом, возникающим во время серьезных
 Старший менеджер, обладающий полномочиями делать вещи выполнимыми.
 Хороший коммуникатор, способный общаться с техническим ИТ персоналом, представителями
бизнеса и клиентами на всех уровнях в пределах организации.
 Признанная личность со всесторонним знанием организации, включая знание о том, как работают
вещи и с кем следует общаться.
 Готов к сверхурочной работе, часто незамедлительно.
 Готов к поездкам и присутствию на местах клиента, если это требуется, и снова незамедлительно.
После назначения менеджера по серьезным инцидентам, он должен собрать всю доступную в настоящее
время информацию и подтвердить текущую ситуацию. Затем менеджер по серьезным инцидентам
должен сформировать группу восстановления.
Технический персонал, вовлеченный в исследование и разрешение серьезного инцидента, носит
название группы восстановления. Эта группа обычно состоит из одного или более технических
специалистов. В зависимости от размера и характера организации, может быть сформирован постоянно
действующий технический персонал для реакции на серьезные инциденты. В такой ситуации это должны
быть опытные сотрудники, обученные техническим навыкам и методике решения задач. Данная
основная группа должна обучаться по всем используемым ключевым стратегическим технологиям и
дополняться другим персоналом поддержки, если для конкретного инцидента требуется другой профиль
навыков. Опытный персонал поддержки должен проходить через основную группу с временным
назначением.
Если ресурсы не позволяют основной группе постоянно находиться на месте или же если количество и
вероятность серьезных инцидентов не гарантируют таких инвестиций, то менеджером по серьезным
инцидентам, когда инцидент признан серьезным, должна формироваться группа восстановления,
действующая по мере необходимости.
Менеджер по серьезным инцидентам должен провести собрание по начальному планированию с группой
восстановления, любыми сотрудниками, которые уже работали с инцидентом, затронутых менеджеров и
любых других соответствующих технических специалистов. Если персонал географически удален друг от
друга, то такое собрание может принять форму теле- или видеоконференции. Цель собрания
заключается в том, чтобы согласовать план восстановления и план связи.
Цель плана восстановления состоит в том, чтобы обеспечить запланированный и скоординированный
подход к восстановлению сервиса. План должен находиться у менеджера по серьезным инцидентам и
должен документировать предпринимаемые действия, лиц, которые должны выполнять действия, а
также время завершения действий. План должен регулярно обновляться в течение существования
серьезного инцидента, гарантируя при этом сохранение старых версий для аудиторского следа.
План восстановления должен содержать следующее:

 Заявление о "проблеме", как она известна в настоящее время.
 Разделение инцидента на категории, детализируя компоненты, интерфейсы и вероятные причины
проблемы.
 План высокого уровня относительно того, как подтвердить или исключить каждую возможную
непосредственную причину.
 Взвешивание для каждой возможной причины на основании вероятности и простоты подтверждения,
позволяя дать приоритет исследованию каждой возможной причины.
 Подробная информация относительно действий по исследованию или решению, которые будут
предприняты на данном этапе, основываясь на назначенных приоритетах.
 Информация о том, кто будет выполнять действия по исследованию или решению.
 График выполнения каждого действия и время следующего обзорного собрания группы
восстановления.
Пример с шаблоном плана восстановления приведен в Приложении E настоящего документа.
Менеджер по серьезным инцидентам должен регулярно проверять прогресс вместе с группой
управления, состоящей из ИТ менеджеров, менеджеров затронутого бизнеса и управления клиентами и
партнерами. Цель собрания группы управления должна состоять в том, чтобы поддерживать все стороны
информированными, обсуждать прогресс, и обеспечивать эскалацию управления, когда это требуется.
После проведения обзорного собрания управления должны быть согласованы и выпущены заявления
обновления прогресса.
Обзорные собрания группы управления и группы восстановления обычно должны проводиться отдельно,
с тем, чтобы каждая группа могла сконцентрироваться на вопросах, соответствующих их ролям. Группа
восстановления должна обсудить технические проблемы и затем предоставить доклад о достигнутых
результатах группе управления, которая может затем сконцентрироваться на вопросах ресурсов,
эскалации и связи. Проведение этих отдельных собраний экономит время, затрачиваемое людьми на
собраниях (а не на фактическую работу по инциденту), позволяя также каждой группе сосредотачиваться
на своих обсуждениях.
Во время серьезных инцидентов поддержание связи часто может стать главной трудностью. Цель плана
связи состоит в том, чтобы обеспечить координацию связи на протяжении существования инцидента.
План связи должен составляться менеджером по серьезным инцидентам и обсуждаться и обновляться
на каждом обзорном собрании группы управления. План должен охватывать следующее:
 Кто должен регулярно обновляться.
 Контактная информация для всех сторон, требующих обновлений.
 Различные типы требуемых обновлений. Могут требоваться различные сообщения обновления в
зависимости от аудитории, с которой осуществляется связь:
 Обновление старшего управления.
 Обновление для всего персонала.
 Обновление для клиентов.
 Обновление для партнеров.
 Обновление для персонала, работающего по серьезному инциденту.
 Заявление для прессы/СМИ.
 Обновление для чрезвычайных сервисов/органов.
 Насколько часто требуется каждый тип обновления и когда должно выполняться следующее
обновление.
 Кто уполномочен согласовывать выпуск каждого заявления об обновлении.

 Механизм, посредством которого будет сообщаться о каждом обновлении.
 Время следующего собрания группы управления.
Для использования во время серьезных инцидентов должны быть составлены шаблон плана связи и
соответствующие списки рассылки по электронной почте; однако для определенных сред, например, в
случае недоступности электронной почты, должны быть также рассмотрены альтернативные методы
связи.
Пример таблицы плана связи включен в Приложение F настоящего документа.
После того, как только план связи и план восстановления будут согласованы, должны быть
распределены любые дополнительно требуемые ресурсы. Все ресурсы должны иметь доступ к плану
восстановления, с тем, чтобы они могли видеть то, что было до этого, и по каким действия они и другие
ресурсы должны воздействовать теперь.
Менеджер по серьезным инцидентам должен гарантировать, что любые необходимые договоренности
относительно перемещения разрешены для персонала поддержки.
После того как только процедура по серьезным инцидентам начнет реализовываться, планы будут
согласованы, а ресурсы распределены, необходимо выполнить стандартное исследование жизненного
цикла инцидента, диагностику, разрешение, восстановление и закрытие. Отличие от главного инцидента
состоит в том, что инцидентом владеет менеджер по серьезным инцидентам, который и координирует
инцидент, а планы восстановления и координации регулярно проверяются и поддерживаются на всем
жизненном цикле инцидента.
Группа восстановления должна регулярно проводить обзорные собрания, с тем, чтобы обсудить
прогресс, обновить план восстановления и выпустить отчет о достигнутых результатах группы
восстановления. Менеджер по серьезным инцидентам может посещать некоторые, но не обязательно
все, обзорные собрания. Интервал между обзорными собраниями должен меняться в зависимости от
объема деятельности. Например, в течение интенсивной фазы исследования собрания должны
проводиться чаще, чем в течение более позднего периода, когда персонал просто ожидает
подтверждения того, что действия по разрешению оказались успешными.
Также должны проводиться регулярные собрания группы управления, для того чтобы держать все
стороны информированными, обсуждать прогресс и решать, когда требуется эскалация управления.
Менеджер по серьезным инцидентам должен способствовать проведению всех собраний группы
управления по прогрессу. И снова, интервал между обзорными собраниями должен меняться согласно
уровню деятельности.
В течение серьезного инцидента может возникнуть необходимость выполнения эскалации управления.
Если инцидент становится более критическим, а у партнеров и клиентов осуществляется эскалация
управления, то необходимо расширить понимание инцидента по цепочке управления. Нужно избегать
таких ситуаций, когда старший менеджер или директор первыми узнают об инциденте от своих коллег в
организации партнера или клиента.
Если имеет место эскалация управления или изменение членов группы восстановления, то должен
регулярно обновляться план связи. Менеджер по серьезным инцидентам ответственен за соглашение
или за получение соглашения для всех заявлений обновления связи перед их выпуском.
С прогрессированием серьезных инцидентов менеджер по серьезным инцидентам должен гарантировать
размещение, распределение и координацию любых дополнительных требований к ресурсам.
Некоторые серьезные инциденты могут требовать использования бизнес-сообщества организации и
планов непрерывности сервиса. Необходимо рассмотреть, как сотрудничают между собой процедура по
серьезным инцидентам и планы непрерывности сервиса и где определены обязанности. Во время
серьезного инцидента менеджер по серьезным инцидентам должен принять решение о том, когда
необходимо привлечь план непрерывности сервиса, и нужно ли это делать вообще, с тем, чтобы
восстановить сервис или сохранить доказательство в случае злоумышленного намерения.
Как правило, менеджер по серьезным инцидентам должен оставаться ответственным за

координирование восстановления, связи и таких действий как сбор доказательств и внедрение обходных
путей.
В зависимости от своих размеров и потребностей, организации могут реализовывать различные уровни
подготовки для обработки серьезных инцидентов. Вопросы, связанные с персоналом, типа таких,
имеются ли полностью занятые менеджеры по серьезным инцидентам и основная группа
восстановления, постоянно находящаяся на месте, были уже рассмотрены выше, но некоторые
организации могут принимать дополнительные подготовительные меры с использованием
специализированных “штабов”, оснащенных персональными компьютерами, оборудованием связи и
белыми досками. Многие организации понимают, что общественное восприятие того, насколько хорошо
они выдержали серьезный инцидент, непосредственно связано с тем, насколько хорошо они
обрабатывали СМИ и как вкладывали капитал в обучение для гарантии того, чтобы их представители и
старшие менеджеры могли “иметь дело со СМИ”. Очевидно, что то, насколько разумно вкладывать
капитал в подготовку к обработке серьезных инцидентов, зависит от размера организации и условий, в
которых она работает. При этом каждая организация должна тщательно рассмотреть потенциальные
воздействия, которые могут произойти, и что они будут означать для организации, ее персонала и ее
клиентов, а также понимать, что рано или поздно серьезный инцидент произойдет. Речь идет не о случае
"если", а о случае "когда".
Процедура по серьезным инцидентам должна продолжиться параллельно обычному процессу
управления инцидентами до тех пор, пока серьезный инцидент не будет закрыт. В течение
заключительных фаз инцидента, когда будут предприняты действия по решению, можно будет
освободить часть группы восстановления от своего назначения, понимания при этом, что она будут
повторно вызвана, если решение окажется неудачным.
При закрытии серьезных инцидентов необходимо уведомить управление проблемами, поскольку оно
отвечает за выполнение проверок после серьезных инцидентов.
Примечание, касающееся технологии. Персонал, ответственный за реагирование на серьезные инциденты, должен быть
надлежащим образом экипирован. Связь часто затруднена, поскольку персонал работает в отдаленных местах или находится в
дороге. Требуется использование технологий мобильной связи, для того чтобы персонал всегда находился в контакте и мог
получить важную, часто быстро изменяющуюся, информацию.
Для содействия планам связи, для электронной почты и текстовых сообщений могут быть составлены списки рассылки. Средства,
типа цифровых дисплеев, системы кабельного телевидения и внутренних систем радиопередачи могут использоваться для
предоставления всему офисному персоналу информации о главных инцидентах.
Персоналу поддержки может понадобиться проверять и обновлять регистрационные записи инцидента, работая удаленно. Должны
быть инструментальные средства группы поддержки, позволяющие проверять и обновлять инциденты удаленно через браузер или
электронную почту. Необходимо принять меры, направленные на гарантию безопасности этих систем.
Менеджер по серьезным инцидентам, а также другой персонал, работающий по серьезному инциденту, должны иметь доступ из
любого места, где бы они ни находились, как к плану связи, так и к плану восстановления. Для получения данной информации
могут применяться порталы, обеспечивающие для уполномоченного персонала удаленный доступ через браузер.
Разрешение и восстановление
На приведенном ниже рисунке показана блок-схема процесса разрешения и восстановления.
Perform recovery actions -
E Problem Выполнение действий по
Management In the case of a major восстановлению
incident, the major incident RFC required? - Требуется RFC?
process continues to
coordinate restoration and
Yes - Да
communications No - Нет
throughout the resolution Perform resolution actions -
and recovery phase. Выполнение действий по
разрешению
Yes
Resolution successful? - Решение
RFC required? Raise RFC успешно?
Is recovery required? - Требуется ли
восстановление?
No
Problem Management - Управление
Change Raise RFC - Выдача RFC
Perform resolution Change (and Release) Management
(and Release)
actions
Management - Управление изменениями (и
релизами)
Change implemented correctly? -
Изменение выполнено правильно?
Inform change management whether
any RFCs should be backed out -
Информирование управления
Change изменениями о том, должны ли
Resolution No No Major Incident какие-либо RFC быть отклонены
implemented
successful? Process
correctly? Investigation and Diagnosis -
Yes Yes
In the case of a major incident, the
major incident process continues to
Perform recovery Inform change
coordinate restoration and
actions management communications throughout the
whether any RFCs resolution and recovery phase - В
should be backed случае серьезного инцидента
Is recovery out процесс по серьезным инцидентам
Yes required? продолжает координировать
восстановление и связь на стадии
разрешения и восстановления
No
Major Incident Process - Процесс по
серьезным инцидентам
F
C
Investigation and
Diagnosis
Closure
Рисунок 21. Блок-схема процесса разрешения и восстановления
Процесс разрешения и восстановления отвечает за то, чтобы любые идентифицированные обходные

пути или решения реализовывались должным образом в соответствии с процессами управления
изменениями и релизами, и что затем предпринимаются любые дополнительные действия по
восстановлению.
Действия по разрешению - это действия, которые должны быть предприняты для того, чтобы разрешить
непосредственную причину инцидента, например, замена неисправного жесткого диска или установка
заплат в приложение базы данных для предотвращения повреждения таблицы.
Действия по восстановлению - это действия, которые все еще должны предприниматься, как только
действия по разрешению будут завершены, а все компоненты вернутся в нормальное рабочее
состояние. В случае повреждения жесткого диска действие по разрешению заключается в замене диска,
что решает причину инцидента. Однако все еще требуется действие по восстановления, заключающееся
в восстановлении содержания диска. Для приложения базы данных применение заплатки является
действием по разрешению, которое разрешает инцидент; при этом все еще необходимы действия по
восстановлению для возврата данных к непротиворечивой точке и рестарта сервиса базы данных. В
зависимости от инцидента, действия по разрешению и восстановлению, возможно, должны выполняться
разными группами.
Инциденты могут перемещаться в стадию разрешения и восстановления из-за обходного пути или
решения, идентифицируемых в фазе исследования и диагностики, или же вследствие обнаружения
управлением проблемами обходного пути или решения проблемы, которая имела один или несколько
нерешенных инцидентов, связанных с ней. Для последнего сценария управление проблемами отвечает
за идентификацию и проверку обходного пути проблемы или же за разрешение и последующую передачу
информации управлению инцидентами. Управление инцидентами отвечает затем за выполнение
разрешения, восстановления и закрытие всех инцидентов, связанных с регистрационной записью
проблемы.
После идентификации действий по разрешению персонал управления инцидентами часто должен
обращаться к процессу управления изменениями для выполнения любых изменений, требуемых для
решения инцидента. Это гарантирует, что изменения надлежащим образом проверяются и
регистрируются, и что учитываются планы возврата. Управление инцидентами должно контролировать
прогресс действий по разрешению через процессы управления изменениями и релизами.
Некоторые инциденты могут разрешаться без необходимости использования RFC. Часто они
представляют собой процедурные проблемы, в которых инцидент возникал из-за “человеческой ошибки”
или неправильного следования процедур.
После выполнения действий по разрешению, управление инцидентами будет отвечать за подтверждение
того, что действия по разрешению были успешными. Если действия не были успешными, то первое, что
необходимо сделать - это проверить, что все изменения были осуществлены правильно. Если
обнаруживается, что изменения были выполнены неправильно, то должен использоваться процесс
управления изменениями для отмены неправильных изменений и планирования нового выполнения.
Если любые RFC были выполнены правильно, но инцидент не был разрешен, то инцидент должен быть
возвращен в процесс диагностики и исследования. Используя процесс управления изменениями
персонал управления инцидентами должен решить, должны ли осуществленные изменения быть
отменены. Во многих случаях осуществленные изменения, возможно, не потребуют отмены, поскольку
они являются полезными. Например, для опробования и разрешения определенного инцидента можно
было бы использовать последний пакет обновления. Если бы это действие не разрешило определенный
намеченный инцидент, то было бы разумно сохранить последний пакет обновления, поскольку это
должно разрешить или предотвратить другие инциденты.
После того, как действия по разрешению будут успешно осуществлены, должны быть выполнены любые
действия по восстановлению. Эти действия по восстановлению часто включают в себя обеспечение того,
чтобы сервис снова стал доступным для пользователей после разрешения инцидента. Действия по
восстановлению должны выполняться до тех пор, пока сервис не восстановится в нормальное
состояние.
Если рассматриваемый инцидент был обработан как серьезный инцидент, то должна продолжаться
процедура по серьезным инцидентам наряду с процессом разрешения и восстановления, обеспечивая
повышением уровня координации, связи и планирования.
После выполнения действий по разрешению и восстановлению регистрационная запись инцидента
должна быть помещена в "разрешенное" состояние и назначена аналитикам службы поддержки,
ответственным за подтверждение разрешения вместе с инициатором.
Примечание, касающееся технологии. Интегрированные наборы инструментальных средств управления сервисом, которые
позволяют осуществлять интеграцию базы данных управления конфигурации (CMDB) с сервисными запросами, регистрационными
записями инцидента, регистрационными записями проблемы, известными ошибками, адресатами уровня сервиса и RFC,
предоставляют организациям важный инструмент для поддержания их инвестиций в процессы управления сервисом.
Уровень интеграции, обеспечиваемый этими инструментальными средствами, позволяет извлекать максимальную выгоду от
управления сервисом. Хотя SMF MOF могут внедряться по отдельности, выгоды могут быть реализованы более полно через более
широкое внедрение, принося интегрированный набор процессов, которые поддерживают и усиливают друг друга.
Инструментальные средства могут позволить персоналу управления инцидентами использовать RFC, связанные или
ассоциируемые с регистрационными записями инцидента, позволяя отслеживать прогресс через отдельный интерфейс вместо
того, чтобы входить в многочисленные приложения и повторно вводить основную информацию.
Закрытие
На приведенном ниже рисунке показана блок-схема процесса закрытия.
In the case of a major Подписи к рисунку:
incident, the major incident Ensure incident details fully updated - Обеспечение
process continues to полного обновления информации об инциденте
C
coordinate restoration and Suspect this is a new problem or known error? -
communications Подозревается, что это - новая проблема или
throughout the resolution
известная ошибка?
and recovery phase.
Yes - Да
No - Нет
Ensure incident Assign closure category - Назначение категории
details fully закрытия
updated Customer confirms resolution? - Заказчик
подтверждает разрешение?
Was this a major incident? - Это был серьезный
инцидент?
Close incident - Закрытие инцидента
Liaise with problem
Suspect this is a management to Liaise with problem management to create problem
new problem or create problem or or known error record where appropriate -
known error? Yes known error record Поддержание связи с управлением проблемами
where appropriate для создания регистрационной записи проблемы
или известной ошибки, если это возможно
No Update incident details - Обновление информации
об инциденте
Investigation and Diagnosis - Исследование и
Assign closure диагностика
category Flag to problem management for review -
Уведомление управления проблемами для
проверки
In the case of a major incident, the major incident
process continues to coordinate restoration and
Major Incident communications throughout the resolution and
Customer Process
Update incident recovery phase. - В случае серьезного инцидента,
confirms
details процесс по серьезным инцидентам продолжает
resolution? No
координировать восстановление и связь на
Yes
стадии восстановления и разрешения.
Major Incident Process - Процесс по серьезным
инцидентам
F
Investigation
and Diagnosis
Yes Flag to problem

Was this a
management for
major incident?
review
No
Close incident
Рисунок 22. Блок-схема процесса закрытия
Стадия закрытия процесса управления инцидентами отвечает за подтверждение вместе с инициатором

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

регистрационной записи. Управление проблемами должно рассмотреть запрос и либо создать новую
регистрационную запись, либо объяснить, почему такая запись в настоящее время не требуется.
Аналитик службы поддержки должен также гарантировать назначение инциденту категории закрытия.
Категория закрытия должна отражать непосредственную причину инцидента. Применяемые фактические
категории закрытия должны быть согласованы с управлением проблемами и созданы на достаточно
подробном уровне, с тем, чтобы могли быть получены полезные метрики и отчеты. Например, если
имеется категория закрытия “ошибка конфигурации” и сообщается, что в течение прошлого месяца 50
инцидентов были вызваны этой проблемой, то управление проблемами будет иметь не так много
информации для продолжения. Однако если эта категория закрытия будет подразделена немного
подробнее, показывая “ошибку конфигурации персонального компьютера”, “ошибку конфигурации
сервера”, “ошибку конфигурации учетной записи”, “ошибка сетевой конфигурации” и так далее, то
информация окажется намного более полезной. Управление проблемами теперь может обнаружить, что
45 из этих 50 инцидентов были вызваны ошибками конфигурациями учетной записи, предоставляя им
намного лучшее начало к идентификации первопричины.
Примечание, касающееся технологии. Инструментальные средства группы поддержки могут быть сконфигурированы на
предоставление списка потенциальных категорий закрытия персоналу, обновляющему регистрационные записи инцидента. Поле
категории закрытия должно быть обязательным, с тем, чтобы гарантировать выбор категории закрытия перед закрытием.
На приведенном ниже рисунке показан пример регистрационной записи инцидента, закрытой с

категорией закрытия “известная ошибка”.
Рисунок 23. Пример регистрационной записи инцидента, закрытой с категорией закрытия

“известная ошибка”.
Очень важно, чтобы список категорий закрытия был всесторонним и поддерживался надлежащим образом. Если персонал не
может найти категорию закрытия, соответствующую инциденту, с которым он имеет дело, то у персонала может быстро возникнуть
привычка выбора случайной категории, только для того чтобы инцидент мог быть закрыт. Поэтому поле категории закрытия не
должно иметь значения по умолчанию. Может быть задана категория закрытия “соответствующая категория отсутствует”, для того,
чтобы дать персоналу выбор на случай, когда он не может выявить категорию закрытия, соответствующую инциденту. Во
избежание использования такой категории, как всеобъемлющей, все случаи ее применения должны детально рассматриваться.
Для менеджера по инцидентам персонала управления проблемами может генерироваться сообщение, информирующее о том, что
была выбрана опция “соответствующая категория отсутствует”. Каждый такой случай должен быть исследован и должно быть
предпринято соответствующее действие для того, чтобы определить новую категорию или сообщить соответствующему персоналу
о категории закрытия, которая должна использоваться.
Ситуация должна находиться под контролем, с тем, чтобы категории закрытия применялись надлежащим образом.
Наконец, функция службы поддержки состоит в выполнении "независимой" проверки, для того, чтобы
подтвердить, что инициатор удовлетворен полученной поддержкой и соглашается с тем, что инцидент
был разрешен. Эта проверка предотвращает ситуации, когда инициаторы обращаются для проверки
прогресса по инциденту, который все еще затрагивает их, а им сообщается о том, что инцидент был
закрыт, потому что персонал поддержки посчитал, что разрешил его. Подобные ситуации ставят в
неудобное положение не только организацию поддержки, но также оказывают очень плохое влияние на
удовлетворение клиента.
Аналитики службы поддержки должны контролировать инциденты, помещаемые в разрешенное
состояние, и связываться с инициатором для подтверждения разрешения. В зависимости от числа
существовавших инцидентов, проверка может быть выполнена по телефону или по электронной почте.
Часто может использоваться комбинация этих способов - с использованием общения по телефону для
первоочередных инцидентов и критических или чувствительных сервисов, и применением электронной
почты для стандартных, повседневных инцидентов и пользователей, с которыми трудно связаться по
телефону.
Примечание, касающееся технологии. После завершения действий по разрешению и восстановлению, регистрационные записи
инцидента должны быть установлены в состояние "разрешенный".
Инструментальные средства могут быть сконфигурированы таким образом, чтобы автоматически послать по электронной почте
письмо (с использованием стандартного шаблона сообщения, направляемого по электронной почте) инициаторам инцидента, как
только их инцидент будет помещен в состояние "разрешенный". Направляемые по электронной почте сообщения должны
содержать регистрационный номер инцидента, зарегистрированные дату и время, а также краткое описание симптомов инцидента,
полученных при начальной регистрации. В письме должно указываться, что инцидент в настоящее время считается разрешенным,
но если дело обстоит не так, или же если инициатор неудовлетворен разрешением, то он может либо ответить по электронной
почте, либо обратиться в службу поддержки по телефону. В письме также необходимо сообщить, что при отсутствии ответа в
пределах определенного периода времени (возможно, несколько недель, для того чтобы охватить случаи, когда инициатор,
например, находится в отпуске), то инцидент будет закрыт. Инструмент должен автоматически закрывать инцидент в случае
отсутствия ответа к концу указанного периода.
Инструментальные средства должны автоматически уведомлять управление проблемами о любых инцидентах, которые были
отмечены как серьезные инциденты. Это без труда может осуществляться посредством электронной почты.
Если инициатор сообщает о том, что инцидент не был разрешен удовлетворительно, то аналитик службы
поддержки должен обновить регистрационную запись инцидента, включая приоритет, если он теперь
является другим, и затем или переназначить инцидент группе решения или осуществить эскалацию
инцидента. Возникают ситуации, когда персонал поддержки сделает все, что он в состоянии сделать
своими текущими ресурсами, но инициатор все еще остается не удовлетворенным ситуацией. Проблемы
производительности являются типичным примером этого, когда инициатор неудовлетворен временем
ответа, но любые корректирующие меры, выполняемые персоналом поддержки, вносят лишь небольшие
отличия или же не дают их вовсе, поскольку критическим параметром является текущая сетевая
инфраструктура и для улучшения ситуации необходимы значительные инвестиции. В этом случае мало
что можно получить от возвращения инцидента группе решения, и аналитик службы поддержки должен
вместо этого расширить инцидент либо до ответственного менеджера сервиса, если таковой имеется,
либо непосредственно до управления проблемами. Очевидно, что это случай, когда может помочь
наличие согласованных адресатов сервиса для времени ответа, когда их достижимость фактически
должным образом установлена до их согласования.
В случае серьезных инцидентов, параллельно процессу закрытия должна выполняться процедура по
серьезным инцидентам, гарантируя расширенные уровни координации, связи и планирования.
Управление проблемами должно быть уведомлено о том, когда закрываются серьезные инциденты,
поскольку оно отвечает за проведение проверок для установления первопричины и возможности другой
обработки инцидента. Управление проблемами должно пытаться идентифицировать, как
воспрепятствовать повторению таких или подобных инцидентов.
5
Роли и обязанности
Основные роли и связанные с ними обязанности для управления инцидентами были определены в
соответствии с лучшими методиками, принятыми в производстве. Организации, возможно, должны
комбинировать некоторые роли, в зависимости от своего размера, структуры и основных соглашений об
уровне сервиса, существующих между ИТ отделом и обслуживаемым бизнесом.
Важно помнить о том, что ниже приводятся описания ролей, а не работ.
Роли, требуемые в процессе управления инцидентами:
 Менеджер по инцидентам
 Аналитик службы поддержки
 Менеджер по серьезным инцидентам
 Специалист по поддержке
Менеджер по инцидентам
Роль менеджера по инцидентам включает в себя ответственность за непрерывное владение процессом
управления инцидентами, для гарантии последовательного прогресса всех инцидентов согласно
состоянию их приоритета. В противном случае, индивидуальные группы решения могли бы работать по
своим собственным приоритетам, приводя к дорогостоящему и неэффективному процессу поддержки.
Там, где непрерывные обзор и ответственность не существуют, организации могут ограничиваться
ярусами поддержки, работающими по своему собственному набору кодов приоритета и
запланированному времени разрешения без указания структуры относительно того, как инциденты
должны обрабатываться, обновляться или подвергаться эскалации. Часто это становится причиной
споров между группами, приводя к низкому удовлетворению клиента, увеличению расходов и
разочарованию персонала.
Во многих организациях роли менеджера по инцидентам и менеджера службы поддержки выполняет
один и тот же человек. Часто роль назначается лицам, ответственным за управление группами
поддержки первой линии или же первой и второй линии.
Для того чтобы инциденты могли подвергаться эскалации, когда это требуется, менеджер по инцидентам
всегда должен быть доступен в течение времени сервиса. Во время критических инцидентов, менеджер
по инцидентам ответственен за принятие решения о необходимости инициализации процедуры по
серьезным инцидентам.
Менеджер по инцидентам должен также отвечать за контроль выполнения процесса управления
инцидентами и стремиться постоянно улучшать процесс.
Основные обязанности менеджера по инцидентам включают в себя:
 Управление производительностью и эффективностью процесса управления инцидентами.
 Составление информации по управлению.
 Возможность управлять работой персонала поддержки первой и второй линии.
 Разработку и поддержку системы управления инцидентами.
Аналитики службы поддержки

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

были разрешены в течение процесса начальной поддержки. Однако их ответственность не заканчивается
в этом месте, и они должны сохранять владение инцидентом, оставаясь ответственными за гарантию
того, что прогресс и эскалация инцидента продолжаются в соответствии с адресатами уровня сервиса.
Аналитики ответственны за предоставление клиентам обновлений по прогрессу на всем протяжении
жизненного цикла инцидента.
После разрешения инцидента, до закрытия регистрационной записи инцидента аналитики должны
подтвердить, что инициатор удовлетворен разрешением инцидента.
Основные обязанности аналитиков службы поддержки включают в себя:
 Регистрацию инцидента.
 Начальную поддержку и классификацию.
 Направление запросов группам решения, когда инциденты не разрешаются во время начальной
поддержки.
 Контроль состояния и продвижения к разрешению всех открытых инцидентов.
 Информирование затронутых пользователей о прогрессе.
 Эскалацию процесса в случае необходимости.
 Разрешение и восстановление инцидентов, не назначенных группам решения.
 Подтверждение разрешения и закрытие инцидентов.
Роль аналитика службы поддержки описана ниже в главе SMF Служба поддержки.
Менеджер по серьезным инцидентам

Роль менеджера по серьезным инцидентам является критической в течение периодов, когда происходят
серьезные инциденты. Если происходит серьезный инцидент, то для инцидента должен быть
немедленно назначен менеджер по серьезным инцидентам. С этого времени и до тех пор, пока инцидент
не будет закрыт, менеджер по серьезным инцидентам ответственен за координированную реакцию по
всей компании, назначение ресурсов группе восстановления, эскалацию управления и управление
связью со всеми вовлеченными сторонами.
Менеджер по серьезным инцидентам ответственен за то, чтобы во время инцидента были составлены и
поддерживались план восстановления и план связи.
Данную роль должен взять на себя старший менеджер, обладающий всесторонним знанием организации
и политическими полномочиями делать вещи выполнимыми. Эта роль включает в себя широкое
взаимодействие с клиентами и часто может быть стрессовой. Она требует наличия способностей
работать с высокой нагрузкой и общаться с внутренними ИТ персоналом и организационным персоналом
на всех уровнях, а также с внешними партнерами и клиентами.
Число требуемых менеджеров по серьезным инцидентам и то, должны ли они исполнять свои
обязательства в течение полного или неполного рабочего дня, зависит от размера и характера
организации. В начале необходимо проанализировать произошедшие ранее серьезные инциденты:
продолжительность времени, в течение которого они были разрешены, то, насколько часто они
происходили, их местоположение, число одновременно произошедших инцидентов, а также то, велась
ли круглосуточная работа по разрешению.
Основные обязанности менеджера по серьезным инцидентам включают в себя:
 Координацию и управление в течение серьезных инцидентов.
 Составление и поддержку плана связи для серьезных инцидентов.
 Содействие составлению и поддержке плана восстановления для серьезных инцидентов.
 Содействие проверкам, выполняемым группами управления.
 Выполнение обновлений прогресса серьезных инцидентов.
 Участие в проверках серьезных инцидентов.
Технические специалисты по поддержке

Microsoft Operations Framework разделяет ИТ среду на ряд уровней: каждый уровень зависит от прочной
основы, для того, чтобы он мог эффективно функционировать. Для ИТ отдела эти уровни являются
следующими:
 Сервис
 Приложение
 Связующее программное обеспечение
 Операционная система
 Аппаратные средства
 Локальная сеть
 Средства
 Выход
Для каждого уровня предусмотрена роль технического специалиста по поддержке, который является
ответственным за участие в группе решения всякий раз, когда инцидент связан с данным уровнем.
Специалисты по поддержке также активно вовлечены в идентификацию проблем и известных ошибок.
Для решения различных типов проблем и известных ошибок в ИТ организации могут быть
задействованы многочисленные индивидуальные группы. Эти “группы решения” должны иметь свою
очередь в инструменте управления проблемами, которому назначены проблемы, требующие их
специальных знаний. Не все группы решения будут чисто "техническими" группами, но все они могут
выполнять некоторую форму функции экспертной поддержки. Примерами "нетехнических" групп решения
могли бы являться процедурные эксперты или группы, ответственные за обучение, обработку RFC или
обработку запросов для изменения согласованных уровней сервиса. Персонал в этих группах
осуществляет экспертную поддержку. Не обязательно весь персонал экспертной поддержки является
внутренним, поскольку множество групп решения могут быть сформированы внешними поставщиками.
Персонал, выполняющий роль поддержки проблемы, вряд ли будут иметь всестороннее знание всех
областей в пределах ИТ инфраструктуры, тем более, что продолжают появляться новые технологии.
Персонал, занимающийся экспертной поддержкой, ответственен за использование знаний специалистов
для содействия управлению проблемами в исследовании и решении проблем.
Если действия по разрешению идентифицированы, то персонал экспертной поддержки должен
выполнить эти действия под контролем процессов управления изменениями и релизами. После
достижения разрешения, данный персонал должен обновить регистрационную запись проблемы и
возвратить ее персоналу поддержки проблемы для закрытия.
Группы экспертной поддержки должны также стараться идентифицировать основные проблемы и
уведомлять о них управление проблемами.
В представленной ниже таблице приведены обязанности технических специалистов по поддержке.
Таблица 7 - Обязанности технических специалистов по поддержке
Роль Основные обязанности
Технический  Обработка сервисных запросов.
специалист по
поддержке  Контроль деталей инцидента, включая затронутые конфигурационные
приложений единицы.
 Исследование и диагностика инцидентов и проблем (включая их разрешение,
где это возможно).
 Обнаружение возможных проблем и уведомление управления проблемами.
 Разрешение и восстановление назначенных инцидентов.
 Работа в качестве члена группы восстановления, если это требуется во
время серьезных инцидентов.
 Выполнение действий по исправлению известных ошибок.
поддержке  Контроль деталей инцидента, включая затронутые конфигурационные
связующего единицы.
программного
обеспечения  Исследование и диагностика инцидентов и проблем (включая их разрешение,

поддержке хранения  Контроль деталей инцидента, включая затронутые конфигурационные
данных единицы.
 Выполнение запросов конечных пользователей на восстановление данных.

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

операционной  Контроль деталей инцидента, включая затронутые конфигурационные
поддержке единицы.
Технический  Гарантирование наличия достаточного числа запасных частей аппаратных
средств для соответствия требованиям уровня сервиса.
поддержке
аппаратных средств  Управление поставкой запасных частей для компании.
 Обработка сервисных запросов.
 Контроль деталей инцидента, включая затронутые конфигурационные
единицы.
сетевой поддержке  Контроль деталей инцидента, включая затронутые конфигурационные
единицы.

поддержке средств  Контроль деталей инцидента, включая затронутые конфигурационные
единицы.
6
Связь с другими SMF
SMF "Управление инцидентами" связана в архитектуре MOF со многими описанными ниже SMF.
Служба поддержки
Служба поддержки исполняет роль исходного шлюза для многих ИТ процессов, включая процесс
управления инцидентами. В отношении многих других ИТ процессов служба поддержки просто передает
к ним запросы; однако для процесса управления инцидентами связь между службой поддержки и
процессом управления инцидентами намного теснее.
Служба поддержки действует в качестве интерфейса между бизнесом и ИТ, и, в этом случае, между
бизнесом и процессом управления инцидентами.
Менеджер службы поддержки ответственен за повседневную координацию процесса управления
инцидентами. Служба поддержки выполняет регистрацию, классификацию и начальную поддержку
управления инцидентами. После того как инциденты будут назначены группе решения, служба
поддержки сохраняет за собой ответственность, осуществляя мониторинг и отслеживание всех
Если служба поддержки функционирует успешно, то многие сервисные запросы и инциденты могут быть
обработаны и решены без выхода за пределы деятельности службы поддержки.
Служба поддержки является ключевым компонентом в отношении удовлетворения клиента процессом
управления инцидентами.
Управление проблемами
Управление проблемами и управление инцидентами тесно связаны друг с другом, но они сосредоточены
на разных полюсах в организации поддержки.
В то время как управление инцидентами сфокусировано на как можно более быстром восстановлении
нормального сервиса, управление проблемами сосредоточено на идентификации и разрешении
основных проблем и их первопричин.
Управление инцидентами предоставляет управлению проблемами большое количество информации,
требуемой для идентификации существования основных проблем. Управление проблемами анализирует
статистику по инцидентам для идентификации появления многократных инцидентов или тенденций
роста для определенных типов инцидентов.
В свою очередь, управление проблемами стремится разрешить основные причины этих инцидентов, для
того чтобы предотвратить их повторное появление.
Управление проблемами сохраняет также информацию о существующих проблемах и известных
ошибках, включая известные обходные пути и решения. Управление инцидентами использует эту
информацию для обеспечения более быстрого разрешения инцидентов.
Управление проблемами ответственно также за оценку серьезных инцидентов после их разрешения.
Цель таких оценок состоит в том, чтобы идентифицировать основные причины, предотвратить любое
повторное появление, идентифицировать механизмы запуска, которые могут использоваться для
раннего обнаружения любого повторного появления, а также идентифицировать, насколько хорошо был
обработан инцидент, с тем, чтобы улучшить будущие реакции.
Управление изменениями
Если управление инцидентами идентифицирует действия по разрешению, которые требуют изменений
конфигурационных единиц, то эти изменения осуществляются под контролем процесса управления
изменениями.
Контроль, обеспечиваемый процессом управления изменениями, сокращает количество изменений,
которые должны быть возвращены, и гарантирует документирование планов возврата в том случае, если
они требуются. Координированное тестирование изменений снижает шанс на последующие инциденты,
вызванные выполнением изменений.
Управление изменениями также предоставляет управлению инцидентами полезную информацию
относительно последних изменений, затронутых конфигурационных единиц и причин для изменений.
Управление конфигурациями
Управление конфигурациями предоставляет важную информацию, используемую в течение процесса
управления инцидентами. База данных управления конфигурациями (CMDB) содержит информацию,
которая может использоваться для:
 Обеспечения и проверки информации об инициаторе запроса.
 Предоставления информации относительно конфигурационных единиц (CI).
 Содействия классификации инцидентов, посредством индикации сервисов и SLA, на которые
воздействует проблема конкретных CI.
 Идентификации отношений и зависимостей между CI.
 Идентификации идентичных или подобных CI с целью сравнения.
 Идентификации альтернативных маршрутов и обходных путей.
 Регистрации изменений конфигурационных единиц из-за RFC.
Управление релизами
Некоторые действия по разрешению, идентифицируемые управлением инцидентами, требуют
выполнения изменений, которые должны внедряться и развертываться как релизы. Эти релизы
координируются и управляются процессом управления релизами.
Аналогично управлению изменениями, управление релизами обеспечивает эффективное планирование,
тестирование и координацию, которые гарантируют, что эти релизы будут развертываться при
минимальных инцидентах.
Управление уровнем сервиса

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

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

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

Мониторинг и контроль сервисов обеспечивает управление событиями и предупредительные
инструментальные средства, которые предоставляют информацию об обнаружении инцидентов и
позволяют осуществлять раннее обнаружение инцидентов. SMF устанавливает пороги, которые
позволяют управлению инцидентами реагировать на инциденты прежде, чем будут нарушены адресаты
сервиса.
Инструментальные средства мониторинга и контроля сервисов могут интегрироваться с
инструментальными средствами службы поддержки, с тем, чтобы обеспечивать автоматическое
генерирование регистрационных записей инцидентов на основании полученных предупреждений.
Приложения
Приложение A: Используемые технологии
Все скриншоты, используемые в настоящем документе, за исключением примера базы знаний, взяты из
приложения управления сервисом Redbox FOX IT, которое объединяет функции управления
конфигурациями, управления изменениями, службы поддержки, управления инцидентами, управления
проблемами и управления операциями для содействия организациям в обеспечении поддержки
мирового класса своим ИТ службам.
Скриншот базы знаний взят из приложения поддержки Microsoft TechNet.
Приложение B: Пример шаблона плана восстановления для

серьезного инцидента
Обзор инцидента
В этом разделе приводится основная информация об инциденте.
Регистрационный
идентификационный номер
инцидента
Дата/время возникновения
инцидента
Дата/время регистрации инцидента
Дата/время объявления о серьезном
инциденте
Контактная информация об
инициаторе
Состояние инцидента
Основной затронутый сервис
Краткое описание инцидента
Описание воздействия и предельных сроков
В этом разделе представлено полное описание воздействия, затронутых сервисов, адресатов сервиса,
находящихся под угрозой / имеющих нарушения, а также соответствующих предельных сроков.
Затронутые сервисы, клиенты и местоположения
Вовлеченные адресаты сервиса
Описание воздействий
Пояснение по предельным срокам / интервалам времени

Роли и контактная информация

В этом разделе представлена контактная информация по персоналу, назначенному для работы с
инцидентом.
Персонал Должность Местоположение Основной Дополнительные Электронная
контактный контактные почта
номер номера
Менеджер(ы)
по серьезным
инцидентам
Главное
контактное
лицо (лица)
по бизнесу
Руководитель
(и) группы
восстановлен
ия
Персонал
группы
восстановлен
ия
Дополнительн
ые
контактные
лица
Исследование инцидента
Заявление об описании инцидента
Данный раздел включает в себя заявление о том, какие затруднения испытываются в настоящее время.
Это заявление может расширяться с получением дополнительной информации об инциденте.
Информация об инциденте
В этом разделе приводится подробная информация об инциденте, включающая в себя:
 Симптомы.
 Затронутые/вовлеченные конфигурационные единицы.
 Описания сервисов.
 Любые уместные диаграммы, отображающие сетевую инфраструктуру/поток данных.
Временная шкала события инцидента

В этом разделе приводится временная шкала событий в течение инцидента. Часто возможно
создать более ясную картину того, "что случилось неправильно”, размещая события и
сообщения об ошибках в хронологическом порядке.
Дата/время Событие
Возможные непосредственные причины

В этом разделе должны регистрироваться идеи относительно возможных непосредственных причин
инцидента. Часто определение непосредственной причины позволяет спланировать то, как разрешить
инцидент. Например, если не функционирует вебсайт, то, возможно, это связано с отказом в доступе из-
за атаки на сервис? Эти возможные причины могут не являться фактическими причинами, но они
помогают создавать пути исследования, для того чтобы могли быть исключены вероятные причины. Для
заполнения таблицы может быть проведен мозговой штурм. Обратите внимание на то, что это -
непосредственные проблемы, а не основные первопричины. Идеи должны быть оценены, для того чтобы
расположить по приоритетам те из них, которые, как предполагается, наиболее вероятно являются
правильными.
Возможная причина Вероятность Каким образом нам следует

(оценка от 1 выполнять исследование,
до 10) чтобы исключить это?
Потенциальные действия по разрешению

В этом разделе должны регистрироваться идеи о потенциальных действиях по разрешению. Например,
если бы имели место затруднения с сетевым подключением сервера, то имеется ли более поздний
драйвер для сетевой платы, который решил бы проблему? Эти действия фактически могут не
решать инцидент, но они обеспечивают пути исследования, которыми можно следовать. Для
заполнения таблицы может быть проведен мозговой штурм. Действия должны быть оценены,
для того чтобы расположить по приоритетам те их них, которые, как предполагается, наиболее
вероятно являются успешными.
Потенциальное действие по Вероятность Как мы можем
разрешению (оценка от 1 проверить/подтвердить это?
до 10)
План действий
В этом разделе должна содержаться подробная информация по действиям, которые
планируются на основании идей, указанных в предыдущем разделе. Действиям должны быть
присвоены приоритеты на основе оценок вероятности.
Действие Назначенный Запланированная Дата/время Состояние
персонал дата/время для завершения
действия действия
Законченные действия
После завершение запланированных действий они должны быть зарегистрированы в этом
разделе, а в невыполненный план действий должны быть добавлены любые последующие
идентифицированные действия.
Действие Назначенный Дата/время Результаты
персонал завершения
действия
Последующая оценка
Этот раздел должен использоваться для документирования даты, времени и места последующей
оценки группы восстановления, включая любую информацию, например, инструкции по
проведению совместной телеконференции.
Дата
Время
Место
Дополнительная информация
Приложение C: Пример таблицы плана связи для серьезных

инцидентов
Таблица плана связи
Номер Менеджер по Дата
инцидент серьезным составления
а инцидентам плана
Номер Дата/время Последнее
версии следующего обновление
таблицы запланированн плана
ого собрания
управления
Тип Составил Заявление Утвердил Дата/время Следующая
заявлени (связь с выпуска запланирован
я документом ная
заявления) дата/время
Фамилия Организац Контактная Требуемы Периодично Метод

получате ия информация й тип сть
ля обновлен
ия

004 ITIL V3 Service Operation OK

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

004 ITIL V3 Service Operation OK

Uploaded by

Copyright:

Available Formats

Функция управления сервисом 1

Функция управления сервисом

Опубликовано: октябрь 2002 г.

Информация, содержащаяся в настоящей документации, представляет собой текущий взгляд

Настоящий документ приводится исключительно в информационных целях. КОРПОРАЦИЯ

Пользователь отвечает за исполнение всех действующих законов об авторском праве.

Корпорация Microsoft может обладать патентами, приложениями, торговыми марками,

Если не отмечено иначе, то приведенные здесь примеры компаний, организаций, продуктов,

© 2005 Microsoft Corporation. Все права защищены.

Microsoft и Windows являются либо зарегистрированными торговыми марками, либо торговыми

Названия упомянутых здесь фактических компаний и продуктов могут являться торговыми

Мониторинг и контроль сервисов .............................................................................................. 73

Резюме для руководства

Управление инцидентами - это критический процесс, который предоставляет организациям

Используя процесс управления инцидентами, организации могут гарантировать, что их ресурсы

Ключевые выгоды управления инцидентами:

Настоящий документ иллюстрирует процессы и действия, вовлеченные в управление

Сервисные запросы (запросына изменение (RFC) или запросы на выполнение пакетных

Затем управление инцидентами обеспечивает структуру, посредством которой инциденты могут

Цели управления инцидентами:

К типичным инцидентам относятся:

Диапазон различных сервисных запросов, полученных ИТ организацией, меняется в

В зависимости от размера и структуры организации некоторые из этих запросов будут

Серьезный инцидент. Инцидент с высокой или потенциально высокой степенью воздействия,

Проблема. Недиагностированная первопричина одного или более инцидентов.

Группы решения. Группы специалистов, работающие над разрешением инцидентов и

Решение. Известно также под названием "постоянное устранение проблемы".

Обходной путь. Идентифицированное средство решения конкретного инцидента, позволяющее

Detected Investigated Resolved

End to end ownership, tracking, and monitoring

Рисунок 1. Жизненный цикл инцидента

Фундаментальной концепцией в рамках управления инцидентами является непрерывное

Если предполагается, что прогресс разрешения инцидента остановился, то служба поддержки

Краткая информация по схеме процесса

На приведенном ниже рисунке показана блок-схема процесса для управления инцидентами.

New incidents - Новые инциденты

Major incident Resolution and

Resolved incidents and

Рисунок 2. Блок-схема процесса управления инцидентами

Главные процессы в рамках управления инцидентами:

 Обнаружение, самообслуживание и регистрация. Этот процесс связан с начальным

Обнаружение, самообслуживание и регистрация

Инциденты могут также обнаруживаться ИТ персоналом, партнерами и поставщиками.

Широко-распространенное использование систем управления событиями является в

Например, если 30 процентов от принятых запросов являются запросами на переустановку

Должна быть составлена таблица типа той, что приведена ниже.

Таблица 1. Таблица самообслуживания

Тип запроса Процент от Разрешено Разрешено Разрешено Разрешено

Из показанной выше таблицы видно, что решения самообслуживания для переустановки

После осуществления действий по внедрению и маркетингу для новых средств самообслуживания, в

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

О высокоприоритетных инцидентах не должно, как правило, сообщаться посредством механизма

Поскольку собирать метрики по запросам, разрешаемым с помощью средств помощи для

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

На рисунке 3 показана регистрационная запись с информацией о пользователе.

Рисунок 3. Регистрационная запись, содержащая подробную информацию о пользователе

Если режим входа осуществляется с использованием вспомогательной клавиатуры телефонного типа, то

Должны рассматриваться и приниматься во внимание другие режимы входа, например, с

Доступ к справочной информации для самостоятельного использования

Организации, вводящие самообслуживание, должны принять во внимание этот пример и стремиться

Это позволяет персоналу, исследующему инцидент, идентифицировать и оценивать первоначальное

На приведенном ниже рисунке показан типичный шаблон регистрационной записи инцидента.

Рисунок 4. Типичный шаблон регистрационной записи инцидента