Kopia rzadko jest tym, co psuje przeniesienie WordPress. Psuje je to, czego nikt nie zapisał: cron, webhook, wtyczka, która wplotła stary hostname w wiersz, skrzynka, która wciąż wychodzi ze starego serwera. Traktuję inwentarz jak migrację. Przesłanie plików to łatwe popołudnie, które przychodzi potem.
Opisz system, zanim go dotkniesz
Zanim ruszy plik, piszę stronę, z której mógłby skorzystać obcy. Wersja PHP. Rozmiar bazy. Linie cron i zaplanowane akcje wewnątrz WordPress, a to nie ta sama lista. Poczta: kto wysyła, przez co i czy SPF już nazywa ten host. Każda integracja, która woła stronę albo którą strona woła. Webhooki płatności i synchronizacja z CRM to zwykłe niespodzianki, bo żyją w ustawieniu wtyczki, którego nikt nie wyeksportował.
Zapisuję też, co dla tego konkretnego sklepu znaczy „działa”. Zakup jednego produktu fizycznego. Zakup jednego produktu wirtualnego. Logowanie. Reset hasła. Formularz kontaktowy, łącznie z mailem, który ma dojść. Wyszukiwanie, jeśli katalog od niego zależy. Jeśli nie umiem nazwać ścieżki, nie jestem gotów zmieniać DNS.
| Linia | Dlaczego to tu jest |
|---|---|
| PHP, rozmiar bazy, cache obiektów | Nowy host może być „w górze” i nadal być złym runtime’em. |
| Cron i zaplanowane akcje | Pominięte nocne zadanie wygląda dobrze, aż poranny raport jest pusty. |
| Ścieżka poczty | Strona może się ładować, gdy każdy mail zamówienia umiera na nowej maszynie. |
| Webhooki i wychodzące API | Zwykle nie są opisane i pierwsze zauważają nazwę hosta. |
| Pięć ścieżek, które zarabiają | Sprawdzenie strony głównej ich nie przechodzi. |
Obniż TTL dzień wcześniej
Ustaw TTL DNS na 300 sekund dzień przed przełączeniem. Jeśli to pominiesz, a nowy host jest zły, część odbiorców trzyma stary rekord przez godziny. Nie przyspieszysz pamięci podręcznej, której nie skróciłeś. Wolę poczekać dzień celowo, niż odkryć to czekanie w trakcie awarii.
Adres stagingu nie jest prawdziwą nazwą hosta
Podnoszę nowy serwer i kieruję na niego tylko własną maszynę, wpisem w pliku hosts, podczas gdy publiczny DNS wciąż serwuje stary host. Potem przechodzę ścieżki na prawdziwej nazwie. Adres staging ukrywa wtyczki, które zapisały domenę produkcyjną w bazie. Zachowują się, dopóki prawdziwa nazwa nie jest w żądaniu, a to dokładnie chwila, w której już nie chcesz niespodzianki.
Jeśli ścieżki krytycznej nie przeszło się na prawdziwej nazwie hosta, migracja nie jest sprawdzona.
Zostaw stary host włączony
Nie rezygnuję ze starego hostingu w tygodniu przeniesienia. Zostaje włączony, tylko do odczytu, co najmniej dwa tygodnie. Kosztuje niewiele. To jedyne wycofanie, które nie zależy od kopii, której jeszcze nie musiałem użyć. Jeśli nowy host źle się zachowa trzeciego dnia, stary rekord wciąż coś znaczy.
Poczta to sprawdzenie, o którym się zapomina
Strona może wyglądać na skończoną, gdy każdy mail o zamówieniu umiera na nowej maszynie. Zapisuję adres From, relay i czy port 25 w ogóle jest otwarty. Na więcej niż jednym hoście nie jest, a jedyna działająca droga to uwierzytelniony relay na 587. SPF ma już jeden rekord. Nie dodaję drugiego. Dwa rekordy SPF się nie łączą. Oba stają się nieważne, a poczta, która wcześniej dochodziła, zaczyna znikać w tygodniu po przeniesieniu, które poza tym poszło dobrze.
Wysyłam jedną prawdziwą wiadomość o zamówieniu i jedno resetowanie hasła z nowego hosta, na skrzynkę, którą kontroluję, zanim nazwę przeniesienie skończonym. Linia logu z napisem “sent” to nie to samo co wiadomość w skrzynce. Ta druga jest testem.
HTTPS na apex i na www. Certyfikat odnawia się sam. Poczta wciąż wychodzi. Pięć ścieżek wciąż się domyka. Potem przez dzień patrzę w log błędów, nie na stronę główną. Strona główna to to, z czego monitor już ci gratuluje. Log to miejsce, gdzie webhook zaczął zwracać 404 dostawcy płatności.
Przeniesienie zrobione w ten sposób jest nudne. O to chodzi. Ciekawe historie o migracjach to prawie zawsze historie o linii, której brakowało w inwentarzu.
