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

1. Общие сведения о процессе

1.1 Цель процесса

Цель процесса Управление инцидентами – скорейшее восстановление доступности и качества предоставления ИТ-услуг и продуктов c целью минимизации ущерба от инцидентов.

1.2 Задачи процесса

Задачами процесса являются:

• Обнаружение инцидентов и их регистрация в СУИТ;

• Техническое расследование и локализация инцидента, поиск варианта решения;

• Возврат ИТ-услуг и продуктов к согласованному уровню доступности и качества предоставления с учётом приоритета инцидента;

• Управление жизненным циклом инцидентов;

• Информирование инициатора и иных участников процесса о статусе обработки инцидента;

• Анализ перечня инцидентов на предмет повторяющихся инцидентов;

• Формирование предложений по улучшению процесса, ИТ продуктов и услуг по итогам анализа инцидентов.

1.3 Принципы процесса

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

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

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

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

• Политика определения значительных инцидентов – описание критериев определения значительных инцидентов от остальных.

• Процесс управления инцидентами является единым и единственным для всех подразделений Организации, вовлеченных в предоставление ИТ-услуг и продуктов.

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

• Инициаторами и источниками информации о возникших инцидентах являются:

  • пользователи (обращения пользователей, зарегистрированные службой поддержки пользователей);

  • ИТ-сотрудники (имеют возможность самостоятельно регистрировать инциденты);

  • системы мониторинга и объективного контроля (автоматическая регистрация инцидентов).

• При регистрации инцидентов проверяется, авторизован ли инициатор регистрировать инцидент по данной ИТ-услуге или продукту (является ли инициатор пользователем ИТ-услуги или продукта Организации, сотрудником Организации, или частью команды услуги или продукта). Если он не авторизован, инцидент от его имени не регистрируется. Исключение допускается для пользователей массовых услуг, групп мониторинга, а также в частном порядке, если список авторизованных инициаторов указан в Соглашениях об уровне ИТ-услуг.

• Запрещено регистрировать инциденты для непродуктивных сред ИТ-услуг и продуктов. Исключения возможны для тестовых и иных сред ИТ-услуг и продуктов, которые непосредственно участвуют в жизненном цикле релизов ПО продуктивной среды ИТ-услуги или продукта. Допускается создание тестовых инцидентов для тестирования систем мониторинга, проверки модулей автоматизации в СУИТ, тестирования интеграций СУИТ.

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

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

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

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

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

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

• Повышение приоритета инцидента разрешено назначенному на инцидент ИТ-специалисту без согласования. Понижение – только через согласование с ответственными за ИТ-услугу или продукт.

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

• Принцип постоянного улучшения процессов реализуется через стандартизированные операции, описанные в практике РИТМ 1.5 Управление ИТ-процессами.

2. Границы и связи процесса

2.1 Входы в процесс

2.2 Выходы из процесса

2.3. Границы применения процесса

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

• Расследование корневых причин инцидентов;

• Коммуникации с пользователями;

• Внедрение изменений в продукты и ИТ-услуги;

• Мониторинг технологий, команд и эффективности работы поставщиков;

• Управление инициативами по совершенствованию;

• Управление восстановлением нормальной работы в случае чрезвычайной ситуации (Управление непрерывностью).

• Работа с тестовыми инцидентами (при тестировании мониторинга, проверки правильного авто-формирования приоритета и др.)

• Работа с инцидентами из непромышленных сред, за исключением случаев, когда непромышленная среда влияет на промышленную (пример, пред-промышленная или тестовая среда релизного цикла продукта)

3. Объекты процесса

3.1. Описание объектов

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

Процесс может использовать данные из объектов иных процессов:

• Запросы на обслуживание (см. процесс «Управление запросами на обслуживание»);

• Проблемы и известные ошибки (см. процесс «Управление проблемами»).

• ИТ-изменения (см. процесс «Управление инфраструктурными изменениями»).

• Статьи Базы знаний (см. процесс «Управление знаниями»).

• Данные БДКЕ (см. процесс «Управление конфигурациями»).

• Задачи (см. процесс «Управление плановыми работами»).

3.2. Классификация объектов

Наименование ИТ-услуги/ИТ-продукта

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

Влияние

Влияние отражает масштаб инцидента или значительность последствий для организации или потребителей.

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

Срочность

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

Приоритет

Расчёт приоритета в виде Матрицы приоритетов создается с целью корректного выбора приоритета инцидента на основе его срочности и влияния на ИТ-услуги, Критичные бизнес-функции и процессы, промышленные среды.

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

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

Матрица приоритетов

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

Значительный инцидент

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

Таким инцидентом можно считать:

- инцидент с приоритетом "1", который произошел с Критичной бизнес-функцией;

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

Категория

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

Можно установить высокоуровневые категории, такие как «Аппаратное обеспечение», «ПО», «Сеть», «СХД», «Облачные услуги» - категории, которые легко можно установить, глядя на описание и источник инцидента. Слишком подробные, многоуровневые категории в этом атрибуте использовать нежелательно, но можно использовать отдельный атрибут, например «Под-категория», который будет связан с каждым родительским атрибутом «Категория» и раскрывать подробнее каждую категорию более подробно (например, Категория = «ПО», Подкатегория «Операционная система», или «Сеть: VPN»).

Затронутая инцидентом конфигурационная единица (КЕ)

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

3.3. Жизненный цикл объектов

3.4. Атрибутивный состав объектов

4. Описание ролей в процессе

4.1 Роли процесса

4.2 RACI-матрица

5. Описание процесса

5.1 Схемы процесса и описание процедур

5.1.1 Общая схема процесса

5.1.2 Детализированные схемы процесса

5.1.2.1 Диагностика инцидента

5.1.2.2 Восстановление сервиса и решение инцидента

5.1.2.3 Управление значительными инцидентами

5.2 Артефакты (материалы, документы, следы) процесса

• Карточка инцидента

• Список исполнителей процессных ролей

• Диаграмма взаимосвязей ПО, используемого процессом

• Шаблоны оповещений

• Шаблоны решения инцидентов

• Формы отчетов или дэшборды по метрикам и КПЭ процесса

6. Обеспечение работы процесса

6.1 Ценность процесса

6.1.1 Описание ценности процесса для каждой группы заинтересованных лиц

6.1.2 Ключевые факторы успеха

6.1.2.1 Ключевые факторы успешного внедрения

• Согласование целей организации с целями процесса

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

• Прозрачность проекта внедрения процесса, оценки рисков и проблем

• Целевые временные показатели в SLA отражают критичность соответствующих ИТ-услуг, продуктов и бизнес-процессов, зависящих от них

• Наличие подробного и актуального каталога продуктов и услуг

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

• Формальное утверждение регламентов и других артефактов процесса

• Обучение ролей процессу до начала его использования

• Согласование и внедрение необходимых политик

• Наличие функционального СУИТ-продукта с модулем управления инцидентами и предварительное обучение его пользователей и администраторов

• Если используется внешний для организации СУИТ-продукт (например SaaS-система) - зафиксировать должный уровень качества предоставления облачной услуги в договоре с провайдером/вендором этого продукта

• Присутствует ПО для составления и автоматизации отчетности или соответствующий модуль в системе управления ИТ (СУИТ)

• Стремление к автоматизации простых операций и распределение нагрузки решения инцидентов

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

6.1.2.2 Ключевые факторы успеха функционирования процесса

• Быстрое решение инцидентов

• Поддержка высокого качества предоставления услуг

• Поддержка высокого уровня удовлетворения пользователей услугами и продуктами

• Поддержка продуктивности организации через улучшение ИТ-продуктивности

• Процесс хорошо описан и интегрирован с другими процессами (обязательна интеграция с Управлением конфигурациями)

• Процесс хорошо автоматизирован, система СУИТ интегрирована с источниками данных (кадровой системой, системой мониторинга и пр.)

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

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

• Ключевые шаги и метрики процесса контролируются автоматически. Влияние человеческого фактора сведено к минимуму

• Все метрики процесса измеряются и оцениваются на регулярной основе

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

6.1.3 Скрытые деструктивные сценарии

• Отложенная регистрация инцидентов

• Обязательный поиск первопричин инцидентов в рамках решения инцидентов (исключение - значительные инциденты)

• Регистрация инцидентов для непродуктивных сред услуг и продуктов (исключение - тестовые среды для промышленных релизов ПО)

• Инциденты для проектной деятельности вне продуктивных сред

• Отсутствие категоризации инцидентов

• Отсутствие целевых временных параметров решения инцидентов

• Несвоевременное выставление статусов

• Отсутствие отчетности и анализа параметров процесса

• Отсутствие ответственности за нарушения процесса

• Отсутствие менеджера процесса

• Процесс не соответствует целям организации

• Многочисленные переназначения инцидента между группами и сотрудниками

6.2 Метрики процесса

Список возможных метрик, которые может выбрать для себя организация в качестве ключевых показателей эффективности (КПЭ):

6.3 Системы, методы и данные для работы процесса

6.3.1 Системы

• Система управление ИТ (СУИТ, или ITSM система)

• БДКЕ (CMDB)*

• Система управления ИТ-активами*

• Портал самообслуживания*

• Парсеры электронной почты*

• Чат-боты и системы коммуникации (мессенджеры)

• Системы мониторинга

• База знаний*

• Системы наблюдаемости

• Системы удаленного администрирования

• Системы ИИ* (классификация инцидентов, автоматическое решение)

• Системы диагностики и записи состояния элементов ИТ-инфраструктуры

• Системы развёртывания

• Система отчетности или BI-аналитики

* отдельные системы, если не входят в состав СУИТ

6.3.2 Данные⁠

⁠6.3.3. Методы, используемые в процессе

Возможные методы, которые используются на практике:

• реактивное решение инцидентов - решение инцидентов при их поступлении со службы поддержки и систем мониторинга;

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

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

• иерархическая эскалация инцидентов - модель назначения ответственных за решение на основе их установленных уровней экспертизы, где:

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

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

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

• роение - в рамках подпроцесса управления значительными инцидентами. Метод, описанный компанией Cisco в 2008 году и закрепленный в виде подхода организацией «Consortium for Service Innovation».

Примечание: данное количество и назначение уровней не ультимативно и может быть изменено под особенности организации;

• автоматическое назначение инцидентов - используя технические возможности СУИТ:

  • автоматическое назначение инцидента на ответственную за решение команду на основе атрибутов инцидента (например, имени ИТ-услуги или ИТ-продукта), затронутого инцидентом;

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

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

• правило «Трех дней» - автоматическое закрытие пол истечению трёх дней системой СУИТ тех решенных инцидентов, для которых требуется формальное подтверждение решения со стороны Пользователя, и оно не получено в рамках трёх рабочих дней.

СУИТ автоматически, или служба поддержки высылают уведомление о необходимости подтвердить решение в момент установления статуса «Решен». Далее, если нет ответа – высылают еще одно уведомление на второй день. Если второе уведомление остается без ответа, высылается последнее уведомление – на третий день. В последнем - Пользователь предупреждается, что инцидент будет закрыт окончательно, если пользователь не ответит. По истечению третьего дня без ответа инцидент закрывается.