Jako vyp­nout a zap­nout jadernou elek­trár­nu. Na migraci sto­letí pra­co­v­ala stov­ka hrdinů

Sporožiro přetr­va­lo až do porev­olučního období, kdy ho Spořitel­na časem převed­la na osob­ní účet a při­dala řadu dalších služeb. S pos­tup­ným vylepšováním bankovní nabíd­ky bylo ale nut­né zásad­ně mod­ern­i­zo­vat IT sys­témy, které sporožiro na pozadí poháněly.

Leg­endární bankovní pro­dukt něko­lik desetiletí fun­go­val na takz­vaném main­fra­mu. Šlo o velký sálový mono­l­i­tický počí­tač, jenž vynikal vysok­ou spolehlivostí a sta­bil­i­tou. Vyro­bi­la ho amer­ická společnost IBM, která main­framy ve výrazně mod­ern­i­zo­vané podobě dělá dodnes. Původ­ní main­framy byly svého času tech­no­log­icky pokročilé, pos­tu­pem doby se z nich ale staly lega­cy prvky brzdící rozvoj byznysu.

„Nebyli jsme schop­ni zpra­cov­á­vat poža­davky, jako jsou nové typy bankovních účtů, potřeb­né funkce nebo leg­isla­ti­va. Prob­lem­at­ické bylo i napo­jení na další interní tech­nolo­gie,“ popisu­je Jaroslav Rych­na, který v České spořitel­ně vede sek­ci takz­vaných core sys­témů.
​„Tech­nolo­gie kolem main­fra­mu za sebou měla desítky let vývo­je, což je něco, do čeho nechcete moc sahat. Sko­ro se bojíte podí­vat na zdro­jový kód, aby se nerozbil.“

A další prob­lém: sporožiro bylo nap­sané v jazyce PL/I a COBOL.
To je věc, která dnes mezi mladý­mi pro­gramá­to­ry tlačeni­ci nevyvolá. Na školách se ten­to jazyk dávno neučí a mno­ho lidí, kteří s ním pra­co­v­ali, je v důchodu. Spořitel­na tedy musela roz­jet migraci na mod­erní jádro. Jak­mile bylo hoto­vo, část interních odborníků na COBOL skutečně do důchodu odešla. ​„Kdy­by­chom do mod­ern­izace šli o pět či deset let později, máme polov­inu týmu a jsme bez potřeb­ných znalostí,“ kon­statu­je Rychna.

Migrace core sys­témů je citlivá věc. Jde o jakési účet­ní jádro banky sloužící ke zpra­cov­ání plateb, držení zůs­tatků, provozu účtů a podob­ně. Core spadá do kat­e­gorie busi­ness či mis­sion crit­i­cal sys­témů, bez nichž ban­ka nemůže fun­go­vat. Výpad­ky mají vliv zejmé­na na rep­utaci společnos­ti. Ideál­ní stav je, když o jádru nikdo neví, pro­tože vše prostě funguje.

Během migrace z main­fra­mu se pro­to roz­jel sys­tem­at­ický a asi tři a půl roku trva­jící pro­ces. Spořitel­na vedle stá­va­jícího lega­cy sys­té­mu začala para­lel­ně rozšiřo­vat nový core. Ban­ka už v té době měla sys­tém, na němž běže­ly hypotéky a firem­ní účty. Byl nap­saný v jazyce PL/SQL od společnos­ti Ora­cle, i pro­to se při migraci sporoži­ra zvo­lil právě ten­to soft­warový stack.

„První rok a půl jsme ana­ly­zo­vali, co původ­ní sys­tém umí, jak se obsluhu­je a jak moc je propo­jený s celou bank­ou. Vytvářeli jsme design nás­tupce. S drob­ným zpožděním za analýza­mi jsme začali vyví­jet funkce do nového jádra a po roce a půl jsme začali připravo­vat migraci,“ vzpomíná Rychna.

Jed­nou z věcí, které bylo nut­né vyřešit, byla mono­li­tičnost sys­té­mu. V době migrace neex­is­to­valy tech­nolo­gie jako Dock­er, pomocí nichž je možné vyčlen­it aplikace do samostat­ně fun­gu­jících celků. Bylo nut­né velký sys­tém ​„rozbít“ do funkcí, které šly do určité míry izolo­vat.
Šlo napřík­lad vytvořit sys­tém, jak se chová běžný účet, a k němu přiřa­dit funkce. Pak bylo možné řešit, jak se vůči běžné­mu účtu chova­jí insol­vence, exekuce a další části. Tak­to se pos­tup­ně složi­la celá skládačka.

Po roce a půl se zača­lo s migrací dat. Neš­lo ovšem o převod typu tab­ul­ka – tab­ul­ka. Původ­ní sporožiro využí­va­lo data­bá­zovou tech­nologii DB2, kter­ou ste­jně jako main­frame vytvoři­lo IBM. PL/SQL v novém jádru je nicméně spo­jený s data­bází Ora­clu, což zna­mená, že data­báze spolu nej­sou kom­pat­i­bil­ní a pracu­jí s jiný­mi datový­mi strukturami.

Core tým ve Spořitel­ně musel vyro­bit převod­ní můstky a export dat z DB2. Na druhé straně se v Ora­clu vytvoři­ly pro­ce­dury pro nata­hování dat a násled­ný import do nového coru. ​„Šel­mostroj“ uprostřed dostal syrová data, před­připrav­il je, začal v novém sys­té­mu volat byznysové pro­ce­dury a provedl val­i­dace. Společně s tím proběh­lo masivní refak­torování kódu, přep­sáno bylo v pod­statě všechno.

Migrace se v začátcích dělala na testo­vacích účtech. Až pak se moh­lo pře­jít na ostrý převod s tím, že se jelo ve vlnách. Ta ini­ci­ační obsa­ho­vala padesát tisíc účtů. Druhá už si trou­fla na jeden mil­ion a třetí na necelé dva mil­iony účtů. Vždy se pra­co­v­a­lo o vík­endech. Tým vyp­nul celou banku a roz­jel pro­ces migrace jed­na ku jed­né.
​„V té době jsme si dělali legraci, že je to jako vypínání a zapínání ato­m­ové elek­trárny,“ smě­je se Rychna.

Výsled­kem je core sys­tém, na kterém Česká spořitel­na jede už něko­lik let. Jádro je opět postaveno on-premise. Běží na serverech vlast­něných a provo­zo­vaných Česk­ou spořitel­nou v něko­li­ka datových cen­trech, a to za využití desítek pro­ce­sorů IBM Pow­er na jeden server.

Tady by bylo dobré se zas­tavit u Ora­clu. Z dnešního pohle­du nemusí jít nut­ně o nejvíc sexy star­tupovou tech­nologii, ale má jed­nu zásad­ní vlast­nost: je to sta­bil­ní a enter­prise-ready řešení. Data­báze Ora­clu dokáže zpra­cov­á­vat mil­iony transakcí naráz. V pří­padě Spořitel­ny jsou to mil­iony transakcí za min­u­tu a desítky ter­aba­jtů držených v živém sys­té­mu s desítka­mi tisíc tabulek.

A tok dat se nezpo­ma­lu­je, naopak. Transakce už neprobíha­jí nára­zově, ale instant­ně. Lidé také čím dál více dáva­jí před hotovostí před­nost plateb­ním kartám nebo službám jako Google Pay a Apple Pay. ​„Důležitá je pro nás udržitel­nost a sta­bili­ta. To je to hlavní, o co nám jde. Nelze použí­vat aktuál­ně nejvíce trendy řešení, které není stavěno pro naše úče­ly a na které nelze sehnat lidi,“ při­b­ližu­je Rychna.

Samot­ný core slouží jako pod­vozek, nad kterým je postave­na vrst­va inte­grací. Ty zprostřed­ková­va­jí plat­for­mu napřík­lad pro­duk­tovým týmům a front-endovým aplikacím. Kromě Ora­clu se inte­gru­jí služ­by jako Kaf­ka a další. V rám­ci Spořitel­ny je k dis­pozi­ci inte­grační kat­a­log, takže je možné vidět, jaké služ­by jsou pro uži­vatele vys­tave­ny a kdo je poskytuje.

Sys­tém je také postaven tak, aby zák­lad­ní služ­by typu zobrazení zůs­tatku na účtu fun­go­valy i v době údrž­by. V data­bázi jsou samostat­ná sché­ma­ta s obrazem zůs­tatků, která se syn­chro­nizu­jí se zbytkem. Jak­mile se na back-endu nasazu­jí změny, mod­ul nedotčeně běží a v pod­statě fun­gu­je jako snap­shot. Vůči svě­tu je stále aktuál­ní. Když se odstavený sys­tém nahodí do provozu, dojde k rych­lé syn­chro­nizaci. Je to podob­né kar­tovým cen­trům, kdy jste pořád schop­ni platit kar­tou, i když je ban­ka dole.

Na migraci se podílel zhru­ba stočlen­ný tým ana­lytiků, designérů a vývo­jářů. V urči­tou dobu se ale změ­na dotk­la prak­ticky všech zaměst­nanců banky. Bylo nut­né změnit pro­cesy, udělat nové front-endy, aplikační rozhraní (API) nebo dash­boardy. Výsled­kem je kromě jiného snížení poč­tu back-endových tech­nologií, aby provoz nebyl příliš drahý a v rám­ci IT nevznikla zbytečná komplexita.

Tým v České spořitel­ně díky migraci z main­fra­mu vytvořil frame­worky, pomocí nichž je možné další převody dělat mno­honá­sob­ně rych­le­ji. Spořitel­na nedávný převod klien­tů Sber­bank a Hel­lo bank! zvlád­la v řádech měsíců.