Вопрос про production ML
A production service already has data, but you need to change the database schema. Describe a safe миграцию.
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Use versioned migration scripts, test them on representative data, make backward-compatible changes first, backfill safely, deploy code in phases, monitor and keep rollback/forward-fix plans.
Полный разбор
Schema changes should be explicit and versioned, commonly through tools such as Alembic, Flyway, Liquibase, Django migrations or an internal migration framework. The migration is reviewed like code and tested against a staging copy or representative fixture data.
For low-risk changes, add nullable columns or new tables first, deploy code that can read/write both old and new shapes, backfill in batches, switch reads, then remove old fields in a later release. This expand-and-contract pattern avoids breaking old application versions during rolling deploys.
For large tables, avoid long locks and unbounded transactions. Use online DDL features where available, batch backfills, idempotent scripts, progress checkpoints and observability. Rollback is often a forward fix: you may not be able to safely undo a destructive migration after data has changed, so destructive steps should be delayed until the new path is stable.
Теория
Safe schema evolution is phased, backward-compatible and observable; destructive changes come last.
Типичные ошибки
- Apply a breaking schema change before deploying compatible application code.
- Run one huge migration on a large table without lock and runtime analysis.
- Treat rollback as simply reversing the SQL after production data has changed.
Как отвечать на собеседовании
- Use the phrase expand-and-contract if you know it, then explain it concretely.
- Name a migration tool but focus on the rollout sequence.