Что на самом деле происходит при обновлении работающего приложения

Вы заполняете форму. Страница зависает. Затем пустой экран. Затем сообщение об ошибке. Вы обновляете страницу, и введённые данные исчезают. Где-то кто-то только что выкатил новую версию приложения, которым вы пользовались.

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

Четыре проблемы, которые никуда не исчезают

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

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

flowchart TD A[Deploy New Version] --> B[Downtime] A --> C[Errors in New Version] A --> D[Data Incompatibility] A --> E[Rollback Trap] B --> F[Lost Revenue] B --> G[User Frustration] C --> H[Crash Under Load] C --> I[Bug in Production] D --> J[Data Corruption] D --> K[Old Code Can't Read New Data] E --> L[Data Loss] E --> M[Manual Reconciliation]

Даунтайм

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

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

Ошибки в новой версии

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

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

Несовместимость данных

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

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

Ловушка отката

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

Удалить их? Оставить в формате, который старый код не может прочитать? Конвертировать обратно? Каждый вариант имеет последствия. Чистый откат — редкость. Большинство откатов влекут за собой потерю данных, ручное согласование или период несогласованности.

Почему эти проблемы неизбежны

Вы не можете устранить эти четыре проблемы. Каждый деплой их привносит. Что вы можете контролировать — насколько сильно они повлияют на пользователей и как быстро вы сможете восстановиться, если что-то пошло не так.

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

Что на самом деле делает хорошая стратегия деплоя

Стратегия деплоя отвечает на три практических вопроса:

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

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

Быстрая проверка реальностью

Прежде чем углубляться в конкретные стратегии вроде rolling update, blue-green или canary release, полезно посмотреть, как большинство команд деплоят сегодня. Самый распространённый паттерн всё ещё самый простой: остановить старую версию, запустить новую, надеяться на лучшее. Это работает для низконагруженных внутренних инструментов. Но не работает для всего, от чего люди зависят.

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

Практический чек-лист перед выбором стратегии

Прежде чем выбирать стратегию деплоя, честно ответьте на эти вопросы. Ответы подскажут, на какие компромиссы идти.

  • Сколько секунд простоя ваши пользователи готовы терпеть, не бросая приложение?
  • Что произойдёт с данными, если новая версия запишет записи в другом формате?
  • Можете ли вы обнаружить ошибки в течение секунд после деплоя, или для их проявления нужны часы?
  • Сколько времени занимает полное восстановление сервиса из резервной копии, если данные повреждены?
  • Можете ли вы откатиться без ручной чистки данных, или каждый откат требует вмешательства DBA?
  • Сколько пользователей пострадает, если новая версия упадёт сразу?

Вывод

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