План миграции с ИИ: пусть ИИ готовит черновик, а люди решают

Почему слепые миграции с ИИ ломают всё

План миграции с ИИ может выглядеть аккуратно, логично и завершённо, но при этом не учитывать одно правило, которое делает данные пригодными для работы. Модель видит имена таблиц, типы полей и примерные строки. Она не видит тихие бизнес-правила, которых ваша команда придерживается каждый день: какие клиенты никогда не должны объединяться, какие счета нужно оставлять неизменными после экспорта или почему у "неактивного" аккаунта всё ещё должна храниться история выставления счетов.

Этот разрыв быстро приводит к реальному ущербу. Если ИИ неправильно сопоставит одно поле, ошибка не останется в одной строке. Она разойдётся по каждой импортированной записи, по всем последующим отчётам и по всем инструментам, которые доверяют новой системе. Неправильное соответствие между "контактом для выставления счетов" и "владельцем аккаунта" звучит мелко, пока письма от отдела продаж, тикеты поддержки и напоминания об оплате не начинают уходить не тому человеку.

Миграции баз данных становятся опасными, когда запись нельзя откатить. Скрипт, который перезаписывает ID, обрезает старые заметки или сводит дубликаты записей, может уничтожить контекст за считаные минуты. Команды часто думают, что смогут исправить всё позже, а потом выясняют, что исходные данные уже изменились, логи неполные или новая система уже начала синхронизировать плохие данные в другие приложения.

Хуже всего то, насколько убедительно может звучать ответ ИИ. Модель часто объясняет свои решения спокойным, аккуратным языком, даже если они построены на неверном допущении. Такой тон подталкивает людей пропустить проверку, потому что план кажется хорошо продуманным. Уверенность — это не доказательство.

Простой перенос записи клиента показывает риск. Допустим, старая система хранит одного человека с тремя адресами электронной почты и многолетними заметками о заказах. Новая система допускает только один email и более короткие текстовые поля. ИИ может предложить взять самый свежий адрес и обрезать заметки, чтобы они поместились. Это решает проблему формата, но может удалить адрес, которым по-прежнему пользуется бухгалтерия, и отрезать детали, нужные службе поддержки при спорах.

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

Определите границы до начала планирования

Прежде чем просить ИИ подготовить план миграции, решите, что инструмент может только черновиком, а что он никогда не должен решать сам. ИИ может превращать заметки в runbook, предлагать порядок шагов, разбивать работу на небольшие партии, составлять тестовые запросы и готовить список проверок для dry run. Он также может подсказать, где нужны проверки отката. Но он не должен выбирать ни один шаг, который может удалить, объединить, перезаписать или раскрыть живые данные.

Запишите эти ограничения простым языком. Если задача обратима и её легко проверить в staging, ИИ может подготовить черновик. Если задача меняет production-данные, правила доступа, платёжные записи, идентификаторы клиентов или журналы аудита, человек должен подтвердить её до запуска. То же правило действует и для скриптов, которые выглядят безобидно, но записывают изменения обратно в базу данных.

Короткая таблица согласования помогает держать команду в рамках:

• ИИ может готовить runbook, последовательность шагов, запросы для проверки и заметки для dry run
• Инженеры проверяют каждую команду перед выполнением
• Назначенный ответственный подтверждает удаление схемы, backfill, объединение и удаление записей
• Продуктовая команда или операционный блок подтверждают изменения, если могут затронуться клиентские записи, биллинг или данные, связанные с комплаенсом
• Любой участник команды запуска может остановить процесс, если результаты выглядят неверно

Для первых прогонов заблокируйте живые записи в той части системы, которую вы тестируете, или используйте окно только для чтения. Это кажется жёстким, но сильно снижает шум. Вам нужно увидеть, работает ли план на стабильных данных, а не пока новые записи продолжают поступать и скрывать ошибки.

Назначайте конкретных людей, а не только роли. "CTO" — слишком расплывчато, если трое думают, что решать должен кто-то другой. В небольшой команде это может быть основатель и старший инженер. Если в компании работает CTO на частичной занятости, он может подтверждать техническую часть, а владелец операционных процессов — бизнес-риски.

Команды часто пропускают этот шаг, потому что он кажется медленным. Но это всё равно быстрее, чем потом разбирать одну неудачную необратимую запись.

Соберите факты, прежде чем просить ИИ помочь

План миграции с ИИ работает только тогда, когда входные данные реальные и полные. Если скормить ему половинчатые сведения из памяти, он может выдать аккуратный план, который сломает production в первый же день.

Начните с текущей схемы. Экспортируйте таблицы, столбцы, типы, индексы, ограничения и любые пояснения к полям, которыми уже пользуется ваша команда. Столбец status в одном приложении может означать состояние платежа, а в другом — состояние аккаунта. ИИ не может безопасно угадать это сам.

Вам также нужна понятная заметка о исходной и целевой системах. Запишите, что именно переносится, где это хранится сейчас, куда должно попасть и какие версии или форматы используются с обеих сторон. Держите описание простым и конкретным, чтобы черновик не смешивал старые правила с новыми.

Прежде чем просить о порядке шагов, соберите в одном месте такие факты:

• последний экспорт схемы и короткие заметки по запутанным полям
• исходная и целевая системы, а также форматы данных и ограничения
• таблицы, где хранятся деньги, юридически значимые записи или данные клиентов
• допустимый простой, окно резервного копирования и время восстановления
• примеры записей с крайними случаями

Последний пункт экономит командам массу времени. Не давайте ИИ только чистые, аккуратные строки. Добавьте пустые значения, старые записи, дублирующиеся email, отменённые заказы, возвраты, объединённые аккаунты и имена или адреса с необычными символами. Такие записи быстро показывают все сложные места.

Критически важные таблицы требуют особого внимания. Если таблица влияет на счета, договоры, налоги или личность клиента, пометьте это явно. Так модель и ваши проверяющие поймут, где человеческая проверка изменений данных должна быть особенно строгой и где позже особенно важны дополнительные проверки отката.

Ограничения по простою тоже имеют значение. План для 5-минутного окна обслуживания выглядит совсем иначе, чем перенос на выходных. То же самое касается времени резервного копирования. Если полное восстановление занимает 3 часа, черновик не должен предполагать быстрый откат.

Эта подготовка становится основой вашего чек-листа миграции базы данных. Она также делает валидацию данных на staging намного полезнее, потому что тестовые данные будут отражать реальные проблемы, а не вычищенную фантазию. Когда люди проверяют черновик, они могут оценить шаги по фактам, а не по надежде.

Разбейте миграцию на маленькие шаги

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

Так план становится проще читать, проще проверять и проще останавливать. Хороший план миграции с ИИ должен казаться почти скучным. Если один шаг ломается, вы должны точно понимать, где остановиться, что изменилось и что нужно откатить.

У каждого шага должны быть пять частей:

• точное действие
• проверка, которая доказывает, что всё сработало
• точка остановки перед любым живым изменением
• действие отката, если проверка провалилась
• человек, который подтверждает следующий шаг

Проверка важна не меньше, чем само действие. Если ИИ пишет: "скопируйте пользователей в новую таблицу", он также должен указать, как команда подтвердит количество строк, долю пустых значений, дублирующиеся ID и поведение приложения перед переходом дальше. Без этого план — всего лишь догадка с красивым оформлением.

Ставьте жёсткую остановку перед каждым необратимым шагом. Сюда относятся удаление старых данных, переписывание основных полей, объединение записей или изменение того, как приложение записывает новые элементы. ИИ часто предлагает чистую последовательность, но людям нужно отмечать точки, где production-данные могут измениться так, что это будет трудно откатить.

Шаги отката должны содержать реальные команды, а не расплывчатые заметки. "Откатить при необходимости" бесполезно в 2 часа ночи. Лучший шаг говорит, кто восстанавливает snapshot, какой скрипт переключает запись обратно, как команда проверяет, что старый путь по-прежнему работает, и сколько обычно занимает такое восстановление.

Прогоните всю последовательность в staging перед production. Используйте данные, похожие на реальные, даже если вы маскируете чувствительные поля. Засекайте время каждого шага. Следите за временем блокировок, медленными запросами, неудачными повторными попытками и расхождением итогов. Если путь отката не работает в staging, production-план ещё не готов.

Чек-лист миграции базы данных работает лучше всего, когда каждый шаг может существовать сам по себе. Если кто-то подключится к звонку на полпути, он всё равно должен видеть текущее состояние, следующий шаг и путь выхода на одном экране.

Добавьте проверки отката к каждому рискованному шагу

Каждому шагу миграции, который меняет живые данные, нужен понятный путь назад. "У нас есть резервные копии" — этого недостаточно. Резервная копия помогает только если её недавно восстанавливали и знают, сколько времени займёт восстановление.

Перед production проведите одну реальную проверку восстановления в безопасной среде. Восстановите последнюю резервную копию, запустите приложение и убедитесь, что данные пригодны для работы. Если восстановление занимает два часа, а окно простоя — 20 минут, команде нужен другой план.

Маленькие проверки лучше, чем одна большая догадка в конце. После каждого шага сравнивайте количество строк до и после изменения. Затем сверяйте факты, которые должны оставаться стабильными: суммы, ID записей и такие временные метки, как created_at и updated_at. Если загружается 250 000 клиентских записей, на выходе должно получиться 250 000, с теми же ID, если только план не предполагает иного.

Эти проверки должны быть в любом чек-листе миграции базы данных, даже если первый черновик написал ИИ.

Короткое время держите обе версии

Для рискованных изменений временно держите старые и новые данные рядом, вместо того чтобы сразу удалять источник. Часто достаточно копии только для чтения. Это дополнительное время помогает команде заметить неправильные сопоставления, пропущенные записи или странные сдвиги временных меток до того, как старые данные исчезнут.

Также нужен чёткий стоп-правило. Команды принимают плохие решения, когда чувствуют давление закончить быстрее. Запишите точные события, которые требуют отката:

• количество строк отличается от ожидаемого
• итоговые суммы не совпадают в рамках согласованного допуска
• ID пропали, продублировались или были случайно изменены
• временные метки сдвигаются так, как план не разрешал
• восстановление занимает больше времени, чем команда утвердила

Назначьте одного человека, который может остановить rollout, и сделайте это решение простым. Если одна проверка не проходит, приостановите следующий шаг, откатите изменения и изучите данные до того, как кто-то попытается срочно чинить всё прямо в production.

Хороший план миграции с ИИ не просто перечисляет шаги. Он говорит людям, когда остановиться, что сравнить и как вернуться к известному хорошему состоянию.

Простой пример с клиентскими записями

Допустим, компания хочет перенести данные клиентов из старой CRM в новую до следующего расчётного периода. В старой базе first_name и last_name хранятся в отдельных полях. В новой системе ожидается одно поле full_name. Там также используется другая модель статусов, поэтому старые значения вроде trial, active и suspended нужно перевести на новые метки.

Вот где план миграции с ИИ действительно помогает, если держать его на коротком поводке. Инструмент может предложить порядок работы, сопоставление полей и список проверок отката. Но люди по-прежнему должны подтвердить каждый шаг, который может повредить данные.

Разумный черновик обычно выглядит так:

• скопировать записи клиентов в staging-таблицу
• собрать full_name из двух старых полей имени
• сопоставить старые значения статусов с новым набором
• пометить записи, которые не сопоставляются без проблем
• приостановить удаление, пока сотрудники не подтвердят совпадения

Объединение имён звучит просто, но грязные записи показывают, почему человеческая проверка важна. У одного клиента может не быть фамилии. У другого в first_name может быть название компании, а в last_name — пусто. У третьего могут быть лишние пробелы или титулы вроде "Dr". ИИ может заметить закономерности, но кому-то всё равно нужно открыть небольшой набор записей и проверить странные случаи.

Десяти записей достаточно для начала, если это не десять случайно выбранных аккуратных записей. Специально проверьте сложные случаи: пустые поля, дублирующиеся аккаунты, необычную историю статусов и записи с заметками от продаж или поддержки. Если они проходят, сопоставление, скорее всего, верное. Если нет — исправьте правила до того, как тронете production.

Со статусами нужна та же аккуратность. Возможно, active становится current, trial — pending, а suspended — on_hold. Такое сопоставление может выглядеть нормально в черновике, но человеку нужно задать один простой вопрос: сохраняет ли каждый новый статус то же бизнес-значение? Если billing, поддержка или отчётность трактуют этот статус по-разному, неверное сопоставление быстро создаст реальные проблемы.

Самый безопасный ход — отложить жёсткое удаление. Держите старые строки доступными, пока команда не подтвердит, что количество клиентов совпадает, выборочные проверки выглядят правильно, а отчёты по-прежнему сходятся как надо. Только после этого кто-то должен утвердить окончательное переключение. Это подтверждение должно быть после прохождения проверок, а не до.

Ошибки, которые команды совершают с планами, написанными ИИ

ИИ может подготовить план миграции, который выглядит аккуратным и завершённым. Именно поэтому ему слишком быстро доверяют. Чистый документ может скрывать неверные догадки, пропущенные крайние случаи и шаги отката, которые рассыпаются в момент, когда реальные данные начинают сопротивляться.

Первая ошибка — соглашаться с предположительными сопоставлениями полей. Если в старой системе есть "name", а в новой — "display_name", план миграции с ИИ может сопоставить их без вопроса, кто и как использует каждое поле. Эта ошибка становится ещё хуже с датами, значениями статусов, кодами стран, налоговыми ID и свободными заметками. Одно неверное сопоставление может за минуты размазать плохие данные по тысячам записей.

Следующая проблема — грязные данные. Команды тестируют план на маленьком чистом наборе и чувствуют себя в безопасности, потому что всё работает. Но production-данные редко бывают чистыми. Какие-то строки пустые, какие-то повторяются, какие-то ломают формат, а в каких-то значения, которых никто не ожидал. Если пропустить валидацию данных на staging с реальными экспортами, ИИ напишет шаги для идеальной базы, а не для вашей настоящей.

Одни и те же предупреждающие признаки повторяются снова и снова:

• План предполагает, что у каждой записи одинаковый набор обязательных полей.
• Дублирующиеся пользователи или клиенты объединяются по слабому правилу.
• В rollback написано "восстановить резервную копию", но никто не засёк время и не проверил это.
• Один релиз одновременно меняет схему, заполняет пропуски в данных, переименовывает поля и обновляет логику приложения.

Шаги отката часто хорошо выглядят на бумаге и не работают на практике. Команды пишут их потому, что так сказано в чек-листе, а не потому, что они репетировали это заранее. Если миграция удаляет строки, переписывает ID или преобразует финансовую историю, откат нужно отрабатывать вживую. Нужно знать, сколько времени занимает восстановление, какие данные потеряются между резервной копией и сбоем, и кто принимает решение остановить процесс.

Попытка изменить слишком много за один релиз — это ошибка, которая связывает всё остальное воедино. Большие релизы скрывают первопричину, когда что-то ломается. Маленькие релизы требуют немного больше времени на планирование, но они намного упрощают человеческую проверку изменений данных. Вы можете проверять одно сопоставление, одно преобразование и одну проверку отката за раз. В первый день это медленнее, но потом намного быстрее, чем разгребать последствия плохой миграции.

Быстрые проверки перед production

Последний час перед миграцией решает, будет ли у вас спокойный релиз или грязный откат. Если хотя бы одна проверка безопасности всё ещё держится на надежде, подождите.

Хороший план миграции с ИИ может предложить порядок шагов, но production требует человеческого подтверждения. Перед началом команда должна проверить пять вещей с доказательствами, а не по памяти.

• Резервная копия полная, свежая и хранится там, откуда команда быстро сможет её достать. Один человек должен восстановить её в чистой среде и доказать, что приложение может читать восстановленные данные.
• Прогон в staging использовал данные, похожие на production, а не аккуратную выборку. Старые строки, пропущенные значения, дублирующиеся записи, странный текст и слишком длинные поля часто и создают настоящие проблемы.
• У каждого шага, который удаляет, объединяет или перезаписывает данные, есть подтверждение владельца. Продукт, операционная команда и все, кто отвечает за записи, должны сказать "да" до открытия окна изменений.
• Мониторинг включён до запуска первого скрипта. Логи, оповещения об ошибках, метрики базы данных и глубина очередей должны быть видны там, где команда может смотреть на них в реальном времени.
• Поддержка знает, что могут заметить пользователи. Если имена, статусы, временные метки или история аккаунта будут выглядеть иначе несколько часов, поддержке нужен короткий бриф и понятный путь эскалации.

Одна деталь всё время выпадает: проверка восстановления. Команды чувствуют себя в безопасности, когда видят задание резервного копирования со статусом "success", но это доказывает только то, что файл существует. Это не доказывает, что резервная копия пригодна, полна и достаточно быстра для восстановления под давлением.

К staging нужна та же честность. Если в production десять лет клиентских записей с грязными импортами и ручными правками, staging должен отражать эту форму. Чистые тестовые данные могут скрыть проблемы до самого плохого момента.

Подтверждение особенно важно для необратимых действий. Если скрипт должен объединить дублирующиеся профили клиентов в одну запись, владелец этих данных должен подтвердить правила сопоставления, крайние случаи и то, что произойдёт с заметками, тегами и историей аудита.

Когда все пять проверок пройдены, команда запуска может сосредоточиться на выполнении, а не на догадках. Это само по себе сильно сокращает количество плохих решений посреди ночи.

Что делать дальше

План миграции с ИИ полезен только тогда, когда он превращается в runbook, по которому реальные люди могут работать под давлением. Очистите черновик, уберите догадки и превратите каждый шаг во что-то конкретное: кто запускает, что именно запускает, какой результат ожидается и что заставляет остановиться.

Хороший runbook в лучшем смысле скучный. В нём должен быть точный порядок действий, проверки перед каждым рискованным изменением, действия отката для каждого необратимого шага и человек, который подтверждает следующий этап. Если коллега прочитает его и всё равно спросит: "Что мне делать сейчас?", значит, черновик ещё нужно дорабатывать.

Перед production запланируйте dry run в staging или на недавней копии production-данных. Засеките время каждого шага. Здесь важны даже мелкие сюрпризы. Копирование данных, которое в теории занимает 4 минуты, на практике может занять 19, и это меняет окно обслуживания, план коммуникаций и решение по откату.

Сделайте финальную подготовку простой:

• Пройдите runbook построчно с людьми, которые будут выполнять миграцию.
• Проверьте восстановление резервной копии, а не только её создание.
• Зафиксируйте ожидаемое время каждого шага и максимальную задержку, которую вы готовы принять.
• Назначьте одного человека, который во время миграции сможет сказать "стоп" или "продолжаем".

Последний пункт спасает команды от хаоса. Пять умных людей, спорящих во время живой миграции, работают медленнее, чем один ясный ответственный, который выслушивает всех и принимает решение. Назначьте этого человека до начала работ, а не в середине неудачного шага.

Если вам нужен второй взгляд, Oleg Sotnikov как CTO на частичной занятости может проверить инструкции по миграции. Это особенно полезно, когда план включает сложную логику отката, производственные риски или работу с ИИ, которая всё ещё требует сильной человеческой проверки.

Не стремитесь к идеальному документу. Стремитесь к runbook, который уставшая команда сможет выполнить в 2 часа ночи без догадок. Если какой-то необратимый шаг всё ещё звучит расплывчато, остановитесь и перепишите его до запуска в production.