Kuanzia mwaka jana, kampuni yetu ilianza kuandaa hackathons. Mashindano ya kwanza kama haya yalifanikiwa sana, tuliandika juu yake ndani . Hackathon ya pili ilifanyika mnamo Februari 2019 na haikufaulu hata kidogo. Kuhusu malengo ya kushikilia mwisho sio muda mrefu uliopita mratibu.
Washiriki walipewa kazi ya kupendeza na uhuru kamili katika kuchagua safu ya teknolojia kwa utekelezaji wake. Ilihitajika kutekeleza jukwaa la kufanya maamuzi kwa uwekaji rahisi wa kazi za bao za wateja ambazo zinaweza kufanya kazi na mtiririko wa haraka wa programu, kuhimili mizigo mizito, na mfumo wenyewe ulikuwa rahisi kubadilika.
Kazi hiyo sio ndogo na inaweza kutatuliwa kwa njia nyingi, kwani tulikuwa na hakika wakati wa maonyesho ya mawasilisho ya mwisho ya miradi ya washiriki. Kulikuwa na timu 6 za watu 5 kwenye hackathon, washiriki wote walikuwa na miradi mizuri, lakini jukwaa letu liliibuka kuwa la ushindani zaidi. Tuna mradi wa kuvutia sana, ambao ningependa kuzungumza juu ya makala hii.
Suluhisho letu ni jukwaa linalozingatia usanifu wa Serverless ndani ya Kubernetes, ambayo hupunguza muda inachukua kuleta vipengele vipya kwa uzalishaji. Huruhusu wachambuzi kuandika msimbo katika mazingira yanayowafaa na kuipeleka katika uzalishaji bila ushiriki wa wahandisi na watengenezaji.
Nini ni bao
Tinkoff.ru, kama kampuni nyingi za kisasa, ina alama za wateja. Alama ni mfumo wa tathmini ya mteja kulingana na mbinu za takwimu za uchanganuzi wa data.
Kwa mfano, mteja anarudi kwetu na ombi la kumpa mkopo, au kufungua akaunti ya mjasiriamali binafsi nasi. Ikiwa tunapanga kumpa mkopo, basi tunahitaji kutathmini solvens yake, na ikiwa akaunti ni mjasiriamali binafsi, basi tunahitaji kuwa na uhakika kwamba mteja hawezi kufanya shughuli za ulaghai.
Msingi wa kufanya maamuzi kama haya ni miundo ya hisabati ambayo huchanganua data kutoka kwa programu yenyewe na data kutoka kwa hifadhi yetu. Mbali na bao, mbinu sawa za takwimu zinaweza pia kutumika katika kutoa mapendekezo ya mtu binafsi kwa bidhaa mpya kwa wateja wetu.
Mbinu ya tathmini kama hiyo inaweza kukubali aina ya data ya pembejeo. Na kwa wakati fulani tunaweza kuongeza parameter mpya kwa pembejeo, ambayo, kulingana na matokeo ya uchambuzi kwenye data ya kihistoria, itaongeza kiwango cha ubadilishaji wa kutumia huduma.
Tuna data nyingi kuhusu mahusiano ya wateja, na wingi wa taarifa hii unaongezeka kila mara. Ili kuweka alama kufanya kazi, usindikaji wa data pia unahitaji sheria (au miundo ya hisabati) ambayo hukuruhusu kuamua haraka ni nani wa kuidhinisha programu, ni nani wa kukataa, na ni nani wa kutoa bidhaa kadhaa zaidi, kutathmini uwezekano wa maslahi yao.
Kwa kazi iliyopo, tayari tunatumia mfumo maalum wa kufanya maamuzi , ambayo, kwa kuzingatia sheria zilizowekwa na wachambuzi, teknolojia na watengenezaji, huamua kuidhinisha au kukataa bidhaa fulani ya benki kwa mteja.
Kuna suluhisho nyingi zilizotengenezwa tayari kwenye soko, mifano ya bao na mifumo ya kufanya maamuzi yenyewe. Tunatumia mojawapo ya mifumo hii katika kampuni yetu. Lakini biashara inakua, inabadilika, idadi ya wateja na idadi ya bidhaa zinazotolewa inaongezeka, na pamoja na hii, mawazo yanaibuka juu ya jinsi ya kuboresha mchakato uliopo wa kufanya maamuzi. Hakika watu wanaofanya kazi na mfumo uliopo wana mawazo mengi juu ya jinsi ya kuifanya iwe rahisi, bora, rahisi zaidi, lakini wakati mwingine mawazo kutoka nje yanafaa. New Hackathon iliandaliwa kwa lengo la kukusanya mawazo ya sauti.
Kazi
Hackthon ilifanyika mnamo Februari 23. Washiriki walipewa kazi ya mapigano: kuunda mfumo wa kufanya maamuzi ambao ulilazimika kukidhi masharti kadhaa.
Tuliambiwa jinsi mfumo uliopo unavyofanya kazi na matatizo gani yanayotokea wakati wa uendeshaji wake, pamoja na malengo gani ya biashara ambayo jukwaa lililotengenezwa linapaswa kufuata. Mfumo lazima uwe na wakati wa haraka wa soko kwa kuunda sheria ili nambari ya kazi ya wachambuzi iingie katika uzalishaji haraka iwezekanavyo. Na kwa mtiririko unaoingia wa maombi, wakati wa kufanya maamuzi unapaswa kuwa mdogo. Pia, mfumo unaotengenezwa lazima uwe na uwezo wa kuuza bidhaa mbalimbali ili kumpa mteja fursa ya kununua bidhaa nyingine za kampuni ikiwa zimeidhinishwa na sisi na kuwa na riba kutoka kwa mteja.
Ni wazi kwamba haiwezekani kuandika mradi tayari-kutolewa mara moja ambayo hakika itaingia katika uzalishaji, na ni vigumu sana kufunika mfumo mzima, kwa hiyo tuliulizwa kutekeleza angalau sehemu yake. Mahitaji kadhaa yalianzishwa ambayo mfano lazima yakidhi. Iliwezekana kujaribu zote mbili kufunika mahitaji yote kwa ukamilifu, na kufanya kazi kwa undani juu ya sehemu za kibinafsi za jukwaa linalotengenezwa.
Kuhusu teknolojia, washiriki wote walipewa uhuru kamili wa kuchagua. Iliwezekana kutumia dhana na teknolojia yoyote: Kutiririsha data, kujifunza kwa mashine, kutafuta matukio, data kubwa na mengine.
Suluhisho letu
Baada ya kujadiliana kidogo, tuliamua kuwa suluhisho la FaaS lingekuwa bora kwa kukamilisha kazi.
Kwa suluhisho hili, ilihitajika kupata mfumo unaofaa wa Serverless kutekeleza sheria za mfumo wa kufanya maamuzi unaotengenezwa. Kwa kuwa Tinkoff hutumia kikamilifu Kubernetes kwa usimamizi wa miundombinu, tuliangalia masuluhisho kadhaa yaliyotengenezwa tayari kwa msingi wake; nitakuambia zaidi juu yake baadaye.
Ili kupata suluhisho la ufanisi zaidi, tuliangalia bidhaa inayotengenezwa kupitia macho ya watumiaji wake. Watumiaji wakuu wa mfumo wetu ni wachambuzi wanaohusika katika ukuzaji wa sheria. Sheria lazima zipelekwe kwa seva, au, kama ilivyo kwetu, zitumike kwenye wingu, kwa uamuzi unaofuata. Kwa mtazamo wa mchambuzi, mtiririko wa kazi unaonekana kama hii:
- Mchanganuzi huandika hati, sheria, au muundo wa ML kulingana na data kutoka ghala. Kama sehemu ya hackathon, tuliamua kutumia Mongodb, lakini uchaguzi wa mfumo wa kuhifadhi data sio muhimu hapa.
- Baada ya kupima sheria zilizotengenezwa kwenye data ya kihistoria, mchambuzi anapakia msimbo wake kwenye jopo la admin.
- Ili kuhakikisha uchapishaji, msimbo wote utaenda kwenye hazina za Git.
- Kupitia paneli ya msimamizi itawezekana kupeleka msimbo katika wingu kama moduli tofauti inayofanya kazi isiyo na seva.
Data ya awali kutoka kwa wateja lazima ipitie huduma maalum ya Uboreshaji iliyoundwa ili kuboresha ombi la awali na data kutoka ghala. Ilikuwa muhimu kutekeleza huduma hii kwa njia ambayo itafanya kazi na hifadhi moja (ambayo mchambuzi huchukua data wakati wa kuunda sheria) ili kudumisha muundo wa data wa umoja.
Hata kabla ya hackathon, tuliamua juu ya mfumo wa Serverless ambao tutatumia. Leo, kuna teknolojia nyingi kwenye soko zinazotumia mbinu hii. Suluhisho maarufu zaidi ndani ya usanifu wa Kubernetes ni Fission, Open FaaS na Kubeless. Kuna hata .
Baada ya kupima faida na hasara zote, tulichagua . Mfumo huu usio na seva ni rahisi sana kudhibiti na unakidhi mahitaji ya kazi.
Kufanya kazi na Fission, unahitaji kuelewa dhana mbili za msingi: kazi na mazingira. Chaguo ni kipande cha msimbo kilichoandikwa katika mojawapo ya lugha ambazo kuna mazingira ya Fission. inajumuisha Python, JS, Go, JVM na lugha nyingine nyingi maarufu na teknolojia.
Fission pia ina uwezo wa kufanya kazi zilizogawanywa katika faili kadhaa, zilizowekwa tayari kwenye kumbukumbu. Uendeshaji wa Fission katika nguzo ya Kubernetes inahakikishwa na maganda maalum, ambayo yanasimamiwa na mfumo yenyewe. Ili kuingiliana na ganda la nguzo, kila chaguo la kukokotoa lazima lipewe njia yake, na ambayo unaweza kupitisha vigezo vya GET au kuomba mwili katika kesi ya ombi la POST.
Kwa hivyo, tulipanga kupata suluhisho ambalo lingeruhusu wachambuzi kupeleka hati za sheria zilizotengenezwa bila ushiriki wa wahandisi na wasanidi. Mbinu iliyofafanuliwa pia huondoa hitaji la wasanidi programu kuandika upya msimbo wa uchanganuzi katika lugha nyingine. Kwa mfano, kwa mfumo wa sasa wa kufanya maamuzi tunaotumia, tunapaswa kuandika sheria katika teknolojia na lugha maalum, upeo wa ambayo ni mdogo sana, na pia kuna utegemezi mkubwa wa seva ya maombi, kwa kuwa rasimu zote za sheria za benki. zimewekwa katika mazingira moja. Matokeo yake, kupeleka sheria mpya ni muhimu kutolewa kwa mfumo mzima.
Katika suluhisho letu lililopendekezwa, hakuna haja ya kutoa sheria; nambari inaweza kutumwa kwa urahisi kwa kubofya kitufe. Pia, usimamizi wa miundombinu katika Kubernetes hukuruhusu usifikirie juu ya mzigo na kuongeza; shida kama hizo hutatuliwa nje ya boksi. Na matumizi ya ghala moja la data huondoa hitaji la kulinganisha data ya wakati halisi na data ya kihistoria, ambayo hurahisisha kazi ya mchambuzi.
Tulichopata
Kwa kuwa tulikuja kwenye hackathon na suluhisho tayari (katika fantasies zetu), tulichopaswa kufanya ni kubadilisha mawazo yetu yote kuwa mistari ya kanuni.
Ufunguo wa mafanikio katika hackathon yoyote ni maandalizi na mpango ulioandikwa vizuri. Kwa hivyo, jambo la kwanza tulilofanya ni kuamua ni moduli zipi ambazo usanifu wetu wa mfumo ungejumuisha na ni teknolojia gani tutatumia.
Usanifu wa mradi wetu ulikuwa kama ifuatavyo:
Mchoro huu unaonyesha pointi mbili za kuingia, mchambuzi (mtumiaji mkuu wa mfumo wetu) na mteja.
Mchakato wa kazi umeandaliwa kama hii. Mchambuzi huendeleza kazi ya sheria na kazi ya uboreshaji wa data kwa mfano wake, huhifadhi msimbo wake kwenye hazina ya Git, na kupeleka mfano wake kwenye wingu kupitia programu ya msimamizi. Wacha tuchunguze jinsi kazi iliyotumwa itaitwa na kufanya maamuzi juu ya maombi yanayoingia kutoka kwa wateja:
- Mteja anajaza fomu kwenye tovuti na kutuma ombi lake kwa mtawala. Maombi ambayo uamuzi unahitaji kufanywa huja kwa ingizo la mfumo na hurekodiwa kwenye hifadhidata katika fomu yake ya asili.
- Ifuatayo, ombi la ghafi linatumwa kwa uboreshaji, ikiwa ni lazima. Unaweza kuongeza ombi la awali na data kutoka kwa huduma za nje na kutoka kwa hifadhi. Hoja iliyoboreshwa inayotokana pia huhifadhiwa kwenye hifadhidata.
- Kazi ya mchambuzi imezinduliwa, ambayo inachukua swali lililoboreshwa kama pembejeo na hutoa suluhisho, ambalo pia limeandikwa kwenye hifadhi.
Tuliamua kutumia MongoDB kama hifadhi katika mfumo wetu kutokana na uhifadhi wa data unaozingatia hati katika muundo wa hati za JSON, kwa kuwa huduma za uboreshaji, ikiwa ni pamoja na ombi la awali, zilijumlisha data yote kupitia vidhibiti vya REST.
Kwa hiyo, tulikuwa na saa XNUMX za kutekeleza jukwaa. Tulisambaza majukumu kwa mafanikio kabisa; kila mshiriki wa timu alikuwa na eneo lake la uwajibikaji katika mradi wetu:
- Paneli za wasimamizi wa mbele kwa kazi ya mchambuzi, ambapo angeweza kupakua sheria kutoka kwa mfumo wa udhibiti wa toleo la hati zilizoandikwa, kuchagua chaguo za kuimarisha data ya uingizaji na kuhariri hati za sheria mtandaoni.
- Backend admin, ikiwa ni pamoja na REST API kwa ajili ya mbele na ushirikiano na VCS.
- Kuweka miundombinu katika Wingu la Google na kutengeneza huduma ya kuimarisha data ya chanzo.
- Moduli ya kuunganisha programu ya msimamizi na mfumo usio na Server kwa uwekaji wa sheria unaofuata.
- Hati za sheria za kupima utendakazi wa mfumo mzima na ujumlisho wa uchanganuzi kwenye programu zinazoingia (maamuzi yaliyofanywa) kwa onyesho la mwisho.
Wacha tuanze kwa utaratibu.
Sehemu yetu ya mbele iliandikwa kwa Angular 7 kwa kutumia UI Kit ya benki. Toleo la mwisho la jopo la msimamizi lilionekana kama hii:
Kwa kuwa kulikuwa na wakati mdogo, tulijaribu kutekeleza utendakazi muhimu tu. Ili kupeleka kazi katika kundi la Kubernetes, ilikuwa ni lazima kuchagua tukio (huduma ambayo sheria inahitaji kuwekwa kwenye wingu) na kanuni ya kazi inayotekeleza mantiki ya kufanya maamuzi. Kwa kila kupelekwa kwa sheria kwa huduma iliyochaguliwa, tuliandika kumbukumbu ya tukio hili. Katika paneli ya msimamizi unaweza kuona kumbukumbu za matukio yote.
Nambari zote za kazi zilihifadhiwa kwenye hazina ya mbali ya Git, ambayo pia ilibidi iwekwe kwenye paneli ya msimamizi. Ili kutoa nambari, vitendaji vyote vilihifadhiwa katika matawi tofauti ya hazina. Jopo la msimamizi pia hutoa uwezo wa kufanya marekebisho kwa maandishi yaliyoandikwa, ili kabla ya kupeleka kazi kwa uzalishaji, huwezi kuangalia tu msimbo ulioandikwa, lakini pia kufanya mabadiliko muhimu.
Mbali na kazi za sheria, tulitekeleza pia uwezo wa kuboresha data ya chanzo hatua kwa hatua kwa kutumia kazi za Uboreshaji, msimbo ambao pia ulikuwa maandishi ambayo iliwezekana kwenda kwenye ghala la data, kupiga simu kwa huduma za watu wengine na kufanya mahesabu ya awali. . Ili kuonyesha suluhisho letu, tulihesabu ishara ya zodiac ya mteja ambaye aliacha ombi na kuamua operator wake wa simu kwa kutumia huduma ya tatu ya REST.
Sehemu ya nyuma ya jukwaa iliandikwa katika Java na kutekelezwa kama programu ya Spring Boot. Hapo awali tulipanga kutumia Postgres kuhifadhi data ya msimamizi, lakini, kama sehemu ya udukuzi, tuliamua kujiwekea kikomo cha H2 rahisi ili kuokoa muda. Kwenye upande wa nyuma, ujumuishaji na Bitbucket ulitekelezwa ili kutoa matoleo ya kazi za uboreshaji wa hoja na hati za sheria. Kwa kuunganishwa na hazina za mbali za Git, tulitumia , ambayo ni aina ya kufunika juu ya amri za CLI, hukuruhusu kutekeleza maagizo yoyote ya git kwa kutumia kiolesura cha programu rahisi. Kwa hivyo tulikuwa na hazina mbili tofauti za kazi na sheria za uboreshaji, na maandishi yote yaligawanywa katika saraka. Kupitia UI iliwezekana kuchagua ahadi ya hivi karibuni ya hati ya tawi la kiholela la hazina. Wakati wa kufanya mabadiliko kwa nambari kupitia paneli ya msimamizi, ahadi za nambari iliyobadilishwa ziliundwa kwenye hazina za mbali.
Ili kutekeleza wazo letu, tulihitaji miundombinu inayofaa. Tuliamua kupeleka kundi letu la Kubernetes kwenye wingu. Chaguo letu lilikuwa Google Cloud Platform. Mfumo usio na seva wa Fission ulisakinishwa kwenye kundi la Kubernetes, ambalo tulisambaza katika Gcloud. Hapo awali, huduma ya uboreshaji wa data ya chanzo ilitekelezwa kama programu tofauti ya Java iliyofunikwa kwenye Pod ndani ya nguzo ya k8s. Lakini baada ya onyesho la awali la mradi wetu katikati ya hackathon, tulipendekezwa kufanya huduma ya Uboreshaji iwe rahisi zaidi ili kutoa fursa ya kuchagua jinsi ya kuimarisha data ghafi ya programu zinazoingia. Na hatukuwa na chaguo ila kufanya huduma ya urutubishaji pia kuwa Serverless.
Kufanya kazi na Fission, tulitumia Fission CLI, ambayo lazima imewekwa juu ya Kubernetes CLI. Kupeleka vitendaji kwenye nguzo ya k8s ni rahisi sana; unahitaji tu kugawa njia ya ndani na kuingilia kazini ili kuruhusu trafiki inayoingia ikiwa ufikiaji nje ya nguzo inahitajika. Kupeleka kitendakazi kimoja kwa kawaida huchukua si zaidi ya sekunde 10.
Uwasilishaji wa mwisho wa mradi na muhtasari
Ili kuonyesha jinsi mfumo wetu unavyofanya kazi, tumeweka fomu rahisi kwenye seva ya mbali ambapo unaweza kutuma maombi ya mojawapo ya bidhaa za benki. Ili kuomba, ilibidi uweke herufi za kwanza, tarehe ya kuzaliwa na nambari ya simu.
Data kutoka kwa fomu ya mteja ilikwenda kwa mtawala, ambayo wakati huo huo ilituma maombi kwa sheria zote zilizopo, baada ya kuimarisha data hapo awali kulingana na hali maalum, na kuzihifadhi kwenye hifadhi ya kawaida. Kwa jumla, tumetumia vipengele vitatu vinavyofanya maamuzi kuhusu programu zinazoingia na huduma 4 za uboreshaji wa data. Baada ya kutuma maombi, mteja alipokea uamuzi wetu:
Mbali na kukataa au kupitishwa, mteja pia alipokea orodha ya bidhaa nyingine, maombi ambayo tulituma sambamba. Hivi ndivyo tulivyoonyesha uwezekano wa uuzaji katika jukwaa letu.
Kulikuwa na jumla ya bidhaa 3 za uwongo za benki zilizopatikana:
- Mikopo.
- Toy
- Rehani.
Wakati wa onyesho, tulituma vitendaji vilivyotayarishwa na hati za uboreshaji kwa kila huduma.
Kila sheria ilihitaji seti yake ya data ya uingizaji. Kwa hiyo, ili kuidhinisha rehani, tulihesabu ishara ya zodiac ya mteja na tukaunganisha hii na mantiki ya kalenda ya mwezi. Ili kuidhinisha toy, tuliangalia kuwa mteja amefikia umri wa watu wengi, na kutoa mkopo, tulituma ombi kwa huduma ya nje ya wazi kwa ajili ya kuamua operator wa simu za mkononi, na uamuzi ulifanywa juu yake.
Tulijaribu kufanya onyesho letu liwe la kuvutia na shirikishi, kila mtu aliyehudhuria angeweza kwenda kwenye fomu yetu na kuangalia upatikanaji wa huduma zetu za kubuni kwao. Na mwisho wa wasilisho, tulionyesha uchanganuzi wa maombi yaliyopokelewa, ambayo yalionyesha ni watu wangapi walitumia huduma yetu, idadi ya idhini, na kukataliwa.
Ili kukusanya takwimu mtandaoni, tulituma pia zana huria ya BI na kuiweka kwenye kitengo chetu cha kuhifadhi. Metabase hukuruhusu kuunda skrini na uchanganuzi juu ya data inayotuvutia; unahitaji tu kusajili muunganisho kwenye hifadhidata, chagua jedwali (kwa upande wetu, makusanyo ya data, kwani tulitumia MongoDB), na ueleze sehemu za riba kwetu. .
Kwa hivyo, tulipata mfano mzuri wa jukwaa la kufanya maamuzi, na wakati wa onyesho, kila msikilizaji angeweza kuangalia utendakazi wake kibinafsi. Suluhisho la kupendeza, mfano uliomalizika na onyesho lililofanikiwa lilituruhusu kushinda, licha ya ushindani mkali kutoka kwa timu zingine. Nina hakika kwamba makala ya kuvutia yanaweza pia kuandikwa kwenye mradi wa kila timu.
Chanzo: mapenzi.com