VTB IT-department has faced emergency situations in system operations several times, where the load on them increased multiple times. Hence, there was a need to develop and test a model that would predict peak loads on critical systems. To achieve this, the bank's IT specialists set up monitoring, analyzed data, and learned to automate forecasts. We will discuss what tools helped to predict the load and whether they managed to optimize operations in a brief article.
Issues with high-load services arise in almost all industries, but they are critical in the financial sector. At the moment of truth, all combat units must be on alert, and it was necessary to know in advance what could happen, even determining the day when the load would surge and which systems would encounter it. Problems need to be fought and prevented, so the need to implement a predictive analytics system was never in question. It was necessary to modernize systems based on monitoring data.
Analytics on the fly
The salary project is one of the most sensitive in case of a failure. It is also the most predictable, so we decided to start with it. Due to high interconnectivity, other subsystems, including remote banking services (RBS), could also experience issues during peak load moments. For instance, clients, thrilled with SMS notifications about incoming funds, would start using them actively. In such cases, the load could surge more than tenfold.
The first forecasting model was created manually. We took the data for the last year and calculated which days would expect the highest peaks: for example, the 1st, 15th, and 25th of each month, as well as the last days of the month. This model required significant labor intensity and did not provide accurate predictions. Nevertheless, it identified bottlenecks where additional 'hardware' was needed and allowed us to optimize the money transfer process by negotiating with anchor clients: instead of disbursing salaries all at once, transactions from different regions were staggered over time. Now we process them in parts that the bank's IT infrastructure can handle without failures.
Saades esimene positiivne tulemus, läksime prognoosimise automatiseerimise juurde. Ootas veel kümme kriitilist ala.
Kasutusmugav lähenemine
VTB-s rakendati MicroFocusi firma jälgimissüsteemi. Sealt saime andme kogumise prognoosimiseks, salvestussüsteemi ja raportite genereerimise süsteemi. Eessõnas oli jälgimine juba olemas, jäi vaid lisada meetrikad, ennustamismoodul ja luua uusi raporteid. Selle lahenduse toetab väline alltöövõtja 'Tehnoserv', seega peamine töö projekti elluviimisel lasus nende spetsialistidel, kuid mudeli koostasime ise. Prognoosimisse süsteemi tegime Prophet'i baasil — see avatud toode on loodud Facebookis. See on lihtne kasutada ja integreerub hõlpsasti meie olemasolevate integreeritud jälgimistööriistade ja Verticaga. Üldiselt analüüsib süsteem koormuse graafikut ja teeb Fourier' seeriate põhjal selle ekstrapoleerimist. Samuti on võimalik lisada teatud koefitsiente päevade kaupa, mis on saadud meie mudelist. Meetriikaid võetakse ilma inimese sekkumiseta, kord nädalas prognoosi arvutatakse automaatselt ümber ja uued raportid saadetakse adressaatidele.
See lähenemine tuvastab peamised tsüklilisused, näiteks aastased, kuukesised, kvartali- ja nädalatsüklid. Palga ja ettemaksete maksmine, puhkuste ja pühade ajad ning allahindlused - kõik see mõjutab süsteemide seadmist. Selgus, et näiteks mõned tsüklid kattuvad üksteisega ning põhikoormus (75%) süsteemidele tuleb Keskföderaalset Ühendusest. Juriidilised ja füüsilised isikud käituvad erinevalt. Kui 'füüsikute' koormus on nädalapäevade vahel suhteliselt ühtlaselt jaotatud (see on väga palju väikseid tehinguid), siis ettevõtete puhul langeb 99,9% tööajale, kusjuures tehingud võivad olla lühikesed, kuid neid võib töödelda ka mitu minutit või isegi tundi.
Saadud andmete põhjal määratakse pikaajalised trendid. Uus süsteem on näidanud, et inimesed liiguvad massiliselt DBO-sse. See on kõigile teada, kuid sellist ulatust me ei oodanud ja alguses ei uskunud me sellesse: panga kontorite külastuste arv väheneb äärmiselt kiiresti, samas kui kaugtehingute arv kasvab sama kiiresti. Seega kasvab ka süsteemide koormus ja see kasvab tulevikus veelgi. Praegu prognoosime koormust kuni 2020. aasta veebruarini. Tavalisi päevi suudame prognoosida 3% veaulatusega, kuid tipptunde 10% veaulatusega. See on hea tulemus.
Pahupooled
Ilma raskusteta ei pääsenud. Fourier' jadadega ekstrapolatsiooni mehhanism ei ületa nulli hästi — me teame, et nädalavahetustel genereerivad juriidilised isikud vähe tehinguid, kuid prognoosimoodul annab kaugel nullist olevad väärtused. Me oleksime saanud need kunstlikult parandada, kuid meie meetod pole tugineda väikestele lahendustele. Lisaks tuli lahendada probleem süsteemide allikast andmete valutuks kogumiseks. Regulaarne teabe kogumine nõuab tõsiseid arvutusressursse, seega ehitasime kiireid vahemälu lahendusi, kasutades replikatsiooni ja saame ärilisi andmeid juba replikate kaudu. Lisakoormuse puudumine peamise süsteemi puhul sellistes olukordades on takistus.
Uued väljakutsed
Otseselt seatud ülesanne tipukoormuse prognoosimiseks on lahendatud: panga ülekoormusega seotud tõrkeid ei ole olnud alates maist käesolevast aastast, ja uus prognoosimisse süsteem on mänginud selles suurt rolli. Jah, seda on osutunud ebapiisavaks, ja nüüd soovib pank mõista, kui ohtlikud on tipphetked. Me vajame prognoose koormustest, kasutades koormustestimise mõõdikuid, ja see töötab juba umbes 30% kriitiliste süsteemide jaoks, teised on prognooside saamise protsessis. Järgmises etapis plaanime prognoosida süsteemide koormust mitte äritehingutes, vaid IT-infrastruktuuri tasemel, st liigume madalamale kihile. Lisaks peame täielikult automatiseerima mõõdikute kogumise ja nende põhjal prognooside koostamise, et mitte tegeleda andmete eksportimisega. Selles ei ole midagi eriskummalist — me lihtsalt ristame monitooringu ja koormustestimise vastavalt parimatele rahvusvahelistele praktikatele.
Allikas: habr.com
