Pillar lapa
Legacy sistēmu modernizācija
Inkrementāla monolīta refaktorēšana mikropakalpojumos, migrācija no novecojušām tehnoloģijām uz modernām, pārvietošana uz mākoni — bez biznesa dīkstāves, ar atcelšanas plānu un pilnu audita pierakstu.
Katram uzņēmumam ir kāda legacy sistēma. Dažiem to ir vairākas. Grāmatvedības aplikācija no 2008. gada, kas kaut kā darbojas. CRM, ko rakstījuši konsultanti, kurus vairs neviens neatceras. Noliktava Access vidē. Kādreiz katru no tām būs jānomaina — jautājums nav vai, bet kad un kā.
Legacy sistēmu modernizācija ir viens no grūtākajiem IT projektu veidiem. Tas prasa līdzsvarot trīs spēkus: biznesa nepārtrauktības saglabāšanu (sistēmai jādarbojas visu laiku), modernu tehnoloģiju ieviešanu (mikropakalpojumi, mākonis, MI) un riska kontroli (katra refaktorēšana var sabojāt kaut ko, kas darbojies gadiem).
Kāpēc nepietiek ar „pārrakstīt no nulles"?
Pēc mūsu pieredzes 9 no 10 veiksmīgām modernizācijām ir inkrementāla refaktorēšana, nevis rewrite. Rewrite vilina ar konceptuālu vienkāršību („sāksim ar tīru lapu"), bet praksē tām ir trīs fundamentālas problēmas:
- Neredzama biznesa loģika. Vecā sistēma satur gadiem ilgi uzkrātus biznesa noteikumus — īpašus nosacījumus lielākajiem klientiem, nodokļu atvieglojumus konkrētām nozarēm, apvedceļus 2015. gada regulām. Lielākā daļa nav dokumentēta. Rewrite tos visus jāatkārto no cilvēku atmiņas vai koda analīzes.
- Darba dublēšana. Jaunās sistēmas rakstīšanas laikā bizness joprojām prasa izmaiņas vecajā (regulas, jauni klienti, mazas kļūdas). Komanda vai nu dublē darbu (izmaiņas divās vietās), vai iesaldē veco sistēmu (biznesa risks).
- Big bang deployment. Pēc gada darba jaunā sistēma ir „gandrīz gatava". Visu lietotāju pārslēgšana vienā naktī rada milzīgu risku. Katra neparedzēta problēma nozīmē atgriešanos pie vecās sistēmas, komandas morāles zudumu, biznesa uzticības iedragāšanu.
Inkrementāla refaktorēšana (visbiežāk pēc Strangler Fig šablona) atrisina visus trīs: biznesa loģika tiek atklāta pakāpeniski, viens patiesības avots katrai entītijai, izvietošana pakāpēs ar feature flags.
Sešas modernizācijas šablonu
Katrs no tiem atrisina konkrētu risku. Vairumā projektu mēs apvienojam vairākus, izvēloties šablonu konkrētajam modulim.
Strangler Fig
Pakāpeniska vecās sistēmas „apvīšana" ar jauniem komponentiem. Vecais kods turpina darboties, bet katra jauna funkcionalitāte nonāk jaunā mikropakalpojumā, un esošie moduļi tiek nomainīti viens pēc otra. Pēc 12-24 mēnešiem vecais monolīts tiek izslēgts.
Anti-corruption layer
Adapteris, kas aizsargā jauno kodu no vecās sistēmas dīvainībām (nesaprotami lauku nosaukumi, dīvaini datumu formāti, nekonsekventi tipi). Visa „neglītā" loģika ir izolēta vienuviet — jaunais kods strādā ar tīru domēna modeli.
Database refactoring
Šabloni no grāmatas Refactoring Databases (Ambler/Sadalage): expand-and-contract shēmas migrācijai, datu validācija pirms veco kolonnu dzēšanas, abu shēmu paralēla uzturēšana aplikācijas migrācijas laikā.
Branch by abstraction
Abstrakcijas slāņa ieviešana ap veco komponentu, paralēla jauna komponenta ieviešana, pakāpeniska pārslēgšana no 0% uz 100% trafika (feature flag). Bez „big bang" izvietošanas.
Shadow mode
Jaunais kods palaists paralēli vecajam — abi apstrādā tos pašus pieprasījumus, bet lietotājam nonāk tikai vecā rezultāti. Rezultāti tiek salīdzināti offline. Pēc atbilstības apstiprināšanas (parasti 2-4 nedēļas) trafiku pārslēdzam uz jauno kodu.
Event sourcing migrācijai
Ierakstām biznesa notikumu plūsmu no vecās sistēmas un atskaņojam to jaunajā. Ļauj sākotnēji validēt jauno arhitektūru bez ražošanas riska un atgriezties pie jebkura vēsturiska stāvokļa.
Tipisks modernizācijas grafiks
Vidējai sistēmai (monolīts ~200 tūkst. koda rindu, 5-10 biznesa moduļi):
- 1. mēnesis: Discovery un dokumentācija. Arhitektūras reverse engineering, atkarību kartēšana, datu plūsmu identificēšana, biznesa procesu dokumentācija ar biznesa cilvēku palīdzību.
- 2. mēnesis: Mērķa arhitektūra un pilotprojekts. Jaunās arhitektūras dizains, tehnoloģiju izvēle, pilots vienkāršākajā modulī (proof of concept). Pirmā pieejas validācija.
- 3.-4. mēnesis: Pirmā ražošanas moduļa izdalīšana. Strangler Fig šablons, shadow mode 2-3 nedēļas, trafika pārslēgšana, hypercare. Pirmā reālā biznesa vērtība.
- 5.-12. mēnesis: Iteratīva nākamo moduļu izdalīšana. Katrs 4-6 nedēļu ciklā: refaktorēšana → testi → shadow → ražošana → hypercare. Pastāvīga procesa uzlabošana, laika samazināšana nākamajiem moduļiem.
- 12.-18. mēnesis: Datu migrācija un monolīta atteikšana. Kad visi kritiskie moduļi izdalīti, pabeidzam vēsturisko datu migrāciju, izslēdzam veco sistēmu, arhivējam. Svinam.
Vecā sistēma vs. modernizētā
| Aspekts | Legacy sistēma (parasti) | Pēc modernizācijas |
|---|---|---|
| Jaunas funkcijas izvietošanas laiks | 4-8 nedēļas (augsts regresijas risks) | 3-7 dienas (automātiskie testi minimizē risku) |
| Testu pārklājums | 5-15% (vai nav) | >80%, CI/CD plūsmā |
| Izstrādātāju pieejamība | Maza (novecojusi tehnoloģija) | Liela (populāri, moderni tehnoloģiju stack) |
| Drošība | Vecas bibliotēkas ar CVE caurumiem | OWASP skenēšana, gitleaks, automātiski atjauninājumi |
| Mērogošana | Vertikāla (vairāk resursu monolītam) | Horizontāla (konkrētu mikropakalpojumu mērogošana) |
| Novērojamība | Žurnāli failos, bez metrikām | Prometheus + Grafana + Sentry + SIEM |
| Atbilstība (GDPR, EU AI Act, ISO 27001) | Prasīga, dārga pierādīšanai | Iebūvēta arhitektūrā, gatava auditam |
Seši tipiski riski — un kā tos adresējam
Risks: Trūkst testu legacy sistēmā
Mazināšana: Vispirms veidojam raksturojuma testus (capture tests) — ierakstām pašreizējo sistēmas uzvedību, balstoties uz ražošanas žurnāliem un trafika ierakstiem. Tikai tad sākam refaktorēšanu, ar testiem kā aizsardzību.
Risks: Zināšanas koncentrētas vienā cilvēkā („truck factor 1")
Mazināšana: Zināšanu pārnese sākas projekta pirmajā nedēļā. Visas sapulces ar sistēmu zinošo cilvēku tiek ierakstītas un transkribētas, galvenie procesi tiek dokumentēti, arhitektūras lēmumi pamatoti. Pēc projekta visa komanda saprot sistēmu.
Risks: Pagaidu komandas palēninājums
Mazināšana: Pirmajos 2-3 mēnešos komanda uztur veco sistēmu + būvē jauno. Dabisks izmaiņu tempa palēninājums. Mazinām to: prioritāte izmaiņām, kas nonāk tikai jaunajā sistēmā, freeze zema prioritāte izmaiņām vecajā kodā.
Risks: Datu migrācija
Mazināšana: Katrai datu migrācijai ir trīs fāzes: dry-run (uz ražošanas kopijas), staging (testa vidē ar reālu datu mērogu), ražošana (servisa logā vai inkrementāli). Atcelšanas plāns gatavs pirms starta.
Risks: Organizatoriskā pretestība
Mazināšana: Komunikācija ar biznesu no pirmās dienas: kāpēc modernizācija, kas mainīsies lietotājam, kāds grafiks, kā mēs mērīsim panākumus. Pirmā iterācija tiek izvēlēta tā, lai ātri parādītu taustāmu vērtību (piem., jauns UI vai ātrāka atskaite).
Risks: Izmaksu nenovērtējums
Mazināšana: Discovery (1-2 nedēļas) pirms projekta cenas. 2-3 nedēļu iterācijas ar konkrētiem piegādājamiem rezultātiem — vieglāk koriģēt kursu nekā ilgā projektā „viss uzreiz". Budžets ar 20-30% rezervi neparedzētiem gadījumiem.
Biežāk uzdotie jautājumi
Kas ir legacy sistēma?
Kāpēc modernizēt, ja sistēma darbojas?
Vai nav vieglāk uzrakstīt visu no jauna?
Vai modernizācija prasa biznesa dīkstāvi?
Cik ilgi parasti ilgst modernizācija?
No kādām tehnoloģijām migrējam visbiežāk?
Kā ar esošajām integrācijām ar citām sistēmām?
Kā ierobežojat biznesa risku?
Kā ar sistēmas dokumentāciju, kuras nav?
Kādas ir modernizācijas izmaksas salīdzinājumā ar vecās sistēmas uzturēšanu?
Sākam ar auditu
Nedēļas tehniskais audits: pašreizējā stāvokļa kartēšana, steidzamāko modernizācijas jomu identificēšana, pakāpenisks plāns ar konkrētiem biznesa rezultātiem pirmajā iterācijā.