Mitä 18 miljoonaa tiliä opetti meille mainframe-migraatiosta

Vuosikymmenten COBOL-koodin uudelleenkirjoitus on näkyvää työtä, joten arviot kohdistuvat siihen. Riski on hiljaisemmassa paikassa: itse reskontrassa. Saldot ovat ainoa asia, jota pankki ei voi arvioida, ja jokainen niihin vaikuttava sääntö — pyöristys, arvopäivä, peruutusten järjestys — on yleensä koodattu kahdesti, kerran koodiin ja kerran järjestelmää käyttävien ihmisten tapoihin. Emme kirjoittaneet ensimmäisen kuuden viikon aikana lainkaan tuotantokoodia, vaan pelkkiä suoritettavia testejä näistä säännöistä. Sen jälkeen kaikelle oli mittatikku.

Uusi reskontra ajoi varjossa neljä kuukautta. Jokainen kirjaus meni molempiin järjestelmiin, ja täsmäytysajo vertasi niitä tili tililtä joka yö ja kirjasi jokaisen eron vikana. Ensimmäinen yö tuotti noin yksitoistatuhatta poikkeamaa. Lähes kaikki johtuivat samasta virheestä: pyöristyssääntöä sovellettiin tapahtuman eri kohdassa. Siinä on rinnakkaisajon arvo — se muuttaa epämääräisen migraatiojännityksen vikamääräksi, joka laskee viikoittain, ja antaa rehellisen vastauksen kysymykseen "olemmeko jo valmiita".

Itse vaihto kesti yhdeksän minuuttia. Koska molemmat järjestelmät olivat kirjoittaneet kuukausia, siirtymä ei ollut datamigraatio vaan muutos siihen, kumpi järjestelmä vastasi lukupyyntöihin. Siirsimme liikenteen vaiheittain, pidimme mainframen lämpimänä ja kirjoituskelpoisena vielä kolme viikkoa, emmekä tarvinneet sitä kertaakaan. Tuloksena oli 40 % pienemmät ajokustannukset ja noin kuusinkertainen suorituskykyvara, mutta sisäisesti toistamisen arvoinen luku on toinen: ei huoltokatkoa eikä yhtäkään asiakasta, jota pyydettiin palaamaan maanantaina.