Практическое руководство по тестированию миграции цифровой инфраструктуры

От функциональной приемки до нагрузочных и аварийных испытаний. Полезно для CTO, CIO и владельцев продуктов.

Мы вошли в эру все более нестабильного интернета. Прежняя уверенность в неуязвимости облачных систем рассыпалась, оставив трезвое осознание, что так как раньше, больше не будет. Недавняя критическая ситуация с дата-центрами в России показала бизнесу, как важно иметь план Б. Практически все игроки IT-рынка получили повод серьезно задуматься о диверсификации данных по разным ЦОД. 

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

Представьте, сервера запустились, база перенеслась, мониторинг светится зеленым. Миграция удалась, не так ли? 

Не обязательно. Пользователь не покупает виртуальную машину: он оплачивает заказ, получает выписку, оформляет заявку. Если эти операции после переезда перестали работать или выполняются втрое дольше, то бизнес несет потери.

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

Что меняется при IT-миграции, даже если код не трогали?

Начнем с определения. Миграция – это перенос приложения или его частей на другую технологическую базу: в новый ЦОД, облако, кластер Kubernetes, СУБД, хранилище, либо к другому поставщику API. При смене хоста меняется в основном среда; при смене платформы – платформенные компоненты; при рефакторе – еще и поведение приложения. 

Стоит всегда помнить, что даже самый легкий переезд не означает нулевой риск. Адреса, DNS, сертификаты, время жизни сессий, версии драйверов, сетевые ACL, файловые пути, тайм-ауты, транзакционная семантика, лимиты внешних сервисов, балансировщики и очереди могут измениться незаметно для разработчика. Система при этом продолжает отвечать, но не проводит платежи, теряет события или выдает отчеты с устаревшими данными.

Чтобы структурировать результаты, удобно делить критерии успеха на три уровня: 

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

Именно третий уровень (операционный) позволяет отвечать за непрерывность бизнеса.

Объясняем на примерах: как компании обжигались при миграции данных

TSB Bank: перенести данные – не значит перенести сервис

В апреле 2018 года шотландский TSB переводил банковские сервисы на новую IT-платформу. Перенос данных сам по себе состоялся, но после переключения возникли серьезные проблемы с обслуживанием через отделения, контакт-центр, цифровой и мобильный банк. Регуляторы указывали на недостатки управления миграцией, испытаний, контроля рисков и готовности к инцидентам. Проблемы затронули значительную долю 5,2 млн клиентов; в 2022 году FCA и PRA (британские регуляторы) оштрафовали банк на £48,65 млн.

Да, возможно, дополнительное QA-тестирование не предотвратило бы катастрофу гарантированно, так как причины были организационными и техническими. Но именно комплексная приемка реальных бизнес-процессов, проверка объема и пиков нагрузки, заранее заданные критерии Go/No-Go и операционные репетиции дали бы руководству основания вовремя остановить переключение.

Knight Capital: одна ошибка вызвала крах бизнеса

В августе 2012 года Knight Capital (один из крупнейших участников фондового рынка США) ошибочно развернула торговое ПО: обновление попало не на все серверы, а старый компонент неожиданно начал отправлять некорректные заявки. По данным SEC, за 45 минут система отправила более 4 млн заявок, а убытки превысили $460 млн. Это не пример инфраструктурной миграции в узком смысле, но точная иллюстрация риска перехода.

Контрмеры для миграции в QA: контроль артефактов и конфигурации на каждом узле, проверки однородности среды, канарейки, ограничение масштаба ошибок, кнопка остановки и мониторинг бизнес-эффектов, а не только CPU. 

Кстати, KCG так и не смогла оправиться от инцидента как независимый бизнес. Технический сбой 1 августа 2012 года нанес фирме непоправимый ущерб, который привел к потере самостоятельности и последующему поглощению.

Cloudflare: пример грамотного переноса инфраструктуры

В 2024 году Cloudflare описала в своем блоге перенос активной DNS-базы, содержащей миллиарды записей. Команда применяла: перенос партиями, многонедельную синхронизацию изменений, проверки исходной и целевой базы и контролируемое переключение записи. Обнаружились даже редко используемые сервисы, упущенные при инвентаризации, а предусмотренный путь возврата помог их обработать. Это не универсальный рецепт для любой СУБД, но сильный пример совмещения проверки данных, постепенности и готовности к исключениям.

Что именно проверяет команда тестирования?

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

Функциональные, регрессионные и приемочные испытания

Тестируются полные цепочки: авторизация — действие — запись в БД — событие — внешний сервис — статус пользователя — журнал аудита. 

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

Интеграции и данные

Проверяются API-контракты, версии схем, TLS, сертификаты, DNS, тайм-ауты, ретраи, идемпотентность, DLQ, порядок и доставка событий. 

Для миграции СУБД дополнительно нужны полнота, уникальность, контрольные суммы, агрегаты и референциальная целостность. Равенство количества строк – лишь первый фильтр: 10 млн перенесенных записей не гарантируют, что верно посчитан баланс каждого клиента.

Если использована CDC-репликация, QA отдельно фиксирует допустимый лаг, момент остановки записи, финальную сверку, специфические сценарии и то, кто является единственным источником истины после перехода. Автоматическая валидация в AWS, например, сравнивает строки, но сама по себе не заменяет проверку бизнес-инвариантов.

Нагрузка, производительность и устойчивость

Руководителю важно знать не сколько RPS выдержал кластер, а как меняются успешные заказы, задержка и ошибки при реальной структуре трафика. Грамотно сначала снять базовые показатели на старой платформе: профиль запросов, суточные пики, распределение транзакций, p50/p95/p99, долю ошибок, очередь, CPU, память, DB locks и внешние лимиты. Затем повторить профиль в сопоставимой целевой среде.

Набор испытаний: baseline-сравнение; ожидаемый пик; spike-тест (резкий всплеск); стресс-тест до найденной точки деградации; отказоустойчивости под нагрузкой. Генератор должен создавать не абстрактные запросы к главной странице, а сочетание чтений, изменений, фоновых задач и вызовов подрядчиков. Особое внимание – «тихим» отказам: очередь растет, но HTTP по-прежнему отвечает 200.

Например, для сервиса с 100 заказами/мин в обычный час и 400 в промо-пик можно согласовать испытание на 400 заказах/мин плюс реалистичный фоновый поток и запас, выведенный из прогноза роста. Критерий не «150% потому что так принято», а бизнес-SLO: скажем, 99,9% корректно оформленных заказов за целевой период, p95 времени оформления по утвержденному порогу, отсутствие потери и дублирования. Все числа в этом примере условные, не отраслевой стандарт.

Безопасность, отказоустойчивость, наблюдаемость

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

Отдельно моделируются недоступность ноды, зоны, БД, очереди, платежного шлюза. Измеряются RTO – фактическое время восстановления – и RPO – фактический объем потери данных во времени; их сравнивают с заранее согласованными пределами. Проверяется именно восстановление из резервной копии, а не сообщение «backup successful». Также чекаются алерты: кто, по какому сигналу и за сколько минут узнает о сбое.

На каком этапе миграции приглашать QA и как организовать работу?

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

Роли и зоны ответственности нужно назначить конкретно: владелец продукта отвечает за допустимый бизнес-риск; руководитель миграции – за последовательность и окно; QA lead – за стратегию, качество доказательств и остаточные дефекты; Infra/Data – за среду и миграцию; SRE – за SLI, реакции на аварии и восстановление; Безопасность – за доступы и контроль данных.

QA формирует рекомендацию, а решение по конкретным действиям принимает уполномоченный владелец риска. Не тестировщик, который поставил галочку.

Мини-план: какие именно проверки запускать перед переключением

Шаг 1.  Составить реестр компонентов и невидимых зависимостей: сервисы, БД, очереди, планировщики, batch, FTP/SFTP, SMTP, SSO, DNS, API партнеров, сертификаты, IP allowlists. Для каждой зависимости – ответственный и сценарий отказа.

Шаг 2.  Снять базовые показатели старой системы на одной и той же модели данных и нагрузки. Установить пороги выхода: SLI, SLO, бизнес-ошибки, p95/p99, объем очередей, долю тайм-аутов; пороги утвердить с продуктом.

Шаг 3.  Подготовить правдоподобную целевую инфраструктуру: версии, лимиты, сетевые пути, объемы данных, обезличенные или синтетические наборы. Отдельно отметить отличия тестовой среды от продакшена – иначе нагрузочные выводы ограничены.

Шаг 4.  Исполнить риск-ориентированный набор проверок: smoke — сквозные сценарии — сверка данных — безопасность — нагрузка — аварии. Критические сценарии автоматизировать и сохранять трассы, логи, результаты прогонов.

Шаг 5.  Провести репетицию переезда на копии: синхронизация, финальная сверка, «заморозка» записи, переключение, прогон smoke, возврат трафика. Измерить время каждого действия. План отката проверять с учетом изменений данных, появившихся уже после старта.

Шаг 6.  Установить режим поэтапного включения.

Шаг 7.  После переключения пройти сквозные бизнес-сценарии, сверить агрегаты данных и алерты; выдержать период усиленного контроля, включающий ночные джобы, отчетные циклы и известные пики. Старую среду выключать только после формального закрытия испытательного срока после перехода.

Как выглядит конкретный тест: от риска до доказательства корректности миграции

Тест считается полезным потому, что у него есть в основе закрытие конкретного риска, предусловия, шаги, наблюдаемый оракул и сохраненное свидетельство: ID транзакций, diff данных, график p95, трасса и время восстановления. Именно эти факты должны рассматриваться миграционным комитетом.

Главный вопрос CTO перед переносом инфраструктуры в идеале должен звучать так: «Какие бизнес-потери мы уже исключили с помощью тестирования, какие еще возможны и что мы сделаем в первые 5 минут, если прогноз окажется неверным?» Если у команды есть четкий и, главное, аргументированный ответ, миграция становится предсказуемой. 

Кого привлекать: своих тестеров или внешнюю QA-команду?

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

Мы в «Лаборатории Качества» предлагаем начать разумно: не с закупки тысячи тест-кейсов, а с короткой диагностической сессии, где разберем: тип миграции, карту сервисов, критичные операции, доступные стенды, базовые показатели, допустимый простой и цену ошибок. По результатам составим план испытаний с оценкой трудозатрат, приоритетов, артефактов и точек принятия решения. Начать очень просто – запишитесь на бесплатную консультацию. 30 минут концентрированного профессионального общения без продаж и обязательств.