Как обновлять работающую систему без остановки бизнеса

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

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

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

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

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

Поэтому безопасное обновление требует ответов на несколько вопросов:

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

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

Что на самом деле означает обновление без остановки

Фраза «обновить систему без остановки» звучит однозначно, но технически может обозначать разные требования.

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

Это не одно и то же.

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

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

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

Такое поведение может быть правильным, если оно предусмотрено бизнес-правилами и пользователь понимает статус своей операции.

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

Начинать нужно с критичных бизнес-операций

До разработки стратегии релиза полезно составить перечень операций, которые нельзя нарушить:

• › создание и изменение заказов;
• › проведение платежей и возвратов;
• › резервирование и списание товаров;
• › обмен данными между CRM и ERP;
• › выполнение регламентных и фоновых заданий;
• › формирование документов, на основании которых совершаются дальнейшие действия.

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

Почему обновление нужно проектировать с учётом переходного состояния

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

Схема упрощена: конкретный способ работы с данными зависит от архитектуры и стратегии развёртывания.

Главный риск возникает именно в переходном периоде. Старая и новая версии могут по-разному трактовать один объект, использовать различные контракты API или предъявлять разные требования к структуре базы данных.

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

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

Как выбрать стратегию развёртывания

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

Rolling deployment: последовательное обновление экземпляров

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

Преимущество подхода — возможность обновлять систему без одновременной остановки всех экземпляров приложения.

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

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

Blue-green deployment: подготовка отдельной среды

При blue-green deployment создаются две среды. Текущая обслуживает пользователей, а новая подготавливается и проверяется отдельно. После прохождения проверок трафик переключается на новую среду.

Такой подход упрощает подготовку и проверку новой версии до её полноценного ввода в эксплуатацию. При необходимости можно предусмотреть возврат трафика на прежнюю среду.

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

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

Canary deployment: постепенное увеличение воздействия

При canary deployment новая версия сначала получает ограниченную долю рабочего трафика. Команда оценивает её поведение, после чего постепенно увеличивает долю запросов.

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

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

Кроме того, если несколько запросов одного бизнес-процесса попадают на разные версии приложения, their поведение должно оставаться совместимым.

Какой вариант выбрать

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

Совместимость версий: условие безопасного перехода

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

CRM уже может работать на новой версии, ERP — на прежней, а интеграционный сервис — обрабатывать сообщения, созданные обеими версиями.

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

Поэтому изменения необходимо проектировать с учётом обратной совместимости.

Пример: изменение контракта между CRM и ERP

Предложим, CRM передаёт в ERP сведения о заказе. В новой версии требуется дополнительное поле, например код канала продаж.

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

Более безопасный переход предполагает предварительную подготовку обеих сторон.

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

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

What проверять при изменении интеграции

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

Изменение базы данных: самая сложная часть отката

Изменения приложения и изменения базы данных необходимо рассматривать отдельно.

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

Рассмотрим пример. В новой версии приложения поле customer_name заменяется на customer_display_name. Если старый код ожидает прежнее поле, а миграция уже удалила его, возвращение старого приложения не восстановит работоспособность.

Именно поэтому для изменения структуры базы данных используют поэтапные миграции.

Подход expand-contract

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

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

Только после подтверждения, что старая структура больше не используется, её можно удалять.

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

Почему нельзя всегда просто откатить миграцию

Некоторые изменения схемы легко обратимы технически, но не обязательно обратимы с точки зрения данных.

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

Поэтому до начала миграции нужно определить:

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

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

Как подготовить настоящий план отката

План отката должен отвечать не на вопрос «как запустить старую версию», а на вопрос «как вернуть систему в допустимое состояние после неудачного изменения».

Это особенно важно, когда релиз затрагивает базу данных, очереди сообщений, фоновые задачи и внешние интеграции.

Перед выпуском необходимо определить несколько сценариев.

Что должно быть в плане восстановления

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

Мониторинг релиза: проверять бизнес-результат, а не только доступность

После развёртывания новой версии недостаточно убедиться, что приложение запустилось и отвечает на запросы.

Нужно проверить, что оно выполняет свою функцию правильно.

Например, API может возвращать успешные ответы, но интеграционный сервис перестанет передавать отдельные категории заказов. Средняя задержка запросов при этом останется в норме.

Поэтому мониторинг релиза должен охватывать три уровня.

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

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

Пример: очередь после обновления

Допустим, во время условного 30-минутного сбоя интеграции в очередь поступает 20 сообщений в секунду.

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

Если бизнес допускает восстановление нормального режима только за 30 минут, текущей пропускной способности недостаточно. Необходимо заранее оценить возможности безопасного ускорения обработки, приоритизации и ограничения входящего потока.

Как автоматизировать выпуск, не автоматизируя хаос

CI/CD позволяет стандартизировать сборку, проверки и развёртывание. Но автоматический конвейер не гарантирует корректность релиза, если критерии качества определены неправильно.

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

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

При этом для критичных релизов полезно разделять следующие виды проверок:

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

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

Сквозной пример: обновление CRM, интеграции и ERP

Рассмотрим условный проект. Компания обновляет CRM, добавляя новые правила обработки заказов и меняя формат сообщения, которое передаётся в ERP.

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

Поэтому переход необходимо организовать по состояниям.

Как выбрать уровень защиты с учётом стоимости и риска

Максимально сложная стратегия не всегда оправданна.

Blue-green deployment может требовать значительных дополнительных ресурсов. Canary deployment предполагает возможность корректно ограничить трафик и интерпретировать результаты. Rolling deployment требует совместимости версий. Поэтапная миграция увеличивает сложность переходного периода.

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

На основании этой оценки выбирают стратегию, набор тестов, глубину мониторинга и порядок восстановления.

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

Чек-лист безопасного обновления

Перед релизом стоит пройти по следующим пунктам.

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

Заключение

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

Rolling deployment, blue-green deployment и canary deployment позволяют управлять способом выпуска. Поэтапные миграции помогают сохранять совместимость данных. Автоматизированные проверки и мониторинг дают возможность обнаруживать отклонения. План восстановления определяет, что делать, если новая версия всё же работает неправильно.

Но ни одна из этих технологий по отдельности не гарантирует безопасного релиза.

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

Поэтому до начала выпуска необходимо определить не только последовательность развёртывания, но и допустимые переходные состояния системы, критерии остановки и проверяемые условия восстановления.

Для руководителя это означает управляемый риск изменений. Для архитектора — необходимость проектировать переходные состояния наряду со штатной архитектурой. Для команды эксплуатации — понятный порядок контроля и восстановления.

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

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).