Миграция устаревших PHP-сайтов без нарушения бизнес-операций

В DigiForge мы видели слишком много проектов по миграции устаревших PHP-приложений, которые пошли не по плану — не потому, что технология была сложной, а потому что бизнес продолжал работать во время переезда. Само слово «миграция» происходит от латинского «перемещение из одного места в другое», и в вычислительной технике оно означает «начать использовать новую компьютерную систему или перенести информацию из одной системы в другую» [1]. Звучит просто, но когда вы мигрируете PHP-монолит, обрабатывающий заказы, пользовательские сессии и платежные интеграции, настоящая задача — сделать так, чтобы ваши клиенты ничего не заметили.

Оцените, прежде чем трогать код

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

Во время аудита также задокументируйте поток данных: как старое приложение подключается к базе данных? Есть ли хранимые процедуры? Используется ли общая файловая система для загруженных изображений или файлов сессий? Многие устаревшие PHP-приложения полагаются на файловые сессии, которые не масштабируются горизонтально. Это тревожный сигнал, который мы устраняем на раннем этапе, часто перенося сессии в Redis или базу данных.

Выберите стратегию миграции, соответствующую вашей толерантности к риску

В DigiForge мы обычно рекомендуем одну из трех стратегий в зависимости от того, какой уровень риска может выдержать бизнес.

Полная перезапись (Big Bang Rewrite)

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

Паттерн «Удушающий плющ» (Strangler Fig Pattern)

Названный в честь тропического растения, которое медленно обвивает своего хозяина, этот паттерн позволяет заменять части устаревшего приложения постепенно. Вы направляете определённые URL или конечные точки API на новый код, в то время как остальная часть продолжает работать на старом PHP. Балансировщик нагрузки или обратный прокси (например, Nginx или HAProxy) могут направлять трафик на основе пути запроса. Каждая заменённая часть снижает риск, потому что вы меняете лишь небольшую область за раз. Мы используем этот паттерн практически в каждой крупной миграции.

Флаги функций повсюду

Даже с паттерном «удушающий инжир» флаги функций дают вам аварийный выключатель. Если новая конечная точка оформления заказа выдаёт ошибки, вы переключаете флаг, и трафик возвращается к старому коду — всё без развёртывания. Хорошо работают такие инструменты, как LaunchDarkly, или простой переключатель на основе базы данных. Мы оборачиваем весь код за флагом, даже подключение к базе данных. Таким образом, мы можем протестировать новый запрос в продакшене всего с несколькими пользователями, прежде чем раскатывать его на всех.

Выполните миграцию с нулевым временем простоя

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

<?php
// Example: dual-write to old and new databases
$legacyDb = getLegacyConnection();
$newDb = getNewConnection();

function saveOrder($orderData) {
    global $legacyDb, $newDb;
    // Write to both
    $legacyDb->insert('orders', $orderData);
    $newDb->insert('orders', $orderData);
}

// Read from legacy until we verify new data
function getOrder($orderId) {
    global $legacyDb;
    return $legacyDb->fetchOne('SELECT * FROM orders WHERE id = ?', [$orderId]);
}

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

Обработка состояния сессии

В устаревших PHP-приложениях часто используется $_SESSION, хранящаяся в файлах. Новое приложение на Laravel или Symfony, скорее всего, ожидает сессии в базе данных или Redis. Чтобы пользователи оставались в системе во время миграции, мы реализуем мост сессий: старое приложение записывает сессии как в файлы, так и в общее хранилище Redis; новое приложение читает из Redis. После завершения миграции запись в файлы отключается, а старый обработчик сессий удаляется.

Постмиграционная валидация и планирование отката

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

В DigiForge мы всегда держим старую рабочую среду запущенной как минимум две недели после крупной миграции. Стоимость нескольких дополнительных серверов ничтожна по сравнению с затратами на неудачный откат, который занимает часы.

Валидация выходит за рамки проверки загрузки страниц. Мы запускаем автоматические тесты бизнес-транзакций: размещение заказа, обновление профиля, обработка возврата. Сравните вывод критических API-эндпоинтов между старой и новой системами. Если вы используете инструмент мониторинга, такой как New Relic или Sentry, настройте пользовательские оповещения для любых ошибок 5xx или медленных запросов. Наконец, привлеките бизнес-команду — пусть они выполнят свои ежедневные рабочие процессы в новой системе на стенде до запуска.

Типичные ошибки и как мы их избегаем

• Предположение, что старый код корректен. В устаревшем PHP часто встречаются скрытые баги, ставшие «фичами». Повторять каждое поведение? Иногда безопаснее исправить баг в новой версии, если бизнес согласен.
• Забывание cron-задач и запланированных задач. Те старые вызовы curl к пользовательскому скрипту? Им нужно место в новой системе. Мы переносим задачи cron в планировщик задач, такой как планировщик Laravel или выделенный воркер.
• Пренебрежение сторонними интеграциями. Платежные шлюзы, API доставки и вебхуки партнеров отправляют данные в определенных форматах. Тестируйте интеграционные эндпоинты заранее — вы не захотите обнаружить несоответствие формата в Черную пятницу.

Еще один урок, который мы усвоили: не доверяйте старой документации. Код — это источник истины. Мы всегда проводим глубокий анализ кода с разработчиком, который написал оригинал (если он доступен), или с членом команды, который поддерживал его годами. Их ментальная модель особенностей приложения бесценна.

Заключение

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

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