Kā migrēt vietnes serveri bez dīkstāves
Publicēts 2026. gada 15. jūlijā
Sāciet migrēšanu ar pilnu, atjaunojamu dublējumu un rakstisku pārslēgšanas plānu. Tā ir drošākā atbilde uz jautājumu, kā migrēt vietnes servera infrastruktūru, nepārvēršot ikdienišķu pārcelšanu pakalpojuma pārtraukumā. Jaunajam serverim jābūt uzbūvētam, aizsargātam un pārbaudītam, pirms DNS novirza uz to jebkuru apmeklētāju. Vecais serveris paliek tiešsaistē, līdz jaunā vide ir izturējusi reālas pārbaudes.
Servera migrēšana ir kas vairāk nekā vietnes failu kopēšana. Pakalpojuma daļa var būt vietne, datubāze, ieplānotie uzdevumi, e-pasta maršrutēšana, SSL sertifikāti, lietotnes izpildes vide, kešatmiņas darbība, DNS ieraksti un ugunsmūra noteikumi. Ja izlaiž vienu nelielu atkarību, vietne sākumlapā var izskatīties labi, kamēr norēķinu e-pasti, veidlapas vai fona uzdevumi klusi nedarbojas. Ne pārāk spoža kļūme, bet tik un tā dārga.
Pirms pārvietošanas kartējiet pašreizējo serveri
Sāciet ar inventarizāciju par to, kas patiesībā darbojas. Nepaļaujieties tikai uz to, ko rāda hostinga vadības panelis. Pārbaudiet dokumenta sakni, lietotnes versiju, datubāzes dzini un versiju, PHP vai Node.js iestatījumus, cron uzdevumus, rindas apstrādes procesus, glabāšanas ceļus, pāradresācijas, vides mainīgos un izejošā e-pasta konfigurāciju.
Uzņēmuma vietnei identificējiet arī visu, kas atrodas ārpus galvenā domēna. Tas var ietvert apakšdomēnus, testēšanas vietnes, API galapunktus, maksājumu atzvansaites, objektu glabātuvi, trešo pušu e-pasta pakalpojumu sniedzējus, analītikas skriptus un DNS ierakstus, ko izmanto verifikācijai. Ja serveris sūta e-pastu tieši, pierakstiet tā sūtīšanas IP, reverse DNS iestatījumu, SPF, DKIM un DMARC ierakstus. E-pasts bieži ir pēdējais elements, ko pamana, un pirmais, par ko klienti sūdzas.
Dokumentējiet arī pašreizējā servera resursu izmantošanu. Pārskatiet CPU slodzi, atmiņas patēriņu, diska vietu, datubāzes izmēru, datplūsmas modeļus un kļūdu žurnālus. Tas parāda, vai jaunais VPS vai dedicētais serveris ir pareizi izmērots. Migrēšana ir labs brīdis, lai atstātu pagātnē pārāk mazu disku, novecojušu PHP versiju vai serveri, kas līdz šim izdzīvojis galvenokārt uz optimisma rēķina.
Vispirms sagatavojiet jauno vidi
Nodrošiniet mērķa serveri pirms produkcijas datu kopēšanas. Instalējiet operētājsistēmas atjauninājumus, izveidojiet ierobežotu administratīvo piekļuvi, konfigurējiet ugunsmūri un instalējiet tikai tos pakalpojumus, kas vietnei nepieciešami. Kur iespējams, paroles piekļuves vietā izmantojiet SSH atslēgas. Atspējojiet nevajadzīgos pakalpojumus un nodrošiniet, ka automātiskie drošības atjauninājumi atbilst jūsu darbības politikai.
Rūpīgi saskaņojiet ar lietotnes prasībām. Vietnei, kas pāriet no PHP 7.4 uz PHP 8.3 vai no MySQL uz jaunāku MariaDB laidienu, var būt nepieciešamas koda izmaiņas, pirms tā darbosies pareizi. Tas pats attiecas uz tīmekļa servera konfigurāciju. Apache rewrite noteikumi, Nginx lokācijas, failu atļaujas un PHP paplašinājumi ne vienmēr pārnesas viens pret vienu.
Iestatiet monitoringu pirms pārslēgšanas, nevis pēc incidenta. Sekojiet pieejamībai, atbildes laikam, CPU, atmiņai, diska izmantojumam, SSL termiņa beigām un galveno pakalpojumu portiem. Lietotnēm ar fona apstrādi uzraugiet arī rindas dziļumu un neveiksmīgos uzdevumus. Ja ir ieviesta pārvaldīta infrastruktūra un monitorings, žurnāli tagad stāsta to pašu stāstu, nevis liek jums minēt pēc tam, kad apmeklētāji ziņo par problēmu.
Veidojiet dublējumu atjaunošanai, nevis tikai sirdsmieram
Izveidojiet jaunu dublējumu tieši pirms migrēšanas loga. Tam jāietver vietnes faili, datubāzes, konfigurācijas faili, lietotāju augšupielādētais saturs un visi lietotnes noslēpumi, kas glabājas ārpus web root. Pārbaudiet, ka dublējumu var atjaunot atsevišķā vietā. Dublējums, kas nekad nav pārbaudīts, ir cerīgs arhīvs, nevis atjaunošanas plāns.
Datubāzēm izmantojiet konsekventu eksportu. Lielām vai aktīvām datubāzēm var būt nepieciešama īpaša apstrāde, lai izvairītos no datu kopēšanas to izmaiņu laikā. Atkarībā no datubāzes un lietotnes varat izmantot apkopes logu, tikai-lasāmu režīmu, replikāciju vai pēdējo inkrementālo sinhronizāciju. E-komercijas veikaliem, rezervāciju sistēmām, SaaS produktiem un dalības vietnēm vajadzīga īpaša piesardzība, jo pasūtījumi un konta izmaiņas var pienākt katru minūti.
Pārcelšanas laikā atstājiet sākotnējo serveri nemainītu. Neatceliet to un nedzēsiet datus, tiklīdz faili parādās mērķa serverī. Vecās vides saglabāšana dod jums tīru atgriešanās ceļu, ja pēc pārslēgšanas parādās slēpta atkarība.
Pārsūtiet failus un datubāzes pa posmiem
Kopējiet sākotnējo datu kopu, kamēr esošā vietne joprojām ir pieejama. Drošas failu pārsūtīšanas rīki, piemēram, rsync over SSH, ir noderīgi, jo tie vēlākajā pēdējā pārejā var sinhronizēt tikai mainītos failus. Datubāzēm importējiet sākotnējo izmetni jaunajā serverī, pēc tam testējiet lietotni pret to, izmantojot pagaidu resursdatora nosaukumu vai lokālu hosts faila pārrakstīšanu.
Neaprobežojieties tikai ar sākumlapas testēšanu. Piesakieties kā administrators un kā parasts lietotājs. Iesniedziet kontaktformu, atiestatiet paroli, augšupielādējiet failu, veiciet testa pirkumu, ja tas ir atbilstoši, pārskatiet darījumu e-pastus un apstipriniet, ka ieplānotie uzdevumi darbojas. Testēšanas laikā pārbaudiet lietotnes žurnālus un tīmekļa servera kļūdu žurnālus. Veiksmīga HTTP 200 atbilde nav pierādījums tam, ka pakalpojums ir vesels.
Ja vienlaikus maināt arī servera arhitektūru, kur iespējams, nošķiriet šīs izmaiņas. Piemēram, pāreja uz jaunu VPS jau pati par sevi ir pietiekami liels darbs, nepapildinot to vēl arī ar datubāzes pārveidi, kešatmiņas slāņa nomaiņu un lietotņu ietvara atjaunināšanu vienā vakarā. Atsevišķi projekti padara kļūmes vieglāk diagnosticējamas un atgriežamas.
Pirms pārslēgšanas samaziniet DNS TTL
DNS ir vieta, kur tehniski veiksmīga migrēšana apmeklētājiem var kļūt mulsinoša. Samaziniet TTL atbilstošajiem A, AAAA, CNAME un ar e-pastu saistītajiem ierakstiem 24 līdz 48 stundas pirms plānotās pārslēgšanas. Mazāks TTL mudina atrisinātājus ātrāk atsvaidzināt ierakstus, tiklīdz norādāt domēnu uz jauno serveri.
Tas negarantē, ka katrs atrisinātājs atjaunināsies uzreiz. Daži tīkli kešo ilgāk, nekā pieprasīts, un lietotājiem var būt lokāla DNS kešošana. Plānojiet pārejas periodu, kurā neliela daļa datplūsmas joprojām var sasniegt veco serveri. Ja vietne pieņem mainīgus datus, jums vajadzīga stratēģija šai pārklāšanās situācijai. Apkopes režīms pēdējās sinhronizācijas laikā bieži ir drošāks nekā jaunu pasūtījumu pieņemšana divos atsevišķos serveros.
Nemainiet vārdu serverus, ja vien nav iemesla pārvietot arī DNS hostingu. Autoritatīvo vārdu serveru maiņa pievieno vēl vienu izplatīšanās slāni un vairāk ierakstu, kas jāpārbauda. Padariet migrēšanu tik garlaicīgu, cik vien iespējams. Garlaicīga infrastruktūra parasti ir veselīga infrastruktūra.
Veiciet pēdējo sinhronizāciju un pārslēdziet datplūsmu
Saskaņotajā pārslēgšanas laikā ieslēdziet lietotnei apkopes režīmu, ja tā raksta klientu datus. Apturiet rindas apstrādes procesus un ieplānotos uzdevumus vecajā serverī, lai tie nevarētu vienu un to pašu uzdevumu apstrādāt divreiz. Veiciet pēdējo failu sinhronizāciju un datubāzes eksportu/importu, pēc tam atjauniniet mērķa konfigurāciju ar produkcijas datubāzes akreditācijas datiem, lietotnes atslēgām un pareizajiem URL.
Iespējojiet lietotni jaunajā serverī un atjauniniet DNS uz tā IP adresi. Apstipriniet, ka SSL sertifikāts ir uzstādīts un ka HTTP pareizi pāradresē uz HTTPS. Ja vietnes priekšā atrodas slodzes balansētājs, CDN vai starpniekserveris, atjauniniet tā izcelsmes konfigurāciju un pārbaudiet, ka tas atpazīst jaunā servera veselības pārbaudes.
Izplatīšanās laikā vērojiet abus serverus. Jaunajam serverim būtu jāuzrāda ienākošie pieprasījumi, savukārt vecajam serverim būtu jāsaņem arvien mazāk datplūsmas. Pārskatiet 404, 500 un atļauju kļūdas, kā arī lietotnei specifiskos brīdinājumus. Sekojiet resursu izmantošanai, jo jauns serveris reālas datplūsmas apstākļos var uzvesties citādi nekā testēšanā.
Pēc migrēšanas pārbaudiet pakalpojumu
Kad datplūsma nonāk jaunajā vidē, veiciet mērķētu produkcijas pārbaudi. Apstipriniet, ka galvenās lapas ielādējas, lietotāji var autentificēties, veidlapas tiek piegādātas, maksājumu vai rezervāciju plūsmas darbojas, vadības paneļi rāda aktuālos datus un augšupielādētie faili ir pieejami. Ja iespējams, testējiet no vairāk nekā viena tīkla, jo jūsu datorā joprojām var būt kešots DNS.
Nākamajās vairākās stundās pārbaudiet ieplānoto aktivitāti. Cron uzdevumi, dublējumi, atjaunošanas, atskaites, rindas apstrādes procesi un webhook saņēmēji bieži atklāj migrēšanas problēmas pēc tam, kad sākotnējā validācija jau ir izturēta. Pārskatiet arī e-pasta žurnālus un piegādes atskaites. Ja vietne izmanto attālinātu SMTP pakalpojumu, apstipriniet, ka jaunā servera IP vai resursdatora nosaukums ir autorizēts.
Atstājiet veco serveri pieejamu vismaz 48 līdz 72 stundas, bet sarežģītām lietotnēm vai lēnām DNS vidēm — ilgāk. Šajā periodā saglabājiet dublējumus no abām pusēm un neveiciet nesaistītas konfigurācijas izmaiņas. Kad monitorings ir tīrs, datplūsma ir stabila un atgriešanās logs ir pagājis, droši pārtrauciet vecā servera ekspluatāciju.
Ziniet, kad izmantot pārvaldītu palīdzību
Vienkārša vizītkartes vietne parasti var tikt pārvietota ar rūpīgu sagatavošanos un īsu apkopes logu. Vietnei ar lielu datplūsmu, aģentūras portfolio ar daudzām klientu vietnēm, SaaS platformai vai serverim ar pielāgotiem pakalpojumiem ir vajadzīgs kontrolētāks plāns. Datubāzes replikācija, pakāpeniskas laidienu izlaišanas, datplūsmas novadīšana un aktīvs monitorings samazina risku, taču tam vajadzīgas arī pieredzējušas rokas.
kodu.cloud var palīdzēt migrēšanas operatīvajā pusē — no mērķa servera sagatavošanas un dublējumiem līdz monitoringam un validācijai. Mērķis nav padarīt procesu noslēpumainu. Tas ir, lai nodrošinātu, ka kāds uzrauga infrastruktūru, kamēr jūs uzturat uzņēmuma darbību.
Laba migrēšana beidzas klusi: apmeklētāji izmanto vietni, ieplānotie uzdevumi darbojas, dublējumi pabeidzas, un nevienam nav jāsūta satraukta vispārēja ziņa. Saglabājiet plānu, dublējumu un veco serveri, līdz pierādījumi rāda, ka pakalpojums atkal ir mierīgs.
Andres Saar klientu atbalsta inženieris