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

Введение

Управление ИТ-услугами (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. Среднее время на восстановление сервиса, позволяет взаимодействовать ИТ-организации со своими потребителями и соотносить достигнутый уровень производительности с целевым уровнем сервиса

Заключение

Разработка процессов и процедур управления инцидентами проводится многими организациями, но далеко не все эти организации делают то же самое для управления проблемами. Часто это происходит из-за недостаточно ясного понимания характеристик этих двух видов деятельности. Управление инцидентами — простейший вид деятельности для понимания, поскольку он просто создает механизм для реагирования на прерывания сервиса. Поскольку «визгливое колесо всегда будет смазано», то управление инцидентами развивается достаточно быстро. Однако для развития управления проблемами часто имеется меньше поводов.

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

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