Kā droši migrēt vietnes
Publicēts 2026. gada 21. jūnijā
Droša vietnes migrācija sākas vēl pirms tiek pārvietoti jebkādi faili. Ja vēlaties zināt, kā droši migrēt vietnes, pirmais uzdevums nav datu kopēšana — tas ir nezināmo faktoru samazināšana. Mēs pārbaudām pašreizējo steku, iesaldējam nevajadzīgas izmaiņas, pārliecināmies, ka dublējumkopijas tiešām var atjaunot, un izveidojam atrites ceļu pirms pieskaramies DNS. Tieši šo daļu daudzas komandas izlaiž, un vēlāk žurnāli stāsta vienu un to pašu.
Migrācijas izgāžas garlaicīgu iemeslu dēļ. Aizmirsts cron darbs turpina rakstīt vecajā datubāzē. DNS tiek pārslēgts, pirms SSL ir gatavs. Pāradresācijas noteikumi tiek nokopēti tikai daļēji. Kešatmiņa vienam cilvēkam liek jaunajai vietnei izskatīties kārtībā, bet visiem pārējiem — salauztai. Nekas no tā nav dramatisks, bet tas ir dārgi. Droša migrācija lielākoties ir disciplinēta darbību secība.
Kā droši migrēt vietnes bez dīkstāves pārsteigumiem
Tīrākās migrācijas sākas ar inventarizāciju. Jums precīzi jāzina, kas tiek pārvietots, kas pārvietošanas laikā var mainīties un kādas atkarības atrodas ārpus servera. Tas nozīmē vietnes failus, datubāzes, multivides krātuvi, SSL sertifikātus, DNS zonas, ieplānotos uzdevumus, e-pasta maršrutēšanu, API integrācijas, maksājumu atzvanus un ugunsmūra noteikumus. Ja vietne izmanto CDN, ārēju attēlu krātuvi, objektu kešatmiņu vai trešās puses meklēšanu, iekļaujiet arī tos.
Šeit komandas atrod mazos slazdus. WooCommerce veikals var būt atkarīgs no maksājumu webhook, kas norāda uz veco IP. SaaS lietotnei var būt fona apstrādātāji otrā mašīnā. Mārketinga vietne var būt vienkārša, bet kontaktu veidlapa sūta caur SMTP pakalpojumu, kas ir ierobežots pēc servera resursdatora nosaukuma. Drošas migrācijas reti ir par sākumlapu. Tās ir par malām.
Pirms kaut ko pārvietojat, izlemiet, kāda veida migrāciju veicat. Vienlīdzīga pārvietošana no viena VPS uz citu ir viens riska līmenis. Pāreja no koplietotā hostinga uz pārvaldītu VPS, vadības paneļu maiņa, PHP jaunināšana un tīmekļa servera nomaiņa no Apache uz Nginx vienlaikus ir pavisam cita lieta. Jūs varat veikt vairākas izmaiņas reizē, bet katrs papildu mainīgais palēnina problēmu novēršanu. Ja iespējams, nodaliet infrastruktūras izmaiņas no lietojumprogrammas izmaiņām.
Sāciet ar dublējumkopijām, kuras jau esat pārbaudījuši
Katrs pakalpojumu sniedzējs saka, ka dublējumkopijas pastāv. Tas ir jauki, bet dublējumkopija ir noderīga tikai tad, ja tā tiek atjaunota tīri un pietiekami ātri jūsu atjaunošanas mērķim. Izveidojiet svaigu failu un datubāzu dublējumkopiju tieši pirms migrācijas. Glabājiet arī kopiju ārpus avota vides, lai nepaļautos uz to, ka vienai platformai būs laba diena.
Ja vietne ietekmē ieņēmumus, veiciet testa atjaunošanu staging vidē. Atveriet atjaunoto vietni, pārbaudiet datubāzes savienojamību, pārbaudiet failu atļaujas un pārliecinieties, ka multivide ielādējas. Ja nevarat pārbaudīt visu lietojumprogrammu, vismaz pārliecinieties, ka dublējumkopijas arhīvs ir pilnīgs un datubāzes dump ir lasāms. Tas nav krāšņs darbs, bet arī skaidrošana grāmatvedībai, kāpēc vakardienas pasūtījumi pazuda mežā, nav krāšņa.
Iesaldējiet izmaiņas migrācijas loga laikā
Satura labojumi, spraudņu instalēšana un koda izvietošanas migrācijas laikā rada split-brain problēmas. Viena sistēma tiek atjaunināta, otra ne, un tagad neviens nav pārliecināts, kura versija ir īstā. Iestatiet īsu izmaiņu iesaldēšanu. Vietnēm ar lielu satura apjomu vai transakciju vietnēm izmantojiet apkopes režīmu vai pēdējās sinhronizācijas laikā pārslēdziet kritiskās daļas tikai lasīšanas stāvoklī.
E-komercijai, rezervācijām vai lietotāju radītam saturam plānojiet delta sinhronizāciju. Lielāko daļu failu un datu nokopējiet iepriekš, pēc tam pārslēgšanas loga laikā veiciet pēdējo sinhronizāciju, lai notvertu pēdējā brīža izmaiņas. Tas saglabā zemu dīkstāvi, neriskējot ar datu nobīdi.
Izveidojiet mērķa vidi pirms pārslēgšanas
Bieža kļūda ir uztvert galamērķa serveri kā tukšu kasti, kuru var konfigurēt vēlāk. Droša migrācija darbojas otrādi. Mērķa videi jābūt gatavai pirms pārslēgšanas: OS salāpīta, tīmekļa steks instalēts, PHP versija apstiprināta, datubāze pielāgota, SSL sagatavots, dublējumkopijas ieplānotas un monitorings iespējots.
Vispirms saskaņojiet lietojumprogrammas prasības, pēc tam uzlabojiet uzmanīgi. Ja vecā vietne darbojas ar PHP 7.4 un lietotne nav sertificēta darbam ar PHP 8.2, migrācijas diena nav īstais brīdis varonībai. Modernizēt varat pēc tam, kad stabilitāte ir apstiprināta. Vispirms miers, pēc tam optimizācija.
Atļaujām un īpašumtiesībām jāpievērš papildu uzmanība. Daudzi “vietne ir migrēta, bet augšupielādes neizdodas” incidenti ir tikai nepareizas lietotāja/grupas īpašumtiesības vai trūkstoši rakstāmi ceļi. Pārskatiet arī cron darbus, rindas apstrādātājus un ieplānotos uzdevumus. Vietne var ielādēties labi, kamēr svarīga fona apstrāde pirms stundas klusi apstājās.
Testējiet, izmantojot hosts failu vai pagaidu URL
Nenovirziet dzīvo DNS, kamēr vietne nav pārbaudīta jaunajā serverī. Izmantojiet hosts faila pārrakstīšanu vai pagaidu priekšskatījuma domēnu, lai privāti testētu lietojumprogrammu. Pārlūkojiet galvenās lapas, iesniedziet veidlapas, piesakieties kā administrators, veiciet testa pasūtījumu, ja tas ir aktuāli, un pārbaudiet e-pasta sūtīšanu. Pārbaudiet attēlus, meklēšanu, API, administratora darbības un visu, kas saistīts ar sesijām vai kešatmiņošanu.
Skatieties tālāk par vizuālajām pārbaudēm. Pārskatiet kļūdu žurnālus, tīmekļa servera žurnālus, PHP-FPM statusu, datubāzes lēnos vaicājumus un diska lietojumu. Pārliecinieties, ka pāradresācijas darbojas, kā paredzēts. Pārliecinieties, ka kanoniskie URL, robots noteikumi un vides mainīgie ir pareizi. Ir pārsteidzoši viegli migrēt produkcijas vietni ar joprojām pievienotu staging noindex galveni. Meklētājprogrammas ir paklausīgas pašos sliktākajos brīžos.
DNS, TTL un pārslēgšanas plānošana
Ja mācāties, kā droši migrēt vietnes, DNS ir vieta, kur sagatavošanās atmaksājas. Samaziniet TTL attiecīgajiem DNS ierakstiem krietni pirms migrācijas loga, ideālā gadījumā 24 līdz 48 stundas iepriekš. Tas palīdz atrisinātājiem ātrāk atsvaidzināties, kad pārslēdzat vietni uz jauno serveri. Tas negarantē tūlītēju glob ālu izplatīšanos, bet samazina laiku, cik ilgi lietotāji var nonākt vecajā atrašanās vietā.
Pārslēgšanas brīdī atjauniniet tikai to, kas nepieciešams. Parasti tas nozīmē A ierakstu, varbūt AAAA, un dažkārt ar pastu saistītus ierakstus, ja tiek pārvietots arī e-pasts. Esiet uzmanīgi, lai nejauktu vietnes migrāciju ar e-pasta migrāciju, ja vien tam nav skaidra iemesla. To apvienošana palielina ietekmes zonu. Skaistākā migrācija bieži ir tā, kas mainīja mazāk lietu.
Saglabājiet veco serveri darbībā drošam pārklāšanās periodam. Pat pēc DNS izmaiņām daži lietotāji un boti vēl kādu laiku sasniegs veco resursdatoru. Šajā periodā uzraugiet piekļuves žurnālus abās sistēmās. Ja vecais serveris joprojām saņem nozīmīgu datplūsmu, turiet to pieejamu un, ja iespējams, rūpīgi virziet rakstīšanas darbības, lai nezaudētu datus.
Uzmaniet kešatmiņošanas un SSL problēmas
CDN kešatmiņas, lietojumprogrammas kešatmiņas un lokālā pārlūka kešatmiņa pēc migrācijas var paslēpt problēmas. Iztīriet tur, kur nepieciešams. Ja tiek izmantota pilnas lapas kešatmiņa, notīriet to pēc pēdējās sinhronizācijas un pēc DNS pārslēgšanas. Pārliecinieties, ka CDN izcelsme ir atjaunināta, ja tāda pastāv.
SSL jābūt gatavam pirms pārslēgšanas, nevis pēc tās. Instalējiet sertifikātus jaunajā vidē, pārbaudiet pilno ķēdi un testējiet HTTP uz HTTPS uzvedību. Jaukta satura brīdinājumi var parādīties, ja cieti iekodēti resursu URL joprojām norāda uz veco domēnu vai protokolu. Tās ir mazas detaļas, bet lietotāji slēdzenes ikonu pamana ātrāk nekā jūsu rūpīgo plānošanu.
Pāradresācijas, SEO un lietojumprogrammas integritāte
Ja domēns paliek tas pats, SEO risks ir zemāks, bet tehniskās pārbaudes joprojām ir svarīgas. Pārliecinieties, ka pāradresācijas no HTTP uz HTTPS, no www uz bez-www vai otrādi, kā arī jebkuras veco ceļu kartēšanas darbojas tieši tā, kā paredzēts. Ja domēns mainās, visaptveroši izmantojiet 301 pāradresācijas un atjauniniet kanoniskās atzīmes, vietņu kartes un iekšējās atsauces.
Nepalaidiet vietni ar pāradresācijas ķēdēm, ja varat no tām izvairīties. Tās palēnina darbību un rada indeksēšanas nekārtību. Pārbaudiet arī pielāgotās kļūdu lapas, robots.txt, XML vietnes kartes ģenerēšanu un strukturētos datus, ja vietne uz tiem paļaujas. Migrācija nav tikai “vietne ielādējas”. Tā ir “vietne darbojas pareizi normālos un robežgadījumu apstākļos”.
Dinamiskām lietojumprogrammām testējiet autentifikāciju, sesijas un atļaujas ar īstām lietotāju lomām. Administrators var darboties, kamēr klienta pieteikšanās neizdodas sīkfailu tvēruma, sesiju krātuves vai starpniekservera galveņu dēļ. Tas ir īpaši bieži aiz slodzes līdzsvarotājiem vai reversajiem starpniekserveriem.
Atrites plāns ir daļa no migrācijas
Migrācija ir droša tikai tad, ja ir iespējama atgriešanās. Definējiet atrites nosacījumus iepriekš. Piemēram: ilgstošas 5xx kļūdas, norēķinu procesa kļūme, bojāta pieteikšanās, smaga veiktspējas regresija vai datu neatbilstība. Definējiet arī, kurš pieņem lēmumu par atriti un cik ilgi pēc pārslēgšanas ilgst novērošanas logs.
Atritei jābūt pietiekami vienkāršai, lai to varētu izpildīt stresa apstākļos. Tas parasti nozīmē saglabāt veco vidi neskartu, ja iespējams, saglabāt vecās datubāzes stāvokli un ātri atgriezt DNS vai datplūsmas maršrutēšanu. Ja jaunajā vidē notika rakstīšanas darbības, jums nepieciešama datu saskaņošanas politika. Tāpēc transakciju vietnēm pēdējās pārslēgšanas laikā nepieciešama papildu piesardzība.
Pirmās 24 stundas monitorējiet īpaši rūpīgi
Pēc pārslēgšanas uzraugiet darbspējas laiku, atbildes laiku, CPU, atmiņu, diska I/O, datubāzes slodzi, SSL derīgumu, rindas dziļumu un dublējumkopiju darbus. Uzraugiet arī lietotājiem redzamus signālus: pasūtījumu plūsmu, kontaktu veidlapas, veiksmīgu pieteikšanos un kļūdu ziņojumus. Migrācija desmitajā minūtē var izskatīties labi un izgāzties trešajā stundā, kad ieslēdzas ieplānotie darbi vai beidzas kešatmiņas termiņš.
Šeit pārvaldīts atbalsts attaisno savu vietu. Labs monitorings noķer resursu pīķus, neizdevušos pakalpojumus un sertifikātu problēmas, pirms klienti kļūst par jūsu brīdinājumu sistēmu. Komandām bez dziļām iekšējām operāciju zināšanām šis mierīgais operacionālais slānis ir svarīgāks nekā vēl viena izvēles rūtiņa hostinga plānā.
Praktisks noteikums drošākām migrācijām
Nemainiet visu tikai tāpēc, ka beidzot ir iespēja. Vispirms pārvietojiet, pēc tam stabilizējiet, treškārt uzlabojiet. Šī secība ietaupa laiku, pat ja uz papīra tā šķiet lēnāka. Ja jums nepieciešama palīdzība ar to, kā droši migrēt vietnes, pareizajam hostinga partnerim jāspēj palīdzēt ne tikai ar pašu serveri, bet arī ar dublējumkopijām, monitoringu, atrites plānošanu un neērtajiem mazajiem robežgadījumiem, kas parādās tikai pēc pusnakts.
Laba migrācija šķiet gandrīz bez notikumiem. Tas ir mērķis. Klusi žurnāli, stabila datplūsma, strādājošas veidlapas, nekādu mistisku cron katastrofu un komanda, kas pēc DNS pārslēgšanas var gulēt. Uzņēmumā kodu.cloud tas parasti ir standarts, uz kuru tiecamies - ne ārišķīgs, vienkārši kontrolēts.
Andres Saar klientu aprūpes inženieris