Servera migrācija bez pārsteiguma plkst. 2 naktī. Pārsteigums
Publicēts 2026. gada 2. septembrī
Servera migrācija ir visdrošākā tad, kad jaunā vide jau ir pārbaudīta, pirms klienti tai vispār pieskaras. Failu kopēšana ir tikai viena darba daļa. Patiesais darbs ir saglabāt datu konsekvenci, lietojumprogrammas darbību, e-pasta piegādi, DNS kontroli, drošības noteikumus, plānotos uzdevumus un mazās konfigurācijas detaļas, kurām ir tendence parādīties visnelaipnākajā stundā.
Biznesa tīmekļa vietnei, SaaS platformai, tiešsaistes veikalam vai aģentūras klientu stekam mērķis nav vienkārši pārvietot serveri. Mērķis ir nomainīt pamatā esošo infrastruktūru ar kontrolētu apkopes logu, pārbaudītu atkāpšanās ceļu un bez nepatīkamiem pārsteigumiem norēķināšanās procesā, pieteikšanās laikā vai datubāzes ierakstos. Pakalpojumam atkal jābūt mierīgam, pirms kādam rodas vajadzība jautāt, kāpēc tas nebija mierīgs.
Sāciet servera migrāciju ar pilnīgu inventarizāciju
Pirms mērķa servera sagatavošanas dokumentējiet, kas tieši darbojas pašreizējā serverī. Tas novērš biežo problēmu, kad galvenā tīmekļa vietne pēc pārslēgšanas darbojas, bet fona darbinieks, rēķinu e-pasta pakalpojums vai aizmirsts klienta apakšdomēns nedarbojas.
Pierakstiet operētājsistēmas versiju, tīmekļa servera un PHP vai izpildlaika vides versijas, datubāzes dzini un versiju, lietojumprogrammas atkarības, SSL sertifikātus, cron darbus, ugunsmūra noteikumus, pasta pakalpojumus, DNS ierakstus, krātuves izmantojumu un aktīvos portus. Konteinerizētām slodzēm iekļaujiet compose failus, vides mainīgos, sējumus, attēlu versijas un noslēpumu pārvaldību. Virtuālajām mašīnām fiksējiet tīkla iestatījumus un pievienoto disku informāciju.
Tāpat identificējiet katru atkarību ārpus servera. Piemēri ir maksājumu vārtejas, transakciju e-pasta pakalpojumu sniedzēji, objektu krātuve, CDN iestatījumi, OAuth atzvani, IP atļauto saraksti, trešo pušu API un licenču serveri. Publiskās IP adreses maiņa var ietekmēt jebkuru no tiem. Dažās vidēs šī nav visskaistākā DNS situācija, taču tā ir kontrolējama, tiklīdz tā ir pierakstīta.
Inventarizācijā jāiekļauj biznesa prioritātes, ne tikai tehniskie komponenti. Veikals apkopes laikā varētu spēt rādīt kešotas kataloga lapas, taču tas nevar droši pieņemt pasūtījumus, ja krājumu ieraksti netiek sinhronizēti. SaaS produkts varētu pieļaut īsu aizkavi pārskatu datos, bet ne klientu autentifikācijā. Šīs atšķirības nosaka migrācijas metodi.
Izvēlieties pareizo migrācijas metodi
Nav vienas vienīgas pareizās pieejas servera migrācijai. Pareizā izvēle ir atkarīga no tā, cik bieži dati mainās, cik liela dīkstāve ir pieņemama un vai esošā programmatūra var tīri darboties jaunajā platformā.
Vienkāršu statisku vietni parasti var nokopēt, pārbaudīt un novirzīt uz jaunu IP ar ļoti mazu risku. Saturu pārvaldošai tīmekļa vietnei ar datubāzi nepieciešams rūpīgāks datubāzes eksports un galīgā sinhronizācija. Aktīvai e-komercijas datubāzei vai vairāknomnieku lietojumprogrammai bieži nepieciešama pakāpeniska pārslēgšana, kur vispirms tiek kopēti faili un vēsturiskie dati, pēc tam īsa rakstīšanas iesaldēšana ļauj konsekventi pārvietot pēdējās datubāzes izmaiņas.
Lielākām sistēmām replikācija var būt sagatavošanas pūļu vērta. Datubāzes replikācija, krātuves sinhronizācija un blue-green izvietošanas modeļi var ievērojami samazināt galīgo pārtraukumu. Tie arī palielina operacionālo sarežģītību, tāpēc tie automātiski nav labākā atbilde katram mazajam uzņēmumam. Tīrs apkopes logs ar pārbaudītu dublējumu bieži ir drošāks nekā pārlieku sarežģīts process, ko neviens nav testējis.
Ja pašreizējais serveris darbojas ar novecojušu operētājsistēmu vai neatbalstītu izpildlaika vidi, uztveriet pārcelšanu kā jaunināšanas projektu, nevis vienkāršu kopēšanu. Vecas pakotnes, novecojušas PHP funkcijas, datubāzes kolācijas izmaiņas un OpenSSL atšķirības var mainīt lietojumprogrammas darbību. Šo problēmu testēšana pirms DNS izmaiņām ir daudz lētāka nekā to atklāšana pēc tam, kad klienti jau ierodas.
Sagatavojiet jauno serveri pirms pārslēgšanas
Nodrošiniet mērķi ar pietiekamu CPU, atmiņu, diska veiktspēju un tīkla kapacitāti reāliem slodzes pīķiem, nevis tikai klusam otrdienas rītam. Kur iespējams, pārskatiet pašreizējos resursu rādītājus. Augsts datubāzes I/O, atmiņas spiediens un gari dublēšanas logi ir signāli, ka tāda paša izmēra serveris var būt par mazu.
Vispirms izveidojiet pamata vidi: operētājsistēmas atjauninājumus, SSH piekļuves kontroli, ugunsmūra noteikumus, fail2ban vai līdzvērtīgu aizsardzību, kur tas ir piemēroti, uzraudzības aģentus, dublēšanas grafikus un lietotāju kontus ar minimāli nepieciešamajām privilēģijām. Instalējiet nepieciešamo lietojumprogrammas steku ar versijām, kas ir testētas pret attiecīgo slodzi.
Jaunajam serverim jābūt arī uzraudzītam, pirms tas saņem produkcijas trafiku. Sekojiet CPU, atmiņai, diska noslodzei, diska latentumam, tīkla trafikam, pakalpojumu pieejamībai un lietojumprogrammu kļūdām. Tehniskākām komandām Prometheus metriku eksportēšana uz Grafana nodrošina noderamu pārskatāmību pārslēgšanas laikā un pēc tās. Serveris, kas atbild uz ping, ne vienmēr ir vesels. Tas var klusi gaidīt, kad tā datubāzes savienojumu pūls izsīks.
Dublējumiem nepieciešama īpaša uzmanība. Pirms darba sākuma izveidojiet pilnīgu, atjaunojamu dublējumu no avota, pēc tam pārbaudiet, ka to var atjaunot. Tas, ka dublējuma fails kaut kur eksistē, ir iedrošinoši, bet tas vēl nav atkopšanas plāns. Saglabājiet neatkarīgu kopiju, līdz migrētā vide ir darbojusies normāli saskaņotā periodā.
Testējiet, nenovirzot klientus uz jauno serveri
Izmantojiet pagaidu resursdatora nosaukumu, testēšanas apakšdomēnu, privāta tīkla ceļu vai lokālu hosts faila aizvietošanu, lai testētu jauno vidi pirms publiskām DNS izmaiņām. Tas ļauj komandai pārbaudīt mērķa serveri tā, it kā tas jau būtu produkcijā, kamēr parastie apmeklētāji turpina izmantot esošo serveri.
Pārbaudiet lietotāju ceļus, kas pelna naudu vai uztur darbību kustībā. E-komercijas vietnei tas nozīmē produktu lapas, groza darbības, norēķināšanos, maksājumu atzvanus, krājumu atjauninājumus, konta e-pastus un pasūtījumu administrēšanu. SaaS lietojumprogrammai testējiet pieteikšanos, paroles atiestatīšanu, fona darbus, failu augšupielādes, API galapunktus, webhookus un konta līmeņa atļaujas.
Pārbaudiet arī tehnisko uzvedību. Apstipriniet, ka pāradresācijas paliek pareizas, SSL sertifikāti ielādējas pareizi, plānotie uzdevumi izpildās, izejošais e-pasts ir autentificēts, žurnāli tiek rakstīti, kešatmiņas tiek pareizi notīrītas un failu īpašumtiesības netraucē augšupielādēm vai atjauninājumiem. Salīdziniet atbildes laikus vecajā un jaunajā serverī, īpaši lapām ar lielu datubāzes slodzi.
Neizlaidiet atkāpšanās testēšanu. Precīzi ziniet, kā jūs atgriezīsiet trafiku uz avota serveri, ja parādīsies kritiska problēma. Tas var nozīmēt iepriekšējā DNS ieraksta atjaunošanu, slodzes balansētāja mērķa maiņu vai iepriekšējās lietojumprogrammas vides saglabāšanu pieejamā, bet tikai lasāmā režīmā. Atkāpšanās plānam jābūt dokumentētai darbībai, nevis cerīgam noskaņojumam.
Kontrolējiet DNS un galīgo datu sinhronizāciju
DNS bieži ir redzamā servera migrācijas daļa, taču tam jābūt pēdējam slēdzim, nevis pirmajam. Iepriekš samaziniet DNS TTL vērtības, ja kontrolējat zonu, ideālā gadījumā 24 līdz 48 stundas pirms plānotās pārslēgšanas. Tas palīdz rezolveriem ātrāk atsvaidzināt jauno adresi, lai gan daži tīkli joprojām var turēt ierakstus ilgāk, nekā prasīts.
Tieši pirms pārslēgšanas samaziniet vai apturiet ierakstus tur, kur lietojumprogramma to atļauj. Ievietojiet vietni apkopes režīmā, apturiet darbiniekus vai uz laiku atspējojiet pasūtījumu iesniegšanu. Veiciet datubāžu, augšupielādēto failu, rindu un citu mainīgo datu galīgo sinhronizāciju. Pēc tam pārbaudiet ierakstu skaitu, nesenās transakcijas un lietojumprogrammas žurnālus mērķī.
Mainiet DNS vai trafika maršrutēšanas mērķi tikai tad, kad galīgā sinhronizācija ir pabeigta. Veco serveri propagācijas laikā atstājiet tiešsaistē un neskartu. Tas joprojām ir vērtīgs kā atskaites punkts un atkāpšanās iespēja. Neatceliet to uzreiz tikai tāpēc, ka sākumlapa izskatās labi no viena biroja savienojuma.
Pēc pārslēgšanas testējiet no vairākiem tīkliem un vērojiet žurnālus. Apstipriniet, ka pieprasījumi sasniedz jauno serveri, fona darbi nedarbojas divreiz, sertifikāti tiek pasniegti pareizi un neaug negaidītas 404, 500 vai atļauju kļūdas. Pievērsiet īpašu uzmanību e-pastam, webhook piegādei, maksājumu paziņojumiem un plānotajiem procesiem. Šie ir pakalpojumi, kas, visticamāk, neuzkrītoši neizdosies.
Stabilizējiet situāciju pēc pārcelšanas
Pirmās 24 līdz 72 stundas joprojām ir daļa no migrācijas. Turpiniet rūpīgāku uzraudzību, pārskatiet resursu izmantojumu pret bāzes līmeni un vērojiet lēnus vaicājumus, kešatmiņas netrāpījumus, krātuves pieaugumu un lietojumprogrammu izņēmumus. Jauns serveris var atklāt kapacitātes vai konfigurācijas problēmas, ko vecā iestatne slēpa.
Kad trafiks un plānotās darbības ir stabili, atkal palieliniet DNS TTL vērtības, ja tās tika samazinātas. Apstipriniet, ka dublējumi darbojas no jaunās sistēmas, un, kur iespējams, veiciet praktisku atjaunošanas pārbaudi. Atjauniniet dokumentāciju ar jaunajām IP adresēm, akreditācijas datiem, arhitektūras piezīmēm un piegādātāju atļauto sarakstiem.
Pārvaldītās infrastruktūras atbalsts šeit ir noderīgs, jo migrācija nebeidzas tad, kad faili nonāk jaunā diskā. Uzņēmumā kodu.cloud operatīvais darbs var ietvert servera sagatavošanu, uzraudzību, dublēšanas plānošanu un palīdzību pārslēgšanas loga laikā, lai jūsu komanda nepaliktu viena ar termināļa uzvedni un strauji atdziestošu kafijas tasi.
Rūpīgai servera migrācijai nav jābūt dramatiskai. Vispirms izveidojiet mērķi, testējiet reālo uzvedību, apzināti pārvietojiet galīgos datus un saglabājiet atkāpšanās ceļu, līdz žurnāli stāsta vienu un to pašu stāstu. Tādā veidā jūs aizsargājat darbspējas laiku, vienlaikus virzot biznesu uz priekšu.
Andres Saar klientu apkalpošanas inženieris