Pilve migratsioon: olemasoleva kolimine ilma kõike lõhkumata

Pilve migratsioon läheb harva katki kopeerimise ajal. See läheb katki hetkel, kui arvatakse, et töö on tehtud. 2026. aasta juulis oli meie serveri ketas, millel töötab kümmekond teenust, nende hulgas Palmora Property CRM (kinnisvaraportaal, mida haldame oma kliendi jaoks), täis ja selle andmebaasid ohus: CRM salvestas sinna ise kinnisvaraobjektide fotod. Viisime need objektisalvestusse ühtegi faili kaotamata; lõks peitus juurdepääsuvõtmetes, mis rakenduseni ei jõudnud.

Migreerimine tähendab siin juba töötava (rakendused, andmed, failid, domeeninimed) kolimist suure teenusepakkuja juurde, teise majutajasse või tagasi oma serverisse. Siin on meetod, mida rakendame töökoormuse kaupa 20–500 inimesega meeskondadele. See eeldab, et infrastruktuuri alus, mis need töökoormused vastu võtab, on juba olemas.

Lühidalt

• Inventeerige ka see, mis elab teie kasutajate juures: seanss, paigaldatud rakendus, teavitused.
• Valige iga töökoormuse jaoks strateegia ja moderniseerige pärast migratsiooni, mitte selle ajal.
• Kopeerige, testige, võrrelge ja alles siis puhastage.
• Kirjutage tagasipöördumise tingimused üles enne alustamist ja hoidke vana teed tõestuse ajaks alles.
• Teadlikult valitud hübriid ei ole ebaõnnestumine.

Mida tuleb enne migreerimist inventeerida?

Google Cloudi migratsioonijuhend jagab migratsiooni neljaks etapiks: hindamine, planeerimine, juurutamine, optimeerimine. Esimese eesmärk on „understand your app and environment inventory, identify app dependencies and requirements, perform total cost of ownership calculations, and establish app performance benchmarks“, see tähendab mõista rakenduste ja keskkonna inventari, tuvastada sõltuvused ja nõuded, arvutada omamise kogukulu ja määrata jõudluse võrdlusalused.

Sõltuvused otsustavad järjekorra. Microsofti planeerimisjuhendi järgi „dependencies between workloads cause service disruptions if not migrated together“ ning iga partii peab kaasa võtma selle, mida tema rakendused vajavad, „including supporting infrastructure such as load balancers, DNS records, or caching layers“, see tähendab ka koormusjaoturid, DNS-kirjed või vahemälukihid.

Inventeerige ka see, mida teie kasutajad enda poolel hoiavad. Brauseri jaoks on teine aadress teine rakendus: kui meie arendatud grupiväljakutsete rakendus Challenge Us vahetas 2026. aasta septembris aadressi, jäid seanss, seaded, paigaldatud rakendus ja teavitused vana aadressi juurde.

Milline strateegia iga töökoormuse jaoks?

AWS-i suurte migratsioonide juhend jagab võimalused seitsmeks strateegiaks, „7 Rs“:

• Retire: kasutuselt kõrvaldada või arhiveerida see, mida enam ei kasutata.
• Retain: hoida kohapeal, praegu või jäädavalt.
• Rehost: majutada ümber midagi muutmata, nn „lift and shift“.
• Relocate: kanda paljud serverid üle nende platvormi pilveversiooni.
• Repurchase: asendada teise versiooni või teise tootega.
• Replatform: kolida koos väikese optimeerimisega.
• Refactor or re-architect: vaadata arhitektuur üle, et kasutada pilvele omaseid funktsioone.

Suure migratsiooni puhul soovitab AWS ümberkujundamisest hoiduda, „because it involves modernizing the application during the migration“, ja soovitab „rehosting, relocating, or replatforming the application and then modernizing the application after the migration is complete“: kõigepealt ümber majutada, ümber paigutada või platvormi vahetada ja alles pärast migratsiooni lõppu moderniseerida.

Kolm meie tehtud migratsiooni mahuvad nendesse lahtritesse: Palmora Property igapäevane sünkroonimine, mis majutati meie serverisse ümber selle samme muutmata; selle CRM-i failide salvestus, mille platvorm vahetati konfiguratsiooni kaudu koodi puutumata; Challenge Usi lehed, mis viidi teise majutajasse neid ümber kirjutamata. Me ei ole teinud ühtegi migratsiooni AWS-i, Google Cloudi ega Azure’isse: nende juhendid on meile siin ühine sõnavara, olenemata sihtkohast.

Miks kopeerida, mitte teisaldada?

Kopeerimine hoiab originaali puutumatuna, kuni koopia pole end tõestanud: tagasipöördumine mahub siis ühte konfiguratsioonireale. Palmora Property CRM-i failide jaoks seadsime pärast ainult lugemisõigusega luuret neli kaitsemeedet:

• Eraldi salvestusruum: veebilehe piltide ruumist puhastatakse orbfailid ja ühises ruumis oleks see puhastus kustutanud CRM-i failid.
• Eraldi juurdepääsuvõti, piiratud selle ruumiga, tühistatav veebilehte puutumata.
• Failid, mis jäävad privaatseks, mida CRM serveerib oma autentimise taga.
• Iga konfiguratsioonifaili varukoopia, kus vana väärtus on alles kommentaarina: see ongi tagasipöördumine.

See CRM on Twenty: meil on see tootmises alates 2025. aasta algusest ja me panustame projekti. See oskab salvestada oma faile S3-ühilduvasse salvestusse, see tähendab sellisesse, mis räägib sama liidest nagu Amazoni salvestusteenus: kontrollisime seda selle koodist. Lõks oli mujal: konteinerite konfiguratsioon edastas ainult osa salvestuse seadetest, ilma juurdepääsuvõtmeteta. Need tuli lisada põhiteenusele ja taustaülesannete teenusele.

Kuidas kontrollida enne ümberlülitamist ja enne puhastamist?

Enne ümberlülitamist testiti juurdepääsu uuele salvestusele lugemiseks ja kirjutamiseks, kopeerimine lõppes vigadeta ja uus konfiguratsioon kinnitati. Pärast ümberlülitamist kolm testi ja neljas pärast puhastamist:

1. 01Lugemine

   Fotodega kuulutus avaneb, serveerituna uuest salvestusest.

2. 02Kirjutamine

   Lisatud pilt jõuab uude salvestusse ja vana kaust ei muutu.

3. 03Terviklikkus

   Kahe poole võrdlus ei leia ühtegi erinevust. Just see test lubab puhastada.

4. 04Lõplik tõend

   Kui vana kaust on tühjendatud, tuleb iga endiselt kuvatav pilt paratamatult uuest salvestusest.

Üks piirang: võrdlus käsitles failide nimesid ja suurusi, ainult ühes suunas, ilma sisu räsita. See näitab, et midagi ei puudu, mitte seda, et iga bait on identne.

Kuidas lülitada ümber nii, et tagasitee jääks?

Tagasipöördumine otsustatakse enne alustamist. Microsoft kirjutab selle selgelt välja: „Always establish rollback criteria and procedures before initiating any migration or deployment.“ Selle käivitajad on mõõdetavad, nagu „CPU usage limits, response time thresholds, or error rates“, see tähendab protsessori kasutuse piirid, vastuseaja lävendid või veamäärad, ja protseduuri testitakse: „Verify that the rollback procedure restores the system to a stable, known-good state.“

Domeeninime puhul sõltub kõik toimingute järjekorrast. Kui Challenge Us vahetas aadressi, oleks ümbersuunamine rakenduse külmutanud: selle service worker, väike programm, mis serveerib seda brauseri vahemälust, ei uuenda end kunagi läbi ümbersuunamise. Mõlemad aadressid serveerisid seega sama versiooni ja vana pakkus kolimist alles siis, kui uus oli valmis.

Kui Challenge Us seejärel majutajat vahetas, tehti see neljas etapis.

Meie reegel sellest ajast: hoida kirje alles ja kasutada marsruutimisreeglit või kustutada see ja siduda nimi kohe järel, mitte kunagi üht ilma teiseta.

Kui kaua vana teed alles hoida?

Migratsioon ei vii alati pilve. Alates 23. juulist 2026 töötab igapäevane sünkroonimine, mis toidab Palmora Property veebilehte selle CRM-ist, meie enda serveris, mitte enam veebipõhises pideva integratsiooni teenuses. CRM on seal kohalik, vahemälud elavad kettal, sammud ja ajakava ei ole muutunud ning lukk takistab kahe käivituse kattumist.

Vana tee jäi alles käsitsi kasutatava varuvariandina. Kuid varuvariant vananeb: selle vahemälu on juulist saadik külmunud, see kontrolliks uuesti tuhandeid objekte ja võiks töötada tunde. Challenge Usi puhul ei lülitata vana aadressi kunagi välja: see ei maksa midagi ja just see toob tagasi juba paigaldatud rakendused. Hoidke vana teed seega alles seni, kuni keegi seda kasutab, ja kontrollige aeg-ajalt, kas see veel töötab.

Millal puhastada ja mida pärast mõõta?

Puhastamine tuleb viimasena, pärast võrdlust ja ettevaatusabinõudega: täpne tee ja kontroll, et kaust sisaldab tõesti seda, mida oodatakse. Pärast seda jääb tagasipöördumine võimalikuks, kuid muudab olemust: umbes tund uuesti kopeerimist, taastatud konfiguratsioon, taaskäivitus. Meie artikkel sellest, mis oma serveri varukoopiates tegelikult katki läheb, tuletab meelde: koopia on väärt ainult siis, kui seda osatakse taastada.

Seejärel mõõtke.

Challenge Us mõõdab omakorda, kes avab rakenduse veel vana aadressi kaudu.

Osa kohapeal hoidmine: kas hübriid on ebaõnnestumine?

Ei, kui see on teadlik valik. AWS teeb „Retain“-ist täieõigusliku strateegia ja toob oma ümberkujundamise näidete hulgas andmebaasi, mille osa tabeleid, „such as customer information, patient, or patient diagnosis tables“, jääb turvalisuse ja vastavusnõuete tõttu kohapeale. Microsoft nõuab dokumenteerida, miks komponent kohapeale jääb, ja piirata vahepealset olekut: „Minimize split-environment operation time.“

Need kaks kliendiprojekti on hübriidsed, teadliku valiku tõttu. Palmora Property CRM töötab meie serveris, selle failid elavad objektisalvestuses ja iganädalane puhastusülesanne jääb praegu pideva integratsiooni teenusesse. Challenge Us vahetas oma lehtede majutajat, kuid selle andmebaas, kontod ja serverifunktsioonid ei liikunud. Edaspidiseks ütleb meie analüüs Euroopa sõltuvusest Ameerika pilvest, mida Euroopa õigus teenusepakkuja vahetamise kuludes muudab.

Kontrollnimekiri enne ümberlülitamist

• Kopeerimine on lõppenud vigadeta ja originaal on puutumata.
• Uued seaded jõuavad kõigi asjassepuutuvate teenusteni, mitte ainult esimeseni.
• Lugemine ja kirjutamine on uues sihtkohas testitud.
• Tagasipöördumise tingimused on kirja pandud koos otsustaja nimega.
• Vana tee jääb avatuks ja te teate, kui kauaks.
• Signaal hoiatab, kui uus tee lakkab töötamast.

Kust alustada

Loetlege, mis peab liikuma, ja märkige iga rea juurde strateegia ning selle tagasipöördumise tingimus. Alustage töökoormusest, mille tagasipöördumine on lihtne, näiteks failidest. Kui teie tööriistad peavad loobuma tellimustest oma serveri kasuks, viib meie SaaS-ist väljumine need üle ükshaaval, kontrollitud andmete ja ettenähtud tagasipöördumisega. Kui sihtkoht on suur teenusepakkuja või Euroopa pilv, kirjutage meile, mis peab liikuma ja kuhu soovite selle viia.

Korduma kippuvad küsimused

Allikad

1. Google Cloudi migratsioonijuhend (uus vahekaart)docs.cloud.google.com
2. Microsofti planeerimisjuhendi (uus vahekaart)learn.microsoft.com
3. AWS-i suurte migratsioonide juhend (uus vahekaart)docs.aws.amazon.com