Внутренний регламент команды разработки: работа с инцидентами
1. Ключевые определения
Инцидент — это любая ошибка или проблема, обнаруженная на продакшн-окружении. Факт обнаружения на проде автоматически делает задачу инцидентом вне зависимости от её масштаба. Инцидент может быть заведен любым членом команды, а также может поступить из Service Desk порталов.
При появлении любого инцидента (не только из Service Desk) дежурный и вся команда автоматически получает нотификацию в Rocket Chat в чате Dev.
Все остальные задачи (баги на тестовых окружениях, фичи, технические задачи, задачи по улучшению) — не являются инцидентами и живут в общем флоу бэклога.
2. Принципы процесса
- Инцидент требует немедленного внимания — его нужно взять в разбор сразу после обнаружения.
- Взять в разбор ≠ немедленно исправить. Сначала — анализ, потом — решение о действиях.
- По итогам разбора дежурный принимает одно из трёх решений: фиксить сейчас / завести задачу в бэклог / отменить инцидент.
- Задачи, заведённые из инцидентов, идут в общий бэклог и приоритизируются по стандартным правилам, но сохраняют связь с исходной задачей-инцидентом для контекста.
3. Роль дежурного разработчика
Ответственность за разбор инцидентов несёт дежурный разработчик — выделенная роль с еженедельной ротацией.
| Аспект | Описание |
|---|---|
| Ротация | Еженедельная, среди мидлов и сеньоров. График составляется тимлидом заранее. |
| Нагрузка | Дежурная неделя = сниженная производительность по задачам спринта. Это норма и учитывается при планировании. |
| Эскалация | Если ситуация непонятна — эскалировать тимлиду в течение 5 минут. Тимлид не исполнитель, а второй уровень поддержки. |
| Полномочия | Дежурный самостоятельно принимает решение: фикс сейчас / бэклог / отмена. При соответствии критериям немедленного фикса — действует без согласования. |
4. Роль лида в процессе
Лид — это второй уровень в процессе работы с инцидентами. Он не занимается разбором напрямую, но обеспечивает соблюдение процесса: дежурный реагирует в срок, разбор качественный, задачи оформлены корректно и не теряются.
Зоны ответственности
| Зона | Обязанность лида | Триггер / когда действовать |
|---|---|---|
| SLA | Пинговать дежурного, если реакция на инцидент вышла за рамки SLA. | Через 15 мин после появления инцидента без реакции дежурного. |
| Качество разбора | Проверить, что результаты разбора зафиксированы в комментарии к инциденту. | После закрытия разбора дежурным. |
| Задачи из инцидента | Убедиться, что заведённые задачи имеют: эпик, исполнителя, приоритет, статус «Готово к разработке». | При переводе инцидента в статус «Разобран». |
| Эскалация | Принимать финальное решение в спорных случаях: фиксить сейчас или в бэклог. | По запросу дежурного или если разбор затянулся. |
| Бэклог | Контролировать, что задачи из инцидентов не теряются в бэклоге и берутся в работу согласно приоритету. | На планировании спринта / регулярно. |
| Статус инцидента | Следить, что статус инцидента в Jira актуален и не «завис» в промежуточном состоянии. | Ежедневно, пока инцидент открыт. |
Принципы
- Лид не подменяет дежурного. Если инцидент в рамках SLA — лид не вмешивается.
- Лид принимает решение в спорных случаях — например, когда дежурный не может однозначно определить: фиксить сейчас или в бэклог. Если есть сомнения — эскалация до CTO.
- Лид несёт ответственность за то, что задачи из инцидентов корректно оформлены до попадания в бэклог.
- При выходе дежурного за SLA лид пингует его, а не берёт разбор на себя — это важно для сохранения ответственности.
Чеклист лида по завершении разбора инцидента
- В инциденте есть комментарий с результатами разбора (масштаб, влияние, решение).
- Если заведена задача — у неё есть эпик, исполнитель, приоритет и статус «Готово к разработке».
- Задача содержит ссылку на инцидент.
- Статус инцидента в Jira актуален.
Если хотя бы один пункт не выполнен — лид возвращает задачу дежурному на доработку, а не исправляет сам.
5. Процесс и SLA
| Этап | Описание | SLA | Ответственный |
|---|---|---|---|
| Взятие в разбор | Дежурный принимает инцидент и приступает к анализу | ≤ 15 минут | Дежурный разработчик |
| Разбор инцидента | Оценка масштаба, влияния, сложности. Решение: фикс сейчас / бэклог / отмена | ≤ 30 мин (крит.) / ≤ 1 ч (некрит.) | Дежурный разработчик |
| Немедленный фикс | Если инцидент соответствует критериям немедленного исправления — фиксим без эскалации | Начало работы сразу после разбора | Дежурный + команда по необходимости |
| Задача в бэклог | Если немедленного фикса не требуется — заводится задача со ссылкой на инцидент и идёт в общий флоу | До конца рабочего дня | Дежурный разработчик |
6. Критерии немедленного фикса
Если инцидент соответствует хотя бы одному из следующих критериев — дежурный принимает решение о немедленном исправлении самостоятельно, без эскалации к тимлиду или руководству.
| Критерий | Примеры | Комментарий |
|---|---|---|
| Сломан core user flow | Не работает плеер, лендинг, авторизация, регистрация | Пользователь не может выполнить ключевое действие |
| Реальная потеря денег | Транзакции не проходят, реклама не показывается и монетизация падает | Прямой финансовый ущерб в реальном времени |
| Массовый сбой — большинство пользователей | Сервис недоступен, 500-е ошибки на главных страницах | Порог >=5% |
| Потеря данных или угроза безопасности | Утечка персональных данных, накрутка средств, фрод, абьюз плеера, некорректная запись в БД | Любой масштаб — фикс немедленно |
| Критический контент недоступен | Умерло API, пропали сервера | Пользователь не видит продукт вообще |
После каждого решенного инцидента можно вносить новые примеры того, что требует немедленного фикса.
Всё, что не попадает под эти критерии — заводится задачей в бэклог и приоритизируется в штатном режиме.
7. Как поставить приоритет задаче из инцидента
Таблица определяет уровень влияния бага на систему через severity и соответствующий приоритет задачи:
| Priority | Severity | Критерий | Примеры | Когда фиксить |
|---|---|---|---|---|
| Приоритет 1 | S5 Trivial | Косметический баг, не влияющий на работоспособность, малозаметный. | Опечатка в описании, неправильный падеж, иконка не по дизайн-системе | При наличии времени |
| Приоритет 2 | S4 Minor | Незначительная ошибка, не нарушающая бизнес-логику, касается удобства использования. | Неровные отступы в карточке, некорректный текст в тултипе, лёгкий фриз интерфейса | В рамках приоритетов по другим задачам бэклога |
| Приоритет 3 | S3 Major | Существенная ошибка, часть основного функционала работает некорректно, но система не «падает». | Не работает переключение озвучки, перемотка ломает таймлайн, не сохраняется история просмотра | В рамках приоритетов по другим задачам бэклога |
| Приоритет 4 | S2 Critical | Нарушение работы ключевой бизнес-логики, потеря данных, проблема безопасности — при наличии workaround. | У части пользователей не стартует видео, ломается SEO-структура, автоплей серий не работает | Ближайшим освободившимся разработчиком с соответствующей экспертизой |
| Приоритет 5 | S1 Blocker | Ошибка, приводящая к невозможности использования продукта или его ключевых функций. | Плеер не открывается, backend не отвечает, 500 ошибки массово, сайт полностью недоступен | Немедленно, можно фиксить прямо в инциденте |
8. Что должен описать дежурный в инциденте
- Масштаб проблемы: сколько пользователей/сессий затронуто (оценочно)
- Влияние: какой функционал сломан, критичен ли он для core user flow
- Воспроизводимость: всегда / иногда / единичный случай
- Сложность решения: оценка в часах или уровне неопределённости
- Принятое решение: фикс сейчас / задача в бэклог / отмена — с обоснованием
- Ссылка на задачу: если заведена задача в бэклог — прикрепить её к инциденту
9. Трейсабилити
Каждая задача, заведённая по итогам инцидента, должна содержать ссылку на исходный инцидент. Это не влияет на приоритет задачи, но даёт контекст при приоритизации бэклога: «это не просто баг, это последствие инцидента на проде».