Копія рідко ламає переїзд WordPress. Ламає те, що ніхто не записав: cron, webhook, плагін, який зашив старий hostname у рядок, скринька, яка все ще йде зі старого сервера. Я вважаю інвентар самою міграцією. Перенесення файлів — легкий день, який приходить після.
Запишіть систему, перш ніж її чіпати
Перш ніж рушить файл, я пишу сторінку, якою міг би користуватися сторонній. Версія PHP. Розмір бази. Рядки cron і заплановані дії всередині WordPress — це не один список. Пошта: хто надсилає, через що і чи називає SPF уже цей хост. Кожна інтеграція, яка кличе сайт або яку кличе сайт. Платіжні webhook і синхронізація з CRM — звичайні сюрпризи, бо живуть у налаштуванні плагіна, яке ніхто не вивантажив.
Я також записую, що для цієї крамниці означає «працює». Оформлення одного фізичного товару. Оформлення одного віртуального. Вхід. Скидання пароля. Форма зв’язку, включно з листом, який має прийти. Пошук, якщо каталог від нього залежить. Якщо я не можу назвати шлях, я не готовий змінювати DNS.
| Рядок | Навіщо це тут |
|---|---|
| PHP, розмір бази, об’єктний кеш | Новий хост може бути «піднятий» і все одно виявитися не тим рантаймом. |
| Cron і заплановані дії | Пропущене нічне завдання виглядає нормально, поки ранковий звіт порожній. |
| Шлях пошти | Сайт може відкриватися, поки кожен лист про замовлення вмирає на новій машині. |
| Вебхуки і вихідні API | Зазвичай вони ніде не записані, і ім’я хоста вони помічають першим. |
| П’ять шляхів, які приносять гроші | Перевірка головної їх не проходить. |
Знизьте TTL за день
Поставте TTL DNS на 300 секунд за день до перемикання. Якщо це пропустити і новий хост виявиться хибним, частина авдиторії ще годинами тримає старий запис. Не можна поквапити кеш, який не вкоротили. Я краще навмисно зачекаю день, ніж виявлю це очікування під час збою.
Адреса staging — не справжнє ім’я хоста
Я піднімаю новий сервер і спрямовую на нього лише свою машину, записом у файлі hosts, поки публічний DNS усе ще віддає старий хост. Потім проходжу шляхи на справжньому імені. Адреса staging ховає плагіни, які зберегли прод-домен у базі. Вони поводяться, поки справжнього імені немає в запиті, а це саме той момент, коли сюрприз уже не потрібен.
Якщо критичний шлях не пройдений на справжньому імені хоста, перенесення не перевірене.
Тримайте старий хост теплим
Я не вимикаю старий хостинг у тиждень переїзду. Він лишається, лише для читання, щонайменше два тижні. Це дешево. Це єдиний відкат, який не залежить від копії, яку мені ще не доводилося використовувати. Якщо новий хост на третій день поводиться погано, старий запис усе ще щось означає.
Пошта — перевірка, про яку забувають
Сайт може виглядати готовим, поки кожен лист про замовлення вмирає на новій машині. Я записую адресу From, relay і чи відкритий узагалі порт 25. На не одному хості він закритий, і єдиний робочий шлях — автентифікований relay на 587. У SPF уже є один запис. Другого я не додаю. Два записи SPF не зливаються. Обидва стають недійсними, і пошта, яка раніше доходила, починає зникати на тижні після переїзду, який у решті минув добре.
Я надсилаю один справжній лист про замовлення і одне скидання пароля з нового хоста на скриньку, яку контролюю, перш ніж назвати переїзд завершеним. Рядок логу “sent” — це не лист у вхідних. Друге і є перевіркою.
HTTPS на apex і на www. Сертифікат оновлюється сам. Пошта все ще йде. П’ять шляхів все ще проходяться. Потім я день дивлюся журнал помилок, не головну. Головна — те, з чим монітор вас уже вітає. Журнал — місце, де webhook почав віддавати 404 платіжному провайдеру.
Переїзд, зроблений так, нудний. У цьому й сенс. Цікаві історії про міграції майже завжди про рядок, якого не було в інвентарі.
