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

Краткая карта действий и план отката

Сначала read-only: собирайте факты (логи, метрики, статус зависимостей), не меняя прод.
Зафиксируйте точку "последнего известного хорошего состояния": версия, конфиг, схема БД, флаги, инфраструктурные изменения.
Выберите стратегию: откат (rollback), обход (feature flag/маршрутизация), деградация функционала, пауза задач.
Назначьте роли: инцидент-менеджер, исполнитель, наблюдатель/проверяющий, коммуникатор.
Определите критерии безопасности: что считается восстановлением и что является стоп-сигналом.
План отката "до эскалации": подготовить артефакты, окно, шаги и проверку, затем только изменения.
После стабилизации: постмортем без поиска виноватых и контрольные меры, чтобы снизить повторяемость.

Диагностика: быстрое определение границ кризиса

Что обычно видит пользователь (симптомы):

Ошибка при входе/оплате/создании заказа, операции "крутятся" и не завершаются.
Часть страниц работает, часть - нет (избирательные 5xx/4xx, пустые ответы).
Данные "пропали" или не обновляются: статусы не меняются, отчёты устарели.
Резкое замедление: таймауты, повторные запросы, "подвисания" UI.
Не сходятся цифры между витринами/сервисами, дубли, "сломанная" идемпотентность.
Фоновые задачи копятся, очереди растут, интеграции отваливаются.

Решение в 5 минут (минимально рискованный старт):

Объявите "заморозку изменений": стоп релизов, миграций, ручных правок в прод.
Соберите временную шкалу: что меняли последним (код, конфиг, инфраструктура, данные).
Проверьте внешние зависимости: статус провайдеров, DNS, сертификаты, платежи, SMTP, CDN.
Снимите read-only срез: ошибки по сервисам, p95/p99 задержек, состояние очередей, saturation ресурсов.
Определите границы: один сервис/регион/версия или системная проблема.

Приоритезация рисков и задач под ограниченные ресурсы

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

Чек-лист быстрой оценки (делайте в указанном порядке):

Есть ли риск потери данных или некорректных списаний/двойных операций?
Задет ли "денежный" контур (оплаты, отгрузки, начисления) или критический SLA?
Можно ли перевести систему в деградированный режим (частичная функциональность вместо полного простоя)?
Есть ли безопасная точка отката (прошлая версия, конфиг, snapshot, тэг релиза)?
Миграции БД: были ли необратимые изменения схемы/данных?
Насколько воспроизводится проблема: у всех/части пользователей, в одном регионе, за прокси?
Есть ли "огонь" в очередях: ретраи, DLQ, лавинообразное нарастание задач?
Не усугубит ли исправление ситуацию (например, перезапуск, прогрев кэшей, массовые пересчёты)?
Какие проверки возможны в read-only, чтобы подтвердить гипотезу без изменений?
Кого надо подключить заранее: DBA, SRE, безопасность, владелец продукта, поддержка?

Когда подключают внешнюю помощь: если вы оказываетесь в ситуации, где нужны параллельные роли и строгая дисциплина (инцидент-менеджмент, откат, коммуникации, постмортем), это часто оформляют как антикризисное управление услуги или управленческий консалтинг для бизнеса - особенно когда простой начинает "съедать" доверие и операционные процессы.

План отката и критерии безопасного возврата к предыдущему состоянию

Три уровня риска отката: что делаем и кто отвечает

Уровень риска	Что делаем (типовые действия)	Критерии "можно делать"	Ответственные
Низкий	Откат конфигурации/фича-флагов, переключение трафика, отключение проблемного фона, read-only режим в части функций	Нет необратимых изменений данных; есть быстрый способ вернуть обратно; есть наблюдаемость (логи/метрики)	Инцидент-менеджер, DevOps/SRE, владелец сервиса
Средний	Откат версии приложения, rollback деплоя, смена образа/артефакта, переключение на предыдущий релиз	Известна совместимость с текущей схемой БД; подготовлен план проверки; окно деградации согласовано	Tech Lead, SRE, QA/наблюдатель
Высокий	Откат миграций/данных, восстановление из бэкапа/snapshot, массовые правки данных, смена топологии	Есть подтверждённая точка восстановления; согласование с бизнесом; подготовлен альтернативный план при неудаче	DBA, SRE, владелец продукта, безопасность (при необходимости)

Критерии безопасного возврата

Корректность: ключевые пользовательские сценарии проходят без ошибок (логин/поиск/оформление/оплата - по вашему домену).
Целостность данных: нет расхождений между источниками истины, нет неконсистентных статусов.
Наблюдаемость: метрики/логи подтверждают спад ошибок и стабилизацию задержек.
Ограничение вреда: остановлены повторные ретраи и "шторм" в очередях/интеграциях.
Обратимость: описан шаг "вернуть назад" на случай, если откат ухудшит ситуацию.

Симптомы → причины → проверка → исправление (шаблон диагностики)

Симптом	Возможные причины	Как проверить (read-only)	Как исправить (от безопасного к рискованному)
Скачок 5xx после релиза	Регрессия в коде, несовместимость с конфигом, неверные переменные окружения	Сравнить версии/артефакты, diff конфигов, ошибки в логах по новому пути кода	Отключить фичу флагом → переключить трафик на предыдущий релиз → rollback деплоя
Таймауты, "подвисания", рост задержек	Перегрузка БД/кэша, N+1, блокировки, внешний провайдер деградирует	Метрики saturation, slow queries, состояние пулов соединений, статус провайдера	Ограничить тяжёлые эндпоинты/кроны → включить деградацию → масштабирование/оптимизация → откат релиза
Данные не обновляются	Застряли очереди, упали воркеры, сломан consumer, дедлоки	Lag очередей, DLQ, health воркеров, ошибки обработки сообщений	Остановить ретраи, чтобы не множить вред → поднять воркеры → повторно обработать DLQ по правилам
Дубли/повторные операции	Нет идемпотентности, ретраи без ключа, неправильная дедупликация	Сопоставить idempotency key/корреляции, анализ повторов по логам	Временный блок/лимит на повтор → фиксация ключей → компенсирующие операции/ручная сверка
Часть пользователей не видит сервис	Проблема региона/маршрутизации, DNS, CDN, сертификаты	Сравнить доступность по регионам, трассировки, сроки сертификатов, ошибки CDN	Переключить трафик/регион → откат DNS/CDN конфигов → эскалация провайдеру
После миграции "сломались" запросы	Несовместимая схема, индексы не созданы, миграция частично применена	Состояние миграций, планы запросов, наличие индексов, ошибки ORM	Отключить новый код-path → добавить отсутствующие индексы → откат к совместимой версии → восстановление из snapshot (если нужно)

Короткий план отката изменений перед эскалацией

Соберите "пакет отката": версия для возврата, конфиги, команды деплоя, порядок действий.
Определите окно и ограничения: что нельзя трогать, где read-only обязателен до последнего момента.
Назначьте наблюдателя: отдельный человек подтверждает критерии успеха/неуспеха.
Подготовьте точку возврата из отката: если станет хуже, как быстро вернуть текущую версию.
Сделайте пробный прогон на стейдже/песочнице (если возможно) или dry-run команд.

Если откат невозможен: альтернативный план

Включить деградированный режим: отключить тяжёлые операции, оставить "чтение" и критические действия.
Перевести часть функций в очередь/асинхрон с честным статусом для пользователя.
Сделать компенсирующие операции (reconcile) вместо возврата данных "назад".
Изолировать повреждённый контур: шард/тенант/регион, чтобы не "потянуть" весь прод.
Зафиксировать правила ручной обработки, чтобы бизнес не остановился (с минимальным риском ошибок).

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

Назначьте инцидент-менеджера и канал (чат/мост): один источник правды, один таймлайн.
Зафиксируйте статус и ограничения: что не делаем (релизы, миграции), какие read-only проверки выполняем.
Оцените влияние: какие сценарии/сегменты/регионы затронуты, есть ли риск для денег и данных.
Сформулируйте гипотезы (не больше 3) и назначьте владельцев на проверку.
Примите решение о стратегии: откат / обход / деградация / пауза, с критерием остановки.
Согласуйте внешние сообщения: поддержка, аккаунт-менеджеры, статус-страница, внутренние стейкхолдеры.
Исполните изменения в порядке роста риска: флаги → маршрутизация → rollback версии → операции с данными.
Проведите верификацию по заранее объявленным критериям и подтвердите окончание инцидента.
Задокументируйте принятые решения и "что пробовали", чтобы не повторять круги.

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

Технические методы восстановления: пошаговые приёмы и готовые скрипты

Пошаговые приёмы (универсальные)

Снимите снимок состояния: текущие версии, активные флаги, состояние миграций, параметры окружения.
Отключите усилители пожара: агрессивные ретраи, крон-задачи, массовые пересчёты, автоскейлинг "в потолок".
Ограничьте трафик: rate limiting, частичная маршрутизация на стабильный пул, временная "очередь ожидания".
Включите деградацию: выключите несущественные модули, оставьте критический путь.
Стабилизируйте данные: заморозьте спорные записи, включите идемпотентность на входе, добавьте дедупликацию.
Выполните откат (если выбран): сначала конфиги/флаги, затем версия, затем - данные (только при необходимости).

Готовые "скрипты" в виде фраз для командной работы

Стоп-слово: "С этого момента изменения в прод запрещены, только read-only проверки, пока не согласуем план".
Фиксация гипотезы: "Гипотеза: проблема началась после изменения X, подтверждаем по Y, владелец проверки - Z, ETA - ...".
Решение об откате: "Критерий отката: если ошибки не снижаются после шага A, выполняем rollback до версии B".
Коммуникация вовне: "Затронуты сценарии ..., временное решение ..., следующий апдейт после подтверждения шагов ...".

Когда пора эскалировать (и не геройствовать)

Есть признаки повреждения данных или финансовых операций, а план восстановления не подтверждён.
Нужно вмешательство в БД (восстановление, репликация, сложные миграции) без уверенной процедуры.
Проблема на стороне провайдера/платёжки/облака, и требуется официальный тикет и трассировки.
Нет наблюдаемости: вы не можете доказать, что стало лучше/хуже после шага.
Инцидент "съедает" команду: параллельно надо вести коммуникации, решения, техработы и разбор рисков.

Кейсы из практики (без раскрытия чувствительных деталей)

Кейс: релиз сломал критический сценарий. Действия: freeze, read-only подтверждение регрессии, отключение фичи флагом, затем откат версии. Итог: восстановили основной поток, снизили поток обращений в поддержку, вернули предсказуемость релизов через обязательные критерии отката.
Кейс: лавина ретраев положила интеграцию. Действия: отключили ретраи и крон, ограничили входящий трафик, стабилизировали очередь, ввели дедупликацию. Итог: остановили самоусугубление, восстановили обработку без новых дублей, оформили лимиты и алерты по лагу.
Кейс: миграция создала частичную несовместимость. Действия: выключили новый код-path, добавили недостающий индекс, проверили планы запросов, затем поэтапно вернули функциональность. Итог: ушли таймауты и блокировки, появилась "двухфазная" схема миграций (совместимость вперёд/назад).

Разбор причин и меры после инцидента: как снизить повторяемость

Постмортем по таймлайну: что было фактом, какие гипотезы проверяли, что сработало, что мешало.
Одна причина - один контрол: каждый выявленный класс ошибок получает конкретную меру (тест, алерт, гейт, регламент).
Гигиена релизов: feature flags, canary/поэтапный rollout, автоматический rollback при ухудшении ключевых метрик.
Совместимые миграции: изменения БД "вперёд/назад", запрет необратимых шагов без отдельного согласования.
Наблюдаемость как контракт: для каждого сервиса - SLI/SLO, корреляция запросов, дашборды и алерты "по симптомам", а не "по CPU".
Управление очередями: лимиты ретраев, DLQ-процедуры, ручной режим обработки при инциденте.
Runbooks: короткие инструкции "если X - делай Y", включая критерии "стоп" и "эскалация".
Роли и тренировки: регулярные учения по инцидентам, закрепление инцидент-менеджера, наблюдателя и коммуникатора.
Управление изменениями: единый журнал изменений и обязательная привязка к тикету/обоснованию риска.

Типовые вопросы по решению ситуаций, когда всё идёт не по плану

Почему нельзя сразу "быстро поправить на проде"?

Потому что без read-only подтверждений вы рискуете усугубить инцидент и потерять точку возврата. Сначала фиксируйте факты и выбирайте минимально рискованный шаг.

Что важнее: откат или "горячий фикс"?

Если есть безопасная точка возврата и инцидент влияет на пользователей, откат чаще быстрее стабилизирует систему. "Горячий фикс" оправдан, когда причина ясна и исправление обратимо.

Как понять, что миграцию БД нельзя откатывать?

Если изменение необратимо (удаление данных/полей, пересчёт без сохранения исходников) или нет подтверждённой точки восстановления. Тогда используйте обход и компенсирующие операции.

Какие проверки считать read-only на практике?

Чтение логов/метрик, выборки из БД без блокирующих правок, просмотр конфигурации и статусов зависимостей. Любые операции, меняющие данные или топологию, - уже риск.

Когда стоит переводить функциональность в деградацию вместо отката?

Когда откат несёт высокий риск (данные/миграции) или не устраняет первопричину. Деградация позволяет сохранить критический путь и выиграть время на корректное восстановление.

Что писать в сообщении бизнесу/поддержке во время инцидента?

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

Как закрепить результат, чтобы "не повторилось"?

Перевести уроки в конкретные контроли: гейты релизов, алерты по симптомам, совместимые миграции, runbook и тренировки. Без этого инциденты возвращаются в новой форме.