Անցյալ տարվանից մեր ընկերությունը սկսել է կազմակերպել հեքըթոններ: Առաջին նման մրցույթը շատ հաջող էր, այդ մասին մենք գրել ենք . Երկրորդ հեքըթոնը տեղի ունեցավ 2019 թվականի փետրվարին և ոչ պակաս հաջողությամբ անցավ։ Վերջինիս անցկացման նպատակների մասին ոչ վաղ անցյալում կազմակերպիչ.
Մասնակիցներին տրվել է բավականին հետաքրքիր առաջադրանք՝ դրա իրականացման համար տեխնոլոգիական փաթեթ ընտրելու լիակատար ազատությամբ։ Հաճախորդների գնահատման գործառույթների հարմար տեղակայման համար անհրաժեշտ էր որոշումների կայացման հարթակ ներդնել, որը կարող էր աշխատել հավելվածների արագ հոսքի հետ, դիմակայել ծանր բեռներին, իսկ համակարգն ինքնին հեշտությամբ ընդլայնելի էր:
Խնդիրն աննշան է և կարող է լուծվել բազմաթիվ առումներով, ինչում մենք համոզվեցինք մասնակիցների նախագծերի վերջնական ներկայացումների ցուցադրության ժամանակ։ Հեքըթոնին 6 հոգանոց 5 թիմ էր, բոլոր մասնակիցներն էլ լավ նախագծեր ունեին, բայց մեր հարթակը ամենամրցունակն էր։ Մենք ունենք շատ հետաքրքիր նախագիծ, որի մասին կցանկանայի խոսել այս հոդվածում։
Մեր լուծումը Kubernetes-ի ներսում առանց սերվերի ճարտարապետության վրա հիմնված հարթակ է, որը նվազեցնում է արտադրության նոր հնարավորությունները բերելու ժամանակը: Այն վերլուծաբաններին թույլ է տալիս կոդ գրել իրենց համար հարմար միջավայրում և այն գործարկել արտադրության մեջ՝ առանց ինժեներների և մշակողների մասնակցության:
Ինչ է վաստակում
Tinkoff.ru-ն, ինչպես շատ ժամանակակից ընկերություններ, ունի հաճախորդների գնահատական: Scoring-ը հաճախորդների գնահատման համակարգ է, որը հիմնված է տվյալների վերլուծության վիճակագրական մեթոդների վրա:
Օրինակ՝ հաճախորդը դիմում է մեզ՝ իրեն վարկ տրամադրելու խնդրանքով կամ մեզ մոտ բացել անհատ ձեռնարկատիրոջ հաշիվ: Եթե մենք նախատեսում ենք նրան վարկ տրամադրել, ապա պետք է գնահատենք նրա վճարունակությունը, իսկ եթե հաշիվը անհատ ձեռնարկատեր է, ապա պետք է վստահ լինել, որ հաճախորդը կեղծ գործարքներ չի կատարի։
Նման որոշումներ կայացնելու հիմքում ընկած են մաթեմատիկական մոդելները, որոնք վերլուծում են ինչպես բուն հավելվածի տվյալները, այնպես էլ մեր պահեստի տվյալները: Ի լրումն միավորների, նմանատիպ վիճակագրական մեթոդներ կարող են օգտագործվել նաև մեր հաճախորդների համար նոր ապրանքատեսակների համար անհատական առաջարկությունների ստեղծման ծառայության մեջ:
Նման գնահատման մեթոդը կարող է ընդունել մի շարք մուտքային տվյալներ: Եվ ինչ-որ պահի մենք կարող ենք մուտքագրում ավելացնել նոր պարամետր, որը, հիմնվելով պատմական տվյալների վրա վերլուծության արդյունքների վրա, կբարձրացնի ծառայությունից օգտվելու փոխակերպման տոկոսադրույքը։
Մենք ունենք բազմաթիվ տվյալներ հաճախորդների հետ հարաբերությունների մասին, և այդ տեղեկատվության ծավալը մշտապես աճում է: Որպեսզի միավորներն աշխատեն, տվյալների մշակման համար պահանջվում են նաև կանոններ (կամ մաթեմատիկական մոդելներ), որոնք թույլ են տալիս արագ որոշել, թե ում հաստատել հայտը, ում մերժել և ում առաջարկել ևս մի քանի ապրանք՝ գնահատելով դրանց հավանական հետաքրքրությունը:
Առաջադրանքի համար մենք արդեն օգտագործում ենք որոշումների կայացման մասնագիտացված համակարգ , որը, հիմնվելով վերլուծաբանների, տեխնոլոգների և մշակողների կողմից սահմանված կանոնների վրա, որոշում է հաճախորդին հաստատել կամ մերժել որոշակի բանկային պրոդուկտ:
Շուկայում կան բազմաթիվ պատրաստի լուծումներ՝ և՛ գնահատման մոդելները, և՛ որոշումների կայացման համակարգերը: Մենք օգտագործում ենք այս համակարգերից մեկը մեր ընկերությունում: Բայց բիզնեսն աճում է, դիվերսիֆիկացվում է, և՛ հաճախորդների, և՛ առաջարկվող ապրանքների քանակը ավելանում է, և դրան զուգահեռ՝ գաղափարներ են առաջանում, թե ինչպես բարելավել առկա որոշումների կայացման գործընթացը: Անշուշտ, գոյություն ունեցող համակարգի հետ աշխատող մարդիկ շատ գաղափարներ ունեն այն մասին, թե ինչպես այն դարձնել ավելի պարզ, ավելի լավ, ավելի հարմար, բայց երբեմն դրսից գաղափարները օգտակար են: Նոր Հեքըթոնը կազմակերպվել է առողջ գաղափարներ հավաքելու նպատակով։
Առաջադրանք
Հեքըթոնն անցկացվել է փետրվարի 23-ին։ Մասնակիցներին առաջարկվել է մարտական առաջադրանք՝ մշակել որոշումների կայացման համակարգ, որը պետք է համապատասխաներ մի շարք պայմանների։
Մեզ ասացին, թե ինչպես է գործում գործող համակարգը և ինչ դժվարություններ են առաջանում դրա գործունեության ընթացքում, ինչպես նաև, թե ինչ բիզնես նպատակներ պետք է հետապնդի մշակված հարթակը։ Համակարգը պետք է արագ ժամանակ ունենա շուկա՝ կանոններ մշակելու համար, որպեսզի վերլուծաբանների աշխատանքային օրենսգիրքը հնարավորինս արագ մտնի արտադրության մեջ: Իսկ հայտերի մուտքային հոսքի համար որոշումների ընդունման ժամանակը պետք է ձգտի նվազագույնի։ Նաև մշակվող համակարգը պետք է ունենա խաչաձև վաճառքի հնարավորություններ, որպեսզի հաճախորդը հնարավորություն տա ձեռք բերել ընկերության այլ ապրանքներ, եթե դրանք հաստատված են մեր կողմից և պոտենցիալ հետաքրքրություն ունեն հաճախորդի կողմից:
Հասկանալի է, որ հնարավոր չէ մեկ գիշերվա ընթացքում գրել պատրաստի թողարկման նախագիծ, որն անշուշտ կմտնի արտադրություն, և բավականին դժվար է ծածկել ամբողջ համակարգը, ուստի մեզ խնդրեցին իրականացնել դրա գոնե մի մասը: Սահմանվել են մի շարք պահանջներ, որոնք նախատիպը պետք է բավարարի։ Կարելի էր փորձել և՛ ամբողջությամբ լուսաբանել բոլոր պահանջները, և՛ մանրամասնորեն աշխատել մշակվող հարթակի առանձին հատվածների վրա։
Ինչ վերաբերում է տեխնոլոգիային, ապա բոլոր մասնակիցներին տրվել է ընտրության լիակատար ազատություն։ Հնարավոր էր օգտագործել ցանկացած հասկացություն և տեխնոլոգիա՝ տվյալների հոսք, մեքենայական ուսուցում, իրադարձությունների աղբյուր, մեծ տվյալներ և այլն:
Մեր լուծումը
Մի փոքր ուղեղի փոթորկից հետո մենք որոշեցինք, որ FaaS լուծումը իդեալական կլինի առաջադրանքը կատարելու համար:
Այս լուծման համար անհրաժեշտ էր գտնել համապատասխան Serverless շրջանակ՝ մշակվող որոշումների կայացման համակարգի կանոններն իրականացնելու համար։ Քանի որ Tinkoff-ը ակտիվորեն օգտագործում է Kubernetes-ը ենթակառուցվածքների կառավարման համար, մենք դրա հիման վրա նայեցինք մի քանի պատրաստի լուծումներ, ես ձեզ ավելի ուշ կպատմեմ դրա մասին:
Ամենաարդյունավետ լուծումը գտնելու համար մենք նայեցինք մշակվող արտադրանքին իր օգտագործողների աչքերով: Մեր համակարգի հիմնական օգտագործողները կանոնների մշակման մեջ ներգրավված վերլուծաբաններն են: Կանոնները պետք է տեղակայվեն սերվերի վրա, կամ, ինչպես մեր դեպքում, տեղակայվեն ամպում, հետագա որոշումների կայացման համար: Վերլուծաբանի տեսանկյունից, աշխատանքային հոսքը հետևյալն է.
- Վերլուծաբանը գրում է սցենար, կանոն կամ ML մոդել՝ հիմնվելով պահեստի տվյալների վրա: Հեքըթոնի շրջանակներում մենք որոշեցինք օգտագործել Mongodb-ը, սակայն տվյալների պահպանման համակարգի ընտրությունն այստեղ կարևոր չէ։
- Պատմական տվյալների վրա մշակված կանոնները ստուգելուց հետո վերլուծաբանն իր կոդը վերբեռնում է ադմինիստրատորի վահանակ։
- Տարբերակումն ապահովելու համար ամբողջ ծածկագիրը կգնա Git պահոցներ:
- Ադմինիստրատորի վահանակի միջոցով հնարավոր կլինի կոդը տեղակայել ամպի մեջ՝ որպես առանձին ֆունկցիոնալ Serverless մոդուլ։
Հաճախորդների սկզբնական տվյալները պետք է անցնեն մասնագիտացված հարստացման ծառայության միջոցով, որը նախատեսված է նախնական հարցումը պահեստից ստացված տվյալներով հարստացնելու համար: Կարևոր էր այս ծառայությունն այնպես իրականացնել, որ այն աշխատեր մեկ պահոցի հետ (որից վերլուծաբանը տվյալներ է վերցնում կանոններ մշակելիս) տվյալների միասնական կառուցվածք պահպանելու համար:
Նույնիսկ հաքաթոնից առաջ մենք որոշեցինք առանց սերվերի շրջանակը, որը կօգտագործենք: Այսօր շուկայում բավականին շատ տեխնոլոգիաներ կան, որոնք իրականացնում են այս մոտեցումը։ Kubernetes ճարտարապետության մեջ ամենատարածված լուծումներն են Fission, Open FaaS և Kubeless: Նույնիսկ կան .
Բոլոր դրական և բացասական կողմերը կշռելուց հետո մենք ընտրեցինք . Այս առանց սերվերի շրջանակը բավականին հեշտ է կառավարվում և համապատասխանում է առաջադրանքի պահանջներին:
Fission-ի հետ աշխատելու համար դուք պետք է հասկանաք երկու հիմնական հասկացություն՝ ֆունկցիա և միջավայր: Ֆունկցիան կոդ է, որը գրված է լեզուներից մեկով, որի համար կա Fission միջավայր: ներառում է Python, JS, Go, JVM և շատ այլ հայտնի լեզուներ և տեխնոլոգիաներ:
Fission-ը նաև ի վիճակի է կատարել գործառույթներ՝ բաժանված մի քանի ֆայլերի՝ նախապես փաթեթավորված արխիվում: Fission-ի շահագործումը Kubernetes կլաստերում ապահովված է մասնագիտացված բլոկներով, որոնք կառավարվում են հենց շրջանակի կողմից: Կլաստերի փոդերի հետ փոխազդելու համար յուրաքանչյուր ֆունկցիայի պետք է հատկացվի իր սեփական երթուղին, և որին կարող եք փոխանցել GET պարամետրերը կամ հարցումի մարմինը POST հարցումի դեպքում:
Արդյունքում, մենք նախատեսում էինք լուծում ստանալ, որը վերլուծաբաններին թույլ կտա տեղակայել մշակված կանոնների սցենարներ՝ առանց ինժեներների և մշակողների մասնակցության: Նկարագրված մոտեցումը նաև վերացնում է մշակողների կողմից վերլուծական ծածկագիրը այլ լեզվով վերագրելու անհրաժեշտությունը: Օրինակ, ներկայիս որոշումների կայացման համակարգի համար, որը մենք օգտագործում ենք, մենք պետք է կանոններ գրենք բարձր մասնագիտացված տեխնոլոգիաներով և լեզուներով, որոնց շրջանակը չափազանց սահմանափակ է, և կա նաև մեծ կախվածություն հավելվածի սերվերից, քանի որ բանկի բոլոր կանոնների նախագծերը. տեղակայվում են մեկ միջավայրում: Արդյունքում, նոր կանոններ կիրառելու համար անհրաժեշտ է ազատել ամբողջ համակարգը:
Մեր առաջարկած լուծումում կանոններ թողարկելու կարիք չկա, կոդը կարող է հեշտությամբ տեղակայվել կոճակի սեղմումով: Նաև Kubernetes-ում ենթակառուցվածքի կառավարումը թույլ է տալիս չմտածել ծանրաբեռնվածության և մասշտաբի մասին, նման խնդիրները լուծվում են առանց արկղերի: Եվ մեկ տվյալների պահեստի օգտագործումը վերացնում է իրական ժամանակի տվյալները պատմական տվյալների հետ համեմատելու անհրաժեշտությունը, ինչը հեշտացնում է վերլուծաբանի աշխատանքը:
Այն, ինչ մենք ստացանք
Քանի որ մենք հաքաթոնին եկել էինք պատրաստի լուծումով (մեր ֆանտազիաներում), մեզ մնում էր միայն մեր բոլոր մտքերը վերածել կոդերի տողերի։
Ցանկացած հաքաթոնում հաջողության գրավականը նախապատրաստումն է և լավ գրված պլանը: Հետևաբար, առաջին բանը, որ մենք արեցինք, այն էր, թե ինչ մոդուլներից է բաղկացած լինելու մեր համակարգի ճարտարապետությունը և ինչ տեխնոլոգիաներ ենք օգտագործելու:
Մեր նախագծի ճարտարապետությունը հետևյալն էր.
Այս դիագրամը ցույց է տալիս մուտքի երկու կետեր՝ վերլուծաբանը (մեր համակարգի հիմնական օգտագործողը) և հաճախորդը:
Աշխատանքային գործընթացը կառուցված է այսպես. Վերլուծաբանը մշակում է կանոնների գործառույթ և տվյալների հարստացման գործառույթ իր մոդելի համար, պահում է իր կոդը Git պահեստում և իր մոդելը տեղակայում է ամպի վրա ադմինիստրատորի հավելվածի միջոցով: Եկեք դիտարկենք, թե ինչպես կկանչվի տեղակայված գործառույթը և որոշումներ կայացնենք հաճախորդների մուտքային հարցումների վերաբերյալ.
- Հաճախորդը կայքում լրացնում է ձևաթուղթ և իր հարցումն ուղարկում վերահսկիչին: Հայտը, որի վերաբերյալ պետք է որոշում կայացվի, գալիս է համակարգի մուտքագրում և գրանցվում տվյալների բազայում իր սկզբնական տեսքով:
- Հաջորդը, անհրաժեշտության դեպքում չմշակված հարցումն ուղարկվում է հարստացման: Նախնական հարցումը կարող եք լրացնել ինչպես արտաքին ծառայություններից, այնպես էլ պահեստից ստացված տվյալներով: Ստացված հարստացված հարցումը նույնպես պահվում է տվյալների բազայում։
- Գործարկվում է վերլուծական ֆունկցիան, որն ընդունում է հարստացված հարցումը որպես մուտքագրում և ստեղծում լուծում, որը նույնպես գրվում է պահեստում:
Մենք որոշեցինք օգտագործել MongoDB-ն որպես պահեստ մեր համակարգում՝ JSON փաստաթղթերի տեսքով տվյալների փաստաթղթակենտրոն պահպանման շնորհիվ, քանի որ հարստացման ծառայությունները, ներառյալ սկզբնական հարցումը, համախմբում էին բոլոր տվյալները REST կարգավորիչների միջոցով:
Այսպիսով, մենք XNUMX ժամ ունեինք հարթակն իրականացնելու համար։ Մենք բավականին հաջող բաշխեցինք դերերը, թիմի յուրաքանչյուր անդամ մեր նախագծում ուներ իր պատասխանատվության ոլորտը.
- Առջևի ադմինիստրատորի վահանակներ վերլուծաբանի աշխատանքի համար, որոնց միջոցով նա կարող էր ներբեռնել կանոններ գրավոր սցենարների տարբերակների կառավարման համակարգից, ընտրել մուտքային տվյալները հարստացնելու տարբերակներ և առցանց խմբագրել կանոնների սկրիպտները:
- Backend-ի ադմինիստրատորը, ներառյալ REST API-ն առջևի և VCS-ի հետ ինտեգրման համար:
- Google Cloud-ում ենթակառուցվածքի ստեղծում և աղբյուրի տվյալների հարստացման ծառայության մշակում:
- Ադմինիստրատորի հավելվածը առանց սերվերի շրջանակի հետ ինտեգրելու մոդուլ՝ կանոնների հետագա տեղակայման համար:
- Վերջնական ցուցադրման համար ամբողջ համակարգի կատարողականությունը ստուգելու և մուտքային հավելվածների վրա վերլուծությունների համախմբման կանոնների սցենարներ (ընդունված որոշումներ):
Սկսենք հերթականությամբ։
Մեր ճակատային մասը գրվել է Angular 7-ում՝ օգտագործելով բանկային UI Kit-ը: Ադմինիստրատորի վահանակի վերջնական տարբերակը այսպիսի տեսք ուներ.
Քանի որ քիչ ժամանակ կար, մենք փորձեցինք իրականացնել միայն հիմնական գործառույթը: Kubernetes կլաստերում ֆունկցիա տեղակայելու համար անհրաժեշտ էր ընտրել իրադարձություն (ծառայություն, որի համար կանոնը պետք է տեղադրվի ամպում) և այն ֆունկցիայի կոդը, որն իրականացնում է որոշումների կայացման տրամաբանությունը։ Ընտրված ծառայության համար կանոնի յուրաքանչյուր տեղակայման համար մենք գրել ենք այս իրադարձության գրանցամատյանը: Ադմինիստրատորի վահանակում դուք կարող եք տեսնել բոլոր իրադարձությունների տեղեկամատյանները:
Գործառույթի ամբողջ կոդը պահվում էր հեռավոր Git պահոցում, որը նույնպես պետք է տեղադրվեր ադմինիստրատորի վահանակում: Կոդը տարբերակելու համար բոլոր գործառույթները պահվում էին պահեստի տարբեր մասնաճյուղերում: Ադմինիստրատորի վահանակը նաև հնարավորություն է տալիս ճշգրտումներ կատարել գրավոր սկրիպտներում, որպեսզի նախքան գործառույթը արտադրության մեջ տեղակայելը, դուք կարող եք ոչ միայն ստուգել գրված կոդը, այլև կատարել անհրաժեշտ փոփոխությունները:
Բացի կանոնների գործառույթներից, մենք նաև ներդրեցինք աղբյուրի տվյալները աստիճանաբար հարստացնելու հնարավորություն՝ օգտագործելով Enrichment ֆունկցիաները, որոնց կոդը նույնպես սկրիպտներ էին, որոնցում հնարավոր էր գնալ տվյալների պահեստ, զանգահարել երրորդ կողմի ծառայություններ և կատարել նախնական հաշվարկներ: . Մեր լուծումը ցուցադրելու համար մենք հաշվարկել ենք հաճախորդի կենդանակերպի նշանը, ով թողել է հարցումը և որոշել իր բջջային օպերատորը՝ օգտագործելով երրորդ կողմի REST ծառայությունը:
Պլատֆորմի backend-ը գրվել է Java-ով և ներդրվել որպես Spring Boot հավելված։ Մենք ի սկզբանե նախատեսում էինք օգտագործել Postgres-ը՝ ադմինիստրատորի տվյալները պահելու համար, սակայն, որպես հաքաթոնի մի մաս, մենք որոշեցինք սահմանափակվել պարզ H2-ով՝ ժամանակ խնայելու համար: Հետևում, ինտեգրումը Bitbucket-ի հետ իրականացվել է հարցումների հարստացման գործառույթների և կանոնների սկրիպտների տարբերակման համար: Հեռավոր Git պահոցների հետ ինտեգրվելու համար մենք օգտագործեցինք , որը մի տեսակ փաթաթում է CLI հրամանների վրա, որը թույլ է տալիս կատարել ցանկացած git հրահանգ՝ օգտագործելով հարմար ծրագրային միջերես: Այսպիսով, մենք ունեինք երկու առանձին պահեստ հարստացման գործառույթների և կանոնների համար, և բոլոր սցենարները բաժանվեցին դիրեկտորիաների: UI-ի միջոցով հնարավոր եղավ ընտրել պահեստի կամայական ճյուղի սցենարի վերջին commit-ը։ Ադմինիստրատորի վահանակի միջոցով կոդի մեջ փոփոխություններ կատարելիս փոխված կոդի պարտավորությունները ստեղծվել են հեռավոր պահեստներում:
Մեր գաղափարը կյանքի կոչելու համար մեզ անհրաժեշտ էին համապատասխան ենթակառուցվածքներ։ Մենք որոշեցինք տեղակայել մեր Kubernetes կլաստերը ամպի մեջ: Մեր ընտրությունը Google Cloud Platform-ն էր: Fission առանց սերվերի շրջանակը տեղադրվել է Kubernetes կլաստերի վրա, որը մենք տեղակայել ենք Gcloud-ում: Սկզբում աղբյուրի տվյալների հարստացման ծառայությունն իրականացվել է որպես առանձին Java հավելված՝ փաթաթված Pod-ով k8s կլաստերի ներսում։ Բայց հաքաթոնի կեսին մեր նախագծի նախնական ցուցադրումից հետո մեզ առաջարկվեց ավելի ճկուն դարձնել Enrichment ծառայությունը՝ հնարավորություն ընձեռելու ընտրելու, թե ինչպես հարստացնել մուտքային հավելվածների չմշակված տվյալները: Եվ մենք այլ ելք չունեինք, քան հարստացման ծառայությունը դարձնել նաև Serverless։
Fission-ի հետ աշխատելու համար մենք օգտագործեցինք Fission CLI-ը, որը պետք է տեղադրվի Kubernetes CLI-ի վերևում: Գործառույթների տեղակայումը k8s կլաստերի մեջ բավականին պարզ է, դուք պարզապես պետք է նշանակեք ներքին երթուղի և մուտք գործեք գործառույթին, որպեսզի թույլատրեք մուտքային երթևեկությունը, եթե անհրաժեշտ է մուտք գործել կլաստերից դուրս: Մեկ գործառույթի տեղակայումը սովորաբար տևում է ոչ ավելի, քան 10 վայրկյան:
Նախագծի վերջնական ներկայացում և ամփոփում
Որպեսզի ցույց տանք, թե ինչպես է աշխատում մեր համակարգը, մենք տեղադրել ենք մի պարզ ձև հեռավոր սերվերի վրա, որտեղ կարող եք հայտ ներկայացնել բանկի արտադրանքներից մեկի համար: Հարցման համար պետք է մուտքագրել ձեր սկզբնատառերը, ծննդյան ամսաթիվը և հեռախոսահամարը:
Հաճախորդի ձևից տվյալները գնացել են վերահսկիչին, որը միաժամանակ հարցումներ է ուղարկել բոլոր առկա կանոնների համար՝ նախապես հարստացնելով տվյալները նշված պայմանների համաձայն և պահել դրանք ընդհանուր պահեստում: Ընդհանուր առմամբ, մենք գործարկեցինք երեք գործառույթ, որոնք որոշումներ են կայացնում մուտքային հավելվածների և 4 տվյալների հարստացման ծառայություններ: Հայտը ներկայացնելուց հետո հաճախորդը ստացավ մեր որոշումը.
Բացի մերժումից կամ հաստատումից, հաճախորդը ստացել է նաև այլ ապրանքների ցանկ, որոնց համար մենք զուգահեռ ուղարկել ենք հարցումներ: Այսպես մենք ցուցադրեցինք խաչաձև վաճառքի հնարավորությունը մեր հարթակում:
Ընդհանուր առմամբ առկա է եղել 3 կեղծ բանկային պրոդուկտ.
- Վարկ.
- Խաղալիք
- Հիփոթեք.
Ցուցադրության ընթացքում մենք տեղակայեցինք յուրաքանչյուր ծառայության համար պատրաստված գործառույթներ և հարստացման սցենարներ:
Յուրաքանչյուր կանոն պահանջում էր մուտքային տվյալների իր հավաքածուն: Այսպիսով, հիփոթեքը հաստատելու համար մենք հաշվարկեցինք հաճախորդի կենդանակերպի նշանը և դա կապեցինք լուսնային օրացույցի տրամաբանության հետ: Խաղալիքը հաստատելու համար մենք ստուգեցինք, որ հաճախորդը լրացել է չափահաս տարիքը, և վարկ տրամադրելու համար հարցում ուղարկեցինք արտաքին բաց ծառայությանը՝ բջջային օպերատորի որոշման համար, և դրա վերաբերյալ որոշում կայացվեց։
Մենք փորձեցինք մեր ցուցադրությունը դարձնել հետաքրքիր և ինտերակտիվ, բոլոր ներկաները կարող էին գնալ մեր ձևաթուղթ և ստուգել մեր գեղարվեստական ծառայությունների հասանելիությունը իրենց: Եվ շնորհանդեսի հենց վերջում մենք ցուցադրեցինք ստացված դիմումների վերլուծություն, որը ցույց էր տալիս, թե քանի մարդ է օգտվել մեր ծառայությունից, հաստատումների և մերժումների քանակը։
Առցանց վերլուծություններ հավաքելու համար մենք լրացուցիչ տեղադրեցինք բաց կոդով BI գործիք և այն պտուտակեց մեր պահեստային միավորին: Metabase-ը թույլ է տալիս մեզ հետաքրքրող տվյալների վրա վերլուծություններով էկրաններ կառուցել, պարզապես անհրաժեշտ է կապ գրանցել տվյալների բազայի հետ, ընտրել աղյուսակներ (մեր դեպքում տվյալների հավաքածուներ, քանի որ մենք օգտագործել ենք MongoDB) և նշել մեզ հետաքրքրող դաշտերը: .
Արդյունքում մենք ստացանք որոշումների կայացման հարթակի լավ նախատիպ, և ցուցադրության ընթացքում յուրաքանչյուր ունկնդիր կարող էր անձամբ ստուգել դրա կատարումը։ Հետաքրքիր լուծումը, պատրաստի նախատիպը և հաջող ցուցադրությունը մեզ թույլ տվեցին հաղթել՝ չնայած մյուս թիմերի ուժեղ մրցակցությանը: Համոզված եմ, որ յուրաքանչյուր թիմի նախագծի վերաբերյալ կարելի է նաև հետաքրքիր հոդված գրել։
Source: www.habr.com