Duke filluar nga viti i kaluar, kompania jonë filloi organizimin e hakatonëve. Konkursi i parë i tillë ishte shumë i suksesshëm, ne kemi shkruar për të në . Hackathoni i dytë u zhvillua në shkurt 2019 dhe ishte jo më pak i suksesshëm. Për qëllimet e mbajtjes së kësaj të fundit jo shumë kohë më parë organizator.
Pjesëmarrësve iu dha një detyrë mjaft interesante me liri të plotë në zgjedhjen e një pirg teknologjie për zbatimin e saj. Ishte e nevojshme të zbatohej një platformë vendimmarrëse për vendosjen e përshtatshme të funksioneve të vlerësimit të klientit që mund të funksiononte me një fluks të shpejtë aplikacionesh, të përballonte ngarkesa të rënda dhe vetë sistemi ishte lehtësisht i shkallëzueshëm.
Detyra është jo e parëndësishme dhe mund të zgjidhet në shumë mënyra, siç u bindëm gjatë demonstrimit të prezantimeve përfundimtare të projekteve të pjesëmarrësve. Në hackathon ishin 6 ekipe me 5 persona, të gjithë pjesëmarrësit kishin projekte të mira, por platforma jonë doli të ishte më konkurruese. Kemi një projekt shumë interesant, për të cilin do të doja të flisja në këtë artikull.
Zgjidhja jonë është një platformë e bazuar në arkitekturën pa server brenda Kubernetes, e cila redukton kohën që duhet për të sjellë funksione të reja në prodhim. Ai i lejon analistët të shkruajnë kodin në një mjedis të përshtatshëm për ta dhe ta vendosin atë në prodhim pa pjesëmarrjen e inxhinierëve dhe zhvilluesve.
Çfarë po shënon
Tinkoff.ru, si shumë kompani moderne, ka vlerësimin e klientëve. Notimi është një sistem vlerësimi i klientit i bazuar në metodat statistikore të analizës së të dhënave.
Për shembull, një klient na drejtohet me një kërkesë për t'i dhënë atij një kredi, ose për të hapur një llogari sipërmarrësi individual me ne. Nëse planifikojmë t'i lëshojmë një kredi, atëherë duhet të vlerësojmë aftësinë paguese të tij, dhe nëse llogaria është një sipërmarrës individual, atëherë duhet të jemi të sigurt që klienti nuk do të kryejë transaksione mashtruese.
Baza për marrjen e vendimeve të tilla janë modelet matematikore që analizojnë të dhënat nga vetë aplikacioni dhe të dhënat nga ruajtja jonë. Përveç pikëzimit, metoda të ngjashme statistikore mund të përdoren edhe në shërbim të gjenerimit të rekomandimeve individuale për produkte të reja për klientët tanë.
Metoda e një vlerësimi të tillë mund të pranojë një sërë të dhënash hyrëse. Dhe në një moment mund të shtojmë një parametër të ri në hyrje, i cili, bazuar në rezultatet e analizës mbi të dhënat historike, do të rrisë shkallën e konvertimit të përdorimit të shërbimit.
Ne mbajmë një mori të dhënash për marrëdhëniet me klientët dhe vëllimi i këtij informacioni po rritet vazhdimisht. Që vlerësimi të funksionojë, përpunimi i të dhënave kërkon gjithashtu rregulla (ose modele matematikore) që ju lejojnë të vendosni shpejt se kush të miratojë një aplikacion, kë të refuzojë dhe kujt të ofrojë disa produkte të tjera, duke vlerësuar interesin e tyre të mundshëm.
Për detyrën në fjalë, ne tashmë përdorim një sistem të specializuar të vendimmarrjes , e cila, bazuar në rregullat e vendosura nga analistë, teknologë dhe zhvillues, vendos nëse do t'i miratojë apo refuzojë klientit një produkt të caktuar bankar.
Ka shumë zgjidhje të gatshme në treg, si modelet e vlerësimit, ashtu edhe vetë sistemet e vendimmarrjes. Ne përdorim një nga këto sisteme në kompaninë tonë. Por biznesi po rritet, po diversifikohet, si numri i klientëve ashtu edhe numri i produkteve të ofruara po rriten dhe bashkë me këtë po shfaqen ide se si të përmirësohet procesi ekzistues i vendimmarrjes. Sigurisht që njerëzit që punojnë me sistemin ekzistues kanë shumë ide se si ta bëjnë atë më të thjeshtë, më të mirë, më të përshtatshëm, por ndonjëherë idetë nga jashtë janë të dobishme. Hackathon i ri u organizua me qëllim të mbledhjes së ideve të shëndosha.
Detyrë
Hackathon u mbajt më 23 shkurt. Pjesëmarrësve iu ofrua një detyrë luftarake: zhvillimi i një sistemi vendimmarrës që duhej të plotësonte një sërë kushtesh.
Na u tha se si funksionon sistemi ekzistues dhe çfarë vështirësish lindin gjatë funksionimit të tij, si dhe çfarë qëllimesh biznesi duhet të ndjekë platforma e zhvilluar. Sistemi duhet të ketë një kohë të shpejtë në treg për zhvillimin e rregullave në mënyrë që kodi i punës i analistëve të hyjë në prodhim sa më shpejt të jetë e mundur. Dhe për fluksin hyrës të aplikimeve, koha e vendimmarrjes duhet të jetë minimale. Gjithashtu, sistemi që po zhvillohet duhet të ketë aftësi ndër-sell në mënyrë që t'i japë klientit mundësinë për të blerë produkte të tjera të kompanisë nëse ato janë të miratuara nga ne dhe kanë interes të mundshëm nga klienti.
Është e qartë se është e pamundur të shkruhet një projekt i gatshëm për publikim brenda natës që sigurisht do të hyjë në prodhim dhe është mjaft e vështirë të mbulohet i gjithë sistemi, ndaj na kërkuan të zbatonim të paktën një pjesë të tij. U krijuan një sërë kërkesash që prototipi duhet të plotësojë. Ishte e mundur të përpiqeshim të mbulonim të gjitha kërkesat në tërësinë e tyre, dhe të punonim në detaje në seksione individuale të platformës që po zhvillohet.
Sa i përket teknologjisë, të gjithë pjesëmarrësve iu dha liria e plotë e zgjedhjes. Ishte e mundur të përdoreshin çdo koncept dhe teknologji: Transmetimi i të dhënave, mësimi i makinerive, burimi i ngjarjeve, të dhënat e mëdha dhe të tjera.
Zgjidhja jonë
Pas një stuhie të vogël idesh, vendosëm që një zgjidhje FaaS do të ishte ideale për të përfunduar detyrën.
Për këtë zgjidhje, ishte e nevojshme të gjendej një kornizë e përshtatshme pa server për të zbatuar rregullat e sistemit të vendimmarrjes që po zhvillohet. Meqenëse Tinkoff përdor në mënyrë aktive Kubernetes për menaxhimin e infrastrukturës, ne shikuam disa zgjidhje të gatshme bazuar në të; unë do t'ju tregoj më shumë rreth tij më vonë.
Për të gjetur zgjidhjen më efektive, ne shikuam produktin që po zhvillohet përmes syve të përdoruesve të tij. Përdoruesit kryesorë të sistemit tonë janë analistët e përfshirë në zhvillimin e rregullave. Rregullat duhet të vendosen në server, ose, si në rastin tonë, të vendosen në cloud, për vendimmarrje të mëvonshme. Nga këndvështrimi i një analisti, rrjedha e punës duket si kjo:
- Analisti shkruan një skript, rregull ose model ML bazuar në të dhënat nga magazina. Si pjesë e hackathon, vendosëm të përdorim Mongodb, por zgjedhja e sistemit të ruajtjes së të dhënave nuk është e rëndësishme këtu.
- Pas testimit të rregullave të zhvilluara mbi të dhënat historike, analisti ngarkon kodin e tij në panelin e administratorit.
- Për të siguruar versionimin, i gjithë kodi do të shkojë në depot e Git.
- Nëpërmjet panelit të administratorit do të mundësohet vendosja e kodit në cloud si një modul i veçantë funksional pa server.
Të dhënat fillestare nga klientët duhet të kalojnë përmes një shërbimi të specializuar Pasurimi të krijuar për të pasuruar kërkesën fillestare me të dhëna nga magazina. Ishte e rëndësishme të zbatohej ky shërbim në atë mënyrë që të funksiononte me një depo të vetme (nga e cila analisti merr të dhëna kur zhvillon rregullat) për të ruajtur një strukturë të unifikuar të dhënash.
Edhe përpara hackathon-it, ne vendosëm për kornizën pa server që do të përdornim. Sot ka mjaft teknologji në treg që zbatojnë këtë qasje. Zgjidhjet më të njohura brenda arkitekturës Kubernetes janë Fission, Open FaaS dhe Kubeless. Madje ka .
Pasi peshuam të mirat dhe të këqijat, ne zgjodhëm . Ky kuadër pa server është mjaft i lehtë për t'u menaxhuar dhe plotëson kërkesat e detyrës.
Për të punuar me Fission, duhet të kuptoni dy koncepte bazë: funksionin dhe mjedisin. Një funksion është një pjesë kodi e shkruar në një nga gjuhët për të cilën ekziston një mjedis Fission. përfshin Python, JS, Go, JVM dhe shumë gjuhë dhe teknologji të tjera të njohura.
Fission është gjithashtu i aftë të kryejë funksione të ndara në disa skedarë, të paketuar paraprakisht në një arkiv. Funksionimi i Fission në një grup Kubernetes sigurohet nga pods të specializuara, të cilat menaxhohen nga vetë korniza. Për të bashkëvepruar me grupet e grupeve, çdo funksioni duhet t'i caktohet itinerarit të tij dhe të cilit mund t'i kaloni parametrat GET ose trupin e kërkesës në rastin e një kërkese POST.
Si rezultat, ne planifikuam të merrnim një zgjidhje që do t'i lejonte analistët të vendosnin skriptet e rregullave të zhvilluara pa pjesëmarrjen e inxhinierëve dhe zhvilluesve. Qasja e përshkruar gjithashtu eliminon nevojën që zhvilluesit të rishkruajnë kodin e analistit në një gjuhë tjetër. Për shembull, për sistemin aktual të vendimmarrjes që përdorim, duhet të shkruajmë rregulla në teknologji dhe gjuhë shumë të specializuara, fushëveprimi i të cilave është jashtëzakonisht i kufizuar, dhe gjithashtu ekziston një varësi e fortë nga serveri i aplikacionit, pasi të gjitha draft rregullat e bankës vendosen në një mjedis të vetëm. Si rezultat, për të vendosur rregulla të reja është e nevojshme të lirohet i gjithë sistemi.
Në zgjidhjen tonë të propozuar, nuk ka nevojë të lëshohen rregulla; kodi mund të vendoset lehtësisht me klikimin e një butoni. Gjithashtu, menaxhimi i infrastrukturës në Kubernetes ju lejon të mos mendoni për ngarkesën dhe shkallëzimin; probleme të tilla zgjidhen jashtë kutisë. Dhe përdorimi i një magazine të vetme të dhënash eliminon nevojën për të krahasuar të dhënat në kohë reale me të dhënat historike, gjë që thjeshton punën e analistit.
Ajo që kemi marrë
Meqenëse erdhëm në hackathon me një zgjidhje të gatshme (në fantazitë tona), gjithçka që duhej të bënim ishte të kthenim të gjitha mendimet tona në rreshta kodi.
Çelësi i suksesit në çdo hackathon është përgatitja dhe një plan i shkruar mirë. Prandaj, gjëja e parë që bëmë ishte të vendosnim se nga cilat module do të përbëhej arkitektura e sistemit tonë dhe cilat teknologji do të përdornim.
Arkitektura e projektit tonë ishte si më poshtë:
Ky diagram tregon dy pika hyrëse, analistin (përdoruesi kryesor i sistemit tonë) dhe klienti.
Procesi i punës është i strukturuar kështu. Analisti zhvillon një funksion rregulli dhe një funksion të pasurimit të të dhënave për modelin e tij, ruan kodin e tij në një depo Git dhe vendos modelin e tij në cloud përmes aplikacionit të administratorit. Le të shqyrtojmë se si do të thirret funksioni i vendosur dhe të marrim vendime për kërkesat hyrëse nga klientët:
- Klienti plotëson një formular në faqen e internetit dhe ia dërgon kërkesën e tij kontrolluesit. Një aplikacion mbi të cilin duhet të merret një vendim vjen në hyrjen e sistemit dhe regjistrohet në bazën e të dhënave në formën e tij origjinale.
- Më pas, kërkesa e papërpunuar dërgohet për pasurim, nëse është e nevojshme. Ju mund ta plotësoni kërkesën fillestare me të dhëna si nga shërbimet e jashtme ashtu edhe nga ruajtja. Pyetja e pasuruar që rezulton ruhet gjithashtu në bazën e të dhënave.
- Nis funksioni i analistit, i cili merr një pyetje të pasuruar si hyrje dhe prodhon një zgjidhje, e cila gjithashtu shkruhet në ruajtje.
Ne vendosëm të përdorim MongoDB si një ruajtje në sistemin tonë për shkak të ruajtjes së të dhënave të orientuara nga dokumentet në formën e dokumenteve JSON, pasi shërbimet e pasurimit, përfshirë kërkesën origjinale, grumbulluan të gjitha të dhënat përmes kontrollorëve REST.
Pra, kishim XNUMX orë për të zbatuar platformën. Ne i shpërndamë rolet me mjaft sukses; secili anëtar i ekipit kishte fushën e tij të përgjegjësisë në projektin tonë:
- Panelet e administrimit të përparme për punën e analistit, përmes të cilave ai mund të shkarkonte rregullat nga sistemi i kontrollit të versioneve të skripteve të shkruara, të zgjidhte opsione për pasurimin e të dhënave hyrëse dhe të modifikonte skriptet e rregullave në internet.
- Administratori i Backend, duke përfshirë REST API për pjesën e përparme dhe integrimin me VCS.
- Vendosja e infrastrukturës në Google Cloud dhe zhvillimi i një shërbimi për pasurimin e të dhënave burimore.
- Një modul për integrimin e aplikacionit të administratorit me kornizën pa server për vendosjen e mëvonshme të rregullave.
- Skriptet e rregullave për testimin e performancës së të gjithë sistemit dhe grumbullimin e analitikëve në aplikacionet hyrëse (vendimet e marra) për demonstrimin përfundimtar.
Le të fillojmë me rregull.
Ballina jonë u shkrua në Angular 7 duke përdorur kompletin e UI-së bankare. Versioni përfundimtar i panelit të administratorit dukej kështu:
Meqenëse kishte pak kohë, ne u përpoqëm të zbatonim vetëm funksionalitetin kryesor. Për të vendosur një funksion në grupin Kubernetes, ishte e nevojshme të zgjidhej një ngjarje (një shërbim për të cilin një rregull duhet të vendoset në cloud) dhe kodin e funksionit që zbaton logjikën e vendimmarrjes. Për çdo vendosje të një rregulli për shërbimin e zgjedhur, ne kemi shkruar një regjistër të kësaj ngjarjeje. Në panelin e administratorit mund të shihni regjistrat e të gjitha ngjarjeve.
I gjithë kodi i funksionit u ruajt në një depo të largët të Git, e cila gjithashtu duhej të vendosej në panelin e administratorit. Për të versionuar kodin, të gjitha funksionet u ruajtën në degë të ndryshme të depove. Paneli i administratorit ofron gjithashtu mundësinë për të bërë rregullime në skriptet e shkruara, në mënyrë që përpara se të vendosni një funksion në prodhim, jo vetëm që mund të kontrolloni kodin e shkruar, por edhe të bëni ndryshimet e nevojshme.
Përveç funksioneve të rregullave, ne kemi zbatuar gjithashtu aftësinë për të pasuruar gradualisht të dhënat e burimit duke përdorur funksionet e Pasurimit, kodi i të cilave ishte gjithashtu skriptet në të cilat ishte e mundur të shkoni në depon e të dhënave, të telefononi shërbime të palëve të treta dhe të kryeni llogaritjet paraprake. . Për të demonstruar zgjidhjen tonë, ne llogaritëm shenjën e zodiakut të klientit që la kërkesën dhe përcaktuam operatorin e tij celular duke përdorur një shërbim REST të palës së tretë.
Backend-i i platformës u shkrua në Java dhe u zbatua si një aplikacion Spring Boot. Fillimisht planifikuam të përdorim Postgres për të ruajtur të dhënat e administratorit, por, si pjesë e hackathon, vendosëm të kufizoheshim në një H2 të thjeshtë për të kursyer kohë. Në backend, integrimi me Bitbucket u zbatua për të versionuar funksionet e pasurimit të pyetjeve dhe skriptet e rregullave. Për integrimin me depot e largëta të Git, ne përdorëm , i cili është një lloj mbështjellësi mbi komandat CLI, që ju lejon të ekzekutoni çdo instruksion git duke përdorur një ndërfaqe të përshtatshme softueri. Pra, ne kishim dy depo të veçanta për funksionet dhe rregullat e pasurimit, dhe të gjithë skriptet u ndanë në drejtori. Nëpërmjet UI ishte e mundur të zgjidhej kryerja më e fundit e një skripti të një dege arbitrare të depove. Kur bëni ndryshime në kod përmes panelit të administratorit, komponimet e kodit të ndryshuar u krijuan në depo të largëta.
Për të zbatuar idenë tonë, na duhej një infrastrukturë e përshtatshme. Ne vendosëm të vendosim grupin tonë Kubernetes në re. Zgjedhja jonë ishte Google Cloud Platform. Korniza pa server të Fission u instalua në një grup Kubernetes, të cilin e vendosëm në Gcloud. Fillimisht, shërbimi i pasurimit të të dhënave burimore u zbatua si një aplikacion i veçantë Java i mbështjellë në një Pod brenda grupit k8s. Por pas një demonstrimi paraprak të projektit tonë në mes të hakatonit, na u rekomandua ta bënim shërbimin e Enrichment më fleksibël për të ofruar mundësinë për të zgjedhur se si të pasurojmë të dhënat e papërpunuara të aplikacioneve hyrëse. Dhe ne nuk kishim zgjidhje tjetër veçse ta bënim shërbimin e pasurimit gjithashtu pa server.
Për të punuar me Fission, ne përdorëm Fission CLI, i cili duhet të instalohet në krye të Kubernetes CLI. Vendosja e funksioneve në një grup k8s është mjaft e thjeshtë; ju vetëm duhet të caktoni një rrugë të brendshme dhe hyrje në funksion për të lejuar trafikun në hyrje nëse nevojitet akses jashtë grupit. Vendosja e një funksioni zakonisht zgjat jo më shumë se 10 sekonda.
Prezantimi përfundimtar i projektit dhe përmbledhja
Për të demonstruar se si funksionon sistemi ynë, ne kemi vendosur një formular të thjeshtë në një server në distancë ku mund të paraqisni një aplikim për një nga produktet e bankës. Për të kërkuar, duhej të futje inicialet, datën e lindjes dhe numrin e telefonit.
Të dhënat nga formulari i klientit shkuan te kontrolluesi, i cili njëkohësisht dërgoi kërkesa për të gjitha rregullat e disponueshme, pasi kishte pasuruar më parë të dhënat sipas kushteve të specifikuara dhe i ruajti në një ruajtje të përbashkët. Në total, ne vendosëm tre funksione që marrin vendime për aplikacionet hyrëse dhe 4 shërbime të pasurimit të të dhënave. Pas dorëzimit të aplikacionit, klienti mori vendimin tonë:
Përveç refuzimit apo miratimit, klienti ka marrë edhe një listë me produkte të tjera, kërkesa për të cilat kemi dërguar paralelisht. Kjo është mënyra se si ne demonstruam mundësinë e shitjes së kryqëzuar në platformën tonë.
Kishte në dispozicion gjithsej 3 produkte fiktive bankare:
- Kredia.
- lodër
- Hipotekë.
Gjatë demonstrimit, ne vendosëm funksione të përgatitura dhe skripta pasurimi për secilin shërbim.
Çdo rregull kërkonte grupin e vet të të dhënave hyrëse. Pra, për të miratuar një hipotekë, ne llogaritëm shenjën e zodiakut të klientit dhe e lidhëm këtë me logjikën e kalendarit hënor. Për të miratuar një lodër, kontrolluam që klienti të kishte mbushur moshën madhore dhe për të lëshuar një kredi, i dërguam një kërkesë një shërbimi të hapur të jashtëm për përcaktimin e operatorit celular dhe u mor një vendim për të.
Ne u përpoqëm ta bënim demonstrimin tonë interesant dhe interaktiv, të gjithë të pranishmit mund të shkonin te formulari ynë dhe të kontrollonin disponueshmërinë e shërbimeve tona imagjinare për ta. Dhe në fund të prezantimit, ne demonstruam analitikë të aplikacioneve të pranuara, të cilat treguan se sa njerëz përdorën shërbimin tonë, numrin e miratimeve dhe refuzimeve.
Për të mbledhur analitikë në internet, ne vendosëm gjithashtu një mjet BI me burim të hapur dhe e vidhosëm në njësinë tonë të ruajtjes. Metabase ju lejon të ndërtoni ekrane me analitikë mbi të dhënat që na interesojnë; ju vetëm duhet të regjistroni një lidhje me bazën e të dhënave, të zgjidhni tabelat (në rastin tonë, koleksionet e të dhënave, pasi kemi përdorur MongoDB) dhe të specifikoni fushat me interes për ne .
Si rezultat, ne morëm një prototip të mirë të një platforme vendimmarrëse dhe gjatë demonstrimit, secili dëgjues mund të kontrollonte personalisht performancën e tij. Një zgjidhje interesante, një prototip i përfunduar dhe një demonstrim i suksesshëm na lejuan të fitonim, pavarësisht konkurrencës së fortë nga ekipet e tjera. Jam i sigurt se mund të shkruhet edhe një artikull interesant për projektin e secilit ekip.
Burimi: www.habr.com