Iaz hasi zen gure enpresa hackath-ak antolatzen. Horrelako lehen lehiaketa oso arrakastatsua izan zen, horri buruz idatzi genuen . Bigarren hackatona 2019ko otsailean egin zen eta ez zuen arrakasta gutxiago izan. Azken hau ez hainbeste eusteko helburuei buruz antolatzaile.
Parte-hartzaileei zeregin interesgarri samarra eman zitzaien inplementaziorako teknologia pila bat aukeratzeko askatasun osoz. Erabakiak hartzeko plataforma bat ezartzea beharrezkoa zen bezeroen puntuazio-funtzioak eroso hedatzeko, aplikazioen fluxu azkar batekin funtziona zezakeen, karga astunak jasateko eta sistema bera erraz eskalagarria zen.
Zeregin ez da hutsala eta modu askotan konpondu daiteke, parte-hartzaileen proiektuen azken aurkezpenen erakustaldian sinetsi genuen bezala. Hackathonean 6 laguneko 5 talde egon ziren, partaide guztiek proiektu onak zituzten, baina gure plataforma lehiakorrena izan zen. Oso proiektu interesgarria dugu, eta horri buruz hitz egin nahiko nuke artikulu honetan.
Gure irtenbidea Kubernetesen barruan Zerbitzaririk gabeko arkitekturan oinarritutako plataforma bat da, eta horrek funtzio berriak ekoizpenera ekartzeko behar duen denbora murrizten du. Analistei komenigarria den ingurune batean kodea idazteko eta ekoizpenean inplementatzeko aukera ematen die ingeniari eta garatzaileen parte-hartzerik gabe.
Zer da puntuazioa
Tinkoff.ru-k, enpresa moderno askok bezala, bezeroen puntuazioa du. Puntuazioa bezeroen ebaluazio sistema bat da, datuak aztertzeko metodo estatistikoetan oinarrituta.
Esate baterako, bezero bat guregana jotzen du mailegu bat emateko eskaerarekin, edo banakako enpresa-kontu bat gurekin irekitzeko. Mailegu bat emateko asmoa badugu, bere kaudimena ebaluatu behar dugu, eta kontua enpresaburu indibiduala bada, bezeroak iruzurrezko transakziorik egingo ez duela ziurtatu behar dugu.
Halako erabakiak hartzeko oinarria aplikazioaren beraren datuak zein gure biltegiratze datuak aztertzen dituzten eredu matematikoak dira. Puntuazioaz gain, antzeko estatistika-metodoak ere erabil daitezke gure bezeroentzako produktu berrietarako gomendio indibidualak sortzeko zerbitzuan.
Ebaluazio horren metodoak sarrerako hainbat datu onar ditzake. Eta uneren batean parametro berri bat gehi diezaiokegu sarrerari, eta horrek, datu historikoen azterketaren emaitzetan oinarrituta, zerbitzua erabiltzearen bihurtze-tasa handituko du.
Bezeroen harremanei buruzko datu ugari gordetzen ditugu, eta informazio horren bolumena etengabe hazten ari da. Puntuazioa funtziona dezan, datuak prozesatzeko arauak (edo eredu matematikoak) ere eskatzen dira, eskabide bat nori onartu, nori uko egin eta produktu pare bat gehiago nori eskaintzea azkar erabakitzeko, haien interes potentziala ebaluatuz.
Esku artean dugun zereginerako, erabakiak hartzeko sistema espezializatu bat erabiltzen dugu dagoeneko , zeinak, analistek, teknologoek eta garatzaileek ezarritako arauetan oinarrituta, bezeroari banku-produktu jakin bat onartu ala ukatu erabakitzen duena.
Merkatuan prest dauden irtenbide asko daude, bai puntuazio ereduak bai erabakiak hartzeko sistemak beraiek. Sistema horietako bat erabiltzen dugu gure enpresan. Baina negozioa hazten ari da, dibertsifikatzen ari da, bai bezero kopurua, bai eskaintzen diren produktuen kopurua handitzen ari da, eta horrekin batera, dauden erabakiak hartzeko prozesua hobetzeko ideiak sortzen ari dira. Segur aski, lehendik dagoen sistemarekin lan egiten duten pertsonek ideia asko dituzte errazagoa, hobea, erosoagoa egiteko, baina batzuetan kanpoko ideiak baliagarriak dira. Hackathon Berria ideia soinudunak biltzeko helburuarekin antolatu zen.
Zeregin
Hackatona otsailaren 23an egin zen. Parte hartzaileei borroka egiteko bat proposatu zitzaien: hainbat baldintza bete behar zituen erabakiak hartzeko sistema bat garatzea.
Lehendik dagoen sistemak nola funtzionatzen duen eta bere funtzionamenduan zehar zein zailtasun sortzen diren esan ziguten, baita garatutako plataformak zer negozio-helburu izan behar dituen ere. Sistemak merkaturatzeko denbora azkarra izan behar du arauak garatzeko, analisten lan kodea ahalik eta azkarren produkzioan sar dadin. Eta aplikazioen sarrerako fluxuari dagokionez, erabakiak hartzeko denborak gutxienera jo beharko luke. Era berean, garatzen ari den sistemak salmenta gurutzatuaren gaitasunak izan behar ditu, bezeroari konpainiako beste produktu batzuk erosteko aukera emateko, baldin eta guk onartzen baditugu eta bezeroarengandik interes potentziala badute.
Argi dago ezinezkoa dela kaleratzeko prest dagoen proiektu bat egun batetik bestera idaztea, zalantzarik gabe ekoizpenera joango dena, eta nahiko zaila dela sistema osoa estaltzea, beraz, gutxienez zati bat ezartzeko eskatu ziguten. Prototipoak bete behar dituen hainbat baldintza ezarri ziren. Baldintza guztiak bere osotasunean betetzen eta garatzen ari den plataformaren atal indibidualak zehatz-mehatz lantzen saiatu ahal izan zen.
Teknologiari dagokionez, parte-hartzaile guztiei aukeratzeko askatasun osoa eman zitzaien. Edozein kontzeptu eta teknologia erabili ahal izan zen: Datuen streaminga, ikaskuntza automatikoa, gertaeren iturria, big data eta beste.
Gure konponbidea
Brainstorming pixka bat egin ondoren, FaaS irtenbide bat zeregina burutzeko aproposa izango zela erabaki genuen.
Irtenbide honetarako, garatzen ari den erabakiak hartzeko sistemaren arauak ezartzeko Zerbitzaririk gabeko esparru egoki bat bilatu behar zen. Tinkoff-ek Kubernetes aktiboki erabiltzen duenez azpiegiturak kudeatzeko, bertan oinarritutako prestatutako hainbat irtenbide aztertu ditugu; geroago kontatuko dizut gehiago.
Irtenbide eraginkorrena aurkitzeko, garatzen ari den produktua erabiltzaileen begietatik begiratu dugu. Gure sistemaren erabiltzaile nagusiak arauen garapenean parte hartzen duten analistak dira. Arauak zerbitzarian zabaldu behar dira, edo, gure kasuan bezala, hodeian zabaldu, gero erabakiak hartzeko. Analista baten ikuspuntutik, lan-fluxua honelakoa da:
- Analistak script, arau edo ML eredu bat idazten du biltegiko datuetan oinarrituta. Hackathonaren baitan, Mongodb erabiltzea erabaki genuen, baina hemen datuak biltegiratzeko sistema aukeratzea ez da garrantzitsua.
- Datu historikoei buruzko garatutako arauak probatu ondoren, analistak bere kodea kargatzen du administrazio panelera.
- Bertsioa ziurtatzeko, kode guztia Git biltegietara joango da.
- Admin panelaren bidez, kodea hodeian zabaldu ahal izango da Zerbitzaririk gabeko modulu funtzional bereizi gisa.
Bezeroen hasierako datuak biltegiko datuekin hasierako eskaera aberasteko diseinatutako Aberaste zerbitzu espezializatu batetik pasatu behar dira. Garrantzitsua zen zerbitzu hau ezartzea biltegi bakarrarekin (hortik analistak datuak hartzen ditu arauak garatzeko orduan) datu-egitura bateratua mantentzeko.
Hackatona baino lehen ere, erabiliko genuen Serverless esparrua erabaki genuen. Gaur egun, merkatuan ikuspegi hori ezartzen duten teknologia asko daude. Kubernetes arkitekturaren barruan soluzio ezagunenak Fission, Open FaaS eta Kubeless dira. Badaude ere .
Alde onak eta txarrak neurtu ondoren, aukeratu genuen . Zerbitzaririk gabeko esparru hau nahiko erraza da kudeatzen eta zereginaren eskakizunak betetzen ditu.
Fisioarekin lan egiteko, oinarrizko bi kontzeptu ulertu behar dituzu: funtzioa eta ingurunea. Funtzioa Fission ingurunea dagoen hizkuntzetako batean idatzitako kode zati bat da. Python, JS, Go, JVM eta beste hainbat hizkuntza eta teknologia ezagun ditu.
Fission-ek hainbat fitxategitan banatutako funtzioak egiteko gai da, aldez aurretik artxibo batean bilduta. Fission-en funtzionamendua Kubernetes kluster batean bermatzen du pods espezializatuek, esparruak berak kudeatzen dituenak. Cluster podekin elkarreragiteko, funtzio bakoitzari bere ibilbide propioa esleitu behar zaio, eta horri GET parametroak pasa diezazkiokezu edo POST eskaera baten kasuan eskaera gorputza.
Ondorioz, analistei ingeniarien eta garatzaileen parte-hartzerik gabe garatutako arauen script-ak zabaltzea ahalbidetuko zuen irtenbide bat lortzea aurreikusi genuen. Deskribatutako ikuspegiak garatzaileek analistaren kodea beste hizkuntza batean berridazteko beharra ezabatzen du. Esaterako, erabiltzen dugun erabakiak hartzeko sistemarako, arauak idatzi behar ditugu teknologia eta hizkuntza oso espezializatuetan, zeinen esparrua oso mugatua baita, eta aplikazio-zerbitzariarekiko menpekotasun handia baitago, banku-arau zirriborro guztiekin. ingurune bakarrean zabaltzen dira. Ondorioz, arau berriak zabaltzeko beharrezkoa da sistema osoa askatzea.
Proposatutako soluzioan, ez dago arauak kaleratu beharrik; kodea erraz zabaldu daiteke botoi baten klik eginez. Gainera, Kubernetes-en azpiegituren kudeaketak karga eta eskalatzeari buruz ez pentsatzea ahalbidetzen du; horrelako arazoak kutxatik kanpo konpontzen dira. Eta datu biltegi bakarra erabiltzeak denbora errealeko datuak datu historikoekin alderatzeko beharra ezabatzen du, eta horrek analistaren lana errazten du.
Lortu duguna
Hackatonera prest egindako irtenbide batekin iritsi ginenez (gure fantasietan), gure pentsamendu guztiak kode lerro bihurtzea besterik ez genuen egin behar.
Edozein hackathonetan arrakastaren gakoa prestatzea eta ondo idatzitako plana da. Hori dela eta, egin genuen lehenengo gauza gure sistemaren arkitektura zein modulutan osatuko zen eta zer teknologia erabiliko genuen erabaki genuen.
Gure proiektuaren arkitektura hau izan zen:
Diagrama honek bi sarrera puntu erakusten ditu, analista (gure sistemaren erabiltzaile nagusia) eta bezeroa.
Lan-prozesua horrela egituratzen da. Analistak bere eredurako arau funtzio bat eta datuak aberasteko funtzio bat garatzen ditu, bere kodea Git biltegi batean gordetzen du eta bere eredua hodeian zabaltzen du administratzaile aplikazioaren bidez. Azter dezagun inplementatutako funtzioa nola deituko den eta har ditzagun bezeroen sarrerako eskaerei buruzko erabakiak:
- Bezeroak webguneko formulario bat betetzen du eta bere eskaera kontrolatzaileari bidaltzen dio. Erabaki bat hartu behar den aplikazio bat sistemaren sarrerara iristen da eta datu-basean erregistratzen da bere jatorrizko forman.
- Ondoren, eskaera gordina aberasteko bidaltzen da, beharrezkoa bada. Hasierako eskaera osa dezakezu kanpoko zerbitzuetako zein biltegiko datuekin. Sortutako kontsulta aberastua datu-basean ere gordetzen da.
- Analista-funtzioa abiarazten da, sarrera gisa kontsulta aberastua hartzen duena eta soluzio bat sortzen duena, biltegian ere idazten dena.
MongoDB gure sisteman biltegiratze gisa erabiltzea erabaki genuen JSON dokumentu moduan dokumentuetara zuzendutako datuen biltegiratzea dela eta, aberaste-zerbitzuek, jatorrizko eskaera barne, datu guztiak REST kontrolagailuen bidez biltzen baitzituzten.
Beraz, XNUMX ordu izan genituen plataforma ezartzeko. Nahiko arrakastaz banatu ditugu rolak; taldekide bakoitzak bere ardura-eremua zuen gure proiektuan:
- Analistaren lanerako front-end administrazio-panelak, zeinen bidez, idatzizko gidoien bertsio-kontrol-sistematik arauak deskargatu, sarrerako datuak aberasteko aukerak hautatu eta arau-scriptak linean editatu ditzake.
- Backend administratzailea, aurrealdeko REST APIa eta VCS-rekin integratzea barne.
- Google Cloud-en azpiegitura konfiguratzea eta iturri-datuak aberasteko zerbitzu bat garatzea.
- Admin aplikazioa Zerbitzaririk gabeko esparruarekin integratzeko modulua, ondorengo arauak hedatzeko.
- Sistema osoaren errendimendua probatzeko arauen gidoiak eta sarrerako aplikazioen (hartutako erabakiak) analisien agregazioa azken erakustaldirako.
Hasi gaitezen ordenan.
Gure frontend-a Angular 7-n idatzi zen bankuaren UI Kit-a erabiliz. Admin panelaren azken bertsioak itxura hau zuen:
Denbora gutxi zegoenez, funtsezko funtzionalitatea bakarrik ezartzen saiatu gara. Kubernetes klusterrean funtzio bat zabaltzeko, gertaera bat (hodeian arau bat zabaldu behar duen zerbitzu bat) eta erabakiak hartzeko logika inplementatzen duen funtzioaren kodea hautatu behar izan dira. Aukeratutako zerbitzurako arau baten hedapen bakoitzeko, gertaera honen erregistroa idatzi genuen. Admin panelean gertaera guztien erregistroak ikus ditzakezu.
Funtzio-kode guztiak urruneko Git biltegi batean gordetzen ziren, administrazio-panelean ere ezarri behar zena. Kodea bertsioratzeko, funtzio guztiak biltegiaren adar ezberdinetan gorde ziren. Admin panelak idatzizko scriptetan doikuntzak egiteko gaitasuna ere eskaintzen du, funtzio bat ekoizpenera zabaldu aurretik, idatzitako kodea egiaztatu ez ezik, beharrezko aldaketak ere egin ditzakezu.
Arau-funtzioez gain, sorburuko datuak pixkanaka aberasteko gaitasuna ere ezarri dugu Aberaste-funtzioak erabiliz, eta horien kodea ere script-ak ziren, zeinetan datu biltegira joan, hirugarrenen zerbitzuetara deitu eta aurretiazko kalkuluak egiteko. . Gure irtenbidea erakusteko, eskaera utzi duen bezeroaren zodiako zeinua kalkulatu dugu eta bere mugikorreko operadorea zehaztu dugu hirugarrenen REST zerbitzu bat erabiliz.
Plataformaren atzeko aldea Javan idatzi zen eta Spring Boot aplikazio gisa inplementatu zen. Hasiera batean Postgres erabiltzea aurreikusten genuen administrazio-datuak gordetzeko, baina, hackatonaren baitan, H2 soil batera mugatzea erabaki genuen denbora aurrezteko. Atzeko aldean, Bitbucket-ekin integrazioa inplementatu zen kontsultak aberasteko funtzioak eta arau-scriptak bertsioratzeko. Urruneko Git biltegiekin integratzeko, erabili dugu , hau da, CLI komandoen gaineko bilgarri moduko bat, edozein git instrukzio exekutatzeko software interfaze erosoa erabiliz. Beraz, bi biltegi bereizi genituen aberasteko funtzio eta arauetarako, eta script guztiak direktoriotan banatuta zeuden. Interfazearen bidez, biltegiaren adar arbitrario bateko script baten azken konpromisoa hautatzea posible zen. Admin panelaren bidez kodean aldaketak egitean, aldatutako kodearen konpromezuak urruneko biltegietan sortu ziren.
Gure ideia gauzatzeko, azpiegitura egokia behar genuen. Gure Kubernetes klusterra hodeian zabaltzea erabaki genuen. Gure aukera Google Cloud Platform izan zen. Fission zerbitzaririk gabeko esparrua Kubernetes kluster batean instalatu zen, Gcloud-en zabaldu genuena. Hasieran, iturburuko datuak aberasteko zerbitzua k8s klusterraren barruan dagoen Pod batean bildutako Java aplikazio bereizi gisa inplementatu zen. Baina hackatonaren erdian gure proiektuaren aurretiazko erakustaldi baten ondoren, Aberaste zerbitzua malgutzea gomendatu ziguten, sarrerako aplikazioen datu gordinak nola aberastu aukeratzeko aukera emateko. Eta aberaste zerbitzua ere Serverless egitea beste aukerarik ez genuen izan.
Fission-ekin lan egiteko, Fission CLI erabili dugu, Kubernetes CLIaren gainean instalatu behar dena. Funtzioak k8s kluster batean zabaltzea nahiko erraza da; barruko ibilbide bat eta funtzioari sarrera bat esleitu behar dituzu sarrerako trafikoa ahalbidetzeko, klusteretik kanpo sarbidea behar bada. Funtzio bat zabaltzeak normalean ez du 10 segundo baino gehiago behar.
Proiektuaren azken aurkezpena eta laburpena
Gure sistemak nola funtzionatzen duen erakusteko, formulario sinple bat jarri dugu urruneko zerbitzari batean, non bankuaren produktuetako baten eskaera aurkez dezakezun. Eskatzeko, zure inizialak, jaioteguna eta telefono zenbakia sartu behar izan dituzu.
Bezeroaren inprimakiko datuak kontrolatzailera joan ziren, eta aldi berean eskuragarri dauden arau guztien eskaerak bidali zituen, aurretik datuak zehaztutako baldintzen arabera aberastu eta biltegiratze komun batean gorde zituen. Guztira, sarrerako aplikazioei buruzko erabakiak hartzen dituzten hiru funtzio eta datuak aberasteko 4 zerbitzu zabaldu ditugu. Eskaera aurkeztu ondoren, bezeroak gure erabakia jaso zuen:
Errefusa edo onespenaz gain, bezeroak beste produktu batzuen zerrenda ere jaso zuen, eta horretarako eskaerak paraleloan bidali genituen. Horrela frogatu genuen gure plataforman salmenta gurutzatua egiteko aukera.
Guztira, 3 banku-produktu fikziozko zeuden eskuragarri:
- Kreditua.
- jostailu
- Hipoteka.
Erakustaldian zehar, zerbitzu bakoitzerako prestatutako funtzioak eta aberasteko scriptak zabaldu genituen.
Arau bakoitzak bere sarrerako datu multzoa behar zuen. Beraz, hipoteka bat onartzeko, bezeroaren zodiako zeinua kalkulatu dugu eta ilargi egutegiaren logikarekin lotu dugu. Jostailu bat onartzeko, bezeroak adin nagusitasuna bete zuela egiaztatu genuen, eta mailegu bat emateko, kanpoko zerbitzu ireki bati eskaria bidali genion telefono mugikorren operadorea zehazteko, eta erabaki bat hartu zen.
Gure erakustaldia interesgarria eta interaktiboa izan dadin saiatu gara, bertaratutako guztiek gure formulariora joan eta gure fikziozko zerbitzuen erabilgarritasuna egiaztatu ahal izan dute. Aurkezpenaren amaieran, jasotako eskaeren analisiak erakutsi genituen, gure zerbitzua zenbat pertsonek erabili zuten, onarpen kopurua eta uko.
Analitika linean biltzeko, kode irekiko BI tresna bat ere zabaldu dugu eta gure biltegiratze-unitatera izorratu. Metabase-k aukera ematen dizu interesatzen zaizkigun datuen analitikak dituzten pantailak eraikitzeko; datu-baserako konexioa erregistratu, taulak hautatzea besterik ez duzu behar (gure kasuan, datu-bildumak, MongoDB erabiltzen dugunez), eta interesatzen zaizkigun eremuak zehaztu. .
Ondorioz, erabakiak hartzeko plataforma baten prototipo on bat lortu genuen, eta erakustaldian, entzule bakoitzak bere errendimendua egiaztatu ahal izan zuen. Irtenbide interesgarri batek, prototipo amaitu batek eta erakustaldi arrakastatsu batek irabazteko aukera eman ziguten, beste taldeen lehia gogorra izan arren. Ziur nago talde bakoitzaren proiektuan artikulu interesgarri bat ere idatzi daitekeela.
Iturria: www.habr.com