Pilier puslapis
Legacy sistemų modernizavimas
Inkrementinis monolito refaktoringas į mikropaslaugas, migracija iš pasenusių technologijų į šiuolaikinius stack'us, perkėlimas į debesį — be verslo prastovų, su rollback planu ir pilnu audito pėdsaku.
Kiekviena įmonė turi kokią nors legacy sistemą. Kai kurios turi jų kelias. Buhalterinė aplikacija iš 2008 metų, kuri kažkaip veikia. CRM, parašytas konsultantų, kurių jau niekas neprisimena. Sandėlys Access'e. Kiekvieną iš jų kažkada teks pakeisti — klausimas ne ar, o kada ir kaip.
Legacy sistemų modernizavimas — vienas iš sudėtingiausių IT projektų tipų. Reikalauja trijų jėgų pusiausvyros: verslo tęstinumo išlaikymo (sistema turi veikti visą laiką), šiuolaikinių technologijų įdiegimo (mikropaslaugos, debesis, DI) ir rizikos kontrolės (kiekvienas refaktoringas gali sugadinti tai, kas veikė metų metus).
Kodėl nepakanka „perrašyti iš nulio"?
Iš mūsų patirties 9 iš 10 sėkmingų modernizacijų — inkrementinis refaktoringas, ne rewrite. Rewrite vilioja konceptualiniu paprastumu („pradėsime nuo švaraus lapo"), bet praktikoje turi tris fundamentalias problemas:
- Nematoma verslo logika. Sena sistema turi metų metų verslo taisyklių — specialūs sąlygos didžiausiems klientams, mokesčių lengvatos konkrečioms šakoms, 2015 metų reguliavimo apėjimai. Dauguma neturi dokumentacijos. Rewrite turi visa tai atkurti iš žmonių atminties arba kodo analizės.
- Darbo dublikavimas. Rašant naują sistemą, verslas toliau reikalauja pakeitimų senoje (reguliavimai, nauji klientai, smulkios klaidos). Komanda arba dubliuoja darbą (pakeitimas dviejose vietose), arba užšaldo seną sistemą (verslo rizika).
- Big bang deployment. Po metų darbo nauja sistema yra „beveik paruošta". Visų vartotojų perjungimas vieną naktį generuoja monumentalią riziką. Kiekviena netikėta problema reiškia grįžimą prie senos sistemos, komandos moralės praradimą, verslo pasitikėjimo pakirtimą.
Inkrementinis refaktoringas (dažniausiai pagal Strangler Fig šabloną) išsprendžia visas tris problemas: verslo logika atrandama palaipsniui, vienas tiesos šaltinis kiekvienai esybei, deployment etapais su feature flag'ais.
Šeši modernizavimo šablonai
Kiekvienas iš jų sprendžia konkrečią riziką. Daugumoje projektų jungiame kelis, parinkdami šabloną konkrečiam moduliui.
Strangler Fig
Palaipsnis senos sistemos „apraizgymas" naujais komponentais. Senas kodas toliau veikia, bet kiekvienas naujas funkcionalumas patenka į naują mikropaslaugą, o esamus modulius keičiame vieną po kito. Po 12-24 mėnesių senas monolitas išjungiamas.
Anti-corruption layer
Adapteris, ginantis naują kodą nuo senos sistemos keistenybių (neskaitomi laukų pavadinimai, keisti datų formatai, nesuderinami tipai). Visa „negraži" logika izoliuota vienoje vietoje — naujas kodas veikia su švariu domeno modeliu.
Database refactoring
Šablonai iš Refactoring Databases knygos (Ambler/Sadalage): expand-and-contract schemų migracijai, duomenų validacija prieš senų stulpelių pašalinimą, lygiagretus abiejų schemų palaikymas aplikacijos migracijos metu.
Branch by abstraction
Abstrakcijos sluoksnio įvedimas aplink seną komponentą, lygiagretus naujo komponento įgyvendinimas, palaipsnis perjungimas nuo 0% iki 100% srauto (feature flag). Be „big bang" diegimo.
Shadow mode
Naujas kodas paleidžiamas lygiagrečiai su senu — abu apdoroja tas pačias užklausas, bet tik seno rezultatai pasiekia vartotoją. Rezultatai palyginami offline. Patvirtinus suderinamumą (paprastai 2-4 savaitės) perjungiame srautą į naują kodą.
Event sourcing migracijai
Įrašome verslo įvykių srautą iš senos sistemos ir atkuriame jį naujoje. Leidžia preliminariai validuoti naują architektūrą be produkcijos rizikos, taip pat grįžti į bet kokią istorinę būseną.
Tipinis modernizavimo grafikas
Vidutinei sistemai (monolitas ~200 tūkst. kodo eilučių, 5-10 verslo modulių):
- 1 mėnuo: Discovery ir dokumentacija. Architektūros reverse engineering, priklausomybių mapping'as, duomenų srautų identifikavimas, verslo procesų dokumentavimas padedant verslo žmonėms.
- 2 mėnuo: Tikslinė architektūra ir bandomasis projektas. Naujos architektūros projektas, technologijų pasirinkimas, bandomasis paprastam moduliui (proof of concept). Pirmasis požiūrio validavimas.
- 3-4 mėnesiai: Pirmojo produkcinio modulio išskyrimas. Strangler Fig šablonas, shadow mode 2-3 savaitėms, srauto perjungimas, hypercare. Pirmoji reali verslo vertė.
- 5-12 mėnesiai: Iteracinis kitų modulių išskyrimas. Kiekvienas 4-6 savaičių cikle: refaktoringas → testai → shadow → produkcija → hypercare. Nuolatinis proceso tobulinimas, laiko redukcija kitiems moduliams.
- 12-18 mėnesiai: Duomenų migracija ir monolito atsisakymas. Kai visi kritiniai moduliai išskirti, finalizuojame istorinių duomenų migraciją, išjungiame seną sistemą, archyvuojame. Švenčiame.
Sena sistema vs. modernizuota
| Aspektas | Legacy sistema (paprastai) | Po modernizavimo |
|---|---|---|
| Naujos funkcijos diegimo laikas | 4-8 savaitės (didelė regresijos rizika) | 3-7 dienos (automatiniai testai minimizuoja riziką) |
| Testų padengimas | 5-15% (arba nėra) | >80%, CI/CD pipeline |
| Kūrėjų prieinamumas | Mažas (pasenusi technologija) | Didelis (populiarūs, šiuolaikiniai stack'ai) |
| Sauga | Senos bibliotekos su CVE spragomis | OWASP skenavimas, gitleaks, automatiniai atnaujinimai |
| Mastelio keitimas | Vertical (daugiau resursų monolitui) | Horizontal (konkrečių mikropaslaugų skalavimas) |
| Stebimumas | Žurnalai failuose, be metrikų | Prometheus + Grafana + Sentry + SIEM |
| Compliance (BDAR, EU AI Act, ISO 27001) | Reikalaujanti, brangi įrodyti | Įdiegta į architektūrą, paruošta auditui |
Šešios tipinės rizikos — ir kaip jas adresuojame
Rizika: Testų trūkumas legacy sistemoje
Mažinimas: Pirmiausia sukuriame charakteristinius testus (capture tests) — įrašome esamą sistemos elgesį pagal produkcinius žurnalus ir srauto įrašus. Tik tada pradedame refaktoringą, su testais kaip apsauga.
Rizika: Žinios sukauptos vienam asmeniui („truck factor 1")
Mažinimas: Žinių perdavimas prasideda pirmą projekto savaitę. Visi susitikimai su sistemą žinančiu asmeniu įrašomi ir transkribuojami, pagrindiniai procesai dokumentuojami, architektūriniai sprendimai pagrindžiami. Po projekto visa komanda supranta sistemą.
Rizika: Laikinas komandos sulėtėjimas
Mažinimas: Pirmuosius 2-3 mėnesius komanda išlaiko seną sistemą + kuria naują. Natūralus pokyčių tempo sulėtėjimas. Mažiname jį: prioritetas pakeitimams, patenkantiems tik į naują sistemą, freeze žemo prioriteto pakeitimams seno kodo.
Rizika: Duomenų migracija
Mažinimas: Kiekviena duomenų migracija turi tris fazes: dry-run (su produkcijos kopija), staging (testavimo aplinkoje su tikru duomenų masteliu), produkcija (aptarnavimo lange arba inkrementiškai). Rollback planas paruoštas prieš pradžią.
Rizika: Organizacinis pasipriešinimas
Mažinimas: Komunikacija su verslu nuo pirmos dienos: kodėl modernizavimas, kas pasikeis vartotojui, koks grafikas, kaip matuojame sėkmę. Pirmoji iteracija parenkama taip, kad greitai parodytų apčiuopiamą vertę (pvz., naujas UI ar greitesnė ataskaita).
Rizika: Kaštų neįvertinimas
Mažinimas: Discovery (1-2 savaitės) prieš projekto kainavimą. 2-3 savaičių iteracijos su konkrečiais pristatomais rezultatais — lengviau pakoreguoti kursą nei ilgame „viskas iš karto" tipo projekte. Biudžetas su 20-30% buferiu nenumatytiems atvejams.
Dažniausiai užduodami klausimai
Kas yra legacy sistema?
Kodėl verta modernizuoti, jei sistema veikia?
Ar ne paprasčiau viską parašyti iš naujo?
Ar modernizavimas reikalauja verslo prastovų?
Kiek trunka tipinis modernizavimas?
Iš kokių technologijų migruojame dažniausiai?
Kas su esamomis integracijomis su kitomis sistemomis?
Kaip ribojate verslo riziką?
Kas su sistemos dokumentacija, kurios nėra?
Kokie modernizavimo kaštai palyginus su senos sistemos priežiūra?
Pradėkime nuo audito
Savaitės techninis auditas: dabartinės būklės mapping'as, skubiausių modernizavimo sričių identifikavimas, etapinis planas su konkrečiais verslo efektais pirmojoje iteracijoje.