VTB IT skyriui ne kartą teko susidurti su avarinėmis situacijomis eksploatuojant sistemas, kai joms tenkantis krūvis išaugo daug kartų. Todėl reikėjo sukurti ir išbandyti modelį, kuris numatytų didžiausią kritinių sistemų apkrovą. Tam banko IT specialistai sukūrė stebėjimą, analizavo duomenis ir išmoko automatizuoti prognozes. Trumpame straipsnyje papasakosime, kokie įrankiai padėjo numatyti apkrovą ir ar padėjo optimizuoti darbą.
Problemų, susijusių su didelės apkrovos paslaugomis, kyla beveik visose pramonės šakose, tačiau finansų sektoriui jos yra labai svarbios. X valandą visi koviniai vienetai turi būti pasiruošę, todėl reikėjo iš anksto žinoti, kas gali nutikti ir net nustatyti dieną, kada krovinys šoktels ir kokios sistemos su tuo susidurs. Gedimus reikia spręsti ir užkirsti jiems kelią, todėl apie būtinybę diegti nuspėjamosios analizės sistemą net nebuvo kalbama. Reikėjo modernizuoti sistemas remiantis monitoringo duomenimis.
Analizė ant kelių
Darbo užmokesčio projektas yra vienas jautriausių nesėkmės atveju. Tai labiausiai suprantama prognozuojant, todėl nusprendėme nuo to pradėti. Dėl didelio jungiamumo kitose posistemėse, įskaitant nuotolines bankininkystės paslaugas (RBS), gali kilti problemų didžiausios apkrovos metu. Pavyzdžiui, klientai, kurie apsidžiaugė SMS žinute apie pinigų gavimą, pradėjo aktyviai ja naudotis. Krovinys gali pašokti daugiau nei eilės tvarka.
Pirmasis prognozės modelis buvo sukurtas rankiniu būdu. Paėmėme praėjusių metų įkėlimus ir apskaičiavome, kuriomis dienomis numatomi didžiausi pikai: pavyzdžiui, 1, 15 ir 25, taip pat paskutinėmis mėnesio dienomis. Šis modelis pareikalavo didelių darbo sąnaudų ir nepateikė tikslios prognozės. Nepaisant to, buvo nustatytos kliūtys, kur reikėjo papildyti techninę įrangą, ir leido optimizuoti pinigų pervedimo procesą, susitarus su pagrindiniais klientais: kad atlyginimai nebūtų duodami vienu maudymosi, sandoriai iš skirtingų regionų buvo paskirstyti laikui bėgant. Dabar juos apdorojame dalimis, kurias banko IT infrastruktūra gali „sukramtyti“ be gedimų.
Gavę pirmąjį teigiamą rezultatą, perėjome prie prognozavimo automatizavimo, savo eilės laukė dar keliolika kritinių sričių.
Visapusiškas požiūris
VTB įdiegė „MicroFocus“ stebėjimo sistemą. Iš ten rinkome duomenis prognozėms, saugojimo sistemą ir ataskaitų teikimo sistemą. Tiesą sakant, stebėjimas jau buvo vykdomas, beliko pridėti metrikas, numatymo modulį ir kurti naujas ataskaitas. Šiam sprendimui pritaria išorės rangovas „Technoserv“, todėl pagrindinis darbas įgyvendinant projektą teko jo specialistams, tačiau modelį kūrėme patys. Prognozavimo sistema buvo sukurta remiantis „Facebook“ sukurtu atviro kodo produktu „Prophet“. Tai paprasta naudoti ir lengvai integruojama su mūsų įdiegtais integruotais stebėjimo įrankiais ir Vertica. Grubiai tariant, sistema analizuoja apkrovos grafiką ir ekstrapoliuoja jį pagal Furjė eilutes. Taip pat galima pridėti tam tikrus koeficientus pagal dieną, paimtus iš mūsų modelio. Metrika imama be žmogaus įsikišimo, prognozė automatiškai perskaičiuojama kartą per savaitę, o gavėjams siunčiamos naujos ataskaitos.
Taikant šį metodą nustatomi pagrindiniai cikliškumas, pavyzdžiui, metinis, mėnesinis, ketvirtinis ir savaitinis. Atlyginimų ir avansų mokėjimai, atostogų laikotarpiai, atostogos ir išpardavimai – visa tai turi įtakos skambučių į sistemas skaičiui. Pavyzdžiui, paaiškėjo, kad kai kurie ciklai persidengia vienas su kitu, o pagrindinė apkrova (75 proc.) sistemoms tenka centrinės federalinės apygardos. Juridiniai ir fiziniai asmenys elgiasi skirtingai. Jei krūvis iš „fizikų“ yra gana tolygiai paskirstytas per savaitės dienas (tai daug smulkių sandorių), tai įmonėms 99,9% išleidžiama darbo valandoms, o operacijos gali būti trumpos arba gali būti apdorojamos per kelias dienas. minučių ar net valandų.
Remiantis gautais duomenimis, nustatomos ilgalaikės tendencijos. Naujoji sistema atskleidė, kad žmonės masiškai pereina prie nuotolinių banko paslaugų. Tai žino visi, tačiau tokių masto nesitikėjome ir iš pradžių netikėjome: skambučių į banko skyrius mažėja itin sparčiai, lygiai tiek pat auga nuotolinių operacijų skaičius. Atitinkamai, sistemų apkrova taip pat auga ir toliau augs. Dabar prognozuojame apkrovą iki 2020 m. vasario mėn. Įprastas dienas galima numatyti su 3% paklaida, o piko dienas - su 10%. Tai geras rezultatas.
Spąstų
Kaip įprasta, tai nebuvo be sunkumų. Ekstrapoliacijos mechanizmas, naudojant Furjė eilutę, neperžengia nulio – žinome, kad juridiniai asmenys savaitgaliais sugeneruoja nedaug operacijų, tačiau numatymo modulis sukuria vertes, kurios toli gražu nėra nulis. Buvo galima juos ištaisyti per prievartą, bet ramentai nėra mūsų metodas. Be to, turėjome išspręsti neskausmingo duomenų gavimo iš šaltinio sistemų problemą. Reguliarus informacijos rinkimas reikalauja rimtų skaičiavimo išteklių, todėl mes sukūrėme sparčiąsias talpyklas naudodami replikaciją ir gauname verslo duomenis iš kopijų. Tokiais atvejais pagrindinėms sistemoms papildomos apkrovos nebuvimas yra blokavimo reikalavimas.
Nauji iššūkiai
Išspręsta nesudėtinga užduotis nuspėti piką: nuo šių metų gegužės banke nebuvo jokių su perkrovomis susijusių gedimų, o nauja prognozavimo sistema suvaidino svarbų vaidmenį. Taip, pasirodė, kad to nepakanka, o dabar bankas nori suprasti, kokios pavojingos jam yra viršūnės. Mums reikia prognozių naudojant apkrovos testavimo metriką, o apie 30 % svarbiausių sistemų tai jau veikia, o likusiose prognozės gaunamos. Kitame etape sistemų apkrovą prognozuosime ne verslo sandoriuose, o IT infrastruktūros požiūriu, t.y. nusileisime vienu sluoksniu žemyn. Be to, turime visiškai automatizuoti metrikų rinkimą ir jais pagrįstų prognozių sudarymą, kad nesusidurtume su atsisiuntimais. Čia nėra nieko įmantraus – mes tiesiog pereiname prie stebėjimo ir apkrovos testavimo, vadovaudamiesi geriausios pasaulinės praktikos pavyzdžiais.
Šaltinis: www.habr.com