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

Короткий ответ

Нет единственно верного универсального процесса — обычно вводят классификацию изменений схемы по риску (аддитивные безопасные автоматом, потенциально ломающие — через обязательный expand-contract с чётким минимальным окном сосуществования версий, по-настоящему масштабные изменения — через параллельный путь данных вроде strangler pattern или dual-write с постепенной миграцией чтения), и платформенная команда задаёт стандартные инструменты/шаблоны (миграционные фреймворки, проверка совместимости схемы в CI) вместо того, чтобы требовать от каждой команды решать это самостоятельно с нуля.

Как это работает подробнее

экспанд-контракт идеально подходит для точечных изменений схемы, но становится тяжеловесным, если применять его буквально к каждому мелкому изменению в системе с частыми релизами — отсюда важность классификации: действительно рискованные изменения (удаление/переименование, смена типа данных, изменение уникальных ограничений) требуют полного цикла, а безопасные аддитивные изменения можно автоматически проверять в CI (например, линтером миграций, который блокирует потенциально ломающие операции без явного помечания как «намеренно ломающее с согласованным окном»). Для по-настоящему масштабных изменений (смена модели данных, разделение монолитной таблицы) часто используют strangler pattern — постепенный перевод части функциональности на новую модель, пока старая и новая сосуществуют и синхронизируются (dual-write или CDC-репликация).

Пример кода

example.sqlКопировать

-- Пример правила линтера миграций (псевдокод):
-- Запретить без явного тега ALLOW_BREAKING в сообщении миграции:
--   DROP COLUMN, DROP TABLE, ALTER COLUMN ... TYPE (несовместимое изменение типа),
--   добавление NOT NULL без DEFAULT на существующую таблицу с данными.

Сравнение

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

Что использовать на практике

• На практике. платформенная команда может предоставить общие инструменты — линтер миграций в CI (например, блокирующий `DROP COLUMN` без специального флага и согласованного тикета), библиотеку для безопасных миграций с автоматическим online-DDL для больших таблиц (чтобы не блокировать таблицу на запись при изменении схемы), и чёткий runbook для команд, не являющихся экспертами в миграциях баз данных.
• Пример. Задача для обсуждения: кандидату — спроектировать, как такой линтер должен обрабатывать legitimate случай (например, команда специально хочет удалить колонку после подтверждённого завершения expand-contract), не блокируя его навсегда и не ослабляя защиту для остальных случаев.

Подводные камни

• Частые ошибки. требуют от каждой продуктовой команды самостоятельно разбираться в nюансах безопасных миграций без платформенной поддержки, что приводит к разному уровню качества и повторяющимся инцидентам; применяют expand-contract бюрократически ко всем изменениям без исключения, замедляя разработку без пропорциональной пользы для низкорисковых случаев.