Zinwentaryzuj projekt przed zaplanowaniem przeniesienia
Użyj ilustracyjnej strony zapytań pod client.example.com: redaktorzy publikują strony projektu, odwiedzający przesyłają brief, a zaplanowane zadanie eksportuje zapytania do systemu klienta. Przeniesienie jej stron publicznych obejmowałoby tylko część zadania. Potwierdź autoryzowany dostęp do źródła i celu, kontrolę domeny oraz kopie odzyskiwania przed ustaleniem daty.
Dla każdego komponentu zapisz jego właściciela, wersję, lokalizację, zależności i kontrolę odbioru. Lokalizacje poświadczeń trzymaj w spisie; hasła i klucze prywatne przechowuj w zatwierdzonym magazynie sekretów.
Przewiń w poziomie, aby zobaczyć wszystkie kolumny tabeli.
| Komponent | Zapisz przed przeniesieniem | Kto to potwierdza |
|---|---|---|
| Domena i DNS | Rejestrator, operator DNS, bieżące rekordy i TTL | Właściciel konta klienta |
| Aplikacja | Wydanie, środowisko uruchomieniowe, rozszerzenia i metoda wdrożenia | Opiekun po stronie agencji |
| Dane i przesłane pliki | Baza danych, ścieżki przesyłania, metoda tworzenia kopii zapasowych i ostatnia użyteczna kopia | Operator danych |
| Formularze i integracje | Odbiorcy, punkty końcowe webhooków i dozwolony cel testowy | Właściciel procesu po stronie klienta |
| Praca zaplanowana | Cron lub harmonogram, strefa czasowa, kolejka i ostatnie udane uruchomienie | Opiekun po stronie agencji |
Udowodnij kopię odzyskiwania przed ingerencją w produkcję
Odtwórz do osobnego celu testowego, nigdy na bazę produkcyjną. W przypadku PostgreSQL zrzut SQL reprezentuje spójny obraz bazy danych, ale zrzut pojedynczej bazy nie obejmuje ról ani przestrzeni tabel całego klastra. Zapisz obiekty pomocnicze wymagane przez aplikację. Ten obraz bazy danych również nie czyni automatycznie spójnymi osobno skopiowanych przesłanych plików. Dokumentacja zrzutu SQL PostgreSQL.
W przypadku projektu WordPress uwzględnij jego pliki i bazę danych. Jeśli adresy URL się zmienią, postępuj zgodnie z wytycznymi dotyczącymi migracji: bezmyślne wyszukiwanie i zamiana w bazie danych może uszkodzić wartości zserializowane. Przećwicz wybraną metodę na kopii. Podręcznik migracji WordPress.
Zapisz znane zapytanie i jego załącznik, odtwórz je i zweryfikuj oba przez aplikację. Przechowuj oryginalną kopię zapasową w bezpiecznym miejscu poza przenoszonym serwerem. Zakończone przesłanie pliku nie jest odbiorem odtworzenia.
Przećwicz procesy, które klient zauważy
Testuj przy użyciu tymczasowej nazwy hosta z kontrolą dostępu lub mapowania nazw tylko dla operatora. Skonfiguruj aplikację dla tej trasy testowej, w tym HTTPS i odpowiednie adresy URL wywołań zwrotnych. Uniemożliw kopii wysyłanie wiadomości produkcyjnych, przetwarzanie prawdziwych płatności lub uruchamianie harmonogramów produkcyjnych. Używaj zatwierdzonych rekordów syntetycznych zamiast niepotrzebnych danych osobowych.
Przed każdą kontrolą zapisz oczekiwany wynik. Zapisz wynik pozytywny lub negatywny, lokalizację dowodu i osobę, która go sprawdziła; zrzut ekranu strony głównej nie zastąpi całej siatki.
Przewiń w poziomie, aby zobaczyć wszystkie kolumny tabeli.
| Proces | Oczekiwany wynik | Dowody do zachowania |
|---|---|---|
| Formularz i załącznik | Jedno zapisane zapytanie i jeden czytelny plik; tylko odbiorca testowy | Identyfikator rekordu syntetycznego i obserwacja dostarczenia |
| Webhook | Zatwierdzone zdarzenie testowe dociera do zamierzonego odbiorcy testowego | Identyfikator zdarzenia i wynik odbiorcy |
| Zaplanowany eksport | Jedno kontrolowane uruchomienie, poprawna strefa czasowa, brak duplikatu ze starego serwera | Identyfikator uruchomienia i porównanie wyeksportowanych rekordów |
| Trasy redaktora i odwiedzającego | Oczekiwane uprawnienia, przekierowania, zasoby i zachowanie HTTPS | Sprawdzone adresy URL i wszelkie szczegóły niepowodzeń |
Zdefiniuj ostatni zapis w starym systemie
W tym przykładzie agencja proponuje krótkie okno konserwacyjne: wstrzymaj przesyłanie zapytań i edycję, zatrzymaj stary harmonogram eksportu, zakończ lub rozlicz pracę w kolejce, a następnie utwórz końcową kopię bazy danych i przesłanych plików. Klient musi zatwierdzić sposób poinformowania odwiedzających, że przesyłanie jest tymczasowo niedostępne.
Zapisz identyfikator ostatniego zaakceptowanego zapytania i czas zatrzymania zapisów. Zweryfikuj, że cel zawiera ten rekord i jego załącznik, zanim zezwolisz na nowe zgłoszenia. Utrzymuj źródło niezdolne do przyjmowania niezależnych zapisów, dopóki odpowiedzi DNS mogą się różnić. Projekt, którego nie można wstrzymać zapisów, wymaga projektu synchronizacji specyficznego dla aplikacji; nie improwizuj go podczas przełączenia.
Prowadź dziennik decyzji DNS
TTL kontroluje, jak długo odpowiedzi DNS są buforowane. Obniżenie go podczas przełączenia nie unieważnia odpowiedzi już zbuforowanych pod wcześniejszą wartością, więc przygotuj zmianę TTL z wyprzedzeniem i obserwuj przejście z odpowiednich sieci. Cloudflare zauważa również, że lokalne buforowanie może opóźnić widoczną zmianę. Dokumentacja TTL DNS Cloudflare.
Zapisz nazwę i typ rekordu, starą wartość, zamierzoną wartość, poprzedni TTL, zatwierdzenie, czas zmiany i zaobserwowany wynik. Sprawdź rekordy IPv6, a także rekordy IPv4, jeśli oba istnieją. Zachowaj niepowiązane rekordy poczty. Po zmianie zweryfikuj, że publiczna nazwa hosta dociera do zamierzonej aplikacji i jej krytycznego procesu, a nie tylko do zamierzonego adresu IP.
Uczyń wycofanie decyzją o danych
Uzgodnij konkretne warunki zatrzymania: brakuje końcowego zapytania, nie można otworzyć załączników, logowanie nie działa lub webhook trafia do niewłaściwego odbiorcy. Zanim rozpoczną się nowe zapisy, możliwy może być przećwiczony powrót do zachowanego źródła. Gdy cel przyjmie nowe zapytania, samo odtworzenie starej kopii zapasowej lub odwrócenie DNS może spowodować utratę tych rekordów.
Jeśli warunek zatrzymania pojawi się po ponownym otwarciu, wstrzymaj zapisy, zachowaj obie kopie i zleć wyznaczonemu operatorowi uzgodnienie zmian przed wyborem systemu autorytatywnego. Zatwierdzający po stronie klienta decyduje, czy kontynuować odzyskiwanie, czy użyć uzgodnionej alternatywy. Prowadź krótki dziennik incydentów zamiast wielokrotnego przełączania DNS.
Zamknij przeniesienie dowodami i własnością
Poproś klienta o przegląd siatki odbioru. Potwierdź jeden aktywny harmonogram, nową ścieżkę kopii zapasowych, własność alertów i następny punkt kontrolny obserwacji. Zachowaj źródło przez uzgodniony okres, a następnie wyraźnie zatwierdź jego wycofanie. Usuń tymczasowy dostęp i dane testowe zgodnie z umową projektową.
Użyj wyniku do aktualizacji arkusza odpowiedzialności operacyjnej oraz budżetu projektu. Ta procedura porządkuje pracę zespołu; nie oznacza wliczonej pomocy migracyjnej ani nieprzerwanej usługi.
Źródła i przegląd
Odniesienia techniczne sprawdzono we wrześniu 12, 2026. Przykłady to ćwiczenia planistyczne; przywołana dokumentacja oprogramowania nie ustala możliwości usługi PrivateHostLab.