Пачынаючы з мінулага года ў нас у кампаніі пачалі арганізоўваць хакатоны. Першае такое спаборніцтва прайшло вельмі паспяхова, пра яго мы пісалі ў . Другі хакатон прайшоў у лютым 2019 і быў не менш паспяховым. Аб мэтах правядзення апошняга не так даўно арганізатар.
Удзельнікам паставілі даволі цікавую задачу з поўнай свабодай у выбары стэка тэхналогій для яе рэалізацыі. Было неабходна рэалізаваць платформу прыняцця рашэнняў для зручнага дэплою функцый скоринга кліентаў, якія б маглі працаваць на хуткім патоку заявак, вытрымлівалі вялікія нагрузкі, а сама сістэма - лёгка маштабавалася.
Задача нетрывіяльная і можа быць вырашана мноствам спосабаў, у чым мы пераканаліся на дэманстрацыі фінальных прэзентацый праектаў удзельнікаў. На хакатоне было 6 каманд па 5 чалавек, ва ўсіх удзельнікаў былі добрыя праекты, але наша платформа аказалася найбольш канкурэнтаздольнай. У нас атрымаўся вельмі цікавы праект, пра які я хацеў бы расказаць у дадзеным артыкуле.
Наша рашэнне - платформа на аснове Serverless архітэктуры ўнутры Kubernetes, якая скарачае час вываду новых фіч на прадакшн. Яна дазваляе аналітыкам пісаць код у зручным для іх асяроддзі і разгортваць яго ў прод без удзелу інжынераў і распрацоўнікаў.
Што такое скорынг
У Tinkoff.ru, як і ў шматлікіх сучасных кампаніях, ёсць скоринг кліентаў. Скарынг - гэта сістэма ацэнкі кліентаў, у аснове якой закладзены статыстычныя метады аналізу дадзеных.
Напрыклад, кліент звяртаецца да нас з просьбай выдаць яму крэдыт, ці адкрыць у нас рахунак ІП. Калі мы плануем выдаць яму крэдыт, то трэба ацаніць яго плацежаздольнасць, а калі кошт ІП, то трэба быць упэўненымі, што кліент не будзе праводзіць ашуканскія аперацыі.
У аснове прыняцця такіх рашэнняў ляжаць матэматычныя мадэлі, якія аналізуюць як дадзеныя самой заяўкі, так і дадзеныя нашага сховішча. Акрамя скоринга падобныя статыстычныя метады таксама могуць выкарыстоўвацца ў працы сэрвісу фармавання індывідуальных рэкамендацый па новых прадуктах для нашых кліентаў.
Метад такой адзнакі можа прымаць самыя розныя дадзеныя на ўваходзе. А ў нейкі момант мы можам дадаць на ўваход новы параметр, які па выніках аналізу на гістарычных даных павысіць канверсію выкарыстання сэрвісу.
У нас захоўваецца мноства дадзеных аб узаемаадносінах з кліентамі, і аб'ём гэтай інфармацыі бесперапынна расце. Каб скорынг працаваў, для апрацоўкі дадзеных патрэбныя яшчэ і правілы (ці матэматычныя мадэлі), якія дазваляюць хутка прыняць рашэнне каму заяўку ўхваліць, каму адказаць адмовай, а каму яшчэ парачку прадуктаў прапанаваць, ацаніўшы яго патэнцыйную зацікаўленасць.
Для пастаўленай задачы ў нас ужо выкарыстоўваецца спецыялізаваная сістэма прыняцця рашэнняў , Якая, на аснове зададзеных аналітыкамі, тэхнолагамі і распрацоўшчыкамі правілаў вырашае, ухваліць той ці іншы банкаўскі прадукт кліенту або адмовіць.
На рынку існуе мноства гатовых рашэнняў як скорынгавых мадэляў, так і саміх сістэм прыняцця рашэнняў. Адну з такіх сістэм мы выкарыстоўваем у сябе ў кампаніі. Але бізнэс расце, дыверсіфікуецца, павялічваецца як колькасць кліентаў, так і колькасць прапанаваных прадуктаў, а нароўні з гэтым з'яўляюцца ідэі як мага палепшыць існуючы працэс прыняцця рашэнняў. Напэўна ў людзей, якія працуюць з існуючай сістэмай, ёсць мноства ідэй як зрабіць прасцей, лепш, зручней, але часам бываюць карысныя ідэі са боку. З мэтай збору разумных ідэй і быў арганізаваны Новы Хакатон.
Пастаўленая задача
Хакатон праводзіўся 23 лютага. Удзельнікам была прапанавана баявая задача: распрацаваць сістэму прыняцця рашэнняў, якая павінна была адпавядаць шэрагу ўмоў.
Нам распавялі, як функцыянуе існуючая сістэма і якія складанасці ўзнікаюць пры яе эксплуатацыі, а таксама якія бізнес-мэты павінна пераследваць распрацоўваная платформа. У сістэмы павінен быць хуткі time-to-market распрацоўваных правіл, каб працоўны код аналітыкаў пападаў у прадакшн як мага хутчэй. А для ўваходнага патоку заявак час прыняцця рашэння павінен імкнуцца да мінімуму. Таксама распрацоўваная сістэма павінна мець магчымасці cross-sell, каб даваць кліенту магчымасць набыць іншыя прадукты кампаніі ў выпадку іх ухвалы з нашага боку і патэнцыйнай зацікаўленасці са боку кліента.
Зразумела, што за адну ноч немагчыма напісаць ready-to-release праект які абавязкова пойдзе ў прадакшн, ды і ўсю сістэму цалкам ахапіць даволі складана, таму нам было прапанавана рэалізаваць хаця б яе частку. Быў устаноўлены шэраг патрабаванняў, якім павінен задавальняць прататып. Можна было паспрабаваць як ахапіць усе патрабаванні цалкам, так і дэталёва прапрацаваць асобныя раздзелы распрацоўванай платформы.
Што да тэхналогій, то ўсім удзельнікам была прадастаўлена поўная свабода выбару. Можна было выкарыстоўваць любыя канцэпцыі і тэхналогіі: Data streaming, machine learning, event sourcing, big data і іншыя.
Нашае рашэнне
Правёўшы невялікі мазгавы штурм мы вырашылі, што для выканання пастаўленай задачы ідэальна падыдзе FaaS рашэнне.
Для дадзенага рашэння неабходна было знайсці прыдатны Serverless фрэймворк для рэалізацыі правіл распрацоўванай сістэмы прыняцця рашэнняў. Так як у Тинькофф для кіравання інфраструктурай актыўна выкарыстоўваецца Kubernetes, мы разгледзелі некалькі гатовых рашэнняў на яго аснове, падрабязней аб ім я раскажу далей.
Для пошуку найболей эфектыўнага рашэння мы зірнулі на распрацоўваны прадукт вачамі яе карыстачоў. Асноўныя карыстальнікі нашай сістэмы - аналітыкі, якія займаюцца распрацоўкай правілаў. Правілы неабходна дэплоіць на сервер, ці як у нашым выпадку, разгортваць у воблаку, для наступнага прыняцця рашэнняў. З пазіцыі аналітыка працоўны працэс выглядае наступным чынам:
- Аналітык піша скрыпт, правіла, або ML мадэль, засноўваючыся на дадзеных са сховішча. У рамках хакатона мы вырашылі выкарыстоўваць Mongodb, але выбар сістэмы захоўвання дадзеных тут не прынцыповы.
- Пасля тэсціравання распрацаваных правілаў на гістарычных дадзеных, аналітык залівае свой код у адмінку.
- З мэтай забеспячэння версіявання ўвесь код будзе трапляць у Git-рэпазітары.
- Праз адмінку можна будзе разгарнуць код у воблаку як асобны функцыянальны Serverless модуль.
Зыходныя дадзеныя ад кліентаў павінны праходзіць праз спецыялізаваны Enrichment-сэрвіс, прызначаны для ўзбагачэння першапачатковага запыту дадзенымі са сховішча. Важна было рэалізаваць дадзены сэрвіс такім чынам, каб забяспечвалася праца з адзіным сховішчам (з якога аналітык бярэ дадзеныя пры распрацоўцы правіл), для падтрымання адзінай структуры дадзеных.
Яшчэ да хакатона мы вызначыліся з Serverless-фрэймворкам, які будзем выкарыстоўваць. На сённяшні дзень на рынку даволі шмат тэхналогій, якія рэалізуюць гэты падыход. Найбольш папулярнымі рашэннямі ў рамках Kubernetes архітэктуры з'яўляюцца Fission, Open FaaS і Kubeless. Ёсць нават .
Узважыўшы ўсе плюсы і мінусы мы спынілі свой выбар на . Дадзены Serverless-фрэймворк даволі просты ў кіраванні і задавальняе патрабаванням пастаўленай задачы.
Для працы з Fission неабходна разумець дзве асноўныя канцэпцыі: function і environment. Функцыяй (function) з'яўляецца кавалак кода напісаны на адной з моў для якога ёсць Fission-асяроддзе (environment). уключае ў сябе Python, JS, Go, JVM і мноства іншых папулярных моў і тэхналогій.
Таксама Fission здольны выконваць функцыі, пабітыя на некалькі файлаў, папярэдне спакаваныя ў архіў. Праца Fission у кластары Kubernetes забяспечваецца спецыялізаванымі падамі, кіраванне якімі бярэ на сябе сам фрэймворк. Для ажыццяўлення ўзаемадзеяння з подамі кластара, на кожную функцыю неабходна прызначыць свой роўт, і ў які можна перадаваць GET параметры або request body у выпадку POST запыту.
У выніку мы планавалі атрымаць рашэнне, якое дазваляе аналітыкам разгортваць распрацаваныя скрыпты правіл без удзелу інжынераў і распрацоўшчыкаў. Апісаны падыход таксама пазбаўляе распрацоўшчыкаў ад неабходнасці перапісваць код аналітыкаў на іншую мову. Напрыклад, для бягучай, выкарыстоўванай намі сістэмы прыняцця рашэнняў прыходзіцца пісаць правілы на вузкапрофільных тэхналогіях і мовах, вобласць ужывання якіх вельмі абмежавана, а таксама прысутнічае моцная залежнасць ад сервера прыкладанняў, бо ўсе праекты правіл банка дэплояцца на адзіным асяроддзі. У выніку чаго для дэплою новых правіл неабходна выконваць рэліз усёй сістэмы.
У прапанаваным намі рашэнні адсутнічае неабходнасць рэлізу правіл, код лёгка разгортваецца па адным націску кнопкі. Гэтак жа кіраванне інфраструктурай у Kubernetes дазваляе не думаць аб нагрузцы і маштабаванні, падобныя праблемы вырашаюцца са скрынкі . А выкарыстанне адзінага сховішчы дадзеных пазбаўляе ад неабходнасці супастаўлення real-time дадзеных з гістарычнымі, што спрашчае працу аналітыка.
Што ў нас атрымалася
Бо на хакатон мы дашлі з ужо гатовым рашэннем (у нашых фантазіях), нам засталося толькі пераўтварыць усе нашы думкі ў радкі кода.
Заклад поспеху на любым хакатоне - гэта падрыхтоўка і добра складзены план. Таму, перш за ўсё мы вызначыліся з якіх модуляў будзе складацца архітэктура нашай сістэмы і якія тэхналогіі мы будзем выкарыстоўваць.
Архітэктура нашага праекта была наступнай:
На дадзенай схеме пазначаны дзве кропкі ўваходу, аналітык (асноўны карыстальнік нашай сістэмы) і кліент.
Працэс працы пабудаваны так. Аналітык распрацоўвае функцыю-правіла і функцыю ўзбагачэння дадзенымі для сваёй мадэлі, захоўвае свой код у Git-рэпазітар, і праз прыкладанне адміністратара разгортвае сваю мадэль у воблаку. Разгледзім як разгорнутая функцыя будзе выклікацца і прымаць рашэнні па ўваходных заяўках ад кліентаў:
- Кліент запаўняючы форму на сайце, дасылае свой запыт на кантролер. На ўваход сістэмы прыходзіць заяўка, па якой неабходна прыняць рашэнне, і запісваецца ў БД у сваім першапачатковым выглядзе.
- Далей волкі запыт адпраўляецца на ўзбагачэнне, калі ў гэтым ёсць неабходнасць. Дапоўніць першапачатковы запыт можна дадзенымі як ад вонкавых сэрвісаў так і са сховішча. Атрыманы абагачаны запыт таксама захоўваецца ў БД.
- Запускаецца функцыя аналітыка, якая на ўваход прымае ўзбагачаны запыт і аддае рашэнне, якое таксама запісваецца ў сховішча.
У якасці сховішча ў нашай сістэме мы вырашылі выкарыстаць MongoDB у выглядзе дакуменарынтаванага захоўвання дадзеных у выглядзе JSON дакументаў, бо сэрвісы ўзбагачэння, уключаючы зыходны запыт, агрэгавалі ўсе дадзеныя праз REST-кантролеры.
Такім чынам, на рэалізацыю платформы ў нас у распараджэнні былі суткі. Мы даволі ўдала размеркавалі ролі, кожны чалец каманды меў сваю зону адказнасці ў нашым праекце:
- Франтэнд-адмінкі для працы аналітыка, праз якую ён мог загружаць правілы з сістэмы кантролю версіявання напісаных скрыптоў, выбіраць варыянты ўзбагачэння ўваходных дадзеных і правіць скрыпты правілаў анлайн.
- Бэкенд-адмінкі, які ўключае ў сябе REST API для фронту і інтэграцыю з VCS.
- Настройка інфраструктуры ў Google Cloud і распрацоўка сэрвісу ўзбагачэння зыходных дадзеных.
- Модуль інтэграцыі прыкладання адмінкі з Serverless-фрэймворкам для наступнага дэплою правілаў.
- Скрыпты правілаў для тэсціравання працаздольнасці ўсёй сістэмы і агрэгацыя аналітыкі па ўваходных заяўках (прынятых рашэннях) для фінальнай дэманстрацыі.
Пачнем па парадку.
Франтэнд у нас быў напісаны на Angular 7 з выкарыстаннем банкаўскага UI Kit. Фінальны варыянт адмінкі выглядаў наступным чынам:
Так як часу было няшмат, мы пастараліся рэалізаваць толькі ключавы функцыянал. Для дэплою функцыі ў Kubernetes кластар неабходна было абраць падзею (сэрвіс, для якога неабходна разгарнуць правіла ў воблаку) і код код функцыі, якая рэалізуе логіку прыняцця рашэння. Па кожным разгортванні правіла для абранага сэрвісу мы пісалі лог гэтай падзеі. У адмінцы можна было бачыць логі ўсіх падзей.
Увесь код функцый захоўваўся ў выдаленым Git-рэпазітары, які таксама неабходна было задаваць у адмінцы. Для версіявання кода ўсе функцыі захоўваліся ў розных галінках рэпазітара. У адмінцы таксама прадугледжана магчымасць унясення карэкціровак у напісаныя скрыпты, каб перад дэплоем функцыі ў прадакшн можна было не толькі праверыць напісаны код, але і ўнесці неабходныя праўкі.
Апроч функцый правіл мы таксама рэалізавалі магчымасць паэтапнага ўзбагачэння зыходных дадзеных з дапамогай Enrichment-функцый, код якіх таксама ўяўляў сабою скрыпты, у якіх можна было хадзіць у сховішча дадзеных, выклікаць іншыя сэрвісы і выканаць папярэднія разлікі. Для дэманстрацыі нашага рашэння мы разлічвалі знак задыяку кліента, які пакінуў заяўку, і вызначалі яго мабільнага аператара выкарыстоўваючы іншы REST сэрвіс.
Бэкенд платформы быў напісаны на Java і рэалізаваны як Spring Boot прыкладанне. Для захоўвання дадзеных адмінкі мы першапачаткова планавалі выкарыстоўваць Postgres, але, у рамках хакатона, вырашылі абмежавацца просценькім H2, у мэтах эканоміі часу. На бэке была рэалізавана інтэграцыя з Bitbucket, для версіявання функцый узбагачэння запытаў і скрыптоў правілаў. Для інтэграцыі з выдаленымі Git рэпазітарамі выкарыстоўвалася , Якая з'яўляецца свайго роду абгорткай над CLI камандамі, якая дазваляе выконваць любыя git інструкцыі, выкарыстоўваючы зручны праграмны інтэрфейс. Так у нас было два асобныя рэпазітары, для функцый узбагачэння і правілаў, а ўсе скрыпты раскладзены па дырэкторыях. Праз UI можна было абраць апошні коміт скрыпту адвольнай галінкі рэпазітара. Пры занясенні правак у код праз адмінку ў выдаленых рэпазітарах ствараліся коміты змененага кода.
Для рэалізацыі нашай ідэі нам была неабходная прыдатная інфраструктура. Мы прынялі рашэнне разгарнуць наш Kubernetes кластар у воблаку. Наш выбар спыніўся на Google Cloud Platform. Serverless-фрэймворк Fission быў усталяваны ў кластары Kubernetes, які мы разгарнулі ў Gcloud. Першапачаткова сэрвіс узбагачэння зыходных дадзеных быў рэалізаваны асобным Java-дадаткам абгорнутым у Pod усярэдзіне кластара k8s. Але пасля папярэдняй дэманстрацыі нашага праекта ў сярэдзіне хакатона, нам парэкамендавалі зрабіць Enrichment сэрвіс больш гнуткім, каб даць магчымасць выбіраць, як узбагачаць волкія дадзеных уваходных заявак. І нам нічога не заставалася, акрамя як зрабіць сэрвіс узбагачэння таксама Serverless.
Для працы з Fission мы выкарыстоўвалі Fission CLI, якую неабходна ўсталёўваць па-над Kubernetes CLI. Дэплой функцый у k8s кластар даволі просты, неабходна толькі прызначыць для функцыі ўнутраны роўт і ingress для дазволу ўваходнага трафіку, калі неабходзен доступ па-за кластарам. Разгортванне адной функцыі як правіла займае не больш за 10 секунд.
Фінальны паказ праекта і падвядзенне вынікаў
Для дэманстрацыі працы нашай сістэмы мы размясцілі на выдаленым серверы прасценькую форму, на якой можна падаць заяўку на адзін з прадуктаў банка. Для запыту неабходна было ўвесці свае ініцыялы, дату нараджэння і нумар тэлефона.
Дадзеныя з кліенцкай формы сыходзілі на кантролер, які раўналежна адпраўляў заяўкі на ўсе даступныя правілы, папярэдне ўзбагаціўшы дадзеныя паводле зададзеных умоў, і захаваўшы іх у агульнае сховішча. Усяго ў нас было разгорнута тры функцыі якія прымаюць рашэнне па ўваходных заяўках і 4 сэрвісу ўзбагачэння дадзенымі. Пасля адпраўлення заяўкі кліент атрымліваў нашае рашэнне:
Кліент апроч адмовы ці ўхвалы таксама атрымліваў спіс іншых прадуктаў, запыты на якія мы адпраўлялі раўналежна. Так мы прадэманстравалі магчымасць cross-sale у нашай платформе.
Усяго было даступна 3 выдуманых прадукта банка:
- Крэдыт.
- цацка
- Іпатэка.
На кожную паслугу падчас дэманстрацый мы разгарнулі падрыхтаваныя функцыі і скрыпты ўзбагачэння.
Для кожнага правіла быў неабходны свой набор уваходных дадзеных. Так, для ўхвалення іпатэкі мы вылічалі знак задыяку кліента і злучалі гэта з логікай месяцовага календара. Для ўхвалення цацкі мы правяралі, што кліент дасягнуў паўналецця, а для выдачы крэдыту мы адпраўлялі запыт у вонкавы адкрыты сэрвіс вызначэння сотавага аператара, і па ім прымалі рашэнне.
Мы паспрабавалі зрабіць нашую дэманстрацыю цікавай і інтэрактыўнай, кожны прысутны мог зайсці на нашу форму і праверыць даступнасць яму нашых выдуманых паслуг. А ў самым канцы прэзентацыі мы прадэманстравалі аналітыку заявак, якія паступілі, дзе было паказана, колькі людзей скарысталіся нашым сэрвісам, колькасць адабрэнняў, адмоваў.
Для збору аналітыкі ў рэжыме анлайн мы дадаткова разгарнулі BI інструмент з адкрытым зыходным кодам і прыкруцілі яго да нашага сховішча. Metabase дазваляе будаваць экраны з аналітыкай па якія цікавяць нас дадзеным, неабходна толькі прапісаць падлучэнне да БД, абраць табліцы (у нашым выпадку калекцыі дадзеных, бо мы выкарыстоўвалі MongoDB), і паказаць якія цікавяць нас палі.
У выніку ў нас атрымаўся нядрэнны прататып платформы прыняцця рашэнняў, і на дэманстрацыі кожны слухач мог уласнаручна праверыць яе працаздольнасць. Цікавае рашэнне, гатовы прататып і паспяховая дэманстрацыя дазволілі нам перамагчы, нягледзячы на моцную канкурэнцыю ў асобе іншых каманд. Упэўнены, што па праекце кожнай каманды можна таксама напісаць цікавы артыкул.
Крыніца: habr.com