Управление инцидентами и проблемами — понятия и принципы

Введение

Управление ИТ-услугами (ITSM) включает работу с инцидентами и проблемами. По мере возрастания роли ИТ в компании растет и потребность в доступности ИТ-услуг. Бизнес-пользователь ожидает решения проблем, как можно быстрее. Реализация процессов управления инцидентами и проблемами нацелена на это. Ниже описано, как устроена работа ИТ-службы с точки зрения управления инцидентами и проблемами. Это описание основано на предложениях ITIL и опыте наших клиентов.

Язык инцидентов и проблем

ITIL Service Support — признанная в мире модель. Основана на передовом опыте и используется как руководство ИТ-организациями для управления. Также определяет дополнительные элементы, необходимые для функционирования ИТ-организации как сервисного бизнеса. Предоставляет технический словарь для обсуждения службы поддержки, определяет понятия и раскрывает отличия между видами деятельности. Например, деятельность, необходимая для реагирования на прерывания или восстановления сервиса, отличается от деятельности по поиску и устранению причин, из-за которых прерывается обслуживание.

Инциденты

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

Примеры инцидентов:

1. Пользователь не может получить e-mail
2. Средство мониторинга сети указывает, что канал связи вскоре переполнится
3. Пользователь ощущает замедление работы приложения

Проблемы

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

Ошибки

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

Примеры ошибок включают:

1. Неправильная сетевая конфигурация компьютера
2. Средство мониторинга неверно определяет статус канала в момент занятости маршрутизатора

Соотношение понятий управления инцидентами и проблемами показано на рисунке 1. Инциденты, проблемы и известные ошибки связаны в жизненный цикл: инциденты это индикаторами проблем ⇒ выявление причины проблемы определяет ошибку ⇒ ошибки затем систематически исправляются.

Управление инцидентами

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

Включает в себя:

1. Выявление и регистрация инцидентов
2. Классификация и начальная поддержка
3. Исследование и диагностика
4. Решение и восстановление
5. Закрытие
6. Владение, мониторинг, отслеживание и связь

Управление проблемами

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

Управление проблемами включает:

1. Контроль проблем
2. Контроль ошибок
3. Предотвращение проблем
4. Анализ проблем

Контроль проблем

Цель контроля проблем — найти причину проблемы, выполнив следующие шаги:

1. Идентификация и регистрация проблем
2. Классификация проблем и определение приоритетов
3. Исследование и диагностика причин

Контроль ошибок

Контроль ошибок исправляет проблемы за счет следующих действий:

1. Идентификация и регистрация известных ошибок
2. Оценка способов устранения и расстановка приоритетов
3. Регистрация по временному обходу ошибки в средствах службы поддержки
4. Закрытие известных ошибок путем исправления
5. Мониторинг известных ошибок для определения необходимости в изменении приоритетов

Анализ проблем

Цель анализа проблем состоит в улучшении процессов управления инцидентами и управления проблемами. Достигается изучением качества результатов по устранению проблем и инцидентов.

Организационные роли и распределение ответственности

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

Первый уровень поддержки

Организация (подразделение), представляющая первый уровень поддержки как правило относится к оперативным службам и называется диспетчерской службой, Call Center, Help Desk, Service Desk.

Роли. Владелец процесса

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

Первая линия поддержки

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

Обязанности

• Точная регистрация инцидентов. Первый уровень поддержки гарантирует, что информация об инциденте вносится в журнал системы. Для этого должно быть:

  • Гарантировано, что карточка инцидента содержит точное и детальное описание проблемы
  • Гарантирован правильный выбор важности/приоритета инцидента
  • Определена природа проблемы, контакты пользователя, влияние на бизнес и ожидаемое время решения

• Владение каждым инцидентом. Как адвокат конечного пользователя первый уровень поддержки обеспечивает успешное разрешение каждого инцидента. При этом гарантируется своевременное решение вопросов за счет:

  • Разработки и управления планом действий по решению вопроса
  • Инициации конкретных назначений заданий для персонала и бизнес-партнеров
  • Эскалации инцидента, если требуется, когда цель не достигается во время
  • Обеспечения внутреннего взаимодействия в соответствии с целями обслуживания
  • Защиты интересов вовлеченных бизнес-партнеров

• Первый уровень поддержки использует базу данных управления проблемами для сопоставления инцидентов известным ошибкам и применения ранее найденных способов разрешения инцидентов. Цель заключается в разрешении 80 процентов инцидентов. Остальные инциденты передаются (эскалируются) на второй уровень.

• Непрерывное улучшение процесса управления инцидентами. Как владелец данного процесса первый уровень поддержки гарантирует улучшение при необходимости процесса посредством:

  • Оценки эффективности данного процесса и таких механизмов поддержки, как отчеты, виды связи и форматы сообщений, процедуры эскалации
  • Разработки специфических для подразделений отчетов и процедур
  • Поддержки и совершенствования взаимодействия и списков эскалации
  • Участие в процессе анализа проблем

Способности и навыки

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

Второй уровень поддержки

Этот уровень относится к оперативным службам.

Роли

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

Обязанности

• Решение инцидентов, переданных с первого уровня. Если для первого уровня поддержки ожидается, 80% решения инцидентов, то для второго уровня поддержки ожидается 75% решения инцидентов, переданных первым уровнем, то есть 15% от числа зарегистрированных инцидентов. Остальные инциденты передаются на третий уровень.
• Определение причин проблем. Второй уровень поддержки определяет причины проблем и предлагает меры по обходу или устранению. Привлекает и управляет другими ресурсами для определения причин. Решение проблем передается на третий уровень, когда причина заключается в архитектурном или техническом вопросе, который превышает их уровень квалификации.
• Обеспечение реализации исправлений и устранений проблем. Второй уровень поддержки инициирует проекты в организациях разработчиках для устранения известных ошибок. Документирует найденные решения, сообщает о них персоналу первого уровня и реализует эти решения в инструментах.
• Постоянный мониторинг инфраструктуры. Второй уровень поддержки пытается идентифицировать проблемы до возникновения инцидентов посредством наблюдения за компонентами инфраструктуры и принятия корректирующих действий при обнаружении дефектов или ошибочных тенденций.
• Заблаговременный анализ тенденций инцидентов. Уже случившиеся инциденты исследуются для того, чтобы определить наличие проблем, которые следует исправить. Исследуются те инциденты, которые закрыты и не сопоставлены известным проблемам, на предмет наличия потенциальных проблем.
• Постоянное совершенствование процесса управления проблемами. Второй уровень поддержки гарантирует, что процесс и возможности адекватны и улучшает их при необходимости. Проводит сессии анализа проблем, чтобы выявить полученные уроки и гарантировать, что средства контроля над процессом, такие как совещания и отчеты, адекватны.

Способности и навыки

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

Третий уровень поддержки

Этот уровень поддержки относится к группе разработки приложений и сетевой инфраструктуры.

Роли

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

Обязанности

• Решение инцидентов, переданных со второго уровня. Так как большинство инцидентов вызывается известными ошибками, 5% инцидентов проходит через второй уровень на третий. Третий уровень отвечает за решение всех инцидентов, которые к ним поступают.
• Участие в деятельности по управлению проблемами. Третий уровень поддержки задействован в поиске причин, способов обхода и устранения ошибок.
• Реализация мер по устранению ошибок из инфраструктуры. У третьего уровня, роль в планировании, конструировании и реализации проектов по устранению недостатков инфраструктуры. Выполнение этих проектов согласовано с рутинной работой по развитию инфраструктуры для достижения нужного баланса.

Способности и навыки

• Эксперты в соответствующих областях. Команды третьего уровня - эксперты, которые планируют и проектируют ИТ-инфраструктуру.

Процессы

Можно выделить три основных процесса, связанных с управлением инцидентами и управлением проблемами:

• процесс управления инцидентами
• процесс контроля проблем
• процесс контроля ошибок

Эти процессы присутствуют в большинстве передовых организаций, хотя могут иметь и другие названия.

Процесс управления инцидентами

Данный процесс сфокусирован на скорейшем восстановлении прерванного сервиса. В таблице 1 приведены основные параметры этого процесса, а на рисунке 1 показана диаграмма его работы.

Таблица 1. Параметры процесса

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

Рисунок 1. Модель процесса

Процесс контроля проблем

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

Таблица 2. Параметры процесса управления проблемами

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

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

Рисунок 2. Модель процесса контроля проблем

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

1. Если у вас достаточное количество проблем, то назначьте постоянную команду. Иначе создавайте команду при появлении проблемы, также как формируется команда под проект;
2. Команда должна быть с междисциплинарным опытом и знаниями;
3. Оцените время на определение причины в момент появления проблемы. В соответствии с этой оценкой следует измерять прогресс в деятельности команды.

Популярные методы поиска причин проблем: Анализ Кепнера и Трего, диаграммы Ишикавы, диаграммы Парето и прочее.

Процесс контроля ошибок

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

Таблица 3. Параметры процесса управления ошибками

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

Рисунок 3. Модель процесса контроля ошибок

Взаимодействия

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

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

В случае важных инцидентов автоматическая рассылка дополняется сообщениями составленными вручную.

Эскалация

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

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

Функциональная эскалация

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

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

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

Иерархическая эскалация

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

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

Отчеты и совершенствование процессов

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

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

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

Такие отчеты позволяют руководителям принимать решения о распределении ресурсов, направлении усилий персонала. Регулярное использование параметров типа:

1. Среднее время обработки карточек на каждом из уровней
2. Количество карточек, переданных и решенных на каждый из уровней, могут помочь выявить слабости ИТ-инфраструктуры

Наконец жизненно необходимый набор отчетов, типа:

1. Процент инцидентов, решенных в заданные сроки
2. Среднее время на восстановление сервиса, позволяет взаимодействовать ИТ-организации со своими потребителями и соотносить достигнутый уровень производительности с целевым уровнем сервиса

Заключение

Управление инцидентами проще, чем управление проблемами. Организации часто уделяют больше внимания управлению инцидентами, потому что это более очевидная и срочная задача.

Управление проблемами требует более системного подхода, как управление портфелем проектов. Организация должна:

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

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