План отката: что восстанавливать помимо изменений в коде

Почему один откат кода не исправит проблему

Реверсия кода меняет только то, что выполняется сейчас. Она не отменяет изменений, которые уже сделал неудачный релиз.

Именно этот разрыв объясняет, почему планы отката часто проваливаются в реальных инцидентах. Версия приложения вернулась назад, но пользователи всё ещё видят сломанные страницы, пропавшие записи, дублирующиеся письма, застрявшие заказы или старые сообщения об ошибке. Код изменили назад. Сервис — нет.

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

Возьмём простой случай. Релиз добавляет новое правило checkout, записывает новые значения в базу и запускает джоб, который повторно пытается платежи. Через пять минут вы откатываете код. Новые значения остаются в базе, джоб продолжает срабатывать, а закэшированные страницы корзины всё ещё показывают сломанный поток. Для команды деплой исчез, для клиентов — проблема осталась.

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

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

Что нужно зафиксировать до релиза

До деплоя выпишите все подвижные части, которые затрагивает релиз. Люди помнят diff кода. Они забывают о флаге, который кто-то переключил, о расписании джоба, которое изменилось, или о шаблоне ответа поддержки, который теперь нужно обновить.

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

Держите изменения кода и изменения состояния в отдельных корзинах. Код обычно откатывать проще. С состоянием сложнее. Если новая версия записала данные в новом формате, поставила тысячи заданий в очередь или сменила продовый параметр, старый код может всё равно падать после отката.

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

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

Держите документ коротким — его должно быть можно прочитать за минуту. Обычно одна страница достаточно. Если список кажется слишком длинным, уберите всё, что не влияет на восстановление. В состоянии стресса побеждает краткость.

Это тот образ операционной привычки, которую Олег Сотников часто продвигает в стартап‑командах на oleg.is: сделайте путь восстановления видимым до запуска. Если уставший инженер в 2 утра может просканировать карту и понять следующий шаг — документ выполняет свою задачу.

Данные нуждаются в собственном пути отката

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

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

Некоторые изменения легко отменить. Можно удалить дубли, вернуть статус, удалить тестовые данные, которые попали в прод. Другие требуют аккуратности. Если миграция удалила колонку, переписала ID, разделила поле на два или начала сохранять данные в новой форме, старое приложение может не уметь читать уже записанные данные.

Смешанные состояния причиняют наибольшую боль. У одного клиента могут быть старые данные, у другого — частично промигрированные, у третьего — новые данные и неудачный повтор. Поэтому откат базы данных нуждается в правилах для частичных записей. Решите, как находить затронутые записи, как их помечать и кто будет запускать ремонт.

Короткий план поможет:

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

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

Простой пример: релиз изменил правила статуса счетов и пометил как «оплачено» 300 заказов слишком рано. Старый код не исправит эти строки. Команде нужен скрипт ремонта, способ остановить дальнейшие записи и точный счёт изменённых записей, прежде чем можно будет считать сервис восстановленным.

Флаги и конфиг могут держать баг живым

Откат кода всё ещё может оставить проблему, если поведение в проде задаётся переключателями вне релиза. Флаг может по‑прежнему вести пользователей в сломанный путь. Переменная окружения может указывать не на ту модель, таймаут или endpoint. Скрытый админ‑переключатель может сделать то же самое, и команды часто про такие вещи забывают, пока что‑то не сломается.

Относитесь к изменениям конфигурации как к части релиза, а не как к заметкам на полях. Отслеживайте каждый флаг, который меняли, какое было старое значение, кто его менял и где этот переключатель живёт. Аналогично для remote config, env vars и любых ручных тумблеров в админке.

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

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

Устаревшие значения тоже создают проблемы. Флаг может быть выключен в одном регионе и включен в другом из‑за задержки синхронизации или нерефреша локального кэша. Фоновые воркеры часто держат старые env vars до перезапуска. Поэтому откат может выглядеть успешным в одном месте и сломанным в другом.

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

Если баг пережил откат, сначала сравните флаги и конфиг. Исправление иногда — один переключатель, а не ещё один деплой.

Джобы и очереди нуждаются в плане остановки и перезапуска

Релиз может исчезнуть, а его джобы продолжать работать. Воркеры могут обрабатывать старые сообщения, ретраить неудачные задачи или запускать cron‑задачи, которые снова пишут те же плохие данные. Если ваш план отката игнорирует этот слой, сервис может оставаться сломанным после возврата к старой версии.

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

До отката решите, какие джобы нужно ставить на паузу в первую очередь. Любая задача, которая может продолжать менять записи, списывать пользователям деньги дважды или отправлять неверные уведомления, должна остановиться до восстановления приложения. Некоторые команды ставят всю очередь на паузу. Другие — только рискованные типы джобов. Оба подхода работают, если это записано и за это отвечает один человек.

Также нужен регламент для задач уже в процессе выполнения. Ворк может стартовать под новой версией и закончить после того, как вы вернули старую. Это может оставить полусделанные обновления или дублирующие сайд‑эффекты. Для каждой важной задачи определите: дать завершиться, отменить или отправить на ручную проверку.

Держите ранбук простым:

• перечислите очереди, воркеры, cron‑задачи и настройки ретраев
• поставьте на паузу задачи, которые могут продолжать писать плохие данные
• проверьте задачи в процессе перед перезапуском воркеров
• решите, какие отложенные задания вы будете дренировать, реплеить или отбросить
• запишите, кто утверждает каждый шаг во время восстановления

С отложенной работой обращайтесь особо аккуратно. Дренирование подходит, когда задания безопасны, но их нужно обработать старым кодом. Реплей — когда можно восстановить очередь из чистых событий. Отбрасывание иногда — наименьшее зло, но только если вы понимаете, что потеряют пользователи и как это исправить позже.

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

Кэш и производные состояния могут пережить релиз

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

Это происходит потому, что код — лишь одна часть состояния системы. Кэш приложения может хранить ответы, сгенерированные сломанной версией. CDN может держать старые страницы на edge‑узлах. Сессии пользователей могут нести неверные права или некорректные данные корзины. Индексы поиска могут указывать на записи, которые больше не соответствуют живому коду.

Выпишите все хранилища производных данных до деплоя. Для большинства команд это кэш приложения, CDN, сессии, индексы поиска, сгенерированные фиды и любые предсобранные страницы или отчёты. Пропустите хоть одну — и сервис может остаться наполовину сломанным после отката.

Что чистить, а что перестраивать

Не очищайте всё по умолчанию. Некоторые сбросы быстро решают проблему. Другие создают новые.

Очищайте кэш приложения, когда изменился shape объектов, названия полей или правила формирования ответов. Пропустите CDN, когда пользователи могут получать сломанные страницы, устаревшие ответы API или старые активы. Сбрасывайте сессии только если сами данные сессии изменились или хранили плохое состояние. Перестраивайте индексы поиска, когда изменились фильтры, ранжирование, поля документов или правила видимости. Пересчитайте отчёты или материализованные представления, если они были сгенерированы из неверных данных.

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

Устаревшие данные живут дольше, чем люди ожидают. Если кэш приложения живёт 30 минут, а CDN держит контент час — неверные результаты могут сохраняться намного дольше после отката. Индексы поиска часто обновляются по расписанию и держатся ещё дольше. Сессии остаются активными, пока пользователь не выйдет или токен не истечёт.

Во время восстановления выполните простую проверку. Откройте продукт как новый посетитель, как залогиненный пользователь и через поиск. Если какой‑то путь всё ещё показывает баг — значит устаревшее состояние ещё в игре. Именно поэтому откат кажется неполным, даже когда деплой вернули назад.

Как выполнять откат по шагам

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

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

Практическая последовательность может выглядеть так:

1. Подтвердите проблему и назначьте одного лидера отката. Этот человек решает, откатывать ли релиз, кто ставит на паузу трафик или джобы и кто публикует обновления.
2. Снимите быстро движущиеся части первыми. Верните флаги и конфиг, которые могут остановить плохое поведение за секунды.
3. Откатите релиз. Задеплойте последнюю рабочую версию, затем очистите или перестройте кэш только там, где устаревшее состояние может сохранять баг.
4. Перезапускайте фоновые задания по стадиям. Проверьте глубину очередей, количество упавших задач и ретраев, прежде чем разрешить всем воркерам снова работать.
5. Протестируйте пользовательские пути, которые действительно используют люди. Залогиньтесь, создайте или отредактируйте запись, завершите платёж или поток оформления заказа и убедитесь, что соответствующий джоб проходит энд‑ту‑энд.

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

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

Простой пример из неудачного релиза

Команда выпускает новый поток оформления заказа в 14:00. Код в стейджинге выглядит нормально, поэтому его включают для 25% клиентов через флаги. Через минуты в поддержку приходят жалобы: в некоторых корзинах неверная сумма, несколько клиентов списаны дважды, приходят письма о заказах, которые на самом деле не завершены.

Баг не только в веб‑приложении. Релиз также поменял, как база хранит резервирование скидок, и фоновый воркер теперь агрессивно ретраит неудачные платежи. Откат кода сам по себе не очистит сломанные строки и не остановит воркер, который реплейит плохие события.

Первые 30 минут

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

В 14:12 один инженер смотрит логи и находит, что новый поток записывает дубли резервов скидок при таймауте платежа. Другой смотрит очередь и видит сотни ретраев. Третий сравнивает недавние заказы с платёжными записями, чтобы понять, кого могли списать дважды.

В 14:18 они запускают старый код снова. Это помогает новым сессиям, но старые итоги корзин всё ещё неверны из‑за кэша. Они чистят кэш оформления и пересчитывают итоги для активных корзин.

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

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

Что изменили после

Команда обновила план отката в тот же день. Теперь каждый релиз checkout требует четырёх вещей до запуска: обратимое изменение данных, команда‑команда для паузы воркеров, шаги по сбросу кэша и шаблон сообщения клиентам.

Они также добавили одно правило, которое экономит много проблем: никто не выполняет откат базы данных или перезапуск воркеров "из головы". Кто‑то обязан следовать письменному чек‑листу. Звучит скучно, но это предотвращает вторую ошибку, которая обычно хуже первой.

Ошибки команд во время восстановления

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

Одна частая ошибка — предположение, что база данных вернулась назад вместе с приложением. Это не так. Если релиз изменил строки, добавил плохие записи или запустил однонаправленную миграцию, старый код может вернуться к базе, которую он уже не понимает. Команды тратят 20–30 минут на погоню за "новыми" ошибками, которые на самом деле вызваны оставшимися старыми данными.

Другая ошибка — фоновые работы, которые продолжают выполняться после отката. Очереди, ретраи, расписанные задания и вебхуки могут продолжать шлёпать те же плохие пейлоады или воссоздавать сломанные записи. Команда откатывает в 10:05 и видит повреждения в 10:20, потому что воркеры так и не остановили работу.

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

Ошибки в сообщениях клиентам тоже часты. Команды пишут "исправлено", когда уровень ошибок упал, но протестировали только первый экран или один счастливый путь. Клиенты затем натыкаются на тот же баг в checkout, настройках аккаунта или отложенной рассылке — это бьёт по доверию сильнее первого сбоя.

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

Небольшой пример иллюстрирует это. Релиз добавляет сломанное правило биллинга, команда откатывает код, сайт всё ещё списывает неверную сумму. Почему? Ретрай‑воркер продолжает реплейить плохие биллинговые события, а кэш показывает старые итоги. Деплой отменён. Сервис — нет.

Быстрая проверка и последующие шаги

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

Сделайте короткую post‑rollback проверку перед закрытием инцидента:

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

Последний шаг важнее, чем многие признаются. Если клиент всё ещё видит проваленный платёж, пропавшую запись или застрявший заказ, ему всё равно, что ваш план отката сработал "на бумаге". Его волнует, может ли он сейчас завершить задачу.

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

Если это повторяется, внешняя помощь может окупиться. Oleg Sotnikov работает с стартапами и небольшими командами над дисциплиной релизов, планированием восстановления и AI‑first операциями разработки — такая ревизия часто дешевле, чем повторять один и тот же простой дважды.