{
  "index": 53,
  "slug": "editorial-2026-07-mechanism-migration-playbook",
  "title": "Миграция без ложного rollback: четыре проверяемых границы перехода",
  "excerpt": "Без инвентаря, сопоставимого трафика, обратимого состояния данных и именованного триггера rollback статус «готово» ничего не доказывает. Разбираем механизм, отрицательные ветки и критерий готовности.",
  "contentHtml": "<p>После переключения на новую версию запросы начинают возвращаться с ошибкой. Команда нажимает rollback, старый маршрут снова отвечает, но часть записей уже прошла через новую схему. Трафик вернулся. Данные — нет. Цена ошибки — не только простой. Оператор теряет границу между тем, что отменилось, и тем, что осталось изменённым. Следующий шаг превращается в ручное расследование.</p>\n<p>Так происходит, когда миграцию описывают одним статусом: «готово», «можно переключать» или «rollback есть». Эти слова смешивают четыре разных вопроса. Известно ли, что именно переезжает? С чем сравнивают новый путь? Можно ли восстановить состояние данных? Понятно ли, когда и кто принимает решение о возврате? Если хотя бы один ответ отсутствует, зелёный статус создаёт ложную уверенность.</p>\n<h2>Тезис: переход состоит из независимых ворот</h2>\n<p>Безопасный переход — это не кнопка и не линейный список задач. Это последовательность ворот. Сначала система должна иметь полный для выбранного случая инвентарь. Затем она должна сравнивать control и candidate на одной границе. После этого нужно отдельно описать состояние данных и способ его восстановления. В конце нужен именованный триггер rollback, владелец решения и оба состояния возврата.</p>\n<p>Ворота проверяют структуру решения. Они не подтверждают, что production уже работает хорошо. Положительный результат означает только: карточка перехода достаточно полна для следующего инженерного шага. Он не переключает маршрут, не переносит записи и не обещает отсутствие ошибок.</p>\n<figure><img src=\"/assets/editorial/2026/migration-playbook-2026-rollback-decision-table.svg\" alt=\"Матрица решений для миграции: четыре синтетических случая, где неполный инвентарь, несопоставимый трафик и необратимые данные останавливают переход, а полный набор границ даёт hand-off\" loading=\"lazy\" /><figcaption>Иллюстрация разделяет причины остановки. Возврат трафика не заменяет восстановление данных, а названный trigger не компенсирует отсутствующую контрольную границу.</figcaption></figure>\n<h2>Механизм: сначала объект, потом движение</h2>\n<p>Начните с одного маршрута и одного типа записи. Для маршрута назовите owner, reader, writer и dependency. Для записи назовите source и target. Такая связка отвечает на вопрос: что именно меняет переход и кто видит результат. Не выводите эти связи из похожего имени файла, URL или сервиса. Если связь неизвестна, верните остановку. Предположение «скорее всего, это тот же объект» уже меняет смысл проверки.</p>\n<p>Инвентарь не обязан охватить всю платформу. Он обязан быть замкнутым для выбранного учебного или реального среза. Если карточка описывает только чтение, не называйте её миграцией записи. Если dependency не указана, нельзя оценивать трафик или восстановление: неизвестно, к какой части данных относится наблюдение.</p>\n<p>Вторые ворота проверяют трафик. Control и candidate должны иметь одну route boundary. Доли 90/10 сами по себе ничего не значат. Если control обслуживает другой путь, это не сравнение. Если control не назван, candidate проверяет себя сам. Observation window тоже должно иметь имя. В реальной среде оно включает период, источник метрик и правила расчёта. В учебном объекте достаточно зафиксировать границу, но нельзя выдавать её за реальные измерения.</p>\n<p>Третьи ворота относятся к данным. Флаг <code>migrated: true</code> не описывает обратный путь. Нужны source, target, reconciliation и restore state. Копия, прошедшая проверку количества строк, ещё не означает, что старую write-семантику можно восстановить. Это особенно важно при расширении схемы, смене идентификатора или переносе владельца записи.</p>\n<p>Четвёртые ворота делают rollback решаемым. Назовите trigger, условие, decision owner, traffic return и data return. Слово «аномалия» слишком широко. Оно не говорит, какой сигнал остановит переход. «Ошибки выросли» тоже недостаточно, если не указаны окно, источник и правило сравнения. Именованный trigger не запускает откат сам. Он делает вопрос воспроизводимым для того, кто принимает решение.</p>\n<h2>Конкретный пример: fail-closed проверка</h2>\n<p>Ниже — учебный JavaScript-пример. Он проверяет только фиксированный объект в памяти. Он не читает балансировщик, базу данных, метрики или Kubernetes API. Его задача — показать отрицательную ветку: candidate существует, но контрольная граница не задана.</p>\n<pre><code>const record = {\n  inventory: {\n    route: 'ledger-read',\n    owner: 'payments-team',\n    dependency: 'ledger-entry'\n  },\n  traffic: {\n    candidate: { routes: ['ledger-read'], share: 10 },\n    control: { routes: [], share: 90 },\n    observationWindow: 'window-v1'\n  }\n};\n\nfunction evaluate(input) {\n  if (!input.inventory.route || !input.inventory.owner || !input.inventory.dependency) {\n    return 'stop-missing-inventory';\n  }\n\n  const candidate = input.traffic.candidate.routes;\n  const control = input.traffic.control.routes;\n  if (!candidate.length || !control.length || candidate.join() !== control.join()) {\n    return 'stop-unbounded-traffic-slice';\n  }\n\n  return 'continue-to-data-and-rollback-gates';\n}\n\nconsole.log(evaluate(record));\n// stop-unbounded-traffic-slice</code></pre>\n<p>Результат не говорит, что новый маршрут опасен. Он говорит более узко: текущая запись не задаёт объект сравнения. Исправление тоже узкое — назвать control с той же границей и повторить проверку. Не следует заменять этот вывод фразой «проверить балансировщик»: код не имеет такого доступа и не может подтвердить действие в окружении.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика перехода по первой наблюдаемой причине</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Rollback вернул старый маршрут, но записи расходятся</td><td>Трафик и data state считались одним rollback</td><td>Назвать отдельно traffic return и data restore</td><td>Остановить переход до описания recovery state</td></tr><tr><td>Есть candidate 10% и control 90%</td><td>У наборов разные route boundaries</td><td>Сравнить route set, owner и окно наблюдения</td><td>Не считать доли сравнением</td></tr><tr><td>Копия завершилась успешно</td><td>Copy приняли за обратимое состояние</td><td>Проверить source, target, reconciliation и restore</td><td>Вернуть stop-irreversible-data-state</td></tr><tr><td>В документе написано «откат при проблеме»</td><td>Нет trigger, условия и владельца решения</td><td>Найти named condition и два return state</td><td>Не расширять слово rollback; дописать границы</td></tr><tr><td>Сервис не назван в инвентаре</td><td>Связь вывели по имени или предположению</td><td>Проверить owner, reader, writer и dependency</td><td>Остановить review на stop-missing-inventory</td></tr></tbody></table></div>\n<h2>Отрицательный путь важнее зелёной ветки</h2>\n<p>Представьте три неполных карточки. В первой нет dependency. Правильный результат — <code>stop-missing-inventory</code>; обсуждать проценты трафика рано. Во второй control и candidate указывают разные маршруты. Результат — <code>stop-unbounded-traffic-slice</code>; числа 90 и 10 не становятся доказательством. В третьей есть source, target и copy, но нет restore state. Результат — <code>stop-irreversible-data-state</code>; возврат маршрута не объявляют полным rollback.</p>\n<p>Есть и четвёртая ошибка: trigger назван, но не задано условие. «Rollback по решению владельца» не отвечает на вопрос, какое наблюдение открывает решение. В таком случае возвращается <code>stop-unnamed-rollback-trigger</code>. Система не должна угадывать порог, подставлять последний dashboard или считать любой timeout достаточным. У разных переходов разные сигналы и разные допустимые последствия.</p>\n<p>Порядок проверки намеренно короткий. Первая ошибка останавливает оценку. Это не скрывает остальные дефекты. Это задаёт ближайшую проверяемую работу. Если перечислить сразу десять проблем, команда может исправить вторую и пропустить первую. Если назвать только статус «не готово», следующий исполнитель снова будет восстанавливать контекст из разговора.</p>\n<h2>Порядок действий</h2>\n<ol><li>Выберите один переход и зафиксируйте его границу: маршрут, тип записи и owner.</li><li>Свяжите маршрут с reader, writer и dependency. Не заполняйте пропуск догадкой.</li><li>Опишите control и candidate с одинаковым route set. Назовите observation window и поля, которые в нём будут проверяться.</li><li>Опишите data transition: source, target, reconciliation и restore state. Не используйте флаг «миграция завершена» как замену обратному пути.</li><li>Назовите trigger, условие, decision owner, traffic return и data return. Разведите эти сущности в отдельных полях или строках.</li><li>Проверьте по очереди положительный случай и контрпримеры для каждого ворот. Сохраните первый stop reason и следующее действие.</li><li>Ограничьте положительный результат статусом hand-off на следующий review. Не превращайте его в разрешение на cutover.</li></ol>\n<h2>Что подтверждают официальные механизмы, а чего не подтверждают</h2>\n<p>У слова rollback нет общего смысла для всех слоёв. В документации Kubernetes откат Deployment относится к его Pod template. Это полезная граница: возврат версии workload не означает возврат записей в хранилище и не отменяет побочные эффекты приложения. Поэтому в карточке перехода traffic return и data return должны быть отдельными полями.</p>\n<p>У базы данных граница может быть другой. PostgreSQL описывает <code>ROLLBACK</code> как отмену изменений текущей транзакции. Это не равно восстановлению данных, уже записанных в другой транзакции, внешней очереди или стороннем сервисе. Нельзя перенести семантику одной транзакции на весь процесс миграции. Сначала назовите объект и границу действия.</p>\n<h2>Ограничения</h2>\n<p>Эта модель не измеряет задержку, error rate, нагрузку, стоимость простоя или долю пользователей. Она не проверяет корректность выбранного owner. Она не знает, что произойдёт при конкурирующих записях, повторной доставке сообщения или частичной недоступности хранилища. Именованный trigger тоже может быть плохим. Механизм лишь не даёт скрыть его отсутствие.</p>\n<p>Учебный код не создаёт traffic slice, не запускает SQL, не меняет Deployment и не выполняет восстановление. Его можно использовать для проверки формы карточки и отрицательных веток. Перед реальным переходом нужны инвентарь конкретной системы, rehearsal, наблюдение, права на действие и отдельно описанная процедура восстановления. Ни один положительный результат этой статьи не заменяет их.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Механизм готов к следующему review, если независимый читатель получает одинаковый результат из одной карточки: выбранный объект назван; owner, reader, writer и dependency связаны; control и candidate имеют общую границу; observation window указан; data state содержит reconciliation и restore; rollback имеет trigger, условие, владельца и два return state; каждый неполный вариант выдаёт именованный stop. Положительный результат остаётся hand-off. В нём нет утверждения о выполненном rollout, исправленных данных или достигнутом production-эффекте.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://kubernetes.io/docs/concepts/workloads/controllers/deployment/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Deployments</a> — официальная документация уточняет, что откат Deployment возвращает часть Pod template, а не произвольное состояние приложения.</li><li><a href=\"https://www.postgresql.org/docs/current/sql-rollback.html\" target=\"_blank\" rel=\"noopener noreferrer\">PostgreSQL: ROLLBACK</a> — официальная документация описывает отмену изменений текущей транзакции и не расширяет её до внешних систем.</li></ul>"
}