IT-дэпартаменту ЗГБ некалькі разоў даводзілася сутыкацца з няштатнымі сітуацыямі ў працы сістэм, калі нагрузка на іх шматкроць узрастала. Таму з'явілася неабходнасць распрацаваць і апрабаваць мадэль, якая прадказвала б пікавую нагрузку на крытычныя сістэмы. Для гэтага IT-спецыялісты банка настроілі маніторынг, прааналізавалі даныя і навучыліся аўтаматызаваць прагнозы. Якія інструменты дапамаглі спрагназаваць нагрузку і ці атрымалася з іх дапамогай аптымізаваць працу, мы раскажам у невялікім артыкуле.
Праблемы з высоканагружанымі сэрвісамі ўзнікаюць практычна ва ўсіх галінах, але для фінансавай сферы яны крытычныя. У гадзіну X усе баявыя адзінкі павінны быць напагатове, а таму патрабавалася ведаць загадзя, што можа здарыцца і нават вызначаць дзень, калі падскочыць нагрузка, і якія сістэмы з ёй сутыкнуцца. Са збоямі трэба змагацца і прадухіляць іх, таму неабходнасць укаранення сістэмы прагнознай аналітыкі нават не абмяркоўвалася. Трэба было мадэрнізаваць сістэмы на аснове звестак маніторынгу.
Аналітыка на каленцы
Зарплатны праект - адзін з самых адчувальных у выпадку збою. Ён жа найболей зразумелы для прагназавання, таму пачаць вырашылі з яго. З-за высокай складнасці ў моманты пікавых нагрузак маглі адчуваць праблемы і іншыя падсістэмы, у тым ліку дыстанцыйнае банкаўскае абслугоўванне (ДБО). Напрыклад, кліенты, узрадаваныя SMS аб паступленні грошай, пачыналі актыўна імі карыстацца. Нагрузка пры гэтым магла падскокваць больш за на парадак.
Першую мадэль для прагнозу стваралі ўручную. Мы ўзялі выгрузку за апошні год і палічылі, у якія дні чакаюцца максімальныя пікі: напрыклад, 1-га, 15-га і 25-га чысла, а таксама ў апошнія дні месяца. Гэтая мадэль патрабавала сур'ёзных працавыдаткаў і не давала дакладнага прагнозу. Тым не менш яна выявіла вузкія месцы, куды трэба было дадаць «жалеза», і дазволіла аптымізаваць працэс пералічэння грошай, дамовіўшыся з якарнымі кліентамі: каб не даваць заробак «залпам», транзакцыі з розных рэгіёнаў разнеслі па часе. Цяпер мы апрацоўваем іх часткамі, якія IT-інфраструктура банка здольная "пражаваць" без збояў.
Атрымаўшы першы станоўчы вынік, мы перайшлі да аўтаматызацыі прагназавання. Сваёй чаргі чакаў яшчэ дзясятак крытычных участкаў.
Комплексны падыход
У ЗГБ укаранілі сістэму маніторынгу кампаніі MicroFocus. Адтуль мы ўзялі збор даных для прагназавання, сістэму захоўвання і сістэму генерацыі справаздач. Па сутнасці, маніторынг ужо быў, заставалася толькі дадаць метрыкі, модуль прадказання і стварыць новыя справаздачы. Падтрымлівае гэтае рашэнне вонкавы падрадчык «Техносерв», таму асноўныя працы па рэалізацыі праекту леглі на яго адмыслоўцаў, але мадэль мы будавалі самастойна. Сістэму прагназавання зрабілі на аснове Prophet - гэты адкрыты прадукт распрацаваны ў Facebook. Ён просты ў выкарыстанні і лёгка інтэгруецца з усталяванымі ў нас сродкамі комплекснага маніторынгу і Vertica. Грубіянска кажучы, сістэма аналізуе графік загрузкі і на аснове шэрагаў Фур'е робіць яго экстрапаляцыю. Ёсць таксама магчымасць дадаваць некаторыя каэфіцыенты па днях, узятыя з нашай мадэлі. Метрыкі здымаюцца без удзелу чалавека, раз на тыдзень прагноз аўтаматычна пералічваецца, новыя справаздачы рассылаюцца адрасатам.
Такі падыход выяўляе асноўныя цыклічнасці, напрыклад, гадавыя, месячныя, квартальныя і тыднёвыя. Выплата заробкаў і авансаў, перыяды адпачынкаў, святы і распродажы - усё гэта ўплывае на колькасць зваротаў да сістэм. Высветлілася, напрыклад, што некаторыя цыклы накладваюцца сябар на сябра, а асноўную нагрузку (75%) на сістэмы дае Цэнтральная федэральная акруга. Юрыдычныя і фізічныя асобы паводзяць сябе па-рознаму. Калі нагрузка ад "фізікаў" адносна раўнамерна размеркавана па днях тыдня (гэта вельмі шмат невялікіх транзакцый), то ў кампаній 99,9% прыпадае на працоўны час, прытым транзакцыі могуць быць кароткімі, а могуць апрацоўвацца на працягу некалькіх хвілін і нават гадзін.
На падставе атрыманых даных вызначаюцца працяглыя трэнды. Новая сістэма выявіла, што людзі масава сыходзяць у ДБО. Гэта ўсім вядома, але такіх маштабаў мы не чакалі і спачатку ў іх не паверылі: колькасць зваротаў у офісы банка надзвычай хутка зніжаецца, і роўна на столькі ж расце колькасць дыстанцыйных транзакцый. Адпаведна, нагрузка на сістэмы таксама расце і будзе расці далей. Цяпер мы прагназуем нагрузку да лютага 2020 года. Нармальныя дні атрымліваецца прадказаць з хібнасцю ў 3%, а віновыя - з хібнасцю ў 10%. Гэта добры вынік.
Падводныя камяні
Без цяжкасцей, як водзіцца, не абышлося. Механізм экстрапаляцыі з выкарыстаннем шэрагаў Фур'е дрэнна пераходзіць праз нуль - мы ведаем, што ў выходныя юрыдычныя асобы генеруюць мала транзакцый, але модуль прадказанні выдае далёкія ад нуля значэння. Можна было паправіць іх прымусова, але мыліцы - не наш метад. Акрамя таго, прыйшлося вырашыць праблему бязбольнага здыму дадзеных з сістэм-крыніц. Рэгулярны збор інфармацыі патрабуе сур'ёзных вылічальных рэсурсаў, таму мы пабудавалі хуткія кэшы з выкарыстаннем рэплікацыі, атрымліваем бізнес-дадзеныя ўжо з рэплік. Адсутнасць дадатковай нагрузкі на майстар-сістэмы ў такіх выпадках - блакавальнае патрабаванне.
Новыя выклікі
Пастаўленая ў лоб задача па прадказанні пікаў была вырашана: звязаных з перагрузкай збояў у банку не было з мая гэтага года, і новая сістэма прагназавання адыграла ў гэтым не апошнюю ролю. Так, яе аказалася недастаткова, і зараз банк хоча зразумець, наколькі небяспечныя для яго пікі. Нам патрэбны прагнозы з выкарыстаннем метрык ад нагрузачнага тэсціравання, і прыкладна для 30% крытычных сістэм гэта ўжо працуе, астатнія ў працэсе атрымання прагнозаў. На наступным этапе мы збіраемся прагназаваць нагрузку на сістэмы не ў бізнес-транзакцыях, а ў тэрмінах IT-інфраструктуры, т. е. апусцімся на пласт ніжэй. Акрамя таго, нам трэба поўнасцю аўтаматызаваць збор метрык і пабудову прагнозаў на іх аснове, каб не займацца выгрузкамі. У гэтым няма нічога выбітнага - мы проста скрыжоўваем маніторынг і нагрузачнае тэсціраванне ў адпаведнасці з лепшымі сусветнымі практыкамі.
Крыніца: habr.com