Keçən ildən şirkətimiz hakatonların təşkilinə başladı. İlk belə müsabiqə çox uğurlu oldu, biz bu barədə yazmışdıq . İkinci hakathon 2019-cu ilin fevralında baş tutdu və heç də az uğur qazanmadı. Bu yaxınlarda sonuncunun keçirilməsinin məqsədləri haqqında təşkilatçı.
İştirakçılara onun həyata keçirilməsi üçün texnologiya yığını seçməkdə tam sərbəstliklə kifayət qədər maraqlı tapşırıq verildi. Sürətli tətbiqlər axını ilə işləyə bilən, ağır yüklərə tab gətirə bilən və sistemin özü asanlıqla miqyaslana bilən müştəri skorinq funksiyalarının rahat yerləşdirilməsi üçün qərar qəbuletmə platformasını həyata keçirmək lazım idi.
İştirakçıların layihələrinin yekun təqdimatlarının nümayişi zamanı əmin olduğumuz kimi, tapşırıq qeyri-ciddidir və bir çox cəhətdən həll edilə bilər. Hackathonda 6 nəfərdən ibarət 5 komanda var idi, bütün iştirakçıların yaxşı layihələri var idi, lakin bizim platformamız ən rəqabətli oldu. Çox maraqlı bir layihəmiz var, bu məqalədə ondan danışmaq istərdim.
Bizim həllimiz Kubernetes daxilində Serversiz arxitekturaya əsaslanan platformadır və istehsala yeni funksiyalar gətirmək üçün lazım olan vaxtı azaldır. O, analitiklərə mühəndislərin və tərtibatçıların iştirakı olmadan onlar üçün əlverişli mühitdə kod yazmağa və onu istehsalata yerləşdirməyə imkan verir.
Qol vurmaq nədir
Tinkoff.ru, bir çox müasir şirkətlər kimi, müştəri reytinqinə malikdir. Qiymətləndirmə məlumatların təhlilinin statistik metodlarına əsaslanan müştəri qiymətləndirmə sistemidir.
Məsələn, müştəri ona kredit vermək və ya bizdə fərdi sahibkar hesabı açmaq xahişi ilə bizə müraciət edir. Əgər ona kredit verməyi planlaşdırırıqsa, o zaman onun ödəmə qabiliyyətini qiymətləndirməliyik və əgər hesab fərdi sahibkardırsa, o zaman müştərinin saxta əməliyyatlar aparmayacağına əmin olmalıyıq.
Bu cür qərarların qəbulu üçün əsas həm proqramın özündən məlumatları, həm də yaddaşımızdakı məlumatları təhlil edən riyazi modellərdir. Müştərilərimiz üçün yeni məhsullar üçün fərdi tövsiyələrin yaradılması xidmətində qiymətləndirmədən əlavə, oxşar statistik metodlardan da istifadə edilə bilər.
Belə bir qiymətləndirmə metodu müxtəlif giriş məlumatlarını qəbul edə bilər. Və nə vaxtsa girişə yeni parametr əlavə edə bilərik ki, bu da tarixi məlumatların təhlilinin nəticələrinə əsasən xidmətdən istifadənin çevrilmə sürətini artıracaq.
Müştəri əlaqələri haqqında çoxlu məlumatımız var və bu məlumatların həcmi daim artır. Hesabın işləməsi üçün məlumatların işlənməsi həmçinin, potensial maraqlarını qiymətləndirərək, kimin ərizəni təsdiqləyəcəyini, kimin imtina edəcəyini və kimə daha bir neçə məhsul təklif edəcəyini tez qərar verməyə imkan verən qaydalar (və ya riyazi modellər) tələb edir.
Qarşıda duran vəzifə üçün biz artıq xüsusi qərar qəbuletmə sistemindən istifadə edirik , hansı ki, analitiklər, texnoloqlar və tərtibatçılar tərəfindən müəyyən edilmiş qaydalara əsaslanaraq, müəyyən bir bank məhsulunu müştəriyə təsdiq edib-etməmək barədə qərar qəbul edir.
Bazarda çoxlu hazır həllər var, həm qiymətləndirmə modelləri, həm də qərar qəbuletmə sistemlərinin özləri. Biz şirkətimizdə bu sistemlərdən birini istifadə edirik. Amma biznes böyüyür, şaxələnir, həm müştərilərin sayı, həm də təklif olunan məhsulların sayı artır və bununla yanaşı, mövcud qərar qəbuletmə prosesini necə təkmilləşdirmək barədə fikirlər də yaranır. Şübhəsiz ki, mövcud sistemlə işləyən insanların onu necə daha sadə, daha yaxşı, daha rahat etmək barədə çoxlu fikirləri var, lakin bəzən kənardan gələn fikirlər faydalı olur. Yeni Hackathon sağlam ideyaları toplamaq məqsədi ilə təşkil edilib.
Tapşırıq
Hackathon fevralın 23-də keçirilib. İştirakçılara döyüş tapşırığı təklif olunub: bir sıra şərtlərə cavab verməli olan qərar qəbuletmə sistemini hazırlamaq.
Mövcud sistemin necə fəaliyyət göstərdiyi və onun işləməsi zamanı hansı çətinliklərin yarandığı, eləcə də hazırlanmış platformanın hansı biznes məqsədləri güdməli olduğu izah edildi. Analitiklərin iş kodunun istehsala mümkün qədər tez daxil olması üçün sistemin qaydaların işlənib hazırlanması üçün sürətli bazara çıxma vaxtı olmalıdır. Daxil olan müraciət axını üçün qərar qəbul etmə müddəti minimuma enməlidir. Həmçinin, inkişaf etdirilən sistem, bizim tərəfimizdən təsdiqləndiyi və müştərinin potensial marağı olduğu halda müştəriyə digər şirkət məhsullarını almaq imkanı vermək üçün çarpaz satış imkanlarına malik olmalıdır.
Aydındır ki, bir gecədə buraxılmağa hazır bir layihə yazmaq mümkün deyil ki, bu, əlbəttə ki, istehsala girəcək və bütün sistemi əhatə etmək kifayət qədər çətindir, ona görə də bizdən ən azı bir hissəsini həyata keçirməyi xahiş etdilər. Prototipin təmin etməli olduğu bir sıra tələblər müəyyən edilmişdir. Həm bütün tələbləri bütövlükdə əhatə etməyə cəhd etmək, həm də işlənən platformanın ayrı-ayrı bölmələri üzərində ətraflı işləmək mümkün idi.
Texnologiyaya gəlincə, bütün iştirakçılara tam seçim azadlığı verildi. İstənilən konsepsiya və texnologiyalardan istifadə etmək mümkün idi: məlumat axını, maşın öyrənməsi, hadisə mənbəyi, böyük verilənlər və s.
Bizim həllimiz
Bir az beyin fırtınası etdikdən sonra qərara gəldik ki, FaaS həlli tapşırığı yerinə yetirmək üçün idealdır.
Bu həll üçün hazırlanmaqda olan qərar qəbuletmə sisteminin qaydalarını həyata keçirmək üçün uyğun Serversiz çərçivə tapmaq lazım idi. Tinkoff infrastrukturun idarə olunması üçün Kubernetes-dən fəal şəkildə istifadə etdiyi üçün biz onun əsasında bir neçə hazır həll variantına baxdıq, bu barədə sizə daha sonra məlumat verəcəyəm.
Ən təsirli həlli tapmaq üçün biz istifadəçilərin gözü ilə inkişaf etdirilən məhsula baxdıq. Sistemimizin əsas istifadəçiləri qaydaların hazırlanması ilə məşğul olan analitiklərdir. Qaydalar serverə yerləşdirilməlidir və ya bizim vəziyyətimizdə olduğu kimi, sonradan qərar qəbul etmək üçün buludda yerləşdirilməlidir. Analitikin nöqteyi-nəzərindən iş prosesi belə görünür:
- Analitik anbardan alınan məlumatlar əsasında skript, qayda və ya ML modeli yazır. Hackathon çərçivəsində biz Mongodb-dan istifadə etmək qərarına gəldik, lakin burada məlumatların saxlanması sisteminin seçimi vacib deyil.
- Hazırlanmış qaydaları tarixi məlumatlar üzərində sınaqdan keçirdikdən sonra analitik öz kodunu admin panelinə yükləyir.
- Versiyanı təmin etmək üçün bütün kodlar Git depolarına gedəcək.
- İdarəetmə paneli vasitəsilə kodu buludda ayrıca funksional Serversiz modul kimi yerləşdirmək mümkün olacaq.
Müştərilərdən gələn ilkin məlumatlar ilkin sorğunu anbardan verilənlərlə zənginləşdirmək üçün nəzərdə tutulmuş ixtisaslaşdırılmış Zənginləşdirmə xidmətindən keçməlidir. Bu xidməti elə bir şəkildə həyata keçirmək vacib idi ki, o, vahid məlumat strukturunu saxlamaq üçün vahid repozitoriya ilə işləsin (analitik qaydalar hazırlayarkən məlumatları ondan alır).
Hackathondan əvvəl də istifadə edəcəyimiz Serversiz çərçivəyə qərar verdik. Bu gün bazarda bu yanaşmanı həyata keçirən kifayət qədər çox sayda texnologiya var. Kubernetes arxitekturasında ən populyar həllər Fission, Open FaaS və Kubeless-dir. Hətta var .
Bütün müsbət və mənfi cəhətləri çəkdikdən sonra seçdik . Bu Serversiz çərçivəni idarə etmək olduqca asandır və tapşırığın tələblərinə cavab verir.
Fission ilə işləmək üçün iki əsas anlayışı başa düşməlisiniz: funksiya və ətraf mühit. Funksiya, Fission mühitinin mövcud olduğu dillərdən birində yazılmış kod parçasıdır. Python, JS, Go, JVM və bir çox digər məşhur dillər və texnologiyalar daxildir.
Fission həm də bir neçə fayla bölünmüş, əvvəlcədən arxivə yığılmış funksiyaları yerinə yetirməyə qadirdir. Fission-un Kubernetes klasterində işləməsi çərçivənin özü tərəfindən idarə olunan ixtisaslaşmış podlar tərəfindən təmin edilir. Klaster podları ilə qarşılıqlı əlaqə yaratmaq üçün hər bir funksiyaya öz marşrutu təyin edilməlidir və siz POST sorğusu olduğu halda GET parametrlərini və ya sorğu orqanını ötürə bilərsiniz.
Nəticədə, analitiklərə mühəndislərin və tərtibatçıların iştirakı olmadan işlənmiş qayda skriptlərini yerləşdirməyə imkan verəcək bir həll əldə etməyi planlaşdırdıq. Təsvir edilən yanaşma həm də tərtibatçıların analitik kodunu başqa dilə yenidən yazmaq ehtiyacını aradan qaldırır. Məsələn, istifadə etdiyimiz hazırkı qərar qəbuletmə sistemi üçün biz yüksək ixtisaslaşmış texnologiyalarda və dillərdə qaydaları yazmalıyıq, onların əhatə dairəsi son dərəcə məhduddur və tətbiq serverindən də güclü asılılıq var, çünki bütün bank qaydaları layihələri vahid mühitdə yerləşdirilir. Nəticədə, yeni qaydaları tətbiq etmək üçün bütün sistemi buraxmaq lazımdır.
Təklif etdiyimiz həllimizdə qaydaların buraxılmasına ehtiyac yoxdur; kod bir düyməni basmaqla asanlıqla yerləşdirilə bilər. Ayrıca, Kubernetes-də infrastrukturun idarə edilməsi yük və miqyas haqqında düşünməməyə imkan verir; bu cür problemlər qutudan kənarda həll olunur. Və vahid məlumat anbarının istifadəsi analitikin işini asanlaşdıran real vaxt məlumatlarını tarixi məlumatlarla müqayisə etmək ehtiyacını aradan qaldırır.
Nə aldıq
Hackathon-a hazır bir həll yolu ilə gəldiyimiz üçün (fantaziyalarımızda) bütün düşüncələrimizi kod sətirlərinə çevirmək kifayət idi.
İstənilən hakatonun uğurunun açarı hazırlıq və yaxşı yazılmış plandır. Buna görə də ilk etdiyimiz iş sistem arxitekturamızın hansı modullardan ibarət olacağına və hansı texnologiyalardan istifadə edəcəyimizə qərar vermək oldu.
Layihəmizin arxitekturası belə idi:
Bu diaqramda iki giriş nöqtəsi, analitik (sistemimizin əsas istifadəçisi) və müştəri göstərilir.
İş prosesi belə qurulub. Analitik öz modeli üçün qayda funksiyası və məlumatların zənginləşdirilməsi funksiyasını işləyib hazırlayır, kodunu Git repozitoriyasında saxlayır və administrator proqramı vasitəsilə modelini buludda yerləşdirir. Yerləşdirilmiş funksiyanın necə çağırılacağını nəzərdən keçirək və müştərilərdən daxil olan sorğular üzrə qərar qəbul edək:
- Müştəri veb saytında bir forma doldurur və sorğusunu nəzarətçiyə göndərir. Haqqında qərar qəbul edilməli olan ərizə sistem daxilinə gəlir və verilənlər bazasında ilkin formada qeyd olunur.
- Bundan sonra xam sorğu, zəruri hallarda zənginləşdirməyə göndərilir. Siz ilkin sorğunu həm xarici xidmətlərdən, həm də yaddaşdan verilənlərlə əlavə edə bilərsiniz. Nəticədə zənginləşdirilmiş sorğu da verilənlər bazasında saxlanılır.
- Zənginləşdirilmiş sorğunu giriş kimi qəbul edən və yaddaşa da yazılan həlli istehsal edən analitik funksiyası işə salınır.
Məlumatların JSON sənədləri formasında sənəd yönümlü saxlanması səbəbindən MongoDB-ni sistemimizdə yaddaş kimi istifadə etmək qərarına gəldik, çünki zənginləşdirmə xidmətləri, o cümlədən ilkin sorğu REST nəzarətçiləri vasitəsilə bütün məlumatları birləşdirdi.
Beləliklə, platformanı həyata keçirmək üçün XNUMX saatımız var idi. Rolları olduqca uğurla bölüşdürdük; layihəmizdə hər bir komanda üzvünün öz məsuliyyət sahəsi var idi:
- Yazılı skriptlərin versiyaya nəzarət sistemindən qaydaları endirə, daxil edilmiş məlumatların zənginləşdirilməsi variantlarını seçə və qayda skriptlərini onlayn redaktə edə bilən analitikin işi üçün qabaqcıl idarəetmə panelləri.
- Backend admini, o cümlədən cəbhə üçün REST API və VCS ilə inteqrasiya.
- Google Cloud-da infrastrukturun qurulması və mənbə məlumatlarının zənginləşdirilməsi üçün xidmətin hazırlanması.
- Qaydaların sonrakı yerləşdirilməsi üçün idarəetmə proqramını Serversiz çərçivə ilə inteqrasiya etmək üçün modul.
- Bütün sistemin işini yoxlamaq üçün qaydaların skriptləri və yekun nümayiş üçün daxil olan tətbiqlər (qərarlar) üzrə analitiklərin toplanması.
Sifariş etməyə başlayaq.
Ön tərəfimiz bank UI Kitindən istifadə edərək Angular 7-də yazılmışdır. İdarəetmə panelinin son versiyası belə görünürdü:
Vaxt az olduğu üçün biz yalnız əsas funksionallığı həyata keçirməyə çalışdıq. Funksiyanı Kubernetes klasterində yerləşdirmək üçün hadisəni (qaydanın buludda yerləşdirilməsi lazım olan xidmət) və qərar qəbul etmə məntiqini həyata keçirən funksiyanın kodunu seçmək lazım idi. Seçilmiş xidmət üçün qaydanın hər yerləşdirilməsi üçün biz bu hadisənin qeydini yazdıq. İdarəetmə panelində bütün hadisələrin qeydlərini görə bilərsiniz.
Bütün funksiya kodu uzaq Git deposunda saxlanılırdı, o da idarəetmə panelində təyin edilməli idi. Kodun versiyaya salınması üçün bütün funksiyalar deponun müxtəlif filiallarında saxlanılırdı. İdarəetmə paneli həm də yazılı skriptlərə düzəlişlər etmək imkanı verir ki, funksiyanı istehsala yerləşdirməzdən əvvəl nəinki yazılı kodu yoxlaya, həm də lazımi dəyişiklikləri edə biləsiniz.
Qaydalar funksiyalarına əlavə olaraq, Zənginləşdirmə funksiyalarından istifadə edərək mənbə məlumatlarını tədricən zənginləşdirmək qabiliyyətini də həyata keçirdik, kodu da məlumat anbarına getmək, üçüncü tərəf xidmətlərinə zəng etmək və ilkin hesablamalar aparmaq mümkün olan skriptlər idi. . Həllimizi nümayiş etdirmək üçün sorğunu tərk edən müştərinin bürcünü hesabladıq və üçüncü tərəfin REST xidmətindən istifadə edərək mobil operatorunu təyin etdik.
Platformanın arxa hissəsi Java-da yazılmış və Spring Boot proqramı kimi həyata keçirilmişdir. Əvvəlcə admin məlumatlarını saxlamaq üçün Postgres-dən istifadə etməyi planlaşdırdıq, lakin hakatonun bir hissəsi olaraq vaxta qənaət etmək üçün özümüzü sadə H2 ilə məhdudlaşdırmağa qərar verdik. Arxa tərəfdə sorğu zənginləşdirmə funksiyalarının və qayda skriptlərinin versiyası üçün Bitbucket ilə inteqrasiya həyata keçirildi. Uzaq Git depoları ilə inteqrasiya üçün istifadə etdik , rahat proqram interfeysindən istifadə edərək istənilən git təlimatlarını yerinə yetirməyə imkan verən CLI əmrləri üzərində bir növ sarğıdır. Beləliklə, zənginləşdirmə funksiyaları və qaydaları üçün iki ayrı depomuz var idi və bütün skriptlər kataloqlara bölündü. UI vasitəsilə deponun ixtiyari filialının skriptinin ən son icrasını seçmək mümkün idi. İdarəetmə paneli vasitəsilə kodda dəyişikliklər edildikdə, dəyişdirilmiş kodun öhdəlikləri uzaq depolarda yaradıldı.
İdeyamızı həyata keçirmək üçün bizə uyğun infrastruktur lazım idi. Kubernetes klasterimizi buludda yerləşdirmək qərarına gəldik. Seçimimiz Google Bulud Platforması idi. Fission serversiz çərçivə Gcloud-da yerləşdirdiyimiz Kubernetes klasterində quraşdırılıb. İlkin olaraq, mənbə məlumatlarının zənginləşdirilməsi xidməti k8s klasterində Pod-a bükülmüş ayrıca Java proqramı kimi həyata keçirilirdi. Lakin hakatonun ortasında layihəmizin ilkin nümayişindən sonra bizə gələn tətbiqlərin xam məlumatlarının zənginləşdirilməsini seçmək imkanı vermək üçün Zənginləşdirmə xidmətini daha çevik etmək tövsiyə olundu. Zənginləşdirmə xidmətini də Serversiz etməkdən başqa seçimimiz yox idi.
Fission ilə işləmək üçün biz Kubernetes CLI-nin üstündə quraşdırılmalı olan Fission CLI-dən istifadə etdik. Funksiyaları k8s klasterinə yerləşdirmək olduqca sadədir; siz sadəcə olaraq daxili marşrut təyin etməli və klasterdən kənara giriş lazım olarsa, gələn trafikə icazə vermək üçün funksiyaya daxil olmalısınız. Bir funksiyanın yerləşdirilməsi adətən 10 saniyədən çox çəkmir.
Layihənin yekun təqdimatı və yekunlaşdırılması
Sistemimizin necə işlədiyini nümayiş etdirmək üçün biz uzaq serverdə bank məhsullarından biri üçün ərizə təqdim edə biləcəyiniz sadə forma yerləşdirdik. Müraciət etmək üçün baş hərflərinizi, doğum tarixinizi və telefon nömrənizi daxil etməlisiniz.
Müştəri formasından məlumatlar əvvəlcədən göstərilən şərtlərə uyğun olaraq məlumatları zənginləşdirərək və ümumi yaddaşda saxlayaraq bütün mövcud qaydalar üçün sorğu göndərən nəzarətçiyə getdi. Ümumilikdə, biz daxil olan tətbiqlər üzrə qərar qəbul edən üç funksiya və 4 məlumat zənginləşdirmə xidməti tətbiq etdik. Ərizəni təqdim etdikdən sonra müştəri qərarımızı aldı:
İmtina və ya təsdiqlə yanaşı, müştəri paralel olaraq göndərdiyimiz digər məhsulların siyahısını da aldı. Platformamızda çarpaz satışın mümkünlüyünü belə nümayiş etdirdik.
Ümumilikdə 3 saxta bank məhsulu mövcud idi:
- Kredit.
- Oyuncaqlar
- İpoteka.
Nümayiş zamanı biz hər bir xidmət üçün hazırlanmış funksiyaları və zənginləşdirmə skriptlərini yerləşdirdik.
Hər bir qayda öz giriş məlumat dəstini tələb edirdi. Beləliklə, ipotekanı təsdiqləmək üçün müştərinin bürcünü hesabladıq və bunu ay təqviminin məntiqi ilə əlaqələndirdik. Oyuncağı təsdiqləmək üçün müştərinin yetkinlik yaşına çatdığını yoxladıq və kreditin verilməsi üçün mobil operatorun müəyyən edilməsi üçün xarici açıq xidmətə sorğu göndərdik və bununla bağlı qərar qəbul olundu.
Nümayişimizi maraqlı və interaktiv etməyə çalışdıq, orada olan hər kəs bizim formamıza daxil olub qondarma xidmətlərimizin onlara olub-olmadığını yoxlaya bildi. Və təqdimatın ən sonunda biz qəbul edilmiş müraciətlərin analitikasını nümayiş etdirdik ki, bu da xidmətimizdən neçə nəfərin istifadə etdiyini, təsdiq və imtinaların sayını göstərir.
Analitikləri onlayn toplamaq üçün biz əlavə olaraq açıq mənbəli BI alətini tətbiq etdik və saxlama vahidimizə vidaladı. Metabaza bizi maraqlandıran məlumatlar üzərində analitika ilə ekranlar qurmağa imkan verir; sadəcə olaraq verilənlər bazası ilə əlaqəni qeydiyyatdan keçirməli, cədvəlləri seçməlisiniz (bizim vəziyyətimizdə, MongoDB-dən istifadə etdiyimiz üçün məlumat kolleksiyaları) və bizi maraqlandıran sahələri göstərməlisiniz. .
Nəticədə biz qərar qəbul edən platformanın yaxşı prototipini əldə etdik və nümayiş zamanı hər bir dinləyici onun performansını şəxsən yoxlaya bildi. Maraqlı həll, hazır prototip və uğurlu nümayiş digər komandaların güclü rəqabətinə baxmayaraq, bizə qalib gəlməyə imkan verdi. Əminəm ki, hər bir komandanın layihəsinə maraqlı məqalə də yazmaq olar.
Mənbə: www.habr.com