SaaS migrācijas uz VPS gadījuma pētījums drošākai pārslēgšanai

Publicēts 2026. gada 28. septembrī

Ražošanas datubāze bija pāraugusi koplietojamo vidi jau ilgi pirms tās faktiskās atteices. Noslodzes periodos atbildes laiks palielinājās, izvietošanas logi šķita riskanti, un komandai nebija skaidri izstrādātas atkopšanas pārbaudes, ja spraudņa atjauninājums vai datubāzes problēma izraisītu neparedzētu kļūmi. Šajā SaaS migrācijas uz VPS gadījuma pētījumā aplūkots apvienots B2B programmatūras nodrošinātāja piemērs, kurš pārvietoja savu lietotni uz pārvaldītu VPS, neuztverot migrācijas nakti kā azartspēli.

Uzņēmumam bija klientu portāls, API, darba procesi, PostgreSQL datubāze un fona e-pasta uzdevumi, kas darbojās mitināšanas iestatījumā, kurš darbam bija kļuvis pārāk pārblīvēts. Tas nebija dramatisks pārtraukuma stāsts. Šādi stāsti reti kad ir noderīgi. Tas bija risku pārvaldības stāsts: pārvietoties, pirms parasta izaugsme kļūst par incidentu.

Sākumpunkts: SaaS steks ar maz rezervju

SaaS nodrošinātājs apkalpoja aptuveni 3500 aktīvu lietotāju, un datplūsma bija koncentrēta ASV darba laikā. Lietotne darbojās tradicionālā tīmekļa stekā: Nginx, PHP-FPM, PostgreSQL, Redis un vairāki ieplānoti darba uzdevumi. Komandai bija pirmkoda kontrole un izvietošanas skripti, taču infrastruktūra bija uzkrājusies ierastajā praktiskajā veidā — viens pakalpojums pēc otra, līdz piektdienā neviens vairs negribēja aiztikt serveri.

Tūlītējais spiediens bija saistīts ar datubāzes veiktspēju. CPU lietojums nebija pastāvīgi augsts, taču īslaicīgi maksimumi lika uzkrāties lēniem vaicājumiem. Diska I/O konkurence parādījās ikreiz, kad dublēšana notika vienlaikus ar pārskatu uzdevumiem. Lietotne parasti spēja atgūties, tomēr “parasti” nav atkopšanas mērķis.

Komandai bija nepieciešama arī lielāka kontrole pār PHP versijām, pakalpojumu konfigurāciju, ugunsmūra noteikumiem un uzraudzību. Koplietojamā mitināšana bija noderīga sākumposmā, taču tā bija sasniegusi savu dabisko robežu. VPS nodrošināja īpaši piešķirtus resursus un vadību saknes līmenī, neprasot uzņēmumam pārvaldīt fizisku aparatūru.

Visus lēmumus noteica viens ierobežojums: klientu sesijas un maksas darbplūsmas nedrīkstēja ilgstoši pārtraukt. Migrācija ar vairāku stundu dīkstāvi bija tehniski iespējama, taču komerciāli nepievilcīga.

Kas tika pārbaudīts pirms migrācijas uz VPS

Pirms jaunās vides izveides migrācijas plāns sadalīja sistēmu komponentos, kurus varēja pārvietot neatkarīgi, un komponentos, kuriem bija nepieciešama galīgā pārslēgšana. Statiskos lietotnes failus, konteineru attēlus un lielāko daļu konfigurācijas varēja pārkopēt iepriekš. Datubāzei bija nepieciešama lielāka piesardzība, jo tā turpināja mainīties līdz galīgajai pārslēgšanai.

Komanda vispirms izmērīja faktisko lietojumu, nevis izvēlējās VPS plānu, balstoties uz optimismu. Tika pārskatīta maksimālā CPU noslodze, RAM patēriņš, datubāzes lielums, krātuves pieaugums, IOPS uzvedība, tīkla pārsūtīšana un vienlaicīgo darba procesu skaits. Iegūtajam VPS tika paredzētas rezerves datplūsmas maksimumiem un uzturēšanai, nevis tikai pietiekama kapacitāte pašreizējo vidējo rādītāju atkārtošanai.

Tika izvēlēts pārvaldīts VPS, jo iekšējā izstrādes komanda spēja uzturēt lietotni, taču nevēlējās kļūt par dežurējošo eskalācijas punktu katram operētājsistēmas brīdinājumam. Šis kompromiss ir skaidri jāpasaka: nepārvaldīta VPS mitināšana uz papīra var maksāt mazāk, taču tā uz jūsu pašu cilvēkiem pārnes labošanu, uzraudzību, dublējumu validēšanu un incidentu sākotnējo analīzi. Komandām ar īpaši norīkotiem infrastruktūras darbiniekiem tas var būt saprātīgi. Nelielai SaaS komandai tas bieži kļūst par dārgu uzmanības novēršanas avotu, kas maskējas aiz zemas mēneša cenas.

Jaunais VPS tika nostiprināts pirms lietotnes datu ielādes. Piekļuve tika ierobežota ar SSH atslēgām, nevajadzīgie pakalpojumi tika noņemti, ugunsmūra noteikumi atļāva tikai nepieciešamo datplūsmu, un automatizētie drošības atjauninājumi tika pārbaudīti, lai pārliecinātos par to saderību ar steku. Izvietošanai un pakalpojumu procesiem tika izveidoti atsevišķi sistēmas lietotāji. Noslēpumi tika pārvietoti ārpus kodbāzes uz aizsargātiem konfigurācijas failiem.

Dublēšana tika konfigurēta divos veidos: ieplānoti ārpus servera glabāti dublējumi atkopšanai pēc servera zuduma un datubāzei specifiski dublējumi ātrākai datu atjaunošanai. Dublējums, kas nekad nav atjaunots, ir tikai cerību pilns fails. Komanda atjaunoja vienu datubāzes dublējumu izolētā testa datubāzē un apstiprināja, ka lietotne to var pareizi nolasīt.

Migrācijas plānā tika izmantota pakāpeniska pārslēgšana

Lietotne tika izvietota jaunajā VPS vairākas dienas pirms migrācijas nakts. Tas deva komandai laiku salīdzināt darbību reālistiskas slodzes apstākļos un novērst nelielas atšķirības PHP paplašinājumos, failu atļaujās, cron izpildē, Redis konfigurācijā un e-pasta piegādē. Šīs detaļas ir garlaicīgas, līdz tās vairs tādas nav.

Pilna cikla testēšanai tika izmantots iestudēšanas resursdatora nosaukums. Iekšējie darbinieki pārbaudīja pierakstīšanos, konta izveidi, norēķinu atbildes zvanus, failu augšupielādi, ieplānotos pārskatus, API autentifikāciju un administrēšanas portālu. Viņi pārbaudīja arī atgriešanas ceļu. Šo daļu daudzas migrācijas izlaiž, jo atgriešanas plānošana šķiet pesimistiska. Patiesībā tieši tā ļauj problēmas laikā pieņemt mierīgu lēmumu.

Galīgajai pārslēgšanai bija četri operacionālie posmi:

• Iepriekš samazināt DNS TTL, lai ierakstu izmaiņas izplatītos ātrāk.
• Veikt sākotnējo datubāzes sinhronizāciju, kamēr vecā platforma joprojām darbojās.
• Īsās galīgās sinhronizācijas laikā pārslēgt intensīvi rakstošās funkcijas uzturēšanas režīmā.
• Atjaunināt DNS, pārbaudīt ražošanas datplūsmu un saglabāt veco vidi pieejamu, līdz tika apstiprināta jaunā pakalpojuma stabilitāte.

Sākotnējā datu pārsūtīšana pārvietoja lielāko daļu datubāzes, neietekmējot lietotājus. Saskaņotajā uzturēšanas laikā komanda apturēja jaunus ierakstus, veica galīgo inkrementālo sinhronizāciju un palaida ražošanas pakalpojumus VPS. Ierakstīšanas apturēšana ilga 11 minūtes. Lietotāji, kuri jau pārlūkoja vietni, varēja turpināt lasīt lielāko daļu publisko un konta lapu, savukārt tādām darbībām kā norēķinu datu atjaunināšana vai jaunu ierakstu iesniegšana tika parādīts īss paziņojums par uzturēšanu.

Šī pieeja nebija pilnībā bez kompromisiem. Migrācija ar gandrīz nulles dīkstāvi, izmantojot datubāzes replikāciju, var vēl vairāk saīsināt galīgo uzturēšanas logu, taču tā palielina sarežģītību un prasa lielāku iepriekšēju sagatavošanos. Šim SaaS nodrošinātājam kontrolēta 11 minūšu ierakstīšanas apturēšana bija drošāka nekā tādas replikācijas arhitektūras izveide, kuru komanda vēlāk nebija gatava darbināt. Laba infrastruktūra ne vienmēr ir vissarežģītākā infrastruktūra.

Kas notika pārslēgšanas laikā

DNS ieraksts tika atjaunināts pēc galīgās datubāzes pārbaudes. Migrācijas komanda uzraudzīja piekļuves žurnālus, kļūdu žurnālus, PostgreSQL savienojumus, PHP-FPM darba procesu aktivitāti, atbildes laikus un fona rindas dziļumu, kad datplūsma sasniedza jauno VPS.

Pirmajā stundā parādījās divas problēmas. Ieplānots pārskata uzdevums izmantoja vecā servera statiski iestatītu ceļu, un viens ārējā API nodrošinātājs atļauto IP adrešu sarakstā bija iekļāvis iepriekšējo izejošo IP adresi. Nevienai no problēmām nebija nepieciešama atgriešana. Pārskata uzdevuma ceļš tika izlabots, bet piegādātāja atļauto adrešu saraksts atjaunināts, izmantojot jauno VPS adresi. Žurnāli tagad vēstīja to pašu stāstu.

Komanda saglabāja veco vidi neskartu, taču atspējoja tajā publisku ierakstīšanu. Tas izveidoja aizsargātu atgriešanas iespēju, vienlaikus novēršot datu sadalīšanos starp divām sistēmām. Pēc 24 stundām ar stabilu lietotnes darbību, veiksmīgiem dublējumiem un normālu rindu apstrādi vecā vide tika izņemta no ražošanas lietojuma.

Rezultāti pēc pārvietošanas uz VPS

Tūlītējais ieguvums bija konsekvence. Lietotnes vidējais atbildes laiks uzlabojās, jo datubāzei un tīmekļa darba procesiem vairs nebija jākonkurē par resursiem ar nesaistītiem nomniekiem. Par ātrdarbības uzlabojumu vērtīgāka bija pārskatāmība: komanda vienā operacionālajā skatā varēja redzēt CPU, RAM, disku, tīklu, pakalpojumu statusu un datubāzes darbību.

SaaS nodrošinātājs ieguva arī pārskatāmāku uzturēšanas kārtību. Atjauninājumus varēja pārbaudīt iestudēšanas vidē pirms ražošanas vides, dublējumi tika izpildīti ārpus pārskatu maksimuma stundām, un brīdinājumiem bija noteikti atbildīgie. Pateicoties pārvaldītam operacionālajam atbalstam un aktīvai uzraudzībai no kodu.cloud, iekšējai komandai bija skaidrāks eskalācijas ceļš gadījumiem, kad bija jāpievērš uzmanība infrastruktūras darbībai.

Migrācija neatcēla visus pienākumus. Klients joprojām bija atbildīgs par lietotnes laidieniem, datu pareizību, lietotāju atļaujām un piegādātāju integrācijām. Mitināšanas slāni varēja uzraudzīt, labot, dublēt un atbalstīt, taču neviens nodrošinātājs nevar noteikt, vai jaunizvietotā funkcija satur biznesa loģikas kļūdu. Skaidras atbildības robežas ir veselīgas sistēmas sastāvdaļa.

Mācības SaaS komandām, kas plāno pāreju uz VPS

Galvenā atziņa ir tāda, ka migrācijas kvalitāti nosaka pirms pārslēgšanas loga. Labākais laiks, lai atklātu nedokumentētu cron uzdevumu, beigušos API akreditācijas datus vai pārāk lielu datubāzes tabulu, ir iestudēšanas laikā, nevis tad, kad klienti atsvaidzina pārlūkprogrammu.

Sāciet ar izmērītu resursu lietojumu un pēc tam atstājiet vietu izaugsmei. Izveidojiet jauno serveri pietiekami agri, lai pārbaudītu reālas darbplūsmas. Apstipriniet dublējumus, tos atjaunojot. Nosakiet, kas izraisa atgriešanu un kurš var pieņemt šo lēmumu. Visbeidzot, uzraugiet pakalpojumu pēc DNS izmaiņām, nevis pasludiniet uzvaru, kad izvietošanas komanda ir pabeigta.

Migrācijai uz VPS vajadzētu nodrošināt jūsu komandai lielāku kontroli un mazāk minējumu vēlu vakarā. Ja plānā ir pārbaudīta atkopšana, pakāpeniska pārsūtīšana un cilvēki, kuri uzrauga serveri pēc datplūsmas ierašanās, pakalpojums atkal var kļūt mierīgs.

Andres Saar Klientu atbalsta inženieris