Во время сбоя не стоит решать с нуля, кто руководит работами, где фиксируются обновления и допустим ли откат релиза. Application incident response plan задаёт повторяемый порядок действий для веб- и мобильного продукта: оценить влияние, назначить роли, сохранить факты, выбрать безопасную меру снижения риска, корректно сообщить клиентам, подтвердить восстановление и превратить выводы в задачи разработки.

Мониторинг и реагирование на инциденты — не одно и то же. Мониторинг обнаруживает симптомы: рост ошибок API, медленный checkout, падения мобильного приложения, задержки фоновых задач или неуспешные платежи. Процесс реагирования координирует людей, решения и коммуникацию, когда эти сигналы уже требуют действий. Один дашборд не отвечает на вопросы, кто может остановить релиз, что сказать пользователям и как подтвердить корректность данных после восстановления.

Определяйте инцидент по влиянию на клиента и бизнес

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

Учитывайте не только доступность. Приложение может отдавать HTTP 200, но показывать устаревшие цены, дублировать операции, неправильно применять права доступа или терять сообщения фоновых процессов. Для SaaS-продукта корректность, конфиденциальность, целостность данных и финансовые последствия нередко важнее, чем формальный uptime.

Стройте severity по масштабу влияния, а не по отказавшему компоненту

Фраза «упала база данных» описывает техническую причину, но не уровень критичности. Severity должна зависеть от числа и типа затронутых пользователей, критичности пользовательского сценария, риска для данных, наличия обходного пути и бизнес-последствий. Для большинства команд достаточно четырёх уровней.

SEV-1: критический сбой или существенный риск для данных

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

SEV-1 обычно означает немедленное включение incident command, заморозку изменений в затронутой зоне, частые обновления для заинтересованных сторон и публичный статус, если проблема влияет на клиентов.

SEV-2: заметная деградация

  • Затронута значимая доля пользователей, регион, платформа или важный клиент.
  • Критичная функция деградировала, но не исчезла полностью, либо есть неудобный, но рабочий обходной путь.
  • Например, новый мобильный релиз падает на поддерживаемой версии ОС, однако веб-версия продукта доступна.

SEV-3 и SEV-4: ограниченное влияние и плановая работа

  • SEV-3: ограниченное влияние, безопасный workaround и отсутствие срочного риска для данных или безопасности.
  • SEV-4: аномалия или небольшой дефект, который можно провести через обычный backlog и цикл релизов.

Первичная оценка всегда делается при неполной информации. Уровень можно повысить или понизить, когда станет понятен blast radius. Главное — не задерживать снижение влияния на пользователей из-за спора о названии уровня.

Первые 30 минут: production incident runbook

  1. Объявите инцидент. Создайте единый канал и запись инцидента. Укажите время, симптом простыми словами, начальный severity, затронутый сервис и incident commander.
  2. Назначьте роли. Incident commander управляет приоритетами и подтверждает решения. Technical lead направляет диагностику и техническую mitigацию. Communications lead готовит внутренние и внешние сообщения. Scribe ведёт временную шкалу, записывает наблюдения, действия и решения. В небольшой команде роли можно совмещать, но commander не должен одновременно тонуть в логах и правках кода.
  3. Определите масштаб. Какие регионы, tenant-ы, версии приложения, endpoint-ы, интеграции и пользовательские сценарии затронуты? Оцените ошибки, задержки, неуспешные операции, рост очередей и обращения в поддержку. Отделяйте подтверждённые факты от гипотез.
  4. Остановите неконтролируемые изменения. Приостановите deploy, конфигурационные правки, миграции схемы и плановые job-ы, которые могут исказить временную шкалу или увеличить масштаб проблемы. Любое экстренное изменение фиксируйте явно.
  5. Выберите немедленную mitigацию. Отключите feature flag, откатите релиз, перенаправьте трафик, остановите вредный worker, ограничьте нагрузку или временно отключите второстепенную функцию. Сначала верните безопасную работу сервиса, затем ищите идеальное постоянное решение.
  6. Сохраните доказательства. Зафиксируйте версии deploy, состояния feature flag, alerts, снимки дашбордов, request ID, audit-логи и время ключевых решений. При подозрении на проблему с данными не запускайте разрушительную очистку или массовую коррекцию до сохранения исходных фактов.

Откат, hotfix или изменение конфигурации?

Application rollback strategy не означает, что любой дефект нужно лечить возвратом к прошлой версии. Откат оправдан, если новый релиз с высокой вероятностью стал триггером, предыдущий артефакт известен как стабильный, возврат совместим с текущими данными и зависимостями, а риск снизится быстрее, чем при поиске и исправлении причины.

Откат может быть опасным или бесполезным, если:

  • релиз выполнил необратимую миграцию базы данных или изменил смысл сохранённых данных;
  • источник проблемы — внешний провайдер, сертификат, DNS, лимит мощности или upstream-зависимость, а не новый код;
  • обе версии одинаково обработают уже повреждённые входные данные;
  • предыдущая версия отменит другой критически важный фикс;
  • мобильная сборка уже установлена на устройствах и требуется серверная совместимость, а не отзыв из магазина.

В таких случаях лучше подойдут server-side kill switch, отключение feature flag, управление трафиком, режим только для чтения, обратно совместимый hotfix или временная изоляция проблемной интеграции. Hotfix стоит делать, только если характер сбоя и границы изменения достаточно понятны. В SEV-1 не превращайте восстановление сервиса в большой рефакторинг.

Для мобильного продукта подготовка особенно важна: установленный binary нельзя мгновенно откатить на каждом устройстве. Версионированные API-контракты, remote configuration, kill switch, правила минимальной поддерживаемой версии и совместимость со старыми клиентами должны быть частью разработки мобильных приложений, а не экстренной мерой после неудачного релиза.

Коммуникация с клиентами: быстро, точно и по существу

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

Некоторые клиенты сейчас могут столкнуться с невозможностью создать новый заказ. Наша команда расследует проблему и принимает меры для снижения влияния. На данный момент нет подтверждений, что существующие заказы затронуты. Следующее обновление будет опубликовано до 14:30 UTC.

Для SEV-1 и релевантных SEV-2 заранее подготовьте процесс обновления status page, шаблон для поддержки и короткий бриф для account-менеджеров. Назначьте интервал обновлений и соблюдайте его, даже если новая информация состоит только в том, что расследование продолжается. Закрывайте инцидент после проверки ключевого пользовательского пути, а не только потому, что инфраструктурный график стал зелёным.

Подтверждайте восстановление по всей цепочке продукта

Нормализовавшийся alert — это свидетельство, но не доказательство полного восстановления. В checklist должны входить:

  • возврат error rate, latency, saturation и доступности к ожидаемому диапазону;
  • синтетическая либо ручная проверка главного сценария: входа, оплаты, заказа, отправки формы, загрузки файла или бронирования;
  • проверка очередей, повторных попыток, worker-ов по расписанию и dead-letter обработки;
  • reconciliation, если операции могли быть пропущены, продублированы или частично завершены;
  • отдельная валидация веб-клиентов, мобильных приложений, публичных API и критичных интеграций;
  • период наблюдения после mitigации для выявления повторения проблемы.

В платежных, складских, торговых и иных транзакционных системах «сервис доступен» не равнозначно «бизнес-данные корректны». Idempotency, неизменяемый audit trail, компенсирующие операции и reconciliation-процедуры должны быть заложены в веб-платформы и приложения до того, как возникнет инцидент.

Превращайте post-incident review в задачи backlog

Проведите разбор без поиска виноватых, пока доступны контекст и доказательства. Зафиксируйте влияние на клиентов, временную шкалу, триггер, способствующие условия, способ обнаружения, попытки mitigации, проверку восстановления и факторы, которые помогли или помешали ответу. Цель — не документ, обвиняющий человека, а изменение, уменьшающее вероятность повторения или риск следующего реагирования.

У каждого существенного action item должны быть владелец, приоритет и срок. «Улучшить мониторинг» — не задача. Хорошие примеры: добавить synthetic assertion для checkout; ввести expand/contract-политику миграций; ежеквартально тестировать rollback; alert-ить ошибки провайдера по tenant-ам; создать replay-safe job для reconciliation; согласовать шаблоны клиентских сообщений с поддержкой и юридической командой.

Если вашей команде нужна постоянная помощь с готовностью on-call, контролем релизов, observability, производительностью, безопасностью или incident drills, услуга POLADO «Техническая поддержка и консалтинг» поможет выстроить процессы под ваш продукт и размер команды. Чтобы оценить существующий runbook или создать application incident response plan, свяжитесь с POLADO.

Краткий checklist плана реагирования

  • Severity определён через влияние на пользователей, бизнес, данные и безопасность.
  • Понятны обязанности incident commander, technical lead, communications lead и scribe.
  • Доступны on-call контакты, production-доступ, пути эскалации и независимый канал связи.
  • Документированы и протестированы стабильные артефакты, feature flags, rollback и ограничения миграций.
  • Проверка восстановления включает ключевые пользовательские сценарии и reconciliation данных, а не только инфраструктурное здоровье.
  • Шаблоны status-обновлений, аудитории и правила согласования определены заранее.
  • Action items после инцидента отслеживаются в backlog до завершения.