Solutional
Lihtsa veebilehe asendamine võib olla üsna sirgjooneline. Kasutajakontode, tellimuste, arvete, väliste integratsioonide ja pikaajaliste tehingutega ärikriitilise toodangusüsteemi asendamine on hoopis teine ülesanne - eriti juhul, kui kliendid peavad saama teenust kasutada kogu migratsiooni vältel.
Selles projektis ei olnud ei vana ega uut süsteemi arendanud meie ning algsed arendusmeeskonnad ei olnud enam kättesaadavad. Enne migratsiooni kavandamist pidime kõigepealt mõistma, kuidas mõlemad platvormid toodangus käitusid ja kuidas andmed nende vahel liikusid.
Vana toodangusüsteemi mõistmine
Legacy-süsteem võttis vastu klientide tellimusi, saatis need komplekteerimiseks välisele tarkvara teenusena platvormile, koostas raamatupidamiskanded ning teavitas kliente ja kullereid.
Lihtsustatud töövoog nägi välja selline:
Diagrammil tähistab B brauserit (Browser), L legacy-süsteemi, S SaaS-teenust, A raamatupidamissüsteemi (Accounting) ja C kullerisüsteemi (Courier).
Klient esitab tellimuse Brauseris ja tellimus saadetakse Legacy-süsteemi (samm [1]).
Legacy-süsteem saadab tellimuse komplekteerimiseks SaaS-teenusesse (samm [2]).
Esialgse deebetarve koostamiseks vajalikud andmed saadetakse Accounting ehk raamatupidamissüsteemi (samm [3]).
Klient saab tellimuse esitada kuni seitse päeva ette. Seetõttu võib komplekteerimine toimuda alles kuni nädal pärast tellimuse esitamist. Kui komplekteerimine on lõpetatud, saadab SaaS-teenus tulemuse tagasi Legacy-süsteemi (samm [4]).
Kui kõiki algselt tellitud tooteid ei õnnestunud komplekteerida, võib olla vaja koostada kreeditarve. Sellisel juhul saadab Legacy-süsteem vajalikud andmed Accounting ehk raamatupidamissüsteemi (samm [5]).
Samal ajal saadab Legacy-süsteem kliendile e-kirja komplekteeritud tellimuse ja võimaliku kreeditarve kohta (samm [6]) ning edastab tarneks vajaliku info Courier ehk kullerisüsteemi (samm [7]).
Tegelik toodangu töövoog hõlmas veel teisigi süsteeme, kuid see lihtsustatud mudel kirjeldas migratsiooni jaoks kriitilisi sõltuvusi.
Uus süsteem ja ühise SaaS-teenuse piirang
Uus platvorm toetas sisuliselt sama äriprotsessi, kuid kasutas teistsugust tehnoloogiapinu ja andmebaasi. Mõlemad süsteemid sõltusid samast välisest komplekteerimisteenusest.
See teenus sai tulemusi tagastada ainult ühele seadistatud otspunktile. See ei suutnud legacy-tellimusi automaatselt vanale platvormile ja uue süsteemi tellimusi uuele platvormile saata. Sellest piirangust sai migratsiooni keskne tehniline kitsendus.
Uue süsteemi paralleelne käitamine
Enne avalikku ümberlülitust käitasime uut süsteemi toodangus piiratud ligipääsuga eraldi domeenil. Kliendi töötajad kasutasid seda päris klientide, tellimuste ja maksetega.
Mõlema süsteemi paralleelne käitamine võimaldas meil toodangukäitumist kontrollitud viisil testida. Samal ajal vajasime legacy-platvormis suunamisloogikat. Kuna tellimuste identifikaatorid olid kahe süsteemi peale unikaalsed, suutis vana süsteemi otspunkt kindlaks teha, kummale platvormile iga komplekteeritud tellimus kuulus.
Diagrammil tähistab B1 vana süsteemi brauserirakendust, B2 uue süsteemi brauserirakendust, L legacy-süsteemi, N uut süsteemi ja S SaaS-teenust.
Kui klient esitas tellimuse vana süsteemi brauserirakenduses B1, jõudis tellimus Legacy-süsteemi (samm [1]).
Sealt saadeti tellimus tavapärasel viisil komplekteerimiseks SaaS-teenusesse (samm [2]).
Kui tellimus esitati uue süsteemi brauserirakenduses B2, jõudis see New ehk uude süsteemi (samm [3]).
Ka uus süsteem saatis tellimuse samasse SaaS-teenusesse, mida kasutas legacy-süsteem (samm [4]).
Pärast komplekteerimist saatis SaaS-teenus tulemuse tagasi ainsale seadistatud otspunktile ehk Legacy-süsteemi (samm [5]).
Legacy-süsteemi lisatud väike suunamiskomponent kontrollis tellimuse unikaalset identifikaatorit. Kui tellimus oli algselt loodud uues süsteemis, suunati tulemus edasi New ehk uude süsteemi (samm [6]). Legacy-süsteemis loodud tellimused jäid vanasse töövoogu.
See ajutine sild võimaldas mõlemal rakendusel korraga töötada, kuigi väline teenusepakkuja toetas ainult üht tagasikutse aadressi.
Migratsiooni nõuded
Andmebaaside struktuur oli erinev, mistõttu pidime migreerima kliendikontod ja valitud ajaloolised andmed. Samuti pidime tagama, et iga enne ümberlülitust esitatud tellimus töödeldakse korrektselt ka siis, kui selle komplekteerimise tulemus saabub mitu päeva hiljem.
Teine nõue tähendas, et legacy-süsteemi ei saanud lihtsalt välja lülitada hetkel, mil kliendid hakkasid uut süsteemi kasutama.
Migratsioonistrateegia valimine
Tehniliselt lihtsaim lahendus olnuks lõpetada tellimuste vastuvõtmine nädal enne ümberlülitust. Nii oleksid kõik legacy-tellimused jõudnud enne uue süsteemi avaldamist lõpuni, kuid samal ajal oleks peatunud ka kliendi äritegevus. Seetõttu ei olnud see realistlik valik.
Selle asemel kavandasime süsteemide paralleelse käitamise ning avaliku domeeni suunamise DNS-i kaudu legacy-serverilt uuele serverile. Klientidele nähtav katkestus pidi kestma vaid mõne minuti.
Pidev andmemigratsioon
Enne ümberlülitust vähendasime DNS-i time-to-live'i ehk TTL-i väärtust, et DNS-resolverid võtaksid uue aadressi kiiresti kasutusele.
Seejärel ehitasime kliendikontode ja nendega seotud andmete jaoks pidevalt töötavad migratsioonitööd. Kontseptuaalselt töötasid need nii:
while (true) {
migrateUsers()
}
Toodangulahendus oli loomulikult töökindlam, kuid põhimõte oli lihtne: sünkroonida muudatusi enne lõplikku ümberlülitust korduvalt. DNS-i muutmise hetkeks oli uus andmebaas juba ajakohane, mistõttu ei vajanud me ühekordse migratsiooni jaoks pikka hooldusakent.
Paroolide turvaline migreerimine
Kaks süsteemi kasutasid erinevaid paroolide räsialgoritme. Paroole ei saanud otse teisendada, sest turvalised parooliräsid ei ole pööratavad.
Seetõttu lubasime migreeritud kliendil uude süsteemi esimest korda sisse logides autentida vana süsteemi räsiga. Pärast edukat autentimist räsiti parool uue algoritmiga uuesti ja salvestati uues vormingus. Migratsioon toimus järk-järgult, ilma et kõik kliendid oleksid pidanud oma parooli kohe lähtestama.
Kasulike ajalooliste andmete migreerimine
Kogu tellimusajaloo migreerimine oleks olnud ebaproportsionaalselt keeruline, sest kaks süsteemi esitasid tellimusi erinevalt. Selle asemel migreerisime praktiliselt kõige väärtuslikuma info: iga kliendi kõige sagedamini tellitud tooted lisati uue süsteemi Lemmikute funktsiooni.
See oli teadlik kompromiss. Migratsioon säilitas kasuliku kasutuskogemuse, ilma et oleksime loonud suure ja riskantse andmete teisendamise projekti info jaoks, mis ei olnud jätkuva äritegevuse seisukohalt kriitiline.
Suunamise ümberpööramine pärast ümberlülitust
Kui DNS suunas kliendid uude süsteemi, hakkas väline SaaS-platvorm saatma ka kõiki komplekteerimise tulemusi uude otspunkti. Seetõttu tuli suunamise suund ümber pöörata.
Diagrammil tähistab B brauserit (Browser), N uut süsteemi (New), S SaaS-teenust ja L legacy-süsteemi.
Pärast ümberlülitust esitas klient uue tellimuse Brauseris ja tellimus jõudis New ehk uude süsteemi (samm [1]).
Uus süsteem saatis tellimuse komplekteerimiseks SaaS-teenusesse (samm [2]).
Pärast komplekteerimist saatis SaaS-teenus tulemuse tagasi New ehk uude süsteemi (samm [3]).
Uues süsteemis loodud tellimuste tulemused jäid uuele platvormile. Kui tellimuse identifikaator näitas, et tellimus oli algselt loodud Legacy-süsteemis, suunas uus süsteem tulemuse tagasi vanale platvormile (samm [4]). Seal jätkus arvete koostamine, kliendi teavitamine ja tarne töötlemine vana töövoo järgi.
Kuna kliendid said tellimusi esitada seitse päeva ette, pidi see vastassuunaline sild jääma pärast ümberlülitust aktiivseks vähemalt nädalaks.
Toodangu ümberlülituse kavandamine
Suured reliisid planeeritakse sageli hilisõhtule või nädala lõppu. See võib vähendada liiklust, kuid tähendab ka väsinud insenere, kättesaamatuid osapooli ja vähest aega järelprobleemide lahendamiseks enne nädalavahetust.
Valisime esmaspäeva hommiku tavapärase tööaja sees. Meeskond oli puhanud, vajalikud inimesed olid kättesaadavad ning ülejäänud nädal jäi monitooringuks ja parandusteks. Klient eelistas alguses öist reliisi, kuid veensime teda, et päevane kättesaadavus vähendab operatiivset riski.
Muutusele eelneval päeval lisasime legacy-rakendusse bänneri, mis hoiatas kliente lühikese katkestuse eest. Esmaspäeval muutsime DNS-i ning uuest süsteemist sai avalik toodanguplatvorm.
Kuna mõlemad kasutajaliidesed olid üheleherakendused, pidid juba avatud legacy-veebiga kliendid enne uue rakenduse laadimist brauserit värskendama. Ostukorvi koostamise pooleli jätnud kliendid kaotasid ka selle sisu; nende ajutiste sessioonide migreerimine oleks lisanud piiratud kasu eest ebamõistlikult palju keerukust.
Ainult väike osa tugipäringutest oli otseselt ümberlülitusega seotud. Mõned kliendid teatasid väikestest vigadest või eelistasid vana kasutajaliidese teatud osi, kuid põhiteenus jäi kättesaadavaks ja planeeritud seisak piirdus mõne minutiga.
Ootamatud probleemid reliisi ajal
Ükski suurem migratsioon ei ole täielikult etteaimatav.
Internetiteenuse pakkuja eiras DNS-i muudatust
Üks Eesti suurimaid internetiteenuse pakkujaid tagastas vähendatud TTL-ist hoolimata kuni kolm tundi vana DNS-i tulemust. Teised resolverid uuendasid aadressi õigesti ning me ei leidnud oma DNS-seadistusest ühtki viga.
Teenusepakkuja eitas vastutust, kuid praktiline tulemus oli see, et osa kliente jõudis plaanitust kauem legacy-süsteemi. Paralleelse käitamise ja suunamise lahendus aitas mõju piirata.
Mäluleke toodangus
Teine üllatus oli märkimisväärne mäluleke kliendi e-kirjade ja SMS-sõnumite saatmise eest vastutavas teavituskomponendis.
See funktsionaalsus oli jõudlustestide ajaks välja lülitatud, sest päris teavituste saatmine oleks tekitanud kliendile tarbetut kulu. Seetõttu ei ilmnenud leke testkeskkonnas. Kui funktsioon hakkas toodangumahus töötama, näitasid monitooringugraafikud probleemi kiiresti ja andsid meile reageerimiseks piisavalt infot.
Intsident kinnitas olulist õppetundi: realistlik testimine on tähtis, kuid sama oluline on jälgitavus, sest iga toodangukäitumist ei saa eelnevalt turvaliselt taastoota.
Stabiliseerimine ja vana süsteemi kasutuselt kõrvaldamine
Reliisile järgnenud päevadel teatasid kliendid mitmest väiksemast probleemist, kuid ükski neist ei peatanud kliendi äritegevust.
See oli rahustav, sest uue rakenduse koodibaasi ei olnud kirjutanud meie ning selles oli juba mitu märki nõrkadest inseneripraktikatest. Me ei saanud garanteerida, et sügavamaid probleeme ei olnud. Pärast migratsiooni jätkasime süsteemi parandamist, eemaldades kasutamata koodi, parandades vigu ja arendades uusi funktsioone.
Mõni nädal hiljem olid kõik legacy-tellimused lõpetatud. Kustutasime ajutise migratsiooni- ja suunamiskoodi ning lülitasime vana platvormi täielikult välja. Sillakoodi eemaldamine oli oluline viimane samm: ajutisest migratsioonitaristust ei tohiks saada püsivat keerukuse allikat.
Legacy-süsteemi asendamise õppetunnid
Selle projekti raske osa ei olnud suure hulga koodi kirjutamine. Ajutised sünkroonimis-, paroolimigratsiooni- ja suunamiskomponendid koosnesid kokku vaid mõnesajast koodireast.
Tegelik töö seisnes äriprotsessi mõistmises, pikaajaliste sõltuvuste tuvastamises, nende väheste koodiridade õige asukoha valimises ning kliente ja käivet kaitsva ümberlülituse kavandamises.
Selliseid projekte ei saa kirjeldada lihtsa arendusülesannete nimekirjana. Klient saab määratleda vana platvormi asendamise eesmärgi, kuid tehniline meeskond peab välja selgitama, kuidas selleni turvaliselt jõuda. See nõuab tihedat koostööd inimestega, kes tunnevad äriprotsessi üksikasjalikult.
Migratsioon õnnestus, sest pärast nädalaid kestnud paralleelset käitamist ja pidevat sünkroonimist taandus lõplik reliis väikeseks ning tagasipööratavaks taristumuudatuseks. Tulemuseks oli uus toodangusüsteem, mille planeeritud seisak kestis ainult mõne minuti ja mille mõju lõppklientidele oli minimaalne.
