Inventariați proiectul înainte de a programa mutarea
Folosiți un site ilustrativ de solicitări la client.example.com: editorii publică pagini de proiect, vizitatorii încarcă un brief, iar o sarcină programată exportă solicitările către un sistem al clientului. Mutarea paginilor publice ar acoperi doar o parte a sarcinii. Confirmați accesul autorizat la sursă și destinație, controalele de domeniu și copiile de recuperare înainte de a vă angaja la o dată.
Pentru fiecare componentă, înregistrați proprietarul, versiunea, locația, dependențele și verificarea de acceptare. Păstrați locațiile acreditărilor în inventar; păstrați parolele și cheile private în depozitul de secrete aprobat.
Derulați orizontal pentru toate coloanele tabelului.
| Componentă | Înregistrați înainte de mutare | Cine confirmă |
|---|---|---|
| Domeniu și DNS | Registrar, operator DNS, înregistrări curente și TTL-uri | Proprietarul contului clientului |
| Aplicație | Versiune, runtime, extensii și metoda de implementare | Responsabilul de mentenanță al agenției |
| Date și fișiere încărcate | Baza de date, căile de încărcare, metoda de backup și ultima copie utilizabilă | Operatorul de date |
| Formulare și integrări | Destinatari, endpoint-uri webhook și destinația de test permisă | Proprietarul fluxului de lucru al clientului |
| Lucrări programate | Cron sau planificator, fus orar, coadă și ultima rulare reușită | Responsabilul de mentenanță al agenției |
Dovediți copia de recuperare înainte de a atinge producția
Restaurați într-o destinație de test separată, niciodată peste baza de date live. Pentru PostgreSQL, un dump SQL reprezintă un instantaneu consistent al bazei de date, dar un dump al unei singure baze de date nu include rolurile sau spațiile de tabel la nivel de cluster. Înregistrați obiectele de suport necesare aplicației dvs. Acel instantaneu al bazei de date nu face automat consistente fișierele încărcate copiate separat. Documentație PostgreSQL SQL dump.
Pentru un proiect WordPress, includeți fișierele și baza de date. Dacă URL-urile se vor schimba, urmați îndrumările specifice migrării: o căutare și înlocuire nediscriminatorie în baza de date poate deteriora valorile serializate. Repetați metoda aleasă pe copie. Manual de migrare WordPress.
Înregistrați o solicitare cunoscută și atașamentul acesteia, restaurați-le și verificați ambele prin aplicație. Păstrați backupul original protejat în afara serverului care este mutat. Un transfer de fișiere finalizat nu este acceptarea restaurării.
Repetați fluxurile de lucru pe care clientul le va observa
Testați folosind un nume de gazdă temporar cu acces controlat sau o mapare de nume doar pentru operator. Configurați aplicația pentru acea rută de test, inclusiv HTTPS și URL-urile de callback relevante. Împiedicați copia să trimită mesaje de producție, să proceseze plăți reale sau să ruleze programe de producție. Folosiți înregistrări sintetice aprobate în locul datelor personale inutile.
Scrieți un rezultat așteptat înainte de fiecare verificare. Înregistrați trecut sau eșuat, locația dovezilor și persoana care le-a examinat; o captură de ecran a paginii de start nu poate ține locul întregii grile.
Derulați orizontal pentru toate coloanele tabelului.
| Flux de lucru | Rezultat așteptat | Dovezi de păstrat |
|---|---|---|
| Formular și atașament | O solicitare stocată și un fișier lizibil; doar destinatarul de test | Identificatorul înregistrării sintetice și observația livrării |
| Webhook | Evenimentul de test aprobat ajunge la consumatorul de test destinat | Identificatorul evenimentului și rezultatul consumatorului |
| Export programat | O rulare controlată, fus orar corect, fără duplicat pe serverul vechi | Identificatorul rulării și comparația înregistrărilor exportate |
| Rute pentru editor și vizitator | Permisiuni așteptate, redirecționări, active și comportament HTTPS | URL-uri verificate și orice detalii de eșec |
Definiți ultima scriere pe sistemul vechi
Pentru acest exemplu, agenția propune o scurtă fereastră de mentenanță: întrerupeți trimiterea solicitărilor și editarea, opriți vechiul program de export, finalizați sau luați în considerare lucrările din coadă, apoi creați copia finală a bazei de date și a fișierelor încărcate. Clientul trebuie să aprobe modul în care li se spune vizitatorilor că trimiterile sunt temporar indisponibile.
Înregistrați ultimul identificator de solicitare acceptat și momentul opririi scrierilor. Validați că destinația include acea înregistrare și atașamentul ei înainte de a permite noi trimiteri. Mențineți sursa incapabilă să accepte scrieri independente cât timp răspunsurile DNS pot diferi. Un proiect care nu poate întrerupe scrierile necesită un design de sincronizare specific aplicației; nu improvizați unul în timpul tranziției.
Păstrați un jurnal de decizii DNS
TTL controlează cât timp sunt memorate în cache răspunsurile DNS. Reducerea acestuia la tranziție nu invalidează răspunsurile deja memorate sub valoarea anterioară, așa că pregătiți orice modificare TTL în avans și observați tranziția din rețelele relevante. Cloudflare notează de asemenea că memoria cache locală poate întârzia o schimbare vizibilă. Documentație Cloudflare DNS TTL.
Înregistrați numele și tipul înregistrării, valoarea veche, valoarea intenționată, TTL-ul anterior, aprobarea, momentul schimbării și rezultatul observat. Verificați înregistrările IPv6 precum și înregistrările IPv4 dacă ambele există. Păstrați înregistrările de mail neasociate. După schimbare, verificați că numele de gazdă public ajunge la aplicația intenționată și la fluxul său critic, nu doar la adresa IP intenționată.
Faceți din rollback o decizie privind datele
Conveniți asupra condițiilor concrete de oprire: ultima solicitare lipsește, atașamentele nu pot fi deschise, autentificarea eșuează sau un webhook ajunge la destinatarul greșit. Înainte de a începe noile scrieri, o revenire repetată la sursa păstrată poate fi posibilă. După ce destinația acceptă noi solicitări, restaurarea unui backup vechi sau inversarea doar a DNS-ului poate pierde acele înregistrări.
Dacă apare o condiție de oprire după redeschidere, întrerupeți scrierile, păstrați ambele copii și rugați operatorul numit să reconcilieze modificările înainte de a alege sistemul autoritar. Aprobatorul clientului decide dacă se continuă recuperarea sau se folosește alternativa convenită. Păstrați un jurnal scurt de incidente în loc să comutați DNS-ul în mod repetat.
Închideți mutarea cu dovezi și responsabilitate
Rugați clientul să revizuiască grila de acceptare. Confirmați un singur planificator activ, noua cale de backup, responsabilitatea pentru alerte și următorul punct de observare. Păstrați sursa pentru perioada convenită, apoi aprobați în mod explicit retragerea acesteia. Eliminați accesul temporar și datele de test conform acordului proiectului.
Folosiți rezultatul pentru a actualiza fișa de responsabilitate operațională și bugetul proiectului. Această procedură organizează munca echipei dvs.; nu implică asistență de migrare inclusă sau serviciu neîntrerupt.
Surse și recenzii
Referințele tehnice au fost verificate în septembrie 12, 2026. Exemplele sunt exerciții de planificare; documentația software menționată nu stabilește capabilitățile de serviciu PrivateHostLab.