Frá og með síðasta ári byrjaði fyrirtækið okkar að skipuleggja hackathons. Fyrsta slíka keppnin heppnaðist mjög vel, við skrifuðum um hana í . Annað hackathonið fór fram í febrúar 2019 og tókst ekki síður. Um markmiðin með því að halda hið síðarnefnda fyrir ekki svo löngu síðan skipuleggjandi.
Þátttakendur fengu frekar áhugavert verkefni með algjöru frelsi við að velja tæknibunka fyrir útfærslu hans. Nauðsynlegt var að innleiða ákvarðanatökuvettvang fyrir þægilega uppsetningu á einkunnaaðgerðum viðskiptavina sem gátu unnið með hröðu flæði forrita, þolað mikið álag og kerfið sjálft var auðvelt að skala.
Verkefnið er ekki léttvægt og hægt að leysa það á margan hátt, eins og við vorum sannfærð um í sýningu lokakynninga á verkefnum þátttakenda. Það voru 6 5 manna teymi á hakkaþoninu, allir þátttakendur voru með góð verkefni en vettvangurinn okkar reyndist samkeppnishæfastur. Við erum með mjög áhugavert verkefni sem mig langar að tala um í þessari grein.
Lausnin okkar er vettvangur byggður á Serverless arkitektúr inni í Kubernetes, sem dregur úr þeim tíma sem það tekur að koma nýjum eiginleikum í framleiðslu. Það gerir greinendum kleift að skrifa kóða í umhverfi sem hentar þeim og setja hann í framleiðslu án þátttöku verkfræðinga og þróunaraðila.
Hvað er að skora
Tinkoff.ru, eins og mörg nútíma fyrirtæki, hefur einkunn viðskiptavina. Stigagjöf er matskerfi viðskiptavina sem byggir á tölfræðilegum aðferðum við gagnagreiningu.
Til dæmis, viðskiptavinur leitar til okkar með beiðni um að gefa honum lán, eða stofna einstaklingsreikning hjá okkur. Ef við ætlum að gefa honum lán, þá þurfum við að meta greiðslugetu hans, og ef reikningurinn er einstaklingur frumkvöðull, þá þurfum við að vera viss um að viðskiptavinurinn muni ekki stunda sviksamleg viðskipti.
Grunnurinn að slíkum ákvörðunum eru stærðfræðilíkön sem greina bæði gögnin úr forritinu sjálfu og gögnin úr geymslunni okkar. Til viðbótar við stigagjöf er einnig hægt að nota svipaðar tölfræðilegar aðferðir við að búa til einstakar ráðleggingar um nýjar vörur fyrir viðskiptavini okkar.
Aðferðin við slíkt mat getur tekið við margvíslegum inntaksgögnum. Og á einhverjum tímapunkti getum við bætt nýrri færibreytu við inntakið, sem, byggt á niðurstöðum greiningar á sögulegum gögnum, mun auka viðskiptahlutfallið við notkun þjónustunnar.
Við höfum mikið af gögnum um samskipti við viðskiptavini og magn þessara upplýsinga fer stöðugt vaxandi. Til að skora virki þarf gagnavinnsla einnig reglur (eða stærðfræðilíkön) sem gera þér kleift að ákveða fljótt hver á að samþykkja umsókn, hverjum á að hafna og hverjum á að bjóða upp á nokkrar vörur í viðbót, og meta hugsanlegan áhuga þeirra.
Fyrir verkefnið sem fyrir liggur notum við nú þegar sérhæft ákvarðanatökukerfi , sem, á grundvelli reglna sem sérfræðingar, tæknifræðingar og þróunaraðilar setja, ákveða hvort eigi að samþykkja eða hafna tiltekinni bankavöru fyrir viðskiptavininn.
Það eru margar tilbúnar lausnir á markaðnum, bæði stigalíkön og ákvarðanatökukerfi sjálf. Við notum eitt af þessum kerfum í fyrirtækinu okkar. En fyrirtækið er að stækka, dreifist, bæði viðskiptavinum og vöruframboði fjölgar og samhliða þessu koma fram hugmyndir um hvernig megi bæta núverandi ákvarðanatökuferli. Vissulega hefur fólk sem vinnur með núverandi kerfi margar hugmyndir um hvernig eigi að gera það einfaldara, betra, þægilegra, en stundum eru hugmyndir utan frá gagnlegar. Nýja hackathonið var skipulagt með það að markmiði að safna góðum hugmyndum.
Verkefni
Hakkaþonið var haldið 23. febrúar. Þátttakendum var boðið upp á bardagaverkefni: að þróa ákvarðanatökukerfi sem þurfti að uppfylla ýmis skilyrði.
Okkur var sagt hvernig núverandi kerfi virkar og hvaða erfiðleikar koma upp við rekstur þess, sem og hvaða viðskiptamarkmiðum þróaði vettvangurinn ætti að stefna að. Kerfið verður að hafa hraðan tíma á markað til að þróa reglur þannig að vinnureglur greiningaraðila komist í framleiðslu eins fljótt og auðið er. Og fyrir komandi streymi umsókna ætti ákvörðunartíminn að vera í lágmarki. Einnig þarf kerfið sem verið er að þróa að hafa krosssölumöguleika til að gefa viðskiptavinum kost á að kaupa aðrar vörur fyrirtækisins ef þær eru samþykktar af okkur og hafa hugsanlegan áhuga viðskiptavinarins.
Það er ljóst að það er ómögulegt að skrifa tilbúið verkefni á einni nóttu sem fer örugglega í framleiðslu og það er frekar erfitt að ná yfir allt kerfið þannig að við vorum beðin um að útfæra að minnsta kosti hluta þess. Settar voru fram nokkrar kröfur sem frumgerðin þarf að uppfylla. Það var hægt að reyna bæði að uppfylla allar kröfur í heild sinni og að vinna ítarlega að einstökum hlutum vettvangsins sem verið er að þróa.
Hvað tækni varðar fengu allir þátttakendur algjört valfrelsi. Það var hægt að nota hvaða hugtök og tækni sem er: Gagnastreymi, vélanám, uppspretta viðburða, stór gögn og fleira.
Lausn okkar
Eftir smá hugarflug ákváðum við að FaaS lausn væri tilvalin til að klára verkefnið.
Fyrir þessa lausn var nauðsynlegt að finna hentugan Serverless ramma til að innleiða reglur ákvarðanatökukerfisins sem verið er að þróa. Þar sem Tinkoff notar Kubernetes virkan fyrir innviðastjórnun, skoðuðum við nokkrar tilbúnar lausnir byggðar á því; ég mun segja þér meira um það síðar.
Til að finna árangursríkustu lausnina skoðuðum við vöruna sem verið er að þróa með augum notenda hennar. Aðalnotendur kerfisins okkar eru sérfræðingar sem taka þátt í regluþróun. Reglurnar verða að vera settar á netþjóninn, eða, eins og í okkar tilviki, settar í skýið, til síðari ákvarðanatöku. Frá sjónarhóli greiningaraðila lítur verkflæðið svona út:
- Sérfræðingur skrifar handrit, reglu eða ML líkan byggt á gögnum frá vöruhúsinu. Sem hluti af hackathoninu ákváðum við að nota Mongodb, en val á gagnageymslukerfi skiptir ekki máli hér.
- Eftir að hafa prófað þróaðar reglur um söguleg gögn hleður sérfræðingur upp kóðanum sínum á stjórnborðið.
- Til að tryggja útgáfu mun allur kóði fara í Git geymslur.
- Í gegnum stjórnborðið verður hægt að dreifa kóðanum í skýinu sem aðskilda virka netþjónalausa einingu.
Upphafleg gögn frá viðskiptavinum verða að fara í gegnum sérhæfða auðgunarþjónustu sem er hönnuð til að auðga upphaflegu beiðnina með gögnum frá vöruhúsinu. Mikilvægt var að innleiða þessa þjónustu á þann hátt að hún myndi vinna með einni geymslu (sem sérfræðingur tekur gögn úr við þróun reglna) til að viðhalda sameinuðu gagnaskipulagi.
Jafnvel fyrir hackathonið ákváðum við Serverless ramma sem við myndum nota. Í dag er töluvert mikið af tækni á markaðnum sem innleiðir þessa nálgun. Vinsælustu lausnirnar innan Kubernetes arkitektúrsins eru Fission, Open FaaS og Kubeless. Það eru jafnvel .
Eftir að hafa vegið alla kosti og galla, völdum við . Þessi netþjónalausi rammi er frekar auðvelt að stjórna og uppfyllir kröfur verkefnisins.
Til að vinna með Fission þarftu að skilja tvö grunnhugtök: virkni og umhverfi. Fall er stykki af kóða sem er skrifaður á einu af tungumálunum sem er Fission umhverfi fyrir. inniheldur Python, JS, Go, JVM og mörg önnur vinsæl tungumál og tækni.
Fission er einnig fær um að framkvæma aðgerðir skipt í nokkrar skrár, forpakkaðar í skjalasafn. Rekstur Fission í Kubernetes klasa er tryggður með sérhæfðum belgjum, sem er stjórnað af rammanum sjálfum. Til að hafa samskipti við þyrpingabálka verður að úthluta hverri aðgerð sinni eigin leið og sem þú getur sent GET færibreytur eða beiðni um meginmál ef um er að ræða POST beiðni.
Fyrir vikið ætluðum við að fá lausn sem myndi gera greinendum kleift að nota þróuð regluforskrift án þátttöku verkfræðinga og þróunaraðila. Nálgunin sem lýst er útilokar einnig þörfina fyrir þróunaraðila til að endurskrifa greiningarkóða á annað tungumál. Til dæmis, fyrir núverandi ákvarðanatökukerfi sem við notum, verðum við að skrifa reglur í mjög sérhæfðri tækni og tungumálum, umfang þeirra er afar takmarkað, og það er líka mjög háð forritaþjóninum, þar sem öll drög að bankareglum. eru settar á vettvang í einu umhverfi. Þar af leiðandi er nauðsynlegt að gefa út allt kerfið til að setja inn nýjar reglur.
Í fyrirhugaðri lausn okkar er engin þörf á að gefa út reglur; kóðann er auðveldlega hægt að dreifa með því að smella á hnapp. Einnig gerir innviðastjórnun í Kubernetes þér kleift að hugsa ekki um álag og stærðarstærð; slík vandamál eru leyst úr kassanum. Og notkun eins gagnavöruhúss útilokar þörfina á að bera rauntímagögn saman við söguleg gögn, sem einfaldar vinnu sérfræðingsins.
Það sem við fengum
Þar sem við komum í hackathonið með tilbúna lausn (í fantasíum okkar), var allt sem við þurftum að gera að breyta öllum hugsunum okkar í kóðalínur.
Lykillinn að árangri á hvaða hackathon sem er er undirbúningur og vel skrifuð áætlun. Þess vegna var það fyrsta sem við gerðum var að ákveða hvaða einingum kerfisarkitektúr okkar myndi samanstanda af og hvaða tækni við myndum nota.
Arkitektúr verkefnisins okkar var sem hér segir:
Þessi skýringarmynd sýnir tvo inngangspunkta, sérfræðinginn (aðalnotandi kerfisins okkar) og viðskiptavininn.
Vinnuferlið er þannig uppbyggt. Sérfræðingurinn þróar regluaðgerð og gagnaauðgunaraðgerð fyrir líkanið sitt, geymir kóðann sinn í Git geymslu og setur líkanið sitt í skýið í gegnum stjórnandaforritið. Við skulum íhuga hvernig innleita aðgerðin verður kölluð og taka ákvarðanir um komandi beiðnir frá viðskiptavinum:
- Viðskiptavinur fyllir út eyðublað á vefsíðunni og sendir beiðni sína til ábyrgðaraðila. Umsókn sem þarf að taka ákvörðun um kemur í kerfisinntak og er skráð í gagnagrunninn í upprunalegri mynd.
- Næst er hrábeiðnin send til auðgunar, ef þörf krefur. Þú getur bætt við upphaflegri beiðni með gögnum bæði frá ytri þjónustu og úr geymslunni. Auðgað fyrirspurn sem myndast er einnig geymd í gagnagrunninum.
- Greiningaraðgerðin er ræst, sem tekur auðgaða fyrirspurn sem inntak og framleiðir lausn sem einnig er skrifuð í geymsluna.
Við ákváðum að nota MongoDB sem geymslu í kerfinu okkar vegna skjalamiðaðrar geymslu gagna í formi JSON skjala, þar sem auðgunarþjónustan, þar með talið upprunalega beiðnin, safnaði saman öllum gögnum í gegnum REST stýringar.
Þannig að við höfðum XNUMX tíma til að innleiða vettvanginn. Við dreifðum hlutverkunum með góðum árangri; hver liðsmaður hafði sitt ábyrgðarsvið í verkefninu okkar:
- Framkvæmdastjórnborð fyrir vinnu sérfræðingsins, þar sem hann gat hlaðið niður reglum úr útgáfustýringarkerfi skrifaðra skrifta, valið valkosti til að auðga inntaksgögn og breytt regluskriftum á netinu.
- Backend admin, þar á meðal REST API fyrir framhliðina og samþættingu við VCS.
- Að setja upp innviði í Google Cloud og þróa þjónustu til að auðga upprunagögn.
- Eining til að samþætta admin forritið við Serverless ramma fyrir síðari uppsetningu reglna.
- Forskriftir reglna til að prófa frammistöðu alls kerfisins og samsöfnun greiningar á komandi forritum (ákvarðanir teknar) fyrir lokasýninguna.
Byrjum í röð.
Framhlið okkar var skrifað í Angular 7 með því að nota bankaviðmótsbúnaðinn. Lokaútgáfan af stjórnborðinu leit svona út:
Þar sem það var lítill tími reyndum við að innleiða aðeins lykilvirknina. Til að dreifa aðgerð í Kubernetes klasa var nauðsynlegt að velja atburð (þjónustu sem þarf að nota reglu fyrir í skýinu) og kóða aðgerðarinnar sem útfærir ákvarðanatökurökfræðina. Fyrir hverja uppsetningu reglu fyrir valda þjónustu skrifuðum við skrá yfir þennan atburð. Í stjórnborðinu gætirðu séð logs yfir alla atburði.
Allur aðgerðarkóði var geymdur í ytri Git geymslu, sem einnig þurfti að stilla á stjórnborðinu. Til að útgáfa kóðann voru allar aðgerðir geymdar í mismunandi greinum geymslunnar. Stjórnborðið veitir einnig möguleika á að gera breytingar á skrifuðum forskriftum, þannig að áður en aðgerð er sett í framleiðslu geturðu ekki aðeins athugað skrifaðan kóða heldur einnig gert nauðsynlegar breytingar.
Til viðbótar við regluaðgerðirnar innleiddum við einnig möguleikann á að auðga upprunagögnin smám saman með auðgunaraðgerðum, en kóðinn á þeim var einnig forskriftir þar sem hægt var að fara í gagnageymsluna, hringja í þjónustu þriðja aðila og framkvæma bráðabirgðaútreikninga. . Til að sýna lausnina okkar reiknuðum við stjörnumerki viðskiptavinarins sem skildi eftir beiðnina og ákváðum farsímafyrirtæki hans með því að nota þriðja aðila REST þjónustu.
Bakendi vettvangsins var skrifaður í Java og útfærður sem Spring Boot forrit. Við ætluðum upphaflega að nota Postgres til að geyma stjórnunargögn, en sem hluti af hackathoninu ákváðum við að takmarka okkur við einfaldan H2 til að spara tíma. Á bakendanum var samþætting við Bitbucket útfærð til að útgáfa auðgunaraðgerðir fyrirspurna og regluforskrifta. Fyrir samþættingu við ytri Git geymslur notuðum við , sem er eins konar umbúðir yfir CLI skipanir, sem gerir þér kleift að framkvæma allar git leiðbeiningar með því að nota þægilegt hugbúnaðarviðmót. Þannig að við vorum með tvær aðskildar geymslur fyrir auðgunaraðgerðir og reglur, og öllum skriftum var skipt í möppur. Í gegnum notendaviðmótið var hægt að velja nýjustu commit af handriti af handahófskenndri grein geymslunnar. Þegar breytingar eru gerðar á kóðanum í gegnum stjórnborðið, voru skuldbindingar fyrir breytta kóðann búnar til í ytri geymslum.
Til að hrinda hugmyndinni okkar í framkvæmd þurftum við viðeigandi innviði. Við ákváðum að dreifa Kubernetes þyrpingunni okkar í skýið. Valið okkar var Google Cloud Platform. Fission netþjónalausi ramminn var settur upp á Kubernetes klasa, sem við settum upp í Gcloud. Upphaflega var auðgunarþjónusta uppspretta gagna útfærð sem sérstakt Java forrit vafinn inn í Pod inni í k8s klasanum. En eftir bráðabirgðasýningu á verkefninu okkar í miðju hakkaþoninu var mælt með því að gera auðgunarþjónustuna sveigjanlegri til að gefa tækifæri til að velja hvernig á að auðga hrá gögn komandi forrita. Og við áttum ekkert val en að gera auðgunarþjónustuna einnig Serverless.
Til að vinna með Fission notuðum við Fission CLI, sem verður að setja ofan á Kubernetes CLI. Að dreifa aðgerðum í k8s þyrping er frekar einfalt; þú þarft bara að tengja innri leið og inngöngu í aðgerðina til að leyfa komandi umferð ef aðgangur er fyrir utan klasann. Að dreifa einni aðgerð tekur venjulega ekki meira en 10 sekúndur.
Lokakynning á verkefninu og samantekt
Til að sýna hvernig kerfið okkar virkar höfum við sett einfalt eyðublað á ytri netþjón þar sem þú getur sent inn umsókn um eina af vörum bankans. Til að biðja um það þurftir þú að slá inn upphafsstafi, fæðingardag og símanúmer.
Gögn úr eyðublaði viðskiptavinarins fóru til ábyrgðaraðilans, sem sendi samtímis beiðnir um allar tiltækar reglur, eftir að hafa auðgað gögnin áður í samræmi við tilgreind skilyrði og vistað þau í sameiginlegri geymslu. Alls settum við í notkun þrjár aðgerðir sem taka ákvarðanir um komandi forrit og 4 gagnaauðgunarþjónustur. Eftir að hafa lagt fram umsóknina fékk viðskiptavinurinn ákvörðun okkar:
Auk synjunar eða samþykkis fékk viðskiptavinurinn einnig lista yfir aðrar vörur, beiðnir sem við sendum samhliða. Þannig sýndum við möguleikann á krosssölu á vettvangi okkar.
Alls voru 3 tilbúnar bankavörur í boði:
- Inneign.
- Toy
- Veð.
Á sýnikennslunni sendum við tilbúnar aðgerðir og auðgunarforskriftir fyrir hverja þjónustu.
Hver regla þurfti sitt eigið sett af inntaksgögnum. Svo, til að samþykkja veð, reiknuðum við stjörnumerki viðskiptavinarins og tengdum þetta við rökfræði tungldagatalsins. Til að samþykkja leikfang var athugað hvort viðskiptavinurinn hefði náð lögræðisaldri og til að gefa út lán sendum við beiðni til utanaðkomandi opinnar þjónustu um að ákvarða farsímafyrirtækið og ákvörðun var tekin um það.
Við reyndum að gera sýnikennsluna okkar áhugaverða og gagnvirka, allir viðstaddir gátu farið í eyðublaðið okkar og athugað hvort skáldaða þjónustu okkar væri tiltæk fyrir þá. Og alveg í lok kynningarinnar sýndum við greiningu á mótteknum umsóknum sem sýndu hversu margir notuðu þjónustu okkar, fjölda samþykkja og synjun.
Til að safna greiningum á netinu settum við einnig upp opið BI tól og skrúfaði það á geymsluna okkar. Metabase gerir þér kleift að byggja upp skjái með greiningu á gögnunum sem vekur áhuga okkar; þú þarft bara að skrá tengingu við gagnagrunninn, velja töflur (í okkar tilfelli, gagnasöfnun, þar sem við notuðum MongoDB) og tilgreina áhugasvið okkar .
Fyrir vikið fengum við góða frumgerð af vettvangi til að taka ákvarðanir og á meðan á sýnikennslunni stóð gat hver hlustandi sjálfur athugað frammistöðu hans. Áhugaverð lausn, fullunnin frumgerð og vel heppnuð sýning gerðu okkur kleift að sigra, þrátt fyrir mikla samkeppni frá öðrum liðum. Ég er viss um að einnig er hægt að skrifa áhugaverða grein um verkefni hvers liðs.
Heimild: www.habr.com