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

Записаться

Управление инцидентами, изменениями и конфигурациями

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

Участники процесса

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

• квалификация сотрудников;
• оптимальная численность, чтобы процесс работал эффективно.

Прежде всего это служба Service Desk (сервис-деск). В неё входят линии поддержки: первая, вторая и третья. Они смотрятся слева направо на схеме процесса.

Инцидент

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

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

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

В ITIL (IT Infrastructure Library, библиотека инфраструктуры ИТ) инцидент — это любое событие, не являющееся частью стандартных операций по предоставлению услуг. Он не связан только с ошибками и сбоями.

Запрос на обслуживание и запрос на изменение

Отдельное событие — запрос на обслуживание (service request). По сути это не инцидент, а именно запрос: предоставление информации или запрос помощи. Но в ITIL он тоже относится к инцидентам.

Запрос на изменение (request for change) — это не просто информация. Это требование выполнить действие, которое что-то изменит в инфраструктуре.

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

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

Такое изменение безопасно, потому что оно прогнозируемое и предусмотренное. Можно заранее решить, как выполнить его без проблем.

Изменения от процессов

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

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

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

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

Реализация изменения

Варианты реализации:

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

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

Взаимосвязь процессов

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

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

Краткие итоги

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

Практическая ценность начинается с дисциплины первой точки контакта: Service Desk фиксирует событие и запускает обработку, а линии поддержки подключаются по мере сложности. Однако скорость реакции сама по себе недостаточна. Устойчивость появляется, когда запросы на изменение анализируются через зависимости инфраструктуры.

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

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