Az esettanulmány első részében felvázoltuk a bolgár DSK Bank számára végzett performanciatesztelés célját, ismertettük a kiválasztott rendszereket, majd rávilágítottunk a banki rendszerek megfelelő méretezésének dilemmájára, és bemutattuk a DSK Banknál felmerülő különleges nehézségeket is. Most áttekintést adunk a tényleges teljesítmény mérésről, majd a belső szakértőkkel való együttműködés módjáról, a menedzsmenttel való kommunikációról, végül pedig az elvárt és tényleges eredményekről.
A DSK Bank akvizíciót hajtott végre, nem pedig egy teljesen új rendszer bevezetése történt. A másik pénzintézet felvásárlásából adódó bővülés a tesztelők számára lényegesen egyszerűbb feladat, mint egy újonnan létrehozott rendszer ellenőrzése, mivel alacsonyabb kockázati szintet jelent. Ilyenkor a feladat lényegében az, hogy nézzük meg egy ismert rendszer működését egy ismeretlen terhelési tartományban.
Egy új rendszer esetében teljesen új fejlesztések, új komponensek, új funkciók lépnek be, amik sok bizonytalanságot és kockázatot jelentenek. A DSK-nál egy létező rendszer megnövekedett adatmennyiségével, és már létező “vasakkal”, szoftverrel, meglévő üzemeltetőkkel, az ő tapasztalataikra is támaszkodva kezdhettünk bele a munkába. (A KPMG és a ProofIT közös csapata új rendszerek performanciatesztelését is végezte már - legutóbb az MKB Banknál.)
A teljesítmény jellegű tesztek és mérések sokfélék lehetnek,
A kérdések, amelyekre válaszokat kaphatunk, lehetnek egészen egyszerű eldöntendő kérdések, például: megfelel-e a rendszer az előzetesen felállított teljesítmény mutatóknak, de lehetnek egészen komplexek is, például: hol vannak szűk keresztmetszetek és milyen körülmények között ütközik beléjük a rendszer, milyen hatást gyakorolnak egymásra az azonos rendszer csoporton működő eltérő szolgáltatások terhelései?
Például a felső terhelési határok keresése közben a szokásosnál jobban terheljük a rendszert, majd megnézzük, ekkor hogyan alakulnak a válaszidők és a tranzakció áteresztő képességek. Ha túlterhelést észlelünk, elkezdünk hozzá plusz erőforrásokat adni - akár hardvert, akár szoftvert vizsgálunk -, abból a célból, hogy az hogyan hat a maximális teljesítményre (itt általában nem lineáris az összefüggés). A méréseink jelentős része a DSK Bank rendszerének tesztelésekor is a módosítások, hangolások eredményeinek ellenőrzésére irányult, majd ezek alapján javaslatokat tettünk a további módosításokra.
Kívülállókban joggal merül fel a kérdés, ha előre lehet tudni, hogy 30-60 százalékkal fog nőni a terhelés, akkor miért nem lehet egyszerűen ennyivel megnövelni az erőforrásokat? Az ilyen összetett rendszerek tervezése nem egzakt tudomány. Vannak szempontok, amiket a tervezés során figyelembe lehet, sőt, figyelembe kell venni. Valójában azonban csak a megvalósítás során lehet véglegesíteni, hogy milyen típusú erőforrásból melyik rétegbe mennyi pluszt is kell beépíteni ahhoz, hogy a tervezett plusz kapacitás megvalósulhasson.
A legtöbb banki folyamat rendkívül összetett. Egyetlen részfolyamatban, például egy mobilbankos utalásban is tucatnyi rendszer vesz részt. Ha ezek közül csak egyetlen rendszerben vagy hardver-komponensben valahol szűk a keresztmetszet, az megfogja az egész folyamatot. A tesztelés során tehát a legtöbb mérés a rendszer viselkedését vizsgálja, extrém körülmények között, illetve e módosításokat követően mérjük vissza, hogy azok elérték-e az elvárt hatást.
Egy pénzügyi rendszer tesztelése - különösen, ha olyan kevés idő áll rendelkezésre, mint a DSK-projekt esetében -, elképzelhetetlen a belső szakemberek, szakértők intenzív közreműködése nélkül. A bolgár banknál az osztályvezetők, csoportvezetők mellett élvezhettük az IT vezető (egyben a bank egyik vezérigazgató-helyettese) támogatását is. Fontos, hogy valamennyi vezetői szinten elfogadják a performancia tesztelés céljait, majd részt vegyenek az erőforrás allokácójában, és a feladatok priorizálásában. (Mindebből jól látható, hogy bár a tesztelést egy külső, független cég végzi, ez nem egy olyan külső munka, ami kiszervezhető lenne anélkül, hogy azt a belső szakemberek észrevegyék.
Bár a performanciatesztelés az egész migrációs projektnek csak egy kis része, de azzal, hogy a tesztelők nagy terheléseket bocsátanak a rendszerekre, annak egész működését befolyásolják, így észrevétlenségről szó sem lehet. A munkát a DSK Banknál természetesen nem az éles banki rendszeren, hanem egy tesztrendszeren végeztük, de itt sem voltunk egyedül. A performanciateszteket ezért erősen koordinálni kellett a többi, a rendszeren futó teszttel és más aktuális tevékenységekkel, hogy a teljesítmény mérések esetleges extrém terhelései se akadályozzák a többi tesztet, és a többi teszt se hasson ki a mérések számszerű eredményeire.
Egy teljesítménytesztelési projekt nagyon különböző kompetenciákat igényel. Ezek a projekt lefutása során is változhatnak. A DSK Bank performanciatesztjén a KPMG és Proofit közös csapata összesen 9 fővel dolgozott.
A munkához a bank biztosította a nagy teljesítményű hardver infrastruktúrát, aminek segítségével képesek voltunk szimulálni akár több tízezer ügyféltől és több ezer banki ügyintézőtől származó egyidejű tranzakciókat is.
Egy bank teljesítménytesztelését nem lehet kicsiben, vagy nagyban végezni. Ezt a feladatot nem lehet redukálni. Ebből adódik, hogy rengeteg információhoz kell hozzájutni, fel kell dolgozni. Ezek a tényezők alapvetően meghatározzák a projekt időtartamát is. A csapat korábbi, hasonló projektjei megközelítőleg 1-1 évig tartottak. Nagyjából ennyi idő szükséges ahhoz, hogy belelássunk a bank működésébe, tervezzünk, fejlesszünk, kommunikáljunk, és több tucat, vagy akár több száz körben is ellenőrzéseket végezzünk.
Most ahhoz, hogy mindezt a DSK Banknál negyedannyi idő, azaz 3 hónap alatt elvégezhessük, komoly kompromisszumokat kellett alkalmaznunk - úgy, hogy azok az eredmény használhatóságát nem veszélyeztessék. A kompromisszumkötés már a célterületek azonosításánál és teljesítménymutatók meghatározásánál megkezdődött - az ideális módszertanhoz képest szűkíteni kellett ezek kiterjedtségét. A szoros határidő miatt mind magunktól, mind pedig a bolgár közreműködőktől folyamatos, extrém teljesítményt, rendkívüli agilitást és rendelkezésre állást kellett megkövetelnünk. Csak mindkét szervezet magasszintű támogatásával és koordinációjával valósulhatott meg ennyi idő alatt a projekt.
Ez extrém napokon a középvezetőkkel akár napi 6-8, a felsővezetőkkel 1-2 egyeztetést is jelentett. A szakértőket, üzemeltetőket akár éjjel, hétvégén, vagy ünnepnapokon is mozgósítani kellett. A kinti kollégák ilyen intenzív foglalkoztatása nem lett volna lehetséges 2-3 vezetői szint megfelelő támogatása nélkül. Azzal hogy a bank oldaláról priorizálták a feladatokat, időben felkészítették az embereket, komolyan megalapozták a mi munkánkat is.
A DSK Bank kibővített rendszere 2020. május elején kezdte meg a működését. Ekkor mutatkozott meg élesben is, hogyan sikerült az átállás. (Sikerült.) Az eredmények mérésekor a válaszidőn, a maximális terhelésen és a kihasználtságon túl még számos mutató határozható meg. A lényeg, hogy ezeknek legyen viszonyítási alapjuk, és hogy ellenőrizhetők legyenek.
Miközben a bankok üzleti folyamatai nagyon hasonlóak, megvalósításuk műszaki szinten nagyon különböző lehet. Ebből is következik, hogy ugyan léteznek dobozos teljesítménymérő eszközök, de ezek csak a standard technológiákra terjednek ki. Egy-egy speciális rendszer, gyártóspecifikus protokoll, és egyéb speciális körülmények mérésére nincs ilyen kész mérőeszköz.
A Proofit rendelkezik saját bővíthető platformmal mind a teljesítmény teszteléshez, mind a funkcionális teszteléshez, ezekre alapozva minden projektjéhez, így a banki projektekhez is önálló, az adott feladatra testreszabott tesztlabor környezetet alakít ki. Ide kerülnek a feladathoz kialakított driverek, szenzorok, és a kiértékelő grafikonok is és ugyanide kerülnek a terhelési mintákat meghatározó konfigurációk, üzenet minták, paraméterek, tesztadatok, valamint a nyers és a kiértékelt eredmények is.
Egy komplexebb iparág vagy -rendszer mérése gyakran megkövetel bizonyos egyedi fejlesztéseket is. Ilyenkor olyan komponenseket is létrehozunk, amik az adott rendszerrel is képesek kommunikálni, helyes és megismételhető módon üzeneteket küldeni, az üzenetekre kapott válaszokat elolvasni, és értelmezni, hogy elegendő legyen annak eldöntéséhez, hogy a kommunikáció üzletileg is sikeres volt-e, vagy ha nem, akkor milyen típusú hibával zárult.
Egy pénzintézeti rendszer tesztelésekor a mérési célok is nagyon rétegzettek tudnak lenni. A DSK-nál is mintegy húszféle mérés készült - ezek mindegyikének más a kiértékelési igénye.
Egy mérési projektben az ügyfél felé fontos követelmény a mérhető rendszerek biztosítása. Banki közegben általában van 4-5 ilyen példány a főrendszerből különböző célokra fenntartva, de kifejezetten teljesítménymérésre dedikált példány nem szokott lenni. A teljesítménymérésnek tehát általában meg kell osztoznia más típusú tesztekkel a környezeteken térben - időben - konfigurációban komoly feladat szokott lenni egy olyan integrált környezet kialakítása, amiben egyszerre ott van az érintett főbb rendszerekből is egy példány
A kialakított mérési rendszerek határozzák meg, melyik rendszer melyik folyamatai és részfolyamatai, melyik üzenettípusok alkalmasak reprezentálni a valós terhelést, Ezek képesek a terhelést a megfelelő csatornákba irányítani. Ezek határozzák meg azt is, hol olvashatók a válaszok, a háttérrendszerek terhelési eredményei.
Egy nagy kereskedelmi banknál általában sok száz üzleti folyamattal és az azok működéséhez szükséges sok száz üzenettípussal kell számolnunk. A teszteléshez ezeket a folyamatokat és a bejárt utakat kell néhány tucatra redukálni úgy, hogy közben a főbb ösvényeket mégis bejárjunk. Ezt a szűkítést úgy kell végrehajtani, hogy közben figyelembe vesszük az iparági és a helyi adottságokat, prioritásokat, gyakoriságokat, statisztikákat.
Általában az alkalmazott tesztlabornak képesnek kell lennie arra, hogy 20-40 üzenettípussal akkora terhelést állítsunk elő, mint amekkorát a valós rendszeren az összes (200-400) tranzakciótípus produkálna.
Az egymásra épülő mérési menetek önmagukban is összetettek, egyenként akár 20 részcélt is tartalmazhatnak. A tesztek között szerepelhet az egyszerű válaszidő mérése, de lehet közöttük több órás, 5 alrendszerre is kiterjedő tartóssági teszt is.
Egy ilyen projekt során nem elegendő egy végső jelentés benyújtása. A fejlesztők és üzemeltetők támogatására fontos a sokkal gyakoribb, extrém esetekben akár a napi szintű, vagy naponta többször is frissülő eredmény biztosítása, amikre konfigurációs, optimalizációs döntéseket lehet alapozni.
Bár a tesztek alapján rengeteg számot és látványos grafikonokat produkálunk, tisztában vagyunk vele, hogy megbízónknak nem erre, hanem főleg ezek értelmezésére és interpretációjára van szükségük. Olyan megalapozott információkra, amik alapján még idejében módosíthatják az érintett rendszereket, folyamatokat, paramétereket.
Csapatunk óriási mennyiségű elemi mérést hajtott végre. Az első, előkészítő hónap után átlagosan minden második napon szükség mérésekre. Projekt második és harmadik hónapjában összesen több mint 700 mérési menettel több mint 20 millió tranzakciót modelleztünk.
A fontosabb rendszereken, folyamattípusokon belül igazolhatóan, ismételhetően megmutattuk, hogy az indulás hetében várható rendkívüli terheléseknél 2-3-szor nagyobb terheléseknél sincs veszélyben a rendszer. (A május elejei éles indulás igazolta ezt.)
