IT-afdelingen i VTB måtte håndtere nødsituationer i driften af systemer flere gange, når belastningen på dem steg mange gange. Derfor blev det nødvendigt at udvikle og teste en model, der kunne forudsige spidsbelastningen på kritiske systemer. For at gøre dette satte bankens IT-specialister overvågning op, analyserede dataene og lærte at automatisere prognoser. Hvilke værktøjer hjalp med at forudsige belastningen, og om det var muligt at optimere arbejdet med deres hjælp, vil vi fortælle i en kort artikel.
Problemer med højt belastede tjenester opstår i næsten alle brancher, men de er kritiske for den finansielle sektor. Ved time X skulle alle kampenheder være klar, så det var nødvendigt på forhånd at vide, hvad der kunne ske og endda bestemme dagen for, hvornår lasten ville stige, og hvilke systemer, der skulle møde den. Fejl skal håndteres og forhindres, så behovet for at implementere et prædiktivt analysesystem blev ikke engang diskuteret. Systemer skulle opgraderes baseret på overvågningsdata.
Analytics på knæet
Et lønprojekt er et af de mest følsomme i tilfælde af fiasko. Det er det mest forståelige for prognoser, så vi besluttede at starte med det. På grund af den høje tilslutningsmuligheder i spidsbelastningsperioder kan andre delsystemer også opleve problemer, herunder remote banking (RB). For eksempel begyndte kunder, der var glade for SMS om modtagelse af penge, aktivt at bruge dem. I dette tilfælde kan belastningen hoppe med mere end en størrelsesorden.
Den første prædiktive model blev oprettet manuelt. Vi tog uploaden for det sidste år og beregnede, på hvilke dage de maksimale toppe forventes: for eksempel den 1., 15. og 25. samt de sidste dage i måneden. Denne model krævede alvorlige arbejdsomkostninger og gav ikke en nøjagtig prognose. Ikke desto mindre identificerede hun flaskehalse, hvor det var nødvendigt at tilføje "jern", og fik lov til at optimere processen med at overføre penge ved at aftale med ankerkunder: For ikke at give løn "i en slurk" blev transaktioner fra forskellige regioner spredt over tid . Nu behandler vi dem i dele, som bankens it-infrastruktur er i stand til at "tygge" uden fejl.
Efter at have modtaget det første positive resultat, gik vi videre til at automatisere prognoser. Et dusin mere kritiske områder ventede på deres tur.
Integreret tilgang
VTB har implementeret et overvågningssystem fra MicroFocus. Derfra tog vi dataindsamling til prognoser, et lagersystem og et rapporteringssystem. Faktisk var der allerede overvågning, det var kun tilbage at tilføje metrics, et forudsigelsesmodul og oprette nye rapporter. Denne løsning er understøttet af den eksterne entreprenør Technoserv, så hovedarbejdet med implementeringen af projektet faldt på dens specialister, men vi byggede selv modellen. Prognosesystemet blev lavet på basis af Prophet - dette åbne produkt blev udviklet af Facebook. Det er nemt at bruge og integreres nemt med vores integrerede overvågningsværktøjer og Vertica. Groft sagt analyserer systemet lasteplanen og ekstrapolerer den ud fra Fourier-serien. Det er også muligt at tilføje nogle koefficienter for dagene taget fra vores model. Målinger tages uden menneskelig indgriben, en gang om ugen genberegnes prognosen automatisk, nye rapporter sendes til modtagerne.
Denne tilgang afslører de vigtigste cyklusser, for eksempel årlige, månedlige, kvartalsvise og ugentlige. Løn og acontobetalinger, ferieperioder, ferier og salg – alt dette påvirker antallet af opkald til systemerne. Det viste sig for eksempel, at nogle cyklusser overlapper hinanden, og hovedbelastningen (75%) på systemerne kommer fra det centrale føderale distrikt. Juridiske enheder og enkeltpersoner opfører sig forskelligt. Hvis belastningen fra "fysikerne" er forholdsvis jævnt fordelt over ugens dage (der er mange små transaktioner), så har virksomheder 99,9% i arbejdstiden, desuden kan transaktioner være korte, eller de kan behandles indenfor flere minutter eller endda timer.
På baggrund af de opnåede data bestemmes langsigtede tendenser. Det nye system afslørede, at folk rejser i massevis til fjernbank. Alle ved dette, men vi forventede ikke en sådan skala og troede først ikke på dem: Antallet af opkald til bankens kontorer falder ekstremt hurtigt, og antallet af fjerntransaktioner vokser med nøjagtig det samme beløb. Derfor vokser belastningen på systemerne også og vil fortsætte med at vokse. Vi forudser nu belastningen indtil februar 2020. Normale dage kan forudsiges med en fejl på 3 %, og spidsbelastningsdage - med en fejl på 10 %. Dette er et godt resultat.
Faldgruber
Som sædvanlig var det ikke uden besvær. Ekstrapolationsmekanismen ved hjælp af Fourier-serien krydser ikke nul godt - vi ved, at juridiske enheder genererer få transaktioner i weekenden, men forudsigelsesmodulet producerer værdier, der er langt fra nul. Det var muligt at rette dem med magt, men krykker er ikke vores metode. Derudover skulle vi løse problemet med smertefri fjernelse af data fra kildesystemer. Regelmæssig indsamling af information kræver seriøse computerressourcer, så vi byggede hurtige caches ved hjælp af replikering, vi får allerede forretningsdata fra replikaer. Fraværet af yderligere belastning på mastersystemerne i sådanne tilfælde er et blokeringskrav.
Nye udfordringer
Den direkte opgave med at forudsige peaks blev løst: Der har ikke været overbelastningsrelaterede fejl i banken siden maj i år, og det nye prognosesystem spillede en vigtig rolle heri. Ja, det var ikke nok, og nu vil banken forstå, hvor farlige spar er for den. Vi har brug for prognoser, der bruger metrics fra belastningstest, og for omkring 30 % af kritiske systemer virker dette allerede, resten er i gang med at indhente prognoser. På næste trin skal vi forudsige belastningen på systemerne, ikke i forretningstransaktioner, men i form af it-infrastruktur, det vil sige, vi vil gå ned til laget nedenfor. Derudover er vi nødt til fuldt ud at automatisere indsamlingen af metrikker og konstruktionen af prognoser baseret på dem, for ikke at håndtere aflæsning. Der er intet udestående i dette - vi krydsovervågning og belastningstest i overensstemmelse med bedste praksis i verden.
Kilde: www.habr.com