Перейти к основному содержимому

Стратегия cutover

Зачем нужно

Документ задаёт правила переключения с исходного контура на целевой домен: dual-write, backfill, переключение трафика, rollback.

Базовая модель

Каждый cutover имеет 5 фаз:

  1. Read-only mirror. Целевой домен запущен, читает данные через ETL/API, но не пишет.
  2. Dual-write. Запись идёт в оба источника. Целевой считается зеркалом, исходный контур — источником истины.
  3. Backfill. Историческая выборка переносится партиями. Idempotent, атомарно по сущности.
  4. Read switch. Чтение переключается на целевой домен. Исходный контур читает только в fallback.
  5. Write switch. Запись переключается на целевой домен, исходный контур переводится в read-only режим.

Между фазами — наблюдение за расхождениями (delta-checks) и rollback-план.

Правила

  • Целевой домен должен пройти acceptance до фазы dual-write.
  • Любой dual-write имеет idempotency_key и таймстамп источника.
  • Backfill идёт партиями, не блокирует prod-трафик.
  • Между фазами — окно стабилизации (минимум 7 дней) с метриками delta.
  • Откат выполним из любой фазы до write switch.

Паттерны по типам данных

Identity (пользователи, сессии)

  • read-only mirror UUID и контактов;
  • dual-write при создании пользователя через исходный контур и целевой identity;
  • backfill UUID и связей (family, organization);
  • читать сначала из целевого identity, fallback в исходный контур;
  • write switch — после feature-flag rollout.

CRM (лиды, сделки, биллинг)

  • read-only mirror лидов из Laravel/форм через события storefront;
  • dual-write при оплатах: новая система получает события платёжного провайдера, старая — продолжает;
  • финансовый backfill по периодам, отчётность согласовывается;
  • write switch — после фискальной сверки.

LMS (курсы, прогресс, занятия)

  • курсы импортируются по одному; пока курс не переключён, прогресс пишется в исходный контур;
  • по переключению курса в целевой LMS — backfill прогресса этого курса, далее запись в целевой домен;
  • занятия и attendance — параллельный двойной учёт ограниченное время для сверки;
  • read switch — по продукту/курсу.

Task-bank

  • задачи импортируются партиями по таксономии;
  • usage в новых уроках — только из целевого task-bank;
  • ранее созданные задачи остаются доступны через read-mirror до миграции набора;
  • write switch — после миграции authoring tools.

Competitions

  • по сезонам: cutover следует раннему migration decision по Мир Олимп: new season only, archive only, import tasks, import seasons/results или hybrid;
  • новый сезон в целевом домене использует LMS activity binding или temporary LMS-compatible adapter, а не competition-owned task runtime;
  • текущие сезоны остаются в исходном контуре до выпуска документов только при выбранном hybrid/import path;
  • результаты опубликованных сезонов остаются неизменными и проверяются по imported score snapshots/publication records.

Management

  • ingestion начинается параллельно с другими фазами;
  • ручные таблицы импортируются как seed-data;
  • замена ручных KPI на live agreggates — последовательно по dashboard.

Rollback

  • каждый cutover оформлен ADR с rollback-планом;
  • write switch разрешён только после успешного теста rollback на staging;
  • скрипты rollback хранятся вместе с миграциями;
  • обратная миграция данных не выполняется автоматически — только по решению.

Метрики и алерты

  • delta count между источниками;
  • задержка ETL/события;
  • ошибки dual-write;
  • DLQ событий миграции;
  • расхождение балансов (для финансовых).

Запрещено

  • ломочный cutover без read-only mirror;
  • write switch без dual-write периода;
  • ручные правки в обеих системах одновременно;
  • удаление данных исходного контура до истечения 1 года после write switch.

Связанные документы