Повторяющийся IT-инцидент опасен тем, что каждый раз выглядит как отдельная мелочь. Пользователю снова перезапустили приложение, провайдер снова «проверяет линию», backup снова запустили вручную, Wi-Fi снова ожил после перезагрузки точки. Заявка закрыта, но причина осталась.
После второго или третьего похожего случая вопрос должен измениться: не «как быстро закрыть заявку», а «почему это возвращается и какое постоянное действие докажет, что проблема снята».
Когда инцидент считать повторяющимся
Повторяемость - это не только одинаковый текст заявки. Проблема может выглядеть по-разному для пользователей, но иметь одну техническую или организационную причину: перегруженный канал, нестабильный коммутатор, нехватка места, слабый регламент изменений, неверный порог мониторинга, зависимость от одного внешнего поставщика.
Практичный критерий: если похожий сбой затрагивает один сервис, одну группу пользователей, одно место, один период времени или один тип оборудования, его нужно связать с предыдущими случаями и разобрать как проблему, а не как новую случайность.
Собрать факты, а не впечатления
Разбор начинается с короткой фактической картины: когда повторялось, кого затрагивало, сколько длилось, что временно помогало, какие изменения были перед первым случаем, что показывали мониторинг и заявки, какие внешние зависимости участвовали.
Не нужно превращать это в длинный отчет. Достаточно таблицы или карточки: дата, симптом, влияние, временное действие, доказательство, статус. Важно, чтобы следующий инженер видел не устные версии, а проверяемую историю.
Workaround не равен исправлению
Временный обход нужен, чтобы вернуть работу: перезапустить сервис, переключить канал, освободить место, выдать временный доступ, перевести пользователей на запасной процесс. Но workaround не должен исчезать вместе с закрытой заявкой.
После обхода нужно записать: что он восстанавливает, какие ограничения оставляет, как долго допустим, кто следит за повтором и какое постоянное действие требуется. Иначе временное решение становится постоянной привычкой, а риск накапливается незаметно.
Назначить владельца проблемы
У повторяющегося инцидента должен быть владелец. Это не всегда человек, который первым принял заявку. Владелец отвечает за то, чтобы причина была разобрана, действие согласовано, изменение выполнено, результат проверен, а повтор отслеживался.
В рамках ITSM ответственным за процесс может быть IT-подрядчик, но влияние и приемку часто подтверждает владелец сервиса со стороны бизнеса. Например, только руководитель отдела может сказать, достаточно ли временного обхода или простой уже требует изменения приоритета.
Искать причину в системе, а не виноватого
Цель разбора - не найти человека, который ошибся, а увидеть слабое место процесса или инфраструктуры. Повтор может появляться из-за старого оборудования, отсутствия мониторинга, неполной документации, неудачного окна работ, слабой эскалации к провайдеру, ручного действия без проверки или отсутствия владельца сервиса.
Хороший вопрос: что должно измениться, чтобы тот же сценарий не повторился при тех же условиях. Если ответ звучит как «будем внимательнее», постоянного действия еще нет.
Постоянное действие должно быть проверяемым
Permanent fix может быть техническим, процессным или организационным: заменить проблемный узел, изменить схему мониторинга, обновить регламент, добавить контроль backup, пересмотреть расписание работ, уточнить договор с провайдером, обучить первую линию задавать правильные вопросы.
Любое действие должно иметь критерий приемки. Не «улучшить Wi-Fi», а «исключить повторные обрывы в переговорной в рабочие часы и подтвердить мониторингом/жалобами за наблюдаемый период». Не «разобраться с backup», а «устранить причину падения задания и получить успешную копию плюс понятное уведомление владельцу».
Связать исправление с изменением
Если постоянное действие меняет конфигурацию, сервис, расписание, оборудование или процесс, его нужно провести как управляемое изменение: scope, риск, окно, откат, коммуникация, проверка. Даже небольшая правка может создать новый инцидент, если сделана без понимания зависимостей.
Это не бюрократия ради формы. Изменение показывает, почему команда решила действовать именно так, кто согласовал риск и как доказали результат после выполнения.
Как закрывать повторяющуюся проблему
- Связать новые заявки с предыдущими похожими случаями.
- Зафиксировать влияние на пользователей и бизнес-сервис.
- Отделить временный обход от постоянного исправления.
- Назначить владельца проблемы и владельца приемки результата.
- Выбрать действие, у которого есть проверяемый критерий успеха.
- Провести изменение с понятным rollback, если оно затрагивает production.
- Наблюдать период после исправления и отметить, повторился ли сценарий.
Что показывать руководителю
Руководителю не нужен полный технический журнал. Ему важно видеть: какой повторяющийся сценарий найден, сколько он стоил во времени или риске, что временно удерживает работу, какое постоянное действие выбрано, кто владелец и когда будет проверка результата.
Если повторов много, полезно смотреть не только на отдельные причины, но и на общий рисунок. Частые повторы по сети говорят о техническом долге. Повторы по доступам - о слабом процессе изменений сотрудников. Повторы по backup - о недостаточном контроле восстановимости. Повторы по провайдерам - о внешней зависимости без нормальной эскалации.
Итог: повторяющийся IT-инцидент нельзя лечить только скоростью реакции. Быстрая поддержка важна, но зрелость появляется тогда, когда команда видит повтор, назначает владельца, устраняет причину и проверяет, что проблема не вернулась.