Pillar page

Sistema zaharren modernizazioa

Monolito-mikrozerbitzuetara berridazketa inkrementala, teknologia zaharkituak modernoetara migrazioa, hodei-migrazioa — negozio-geldialdirik gabe, rollback plana eta auditoria-arrasto osoarekin.

Ondare-sistemaren auditoria Zerbitzu guztiak

Enpresa orok ondare-sistemaren bat du. Batzuek hainbat dituzte. 2008ko kontabilitate-aplikazio bat oraindik nolabait funtzionatzen duena. Inork gogoratzen ez duen aholkulariek idatzitako CRM bat. Access-en exekutatzen den biltegi bat. Bakoitza azkenean ordeztu behar da — galdera ez da noiz, baizik eta noiz eta nola.

Ondare-sistemen modernizazioa IT proiektu mota zailenetako bat da. Hiru indar orekatu behar dira: negozio-jarraitutasuna (sistemak denbora osoan funtzionatzen jarraitu behar du), teknologia modernoak sartzea (mikrozerbitzuak, hodeia, AA) eta arrisku-kontrola (berridazketa bakoitzak urteetan funtzionatu duen zerbait apur dezake).

Zergatik ez „zerotik berridatzi" soilik?

Gure esperientziaren arabera, 10 modernizazio arrakastatsuetatik 9 berridazketa inkrementala da, ez rewrite. Rewrite-ak kontzeptualki tentagarriak dira („orrialde garbiarekin hasiko gara"), baina praktikan hiru oinarrizko arazo dituzte:

  • Negozio-logika ikusezina. Sistema zaharrak urteetako negozio-arauak ditu — bezero handienen baldintza bereziak, sektore espezifikoetarako zerga-salbuespenak, 2015eko araudirako konponbideak. Gehiena dokumentatu gabe dago. Rewrite batek guztiak berreraiki behar ditu pertsonen oroimenetik edo kode-analisitik.
  • Lan bikoiztua. Sistema berria idazten den bitartean, negozioak zaharrean aldaketak eskatzen ditu (araudiak, bezero berriak, akats txikiak). Taldeak lana bikoizten du (aldaketak bi lekutan) edo sistema zaharra izozten du (negozio-arriskua).
  • Big bang deployment. Urtebeteko lanaren ondoren, sistema berria „ia prest" dago. Erabiltzaile guztiak gau bakar batean aldatzeak arrisku monumentala sortzen du. Ustekabeko arazo orok sistema zaharrera itzultzea, taldearen moralaren galera eta negozio-konfiantzaren higadura esan nahi du.

Berridazketa inkrementalak (normalean Strangler Fig ereduari jarraituz) hirurak konpontzen ditu: negozio-logika pixkanaka aurkitzen da, entitate bakoitzeko egiaren iturri bakarra, faseetan hedapena feature flag-ekin.

Sei modernizazio-eredu

Bakoitzak arrisku espezifiko bati erantzuten dio. Proiektu gehienetan batzuk konbinatzen ditugu, modulu bakoitzeko eredua aukeratuz.

Strangler Fig

Sistema zaharra osagai berriekin pixkanaka „inguratzea". Kode zaharrak funtzionatzen jarraitzen du, baina eginbide berri oro mikrozerbitzu berri batera doa eta lehendik dauden moduluak banan-banan ordezkatzen dira. 12-24 hilabeteren ondoren monolito zaharra itzaltzen da.

Anti-corruption layer

Sistema zaharraren bitxikeriak (eremu-izen irakurtezinak, data-formatu arraroak, mota inkoherenteak) babesten dituen egokitzailea. Logika „itsusi" guztia leku batean isolatuta — kode berriak domeinu-eredu garbi batean lan egiten du.

Datu-baseen berridazketa

Refactoring Databases liburuko (Ambler/Sadalage) ereduak: expand-and-contract eskema-migraziorako, datuen baliozkotzea zutabe zaharrak askatu aurretik, bi eskemak paraleloan exekutatzea aplikazioaren migrazioan zehar.

Branch by abstraction

Osagai zaharraren inguruko abstrakzio-geruza bat sartzea, osagai berria paraleloan inplementatzea, trafikoa pixkanaka %0tik %100era aldatzea (feature flag). „Big bang" hedapenik gabe.

Shadow mode

Kode berria zaharrarekin batera exekutatzen da — biek prozesatzen dituzte eskaera berberak, baina sistema zaharreko emaitzak baino ez dira iristen erabiltzaileari. Emaitzak offline konparatzen dira. Bateragarritasuna baieztatu ondoren (tipikoki 2-4 aste) trafikoa kode berrira aldatzen dugu.

Event sourcing migraziorako

Sistema zaharreko negozio-gertaeren korrontea grabatzen dugu eta berrian erreproduzitzen dugu. Honek arkitektura berriaren aurretiazko baliozkotzea ahalbidetzen du ekoizpen-arriskurik gabe, eta edozein egoera historikora itzultzeko gaitasuna.

Modernizazio-egutegi tipikoa

Tamaina ertaineko sistema baterako (~200 mila kode-lerroko monolitoa, 5-10 negozio-modulu):

  1. 1. hilabetea: Discovery eta dokumentazioa. Arkitekturaren reverse engineering, mendekotasunen mapaketa, datu-fluxuen identifikazioa, negozio-prozesuen dokumentazioa negozio-interesdunen laguntzaz.
  2. 2. hilabetea: Helburu-arkitektura eta pilotua. Arkitektura berriaren diseinua, teknologien hautaketa, modulurik sinpleenean pilotua (proof of concept). Hurbilketaren lehen baliozkotzea.
  3. 3-4. hilabeteak: Lehen ekoizpen-modulua moztea. Strangler Fig eredua, shadow mode 2-3 astetan, trafiko-aldaketa, hypercare. Lehen negozio-balio erreala.
  4. 5-12. hilabeteak: Ondoz ondoko moduluak iteratiboki moztea. Bakoitza 4-6 asteko zikloan: berridazketa → probak → shadow → ekoizpena → hypercare. Prozesuaren etengabeko hobekuntza, modulu bakoitzeko denbora-murrizketa.
  5. 12-18. hilabeteak: Datu-migrazioa eta monolitoaren erretiratzea. Modulu kritiko guztiak moztu ondoren, datu historikoen migrazioa amaitzen dugu, sistema zaharra itzaltzen dugu, artxibatzen dugu. Ospatu.

Ondare-sistema vs. modernizatua

AlderdiaOndare-sistema (tipikoa)Modernizazioaren ondoren
Eginbide berri bat bidaltzeko denbora4-8 aste (erregresio-arrisku handia)3-7 egun (proba automatizatuek arriskua minimizatzen dute)
Proba-estaldura%5-15 (edo bat ere ez)>%80, CI/CD pipelinen
Garatzaileen erabilgarritasunaBaxua (teknologia zaharkitua)Altua (stack ezagunak, modernoak)
SegurtasunaLiburutegi zaharrak konpondu gabeko CVErekinOWASP eskaneatzea, gitleaks, eguneratze automatikoak
EskalatzeaBertikala (monolitoarentzat baliabide gehiago)Horizontala (mikrozerbitzu espezifikoen eskalatzea)
BehagarritasunaErregistroak fitxategietan, metrikarik gabePrometheus + Grafana + Sentry + SIEM
Compliance (DBEO, EU AI Act, ISO 27001)Exijentea, frogatzeko garestiaArkitekturan integratua, auditoriarako prest

Sei arrisku tipiko — eta nola kudeatzen ditugun

Arriskua: Probarik ez ondare-sisteman

Mitigazioa: Lehenik karakterizazio-probak eraikitzen ditugu (capture tests) — sistemaren uneko portaera grabatzen dugu ekoizpen-erregistroetan eta trafiko-grabazioetan oinarrituta. Gero baino ez dugu berridazketa hasten, probak segurtasun-sare gisa.

Arriskua: Pertsona batean kontzentratutako ezagutza („truck factor 1")

Mitigazioa: Ezagutzaren transferentzia proiektuaren lehen astean hasten da. Sistema ezagutzen duen pertsonarekin egiten diren bilera guztiak grabatu eta transkribatu egiten dira, funtsezko prozesuak dokumentatu, arkitektura-erabakiak justifikatu. Proiektuaren ondoren talde osoak ulertzen du sistema.

Arriskua: Taldearen behin-behineko moteltzea

Mitigazioa: Lehen 2-3 hilabeteetan taldeak sistema zaharra mantentzen du + berria eraikitzen du. Aldaketa-abiaduran moteltze naturala. Honela arintzen dugu: sistema berrira soilik doazen aldaketei lehentasuna emanez, kode zaharrean lehentasun txikiko aldaketak izoztuz.

Arriskua: Datu-migrazioa

Mitigazioa: Datu-migrazio bakoitzak hiru fase ditu: dry-run (ekoizpen-kopia batean), staging (proba-ingurunean benetako eskalako datuekin), ekoizpena (zerbitzu-leihoan edo inkrementalki). Rollback plana hasi aurretik prest.

Arriskua: Erakunde-erresistentzia

Mitigazioa: Negozioarekin komunikazioa lehen egunetik: zergatik modernizatzen dugun, zer aldatzen den erabiltzailearentzat, zein den egutegia, nola neurtzen dugun arrakasta. Lehen iterazioa balio ukigarria azkar erakusteko aukeratzen da (adib. UI berria edo txosten azkarragoa).

Arriskua: Kostuaren azpiestimazioa

Mitigazioa: Discovery (1-2 aste) proiektuaren prezioaren aurretik. 2-3 asteko iterazioak entregagai zehatzekin — errazagoa da ibilbidea zuzentzea „dena batera" proiektu luze batean baino. Aurrekontua %20-30eko bufferrekin aurreikusi gabekoetarako.

Maizen egiten diren galderak

Zer da ondare-sistema bat?
Ondare-sistema bat erakundean oraindik exekutatzen ari den softwarea da, baina teknologia zaharkitu batean oinarritzen da, zor tekniko sakona du, probarik ez du, dokumentaziorik ez du edo idatzi zuen garatzailerik ez du. Adibide klasikoak: PHP 5.x edo .NET Framework 4.0 aplikazio monolitikoa, migraziorik gabeko datu-basea, jQuery frontend-a, FTP hedapena. Funtzionatzen du, baina aldaketa bakoitza arrisku eta kostu handikoa da.
Zergatik modernizatu sistemak funtzionatzen badu?
Hiru arrazoi nagusi. Lehenik: mantentze-kostua esponentzialki hazten da sistemaren adinarekin — gero eta garatzaile gutxiagok ezagutzen dute teknologia, aldaketa bakoitzak gehiago hartzen du, akats bakoitzak eremu zabalagoa du. Bigarrenik: segurtasun-arriskua — framework zaharrek konpondu gabeko ahultasunak dituzte, hornitzailearen euskarririk ez dute, DBEO/ISO 27001ekin betetzen ez dute. Hirugarrenik: negozio-hazkundearen blokeoa — eskakizun berriak (mugikorra, API, integrazioak, AA) zaila edo ezinezkoa da gehitzea.
Ez al da errazagoa dena hutsetik berridaztea?
„Berridatzi vs. berridazketa" dilema klasikoa. Berridazketak kontzeptualki tentagarriak dira, baina praktikan planifikatutakoa baino 2-3 aldiz luzeagoak dira, proiektua negozio-logika ikusezina berreraikitzeko pisuaren azpian itoz doa, eta bitartean sistema zaharra garatzen jarraitu behar da (lan bikoiztua). Gure esperientziatik: 10 modernizazio arrakastatsuetatik 9 berridazketa inkrementala da (Strangler Fig eredua) — sistema zaharraren zatiak pixkanaka ordezkatzea negozio-jarraitutasuna mantenduz. Rewrite-ak sistema oso txikietarako bakarrik du zentzua.
Modernizazioak negozio-geldialdia eskatzen al du?
Proiektu gehienetan, ez. Osagaiak „bizirik" trukatzea ahalbidetzen duten ereduak erabiltzen ditugu: blue-green deployment, feature flags, dark launches, kode zaharra eta berria paraleloan exekutatzea emaitzen konparaketarekin (shadow mode). Zerbitzu-leiho laburrak beharrezkoak izan daitezke eskema-aldaketa esanguratsuak dituzten datu-base migrazioetarako, baina aldez aurretik planifikatzen ditugu (tipikoki gauez, asteburuan) rollback plan osoarekin.
Zenbat irauten du modernizazio tipikoak?
Eskalaren araberakoa da. Monolitoaren modulu bakar bat mikrozerbitzu gisa moztua: 1-2 hilabete. Modernizazio handiagoa (5-10 modulu, datu-base berria, API berria): 6-12 hilabete 2-3 asteko iterazioetan. Enpresa-mailako monolito baten eraldaketa osoa: 18-36 hilabete, baina negozio-balioa lehen iterazioaren ondoren agertzen da — moztutako modulu bakoitzak berehala onurak ematen ditu (aldaketa azkarragoak, arrisku txikiagoa, behagarritasun hobea).
Zer teknologietatik migratzen dugu sarrien?
Bide ohikoenak: PHP 5/7 → PHP 8 edo Python (FastAPI) edo Node.js (Express/Fastify). .NET Framework 4.x → .NET 8 edo Java/Spring Boot. Java EE (JBoss/WebSphere) → Spring Boot edo Quarkus. jQuery + monolithic templates → React/Vue/Astro. Oracle DB → PostgreSQL (lizentzia-aurrezpen esanguratsuak). On-premise → hodeia (AWS, Azure, GCP, hodei pribatu lokala).
Eta beste sistemekin lehendik dauden integrazioak?
Lehendik dagoen integrazio oro discovery fasean mapatzen da. Migrazio-planak hau hartzen du: lehendik dauden kontratuen babesa (barneko eta kanpoko bezeroek ez dute aldaketarik nabaritzen), bertsioak sartzea (v1 kontratu zaharra, v2 berria), kontsumitzaileak v2-ra pixkanaka migratzea, ondoren v1 kentzea. Atzerako bateragarritasun osoa migrazioan zehar.
Nola murrizten duzue negozio-arriskua?
Bost geruza: 1) inkrementaltasuna — modulu bat aldi berean ordezkatzen dugu, ez dena batera; 2) karakterizazio-probak — berridazketaren aurretik sistemaren uneko portaera harrapatzen dugu (capture tests), eta gero egiaztatzen dute ezer ez dela apurtu; 3) feature flags — funtzionaltasun berria pixkanaka zabaltzen da (erabiltzaileen %1 → %10 → %50 → %100); 4) rollback plana hedapen bakoitzeko (<5 min); 5) hypercare ezarpenaren ondoren (monitorizazio intentsiboa 2-4 aste).
Eta existitzen ez den sistemaren dokumentazioa?
Ohiko ondare-arazoa. Proiektuaren lehen etapa: dokumentazioaren reverse engineering. AA agenteek kodea, datu-basearen eskema, ekoizpen-erregistroak aztertzen dituzte eta sortzen dituzte: arkitektura-diagrama, amaiera-puntuen zerrenda, mendekotasun-mapa, negozio-prozesuen deskribapenak. Dokumentazio hau gero negozio-jendearekin egiaztatzen da (kodetik ulertu dugun bezala ikusten al du prozesuak). Emaitza: dokumentazio osoa berridazketa hasi aurretik, modernizazio-proiekturako bakarrik ez, baita produktu-talderako ere baliagarria.
Nola konparatzen dira modernizazio-kostuak sistema zaharrari eustearekin?
Epe laburrean, modernizazioa mantenua baino garestiagoa da (berridazketa-inbertsioa + sistema zaharra paraleloan mantentzea). Break-even puntua (non sistema berria zaharra baino merkeagoa bihurtzen den mantentzeko) tipikoki 12-18 hilabeteren ondoren gertatzen da. Horren ondoren sistema berria: mantentzeko gutxiago kostatzen da (garatzaile gutxiago, automatizazio gehiago), aldaketa azkarragoak ahalbidetzen ditu (merkaturatze-denbora laburragoa), arriskua murrizten du (behagarritasun hobea, proba gehiago, akatsen isolamendua).

Has gaitezen auditoria batekin

Aste bateko auditoria teknikoa: uneko egoeraren mapaketa, modernizazio-arlo presaberenak identifikatzea, faseen plana lehen iterazioan negozio-emaitza zehatzekin.

Eskatu sistemaren auditoria Software garapena