{
  "index": 142,
  "slug": "editorial-2024-01-field-legacy-modernization",
  "title": "Модернизация legacy-системы: как ограничить rollout и не перепутать rollback с восстановлением данных",
  "excerpt": "Практическая схема замены одного участка legacy-системы: узкий шов, сравнимый control, ограниченная волна и отдельная проверка обратимости данных.",
  "contentHtml": "<p>В зрелом проекте слово «модернизация» часто появляется раньше, чем найдено конкретное место изменения. Проекту много лет, команда снова обсуждает полное переписывание, а перед переключением нового обработчика остаются вопросы: какой трафик он увидит, с чем его сравнивать, кто остановит волну и что произойдёт с уже записанными данными.</p>\n<p>Цена ошибки — не только временный рост ошибок. Новый путь может создать заказ, изменить баланс, отправить письмо или записать событие до обнаружения проблемы. Переключатель вернёт следующие запросы в старую систему, но уже созданный внешний эффект сам не исчезнет. Поэтому безопасная модернизация начинается с узкого шва и проверяемого решения, а не с обещания заменить весь монолит за один раз.</p>\n<p><strong>Главная граница.</strong> Rollout отвечает на вопрос «кому разрешён новый код». Rollback маршрута отвечает на вопрос «куда направить следующий запрос». Восстановление данных отвечает на вопрос «как обработать эффект, который уже произошёл». Это связанные, но разные действия.</p>\n<h2>Выберите шов, а не весь проект</h2>\n<p>Шов — участок поведения, который можно отделить от остальной системы: чтение карточки товара, расчёт тарифа или получение профиля. Для первой волны подходит операция с понятными входами, ограниченным числом потребителей и наблюдаемым результатом. Если операция меняет деньги, права или вызывает внешний сервис, граница должна включать эти эффекты, а не только HTTP-ответ.</p>\n<p>Другой инженер должен суметь назвать вход, старый контракт, новый контракт, владельца решения и способ остановить поток. Если измеряется только общий процент ошибок системы, шов слишком широк. Если неизвестно, кто пользуется старой схемой данных, сначала собирают зависимости и добавляют совместимый адаптер. Ниже приведён учебный сценарий: он объясняет способ проверки, но не выдаёт себя за отчёт о конкретной production-системе.</p>\n<table><caption>Минимальная карточка шва перед первым включением</caption><thead><tr><th>Поле</th><th>Пример</th><th>Что должно быть проверено</th></tr></thead><tbody><tr><td>Операция</td><td><code>GET /catalog/items/{id}</code></td><td>Понятно, какой запрос входит в волну</td></tr><tr><td>Владелец</td><td>Команда каталога</td><td>Есть ответственный за stop/continue</td></tr><tr><td>Control</td><td><code>legacy-v3</code></td><td>Есть известная версия для сравнения</td></tr><tr><td>Candidate</td><td><code>adapter-v1</code></td><td>Новый путь виден в логах и метриках</td></tr><tr><td>Состояние</td><td>Только чтение</td><td>Rollback маршрута не обещает откат записи</td></tr><tr><td>Сигналы</td><td>5xx, p95, schema diff</td><td>У каждого сигнала есть источник и порог</td></tr></tbody></table>\n<figure><img src=\"/assets/editorial/2024/legacy-modernization-2024-rollout-gate.svg\" alt=\"Петля rollout-модернизации: legacy-only, ограниченная подача candidate, проверка evidence и выбор между расширением и возвратом к legacy-only; граница необратимых данных показана отдельно\" loading=\"lazy\" /><figcaption>Схема показывает порядок принятия решения для учебного read-only шва. Это не отчёт о реальном трафике, метриках или выполненном возврате маршрута.</figcaption></figure>\n<h2>Поставьте proxy и сохраните старый контракт</h2>\n<p>Шов обычно оформляют как proxy, adapter или anti-corruption layer. Сначала слой пропускает все вызовы в legacy без изменения. Затем для выбранной операции он отправляет запрос в candidate, преобразует его внутренний ответ в прежний внешний контракт и позволяет одним изменением правила вернуть следующие запросы в legacy. Потребители не обязаны мигрировать одновременно с серверной реализацией.</p>\n<p>У proxy есть собственный риск: он может стать единой точкой отказа или узким местом. Его latency и ошибки измеряют отдельно, а исходный pass-through маршрут проверяют до включения candidate. Наличие прокси само по себе не доказывает готовность: нужны его версия, конфигурация и поведение при недоступности нового обработчика.</p>\n<p>Следующая команда показывает форму сравнения двух read-only маршрутов. Заголовок <code>X-Route</code> — условный интерфейс тестового адаптера; его нельзя посылать в произвольный production endpoint. Подставьте документированный способ выбрать control и candidate. Нормализуйте только поля, которые заранее признаны техническими.</p>\n<pre><code>test -n \"$BASE_URL\" || { echo \"set BASE_URL\" &gt;&amp;2; exit 2; }\ntest -n \"$ITEM_ID\" || { echo \"set ITEM_ID\" &gt;&amp;2; exit 2; }\n\nfor route in legacy candidate; do\n  curl --fail-with-body --silent --show-error \\\n    -H \"X-Route: $route\" \\\n    \"$BASE_URL/catalog/items/$ITEM_ID\" &gt; \"$route.json\"\ndone\n\njq -S 'del(.requestId, .generatedAt)' legacy.json &gt; legacy.normalized.json\njq -S 'del(.requestId, .generatedAt)' candidate.json &gt; candidate.normalized.json\ndiff -u legacy.normalized.json candidate.normalized.json</code></pre>\n<p>Нулевой diff проверяет только один вход и выбранную нормализацию. Добавьте valid, invalid, отсутствующий идентификатор, forbidden и повторный запрос. Если вызов имеет скрытый побочный эффект, сравнение JSON не заменяет журнал вызовов и сверку состояния.</p>\n<h2>Сделайте canary измеримым</h2>\n<p>Canary — не произвольные «десять процентов». В модели Google SRE candidate получает подмножество population на ограниченное время, а оставшаяся часть служит control. Нужны способ разделить трафик, процедура оценки и связь этой оценки с решением о выпуске. Разделителем может быть tenant, стабильная группа пользователей, отдельный маршрут или версия на балансировщике.</p>\n<p>Control должен быть сопоставим с candidate. Если новый код обслуживает только новых пользователей, различие может объясняться population. Если метрика строится каждый час, а волна длится пятнадцать минут, сигнал запоздает. Общая база, кеш или очередь могут позволить candidate повлиять на control, поэтому сравнение дополняют абсолютным SLO.</p>\n<table><caption>Пример decision gate для учебной волны</caption><thead><tr><th>Измерение</th><th>Источник</th><th>Если результат неизвестен</th></tr></thead><tbody><tr><td>HTTP 5xx по версии</td><td>Счётчик запросов proxy</td><td>Поставить волну на паузу</td></tr><tr><td>p95 latency</td><td>Histogram одного маршрута</td><td>Не расширять population</td></tr><tr><td>Схема ответа</td><td>Нормализованный contract diff</td><td>Разобрать поле и потребителей</td></tr><tr><td>Повторный эффект</td><td>record id или idempotency key</td><td>Остановить write-path</td></tr><tr><td>Состояние control</td><td>Абсолютный SLO</td><td>Отделить общий сбой от candidate</td></tr></tbody></table>\n<p>Порог — проектное решение, не универсальная цифра. Его связывают с SLO, размером выборки, длительностью окна и ценой ошибки. Один успешный ответ не доказывает совместимость, а хороший общий error rate может скрыть редкий дорогой сценарий.</p>\n<h2>Отделите симптом от вывода</h2>\n<table><caption>Диагностическая матрица перед расширением</caption><thead><tr><th>Симптом</th><th>Гипотеза</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Обсуждают только процент</td><td>Размер подменил стратегию</td><td>Назвать population, control, window и owner</td><td>Не включать candidate</td></tr><tr><td>Оба пути вернули 200</td><td>Сравнили транспорт, не смысл</td><td>Проверить поля, ошибки, latency и effect</td><td>Добавить contract cases</td></tr><tr><td>Candidate медленнее вечером</td><td>Различается нагрузка или cache state</td><td>Сопоставить окно, ключ и backend</td><td>Повторить в сопоставимой группе</td></tr><tr><td>После rollback появились дубли</td><td>Запись уже произошла</td><td>Сверить record id и журнал</td><td>Остановить запись, не делать blind delete</td></tr><tr><td>Никто не нажимает stop</td><td>Нет владельца и prior state</td><td>Проверить runbook на тестовом контуре</td><td>Вернуть решение на подготовку</td></tr></tbody></table>\n<p>Рост 5xx в candidate — сигнал остановиться, но не автоматическое доказательство причины: общая зависимость и несовпадающие окна могут менять оба пути. И наоборот, хороший A/B-график не отменяет проверки денежных, правовых и permission-sensitive эффектов.</p>\n<h2>Проведите волну как runbook</h2>\n<ol><li>Опишите один шов, его потребителей, владельца и границу состояния.</li><li>Зафиксируйте legacy-контракт: успешный вход, отказ, права, повтор и побочный эффект.</li><li>Поставьте proxy в pass-through и проверьте старый маршрут.</li><li>Подготовьте candidate с тем же внешним контрактом и отдельной версией в логах.</li><li>Сделайте dry run: valid, invalid, not found, forbidden и repeat.</li><li>Задайте population, control, duration, сигналы, пороги и владельца решения.</li><li>Включите стабильную малую группу на окно, покрывающее реальную рабочую нагрузку.</li><li>Сравните candidate с control и абсолютным SLO; unknown трактуйте как stop.</li><li>При остановке зафиксируйте состояние маршрута и переключите следующие запросы на известную версию.</li><li>Отдельно проверьте record id, внешние вызовы и очередь, затем решайте: расширять, чинить вперёд или восстанавливать данные.</li></ol>\n<h2>Rollback не отменяет уже созданный эффект</h2>\n<p>Для read-only шва rollback часто означает смену правила proxy: следующие запросы снова идут в legacy. Но общий кеш, sticky session, изменённая схема или миграция справочника могут связать старый и новый пути. Перед возвратом нужно проверить, что legacy понимает актуальное состояние и candidate не изменял его косвенно.</p>\n<p>Для write-операции новый обработчик мог создать заказ, отправить сообщение, вызвать платёжный шлюз или записать событие. Остановка candidate предотвращает часть новых вызовов, но не удаляет запись из внешней системы. Компенсация может быть невозможной, породить второй эффект или потребовать бизнес-решения.</p>\n<p>AWS различает cutover без новых данных и возврат после появления новых транзакций: во втором случае нужен отдельный план работы с данными, например fail-forward, dual-write или проверенное восстановление из backup. Это не универсальный рецепт. Способ выбирают по модели владения данными, RPO/RTO, идемпотентности и требованиям бизнеса.</p>\n<p>Минимальный набор для write-path — record id, журнал переходов, idempotency key или доказанное отсутствие повторной доставки, владелец сверки и порядок действий при расхождении. Если элементов нет, первый шов лучше сузить до чтения, добавить preview или оставить запись в legacy. Аварийный delete-скрипт без карты зависимостей — не стратегия восстановления.</p>\n<h2>Ограничения и критерий готовности</h2>\n<p>Canary снижает размер воздействия, но не заменяет тесты и не даёт статистической гарантии. Маленькая population может не содержать редкие роли. Synthetic traffic не воспроизводит все реальные состояния. Общие backend-компоненты нарушают независимость control и candidate. Система с балансами, правами или внешними эффектами требует более строгой границы, чем read-only endpoint.</p>\n<p>Универсального безопасного процента нет. Десять процентов запросов к операции, меняющей баланс, могут быть чрезмерным риском; для чтения сто процентов могут быть приемлемы после проверки совместимости. Размер и duration выбирают так, чтобы увидеть релевантную нагрузку, не потратить незаметно error budget и успеть остановить волну до необратимого ущерба.</p>\n<p><strong>Готовность доказана</strong>, когда без устного контекста можно показать точный шов, control и candidate, population, окно, источники сигналов, тестовые cases, stop/rollback runbook, список необратимых эффектов, владельца сверки, совместимость схемы и безопасное поведение при недоступности candidate. Пока хотя бы один пункт неизвестен, волну не расширяют.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/strangler-fig.html\" target=\"_blank\" rel=\"noopener\">AWS Prescriptive Guidance: Strangler fig pattern</a> — постепенная замена функций через proxy, маршрутизацию и adapter; описаны риски proxy layer и согласованности данных.</li><li><a href=\"https://sre.google/workbook/canarying-releases/\" target=\"_blank\" rel=\"noopener\">Google SRE Workbook: Canarying Releases</a> — canary как частичное ограниченное по времени включение, роль control, оценка и ограничения общей инфраструктуры.</li><li><a href=\"https://docs.aws.amazon.com/wellarchitected/2024-06-27/framework/ops_mit_deploy_risks_plan_for_unsucessful_changes.html\" target=\"_blank\" rel=\"noopener\">AWS Well-Architected Framework: Plan for unsuccessful changes</a> — документированный и проверенный rollback/fix-forward план, малые изменения и наблюдаемые сигналы.</li><li><a href=\"https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/cutover-stage.html\" target=\"_blank\" rel=\"noopener\">AWS Prescriptive Guidance: Cutover stage</a> — различие возврата до и после появления новых транзакций и варианты обращения с изменёнными данными.</li></ul>"
}