Jako vypnout a zapnout jadernou elektrárnu. Na migraci století pracovala stovka hrdinů
Na jaře roku 1972 přišla do tehdejšího Československa revoluční věc. Česká spořitelna začala nabízet sporožiro, vůbec první osobní bankovní účet u nás, který postupně nahrazoval vkladní knížky.
Sporožiro přetrvalo až do porevolučního období, kdy ho Spořitelna časem převedla na osobní účet a přidala řadu dalších služeb. S postupným vylepšováním bankovní nabídky bylo ale nutné zásadně modernizovat IT systémy, které sporožiro na pozadí poháněly.
Legendární bankovní produkt několik desetiletí fungoval na takzvaném mainframu. Šlo o velký sálový monolitický počítač, jenž vynikal vysokou spolehlivostí a stabilitou. Vyrobila ho americká společnost IBM, která mainframy ve výrazně modernizované podobě dělá dodnes. Původní mainframy byly svého času technologicky pokročilé, postupem doby se z nich ale staly legacy prvky brzdící rozvoj byznysu.
„Nebyli jsme schopni zpracovávat požadavky, jako jsou nové typy bankovních účtů, potřebné funkce nebo legislativa. Problematické bylo i napojení na další interní technologie,“ popisuje Jaroslav Rychna, který v České spořitelně vede sekci takzvaných core systémů.
„Technologie kolem mainframu za sebou měla desítky let vývoje, což je něco, do čeho nechcete moc sahat. Skoro se bojíte podívat na zdrojový kód, aby se nerozbil.“
COBOL na smetišti dějin
A další problém: sporožiro bylo napsané v jazyce PL/I a COBOL.
To je věc, která dnes mezi mladými programátory tlačenici nevyvolá. Na školách se tento jazyk dávno neučí a mnoho lidí, kteří s ním pracovali, je v důchodu. Spořitelna tedy musela rozjet migraci na moderní jádro. Jakmile bylo hotovo, část interních odborníků na COBOL skutečně do důchodu odešla. „Kdybychom do modernizace šli o pět či deset let později, máme polovinu týmu a jsme bez potřebných znalostí,“ konstatuje Rychna.
Migrace core systémů je citlivá věc. Jde o jakési účetní jádro banky sloužící ke zpracování plateb, držení zůstatků, provozu účtů a podobně. Core spadá do kategorie business či mission critical systémů, bez nichž banka nemůže fungovat. Výpadky mají vliv zejména na reputaci společnosti. Ideální stav je, když o jádru nikdo neví, protože vše prostě funguje.
Během migrace z mainframu se proto rozjel systematický a asi tři a půl roku trvající proces. Spořitelna vedle stávajícího legacy systému začala paralelně rozšiřovat nový core. Banka už v té době měla systém, na němž běžely hypotéky a firemní účty. Byl napsaný v jazyce PL/SQL od společnosti Oracle, i proto se při migraci sporožira zvolil právě tento softwarový stack.
„První rok a půl jsme analyzovali, co původní systém umí, jak se obsluhuje a jak moc je propojený s celou bankou. Vytvářeli jsme design nástupce. S drobným zpožděním za analýzami jsme začali vyvíjet funkce do nového jádra a po roce a půl jsme začali připravovat migraci,“ vzpomíná Rychna.
Jednou z věcí, které bylo nutné vyřešit, byla monolitičnost systému. V době migrace neexistovaly technologie jako Docker, pomocí nichž je možné vyčlenit aplikace do samostatně fungujících celků. Bylo nutné velký systém „rozbít“ do funkcí, které šly do určité míry izolovat.
Šlo například vytvořit systém, jak se chová běžný účet, a k němu přiřadit funkce. Pak bylo možné řešit, jak se vůči běžnému účtu chovají insolvence, exekuce a další části. Takto se postupně složila celá skládačka.
Po roce a půl se začalo s migrací dat. Nešlo ovšem o převod typu tabulka – tabulka. Původní sporožiro využívalo databázovou technologii DB2, kterou stejně jako mainframe vytvořilo IBM. PL/SQL v novém jádru je nicméně spojený s databází Oraclu, což znamená, že databáze spolu nejsou kompatibilní a pracují s jinými datovými strukturami.
Tři a půl roku dlouhý proces
Core tým ve Spořitelně musel vyrobit převodní můstky a export dat z DB2. Na druhé straně se v Oraclu vytvořily procedury pro natahování dat a následný import do nového coru. „Šelmostroj“ uprostřed dostal syrová data, předpřipravil je, začal v novém systému volat byznysové procedury a provedl validace. Společně s tím proběhlo masivní refaktorování kódu, přepsáno bylo v podstatě všechno.
Migrace se v začátcích dělala na testovacích účtech. Až pak se mohlo přejít na ostrý převod s tím, že se jelo ve vlnách. Ta iniciační obsahovala padesát tisíc účtů. Druhá už si troufla na jeden milion a třetí na necelé dva miliony účtů. Vždy se pracovalo o víkendech. Tým vypnul celou banku a rozjel proces migrace jedna ku jedné.
„V té době jsme si dělali legraci, že je to jako vypínání a zapínání atomové elektrárny,“ směje se Rychna.
Výsledkem je core systém, na kterém Česká spořitelna jede už několik let. Jádro je opět postaveno on-premise. Běží na serverech vlastněných a provozovaných Českou spořitelnou v několika datových centrech, a to za využití desítek procesorů IBM Power na jeden server.
Tady by bylo dobré se zastavit u Oraclu. Z dnešního pohledu nemusí jít nutně o nejvíc sexy startupovou technologii, ale má jednu zásadní vlastnost: je to stabilní a enterprise-ready řešení. Databáze Oraclu dokáže zpracovávat miliony transakcí naráz. V případě Spořitelny jsou to miliony transakcí za minutu a desítky terabajtů držených v živém systému s desítkami tisíc tabulek.
A tok dat se nezpomaluje, naopak. Transakce už neprobíhají nárazově, ale instantně. Lidé také čím dál více dávají před hotovostí přednost platebním kartám nebo službám jako Google Pay a Apple Pay. „Důležitá je pro nás udržitelnost a stabilita. To je to hlavní, o co nám jde. Nelze používat aktuálně nejvíce trendy řešení, které není stavěno pro naše účely a na které nelze sehnat lidi,“ přibližuje Rychna.
Samotný core slouží jako podvozek, nad kterým je postavena vrstva integrací. Ty zprostředkovávají platformu například produktovým týmům a front-endovým aplikacím. Kromě Oraclu se integrují služby jako Kafka a další. V rámci Spořitelny je k dispozici integrační katalog, takže je možné vidět, jaké služby jsou pro uživatele vystaveny a kdo je poskytuje.
Migrace s sebou nesla změny na všech úrovních
Systém je také postaven tak, aby základní služby typu zobrazení zůstatku na účtu fungovaly i v době údržby. V databázi jsou samostatná schémata s obrazem zůstatků, která se synchronizují se zbytkem. Jakmile se na back-endu nasazují změny, modul nedotčeně běží a v podstatě funguje jako snapshot. Vůči světu je stále aktuální. Když se odstavený systém nahodí do provozu, dojde k rychlé synchronizaci. Je to podobné kartovým centrům, kdy jste pořád schopni platit kartou, i když je banka dole.
Na migraci se podílel zhruba stočlenný tým analytiků, designérů a vývojářů. V určitou dobu se ale změna dotkla prakticky všech zaměstnanců banky. Bylo nutné změnit procesy, udělat nové front-endy, aplikační rozhraní (API) nebo dashboardy. Výsledkem je kromě jiného snížení počtu back-endových technologií, aby provoz nebyl příliš drahý a v rámci IT nevznikla zbytečná komplexita.
Tým v České spořitelně díky migraci z mainframu vytvořil frameworky, pomocí nichž je možné další převody dělat mnohonásobně rychleji. Spořitelna nedávný převod klientů Sberbank a Hello bank! zvládla v řádech měsíců.
