🔎 Инцидент, запрос на обслуживание, изменение - где границы и как не путать Четкие границы между инцидентом, запросом на обслуживание и запросом на изменение - это скорость и предсказуемость. Далее - простой детектор и чек-листы для бизнес-приложений.
🧠 Что есть что • Инцидент - неплановое прерывание сервиса или ухудшение качества. Цель - быстро вернуть норму. • Запрос на обслуживание - формальная просьба пользователя о предоставлении стандартного сервиса/доступа/информации/операции в бизнес-приложении. Не меняет конфигурацию сервиса, выполняется по заранее описанной процедуре, часто автоматизируется и не требует отдельного согласования. • Запрос на изменение - добавление, модификация или удаление элементов сервиса, инфраструктуры или кода, способное повлиять на сервис. Требует оценки риска и авторизации и планирования.
🧭 Быстрый детектор границ • Есть деградация или простой - инцидент. Ищем обход, откат, перезапуск. • Ничего не сломано, нужна операция в бизнес-приложении: доступ, отчет, выгрузка, консультация - запрос на обслуживание. • Нужно изменить конфигурацию/код/инфраструктуру - запрос на изменение.
🔍 Запрос на обслуживание и изменение - простые проверки • Меняется ли состояние рабочей среды (конфигурация, код, интеграции)? Да - это запрос на изменение. Нет - запрос на обслуживание. • Можно ли автоматизировать выполнение без влияния на сервис? Это запрос на обслуживание. • Требуется тестирование/окно внедрения/план отката? Да - запрос на изменение.
🧩 Примеры в 1С • Не проводят документы в 1С из-за блокировок - инцидент. Цель - восстановить работу, при необходимости откатить релиз. • Создать пользователя 1С и выдать доступ к отчетам - запрос на обслуживание. Без комитета по изменениям. • Обновление конфигурации по требованиям регулятора - запрос на изменение. Оценка риска, окно, откат, уведомления. • Новый обмен 1С - Bitrix24 или смена схемы сообщений - запрос на изменение. Планирование, тестирование, откат. • Разовая выгрузка данных или подготовка отчета без изменений кода - запрос на обслуживание. • Изменился адрес вебхука CRM, обмены перестали приходить - инцидент. Быстрые правки, восстановление.
🚫 Антипаттерны • Регистрируем инцидент как запрос на обслуживание - теряем скорость реакции и увеличиваем среднее время восстановления. • Ведем стандартный запрос на обслуживание через изменения - тормозим поток. • Подменяем запрос на изменение запросом на обслуживание ("просто попросили настроить") - копим неучтенные риски.
✅ Зачем это разделение Разделение потоков убирает конкуренцию задач: срочные сбои не вытесняются рутинными просьбами, запросы по каталогу исполняются быстрее за счет стандартизации и автоматизации. Изменения планируются, детально прорабатываются, проходят оценку риска и план отката - меньше сбоев. Четкая классификация дает честные метрики и предсказуемые сроки - легче защищать бюджет и управлять приоритетами.
