Міграція застарілих 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 ми провели десятки бізнесів через цей процес. Ключ у тому, щоб рухатися маленькими, оборотними кроками, завжди тримати стару систему в роботі та не припиняти моніторинг, доки не переконаєтеся, що нова система стабільна.

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