Если инцидент закрыт, это не значит, что проблема решена

Пятница, 23:40, прод лежит. Дежурный поднимает сервис за сорок минут: перезапустил контейнер, всё заработало. Инцидент закрыт, MTTR красивый, все спать.

Через десять дней то же самое: тот же сервис, та же ошибка в логах. Снова подняли и снова закрыли.

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

Никто не забыл — просто в процессе нет явного владельца за фиксацию проблемы. Ответственность размазана между поддержкой и разработкой.

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

Почему две хорошие системы не равны одному процессу

Всем привет, это команда SimpleOne SDLC. Давайте в этой статье обсудим такую мысль: системы поддержки (сервис деск, ITSM) и трекер разработки должны друг в друг интегрироваться, или пусть живут отдельно и решают свои собственные задачи?

Системы поддержки работают в логике «потушить»: инцидент закрыт → SLA выполнен → все довольны (премии быть). Цель — восстановить сервис, а не устранить причину. В этом дизайн системы: например, тот же стандарт ITIL разграничивает «инцидент» и «проблему» намеренно, ведёт их параллельно, чтобы не тормозить восстановление разбирательством о первопричинах.

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

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

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

Как может выглядеть сквозной процесс и автоэскалация

Глобально процесс примерно такой:

Альтернативный подход — обрабатывать инциденты полностью на стороне саппорта и передавать в разработку только вручную отобранные кейсы.

Он проще на старте, но при росте обращений приводит к потере части информации и задержкам.

И вот что происходит с обеих сторон:

• У агента поддержки: когда сервис упал и инцидент зарегистрирован, дежурный в процессе восстановления может заметить, что это уже второе падение за месяц. В таком случае прямо с формы инцидента он нажимает «Создать дефект»: поля заполняются автоматически — тема, описание, приоритет, вложения со скриншотами. Дефект уходит в бэклог разработки. Агент выходит покурить, а затем закрывает инцидент и продолжает работу, не переключаясь в трекер, не копируя текст вручную.

После того как разработчик берёт дефект в работу, в активити фид инцидента автоматически появляются уведомления: «Дефект взят в разработку», затем «Выпущено». Агент видит прогресс без единого запроса в Telegram. Более того, он знает, что с этим конкретным инцидентом ему больше разбираться не придётся.

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

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

Где подход может не сработать:

• при отсутствии нормального triage бэклог быстро засоряется

• большое количество дубликатов инцидентов увеличивает шум

• для маленьких команд процесс может быть избыточным

А может, лучше пусть отдельно?

Прежде чем строить мосты, честно ответим на вопрос: а точно нужно?

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

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

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

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

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

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

Как понять, что вам надо связать поддержку с разработкой

Вот три признака, что пора:

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

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

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

***

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

Как у вас устроена передача контекста между поддержкой и разработкой — формально или на личных договорённостях?