Уточнить, что именно возвращает откат
Например, в Kubernetes возврат Deployment к предыдущей ревизии относится к его шаблону Pod. Это не универсальная машина времени для всех связанных данных. Если отдельная миграция изменила внешнюю базу, её состояние нужно учитывать самостоятельно. Представим сервис, который раньше читал отображаемое имя из одного столбца, а теперь должен использовать другой. Удаление старого столбца одновременно с выпуском нового кода создаёт риск: прежняя версия после возврата продолжит обращаться к отсутствующим данным. Проверять нужно сочетание версии кода и состояния схемы, а не только успешный запуск контейнера.
Разделить расширение и удаление
Один из подходов к изменению схемы состоит в поэтапном расширении и последующем сокращении. Сначала добавляют новую структуру, сохраняя необходимую совместимость. Затем переносят данные и переводят приложение на новый способ работы. Старую структуру удаляют только после проверки, что она больше не требуется поддерживаемым версиям и процессам. В нашем примере мало однократно скопировать имена: во время перехода могут появляться новые записи и изменения. Нужно заранее определить источник истины и порядок поддержания согласованности. Конкретная реализация зависит от системы; механическое добавление двух записей в разные столбцы ещё не гарантирует корректности.
Проверить поведение после возврата
Тестовый сценарий должен включать чтение прежних данных, создание новых и изменение существующих записей. Отдельно проверяют, что произойдёт после возврата старого приложения на промежуточной схеме. Если новый формат уже содержит сведения, которые старая версия не понимает, простого запуска может быть недостаточно. Резервная копия тоже требует отдельного плана восстановления: её наличие не объясняет, что станет с данными, поступившими позже. Для каждого этапа полезно записать допустимые версии, признаки ошибки и условие перехода дальше. Проверку проводят в подготовленной среде с тестовыми данными до изменения рабочей системы.
Попробуйте на практике
На бумаге разберите переименование поля отображаемого имени в вымышленном сервисе. Не выполняйте миграции и команды против реальной базы.
- Обозначьте старое приложение как версию А: оно читает и изменяет только прежнее поле. Запишите, почему после его удаления возврат версии А не решит проблему.
- Нарисуйте промежуточную схему, где оба поля существуют. Укажите вопросы о переносе имеющихся значений и о новых изменениях во время перехода.
- Составьте проверки для чтения, создания и обновления записи в новой версии. Отдельной строкой опишите ожидаемое поведение старой версии после возврата на промежуточной схеме.
- Запишите условие удаления прежнего поля: какие приложения и фоновые процессы больше не должны от него зависеть и каким наблюдением это подтверждается.
Как проверить результат. План различает возврат приложения и изменение данных. В нём есть проверка старого кода на промежуточной схеме, обработка новых записей и явное условие удаления прежней структуры.
Частые вопросы
Если контейнер запустился, откат можно считать успешным?
Запуск подтверждает только часть состояния. Нужно проверить значимые операции приложения и доступ к данным. Ошибка может проявляться только при чтении определённой записи или при попытке сохранить изменение.
Подход с двумя этапами гарантирует отсутствие простоя?
Нет. Он помогает управлять совместимостью, но результат зависит от миграции, объёма данных, блокировок, поведения приложения и проверки. Конкретный план нужно испытывать в условиях, соответствующих задаче.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.