Авария, плановая работа, изменение и проблема требуют разных правил управления. Если все называть аварией, SLA превращается в спор о словах. Если плановую работу маскировать под обычную заявку, бизнес внезапно получает простой без предупреждения. Рабочий подход начинается с классификации события: что уже сломано, что меняется осознанно, что временно ограничивается и кто должен быть заранее предупрежден.
Базовая модель
Инцидент - это незапланированное ухудшение сервиса: пользователи не могут работать, данные недоступны, связь нестабильна, важная система отвечает с ошибками. Цель управления инцидентом - быстрее восстановить нормальную работу и зафиксировать последствия.
Плановая работа - заранее согласованное действие в окне обслуживания: обновление, перенос, замена оборудования, проверка восстановления, настройка мониторинга. Она может временно ограничить сервис, но это ограничение известно до начала.
Изменение - любое осознанное вмешательство в инфраструктуру, которое может повлиять на сервис: новая политика, миграция, настройка маршрутизации, замена сервера, изменение прав. Изменение может проходить без простоя, но все равно требует владельца, проверки и плана возврата.
Проблема - причина повторяющихся или серьезных инцидентов. Ее не всегда можно устранить сразу. Для проблемы важны анализ причин, постоянное исправление и временные меры, которые снижают риск до завершения работ.
Быстрая классификация
| Вопрос | Если да | Что это обычно значит |
|---|---|---|
| Сервис уже работает хуже нормы без согласованного окна? | Да | Инцидент |
| Ограничение было заранее согласовано с бизнесом? | Да | Плановая работа или изменение |
| Действие меняет конфигурацию, зависимость или режим эксплуатации? | Да | Изменение, даже если простоя нет |
| Событие повторяется и требует устранения причины? | Да | Проблема |
| Пользователь просто просит стандартную помощь? | Да | Заявка на обслуживание |
Эта таблица не заменяет здравый смысл. Например, плановое обновление, которое вышло за окно и остановило сервис, сначала становится инцидентом восстановления, а уже потом разбирается как неудачное изменение.
Чем отличается управление
| Тип события | Главная цель | Кто должен знать | Что фиксировать |
|---|---|---|---|
| Инцидент | Восстановить сервис | Пользователи, владелец сервиса, поддержка | начало, влияние, приоритет, действия, восстановление, причина если известна |
| Плановая работа | Выполнить согласованный объем | затронутые подразделения, сервис-деск, ответственный за бизнес-процесс | окно, объем, риск, контакт, критерии завершения |
| Изменение | Безопасно поменять состояние системы | владелец сервиса, инженер, поддержка | причина, план, проверка, откат, результат |
| Проблема | Убрать повторяемую причину | владелец риска, технический ответственный | симптомы, гипотезы, временные меры, постоянное решение |
| Заявка | Выполнить стандартную работу | заявитель и поддержка | запрос, статус, результат |
Что сделать до плановой работы
Плановая работа должна быть видимой до начала. Минимальный набор: цель, затронутые сервисы, ожидаемое влияние, окно, ответственный, критерии успеха, критерии остановки и способ отката. Если работа может затронуть пользователей, им нужно сообщить не технические подробности, а практическое последствие: когда сервис может быть недоступен, что делать в это время и куда обращаться при проблемах после окна.
Для регулярной поддержки важно отделять окно обслуживания от обещанного уровня сервиса. Согласованное окно не должно считаться обычной аварией, но и не должно становиться способом скрывать плохо подготовленные изменения. Если окно превышено, последствия фиксируются отдельно.
Как не путать SLA
SLA обычно описывает реакцию и восстановление для инцидентов, но не должен слепо переноситься на любую активность. У заявки на подключение рабочего места, аварии файлового сервера и плановой миграции разные ожидания. Ошибка в классификации дает плохую управляемость: отчет показывает нарушение там, где была согласованная работа, или не показывает простой, потому что его назвали задачей.
Хороший SLA-отчет разделяет инциденты, плановые окна, изменения и повторяющиеся проблемы. Тогда руководитель видит не только проценты, но и причины: что действительно ломалось, что было запланировано, какие изменения прошли успешно и какие риски требуют отдельного решения.
Типовые ошибки
- любое обращение пользователя называют инцидентом, и очередь поддержки теряет приоритеты;
- любое инженерное действие называют заявкой, и изменения проходят без оценки риска;
- плановые работы согласуют только внутри IT, а бизнес узнает о простое в момент недоступности сервиса;
- после неудачного изменения обсуждают только скорость восстановления, но не меняют процесс подготовки;
- повторяющиеся инциденты закрывают по одному, не заводя проблему и постоянное исправление.
Практический минимум процесса
Достаточно пяти правил. Первое: у каждого события есть тип. Второе: тип можно изменить, если факты изменились. Третье: плановое влияние на сервис согласуется заранее. Четвертое: изменение имеет владельца проверки и отката. Пятое: повторяемые сбои собираются в проблему, а не растворяются в истории заявок.
При таком подходе ITSM не превращается в бюрократию. Он помогает всем участникам говорить на одном языке: поддержка понимает, что восстанавливать, инженер - что менять, руководитель - где был реальный риск, а пользователь - чего ожидать.
Для управляемого процесса это связано с ITSM-практиками: заявки, инциденты, изменения, SLA и отчетность должны работать вместе. Подробнее о таком подходе смотрите в разделе ITSM.
Итог: аварию отличает незапланированное ухудшение сервиса, плановую работу - заранее согласованное влияние, изменение - управляемое вмешательство в состояние системы, а проблему - причина повторяющихся сбоев. Если эти типы не смешивать, поддержка быстрее восстанавливает сервис, а отчетность становится полезной для решений.