Aprelin 25-də biz Mail.ru Group-da buludlar və ətraflar haqqında konfrans keçirdik - . Bir neçə məqam:
- Əsas — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center və Yandex.Cloud bulud bazarımızın xüsusiyyətləri və onların xidmətləri haqqında danışdı;
- Bitrix24-dən olan həmkarları necə olduqlarını izah etdilər ;
- Leroy Merlin, Otkritie, Burger King və Schneider Electric maraqlı təqdim etdi — bizneslərinin İT qarşısında hansı vəzifələr qoyduğunu və hansı texnologiyaları, o cümlədən bulud texnologiyalarını ən perspektivli hesab edirlər.
Siz mailto:CLOUD konfransından bütün videolara baxa bilərsiniz , və burada mikroservislər haqqında müzakirənin necə getdiyini oxuya bilərsiniz. MegaFon biznes sistemlərinin tədqiqat və inkişaf mərkəzinin rəhbəri Aleksandr Deulin və M.Video-Eldorado qrupunun informasiya texnologiyaları üzrə direktoru Sergey Sergeev monolitlərdən qurtulmaq üzrə uğurlu hallarını bölüşüblər. Biz həmçinin İT strategiyası, proseslər və hətta HR ilə bağlı məsələləri müzakirə etdik.
Panel iştirakçıları
- Sergey Sergeyev, Qrup CIO "M.Video-Eldorado";
- Aleksandr Deulin, biznes sistemlərinin tədqiqatı və inkişafı mərkəzinin rəhbəri MegaFon;
- Moderator - Dmitri Lazarenko, PaaS istiqamətinin rəhbəri Mail.ru Bulud Həlləri.
Aleksandr Deulinin çıxışından sonra O, M.Video-Eldorado-dan Sergey Sergeev və Mail.ru Cloud Solutions-dan müzakirə moderatoru Dmitri Lazarenko tərəfindən müzakirəyə qoşulur.
Aşağıda müzakirənin stenoqramını sizin üçün hazırlamışıq, lakin siz videoya da baxa bilərsiniz:
Mikroservislərə keçid bazar ehtiyaclarına cavabdır
Dmitri:
Mikroservislərə köçməkdə hər hansı uğurlu təcrübəniz olub? Və ümumiyyətlə: mikroservislərdən istifadənin və ya monolitdən mikroservislərə keçməyin ən böyük biznes faydasını harada görürsünüz?
Sergey:
Biz artıq mikroservislərə keçiddə müəyyən yol keçmişik və üç ildən artıqdır ki, bu yanaşmadan istifadə edirik. Mikroservislərə olan ehtiyacı əsaslandıran ilk ehtiyac müxtəlif qabaqcıl məhsulların arxa ofislə sonsuz inteqrasiyası idi. Və hər dəfə biz bu və ya digər xidmətin fəaliyyəti üçün öz qaydalarımızı həyata keçirərək əlavə inteqrasiya və inkişaf etməyə məcbur olurduq.
Müəyyən bir nöqtədə, sistemlərimizin işləməsini və funksionallığın çıxışını sürətləndirməli olduğumuzu başa düşdük. Həmin anda mikroservislər və mikroservis yanaşması kimi anlayışlar artıq bazarda mövcud idi və biz bunu sınamaq qərarına gəldik. Bu, 2016-cı ildə başladı. Sonra platformanın təməli qoyuldu və ilk 10 xidmət ayrıca komanda tərəfindən həyata keçirildi.
İlk, ən çox yüklənən xidmətlərdən biri qiymətlərin hesablanması xidməti idi. İstənilən kanala, M.Video-Eldorado şirkətlər qrupuna, istər veb-sayt, istərsə də pərakəndə satış mağazasına daxil olanda, orada məhsul seçin, internet səhifəsində və ya “Səbət”də qiymətə baxın, qiymət avtomatik olaraq müəyyən edilir. bir xidmət tərəfindən hesablanır. Bu niyə lazımdır: bundan əvvəl hər bir sistemin promosyonlarla işləmək üçün öz prinsipləri var idi - endirimlərlə və s. Bizim arxa ofisimiz qiymətlərlə məşğul olur, endirim funksiyası başqa sistemdə həyata keçirilir. Bunun mərkəzləşdirilməsi və bizə bunu həyata keçirməyə imkan verəcək bir iş prosesi şəklində unikal, ayrıla bilən bir xidmət yaradılmalı idi. Demək olar ki, belə başladıq.
İlk nəticələrin dəyəri çox böyük idi. Birincisi, biz ayrı-ayrılıqda və ümumi şəkildə işləməyə imkan verən ayrıla bilən qurumlar yarada bildik. İkincisi, biz daha çox sistemlə inteqrasiya baxımından sahiblik dəyərini aşağı saldıq.
Son üç il ərzində biz üç cəbhə sistemi əlavə etdik. Onları şirkətin ödəyə biləcəyi eyni miqdarda resurslarla saxlamaq çətin idi. Buna görə də, bazara sürət, daxili xərclər və səmərəlilik baxımından cavab verən yeni satış nöqtələri axtarmaq vəzifəsi ortaya çıxdı.
Mikroservislərə keçidin uğurunu necə ölçmək olar
Dmitri:
Mikroservislərə keçiddə uğur necə müəyyən edilir? Hər bir şirkətdə “əvvəl” nə idi? Keçidin uğurunu müəyyən etmək üçün hansı metrikdən istifadə etdiniz və onu əslində kim müəyyənləşdirdi?
Sergey:
Hər şeydən əvvəl, o, İT daxilində yeni imkanların “kilidini açan” bir imkan kimi doğuldu. Bazar çağırışlarına cavab verərək, nisbətən eyni pul üçün hər şeyi daha sürətli etməyə ehtiyacımız var idi. İndi müvəffəqiyyət müxtəlif sistemlər tərəfindən təkrar istifadə edilən xidmətlərin sayında, proseslərin öz aralarında birləşməsində ifadə olunur. İndi var, amma o anda bir platforma yaratmaq və biz bunu edə biləcəyimiz fərziyyəsini təsdiqləmək üçün bir fürsət idi, bu, effekt verəcək və biznes vəziyyətini hesablayacaq.
İskəndər:
Uğur daha çox daxili hissdir. Biznes həmişə daha çox istəyir və geridə qalan işlərimizin dərinliyi uğurun sübutudur. Mənə elə gəlir.
Sergey:
Bəli, razıyam. Üç il ərzində artıq iki yüzdən çox xidmətimiz və geridə qalmış işlərimiz var. Komanda daxilində resurslara ehtiyac yalnız artır - hər il 30%. Bu, insanlar hiss etdikləri üçün baş verir: daha sürətlidir, fərqlidir, müxtəlif texnologiyalar var, bütün bunlar inkişaf edir.
Mikroservislər gələcək, lakin əsas qalacaq
Dmitri:
Bu, inkişafa sərmayə qoyduğunuz heç vaxt bitməyən bir proses kimidir. Biznes üçün mikroservislərə keçid artıq başa çatıb, ya yox?
Sergey:
Cavab vermək çox asandır. Necə düşünürsünüz: telefonların dəyişdirilməsi sonsuz bir prosesdir? Hər il özümüz telefon alırıq. Və budur: sürətə ehtiyac olduğu müddətcə, bazara uyğunlaşmaq üçün bəzi dəyişikliklər tələb olunacaq. Bu o demək deyil ki, biz standart şeylərdən imtina edirik.
Ancaq biz hər şeyi bir anda ört-basdır edə bilmərik. Bizdə əvvəllər mövcud olan köhnə, standart inteqrasiya xidmətləri var: müəssisə avtobusları və s. Amma geriləmə var, ehtiyac da var. Mobil proqramların sayı və onların funksionallığı artır. Eyni zamanda heç kim demir ki, sənə 30% daha çox pul veriləcək. Yəni bir tərəfdən həmişə ehtiyaclar, digər tərəfdən isə səmərəlilik axtarışı var.
Dmitri:
Həyat yaxşı vəziyyətdədir. (gülür)
İskəndər:
Ümumiyyətlə, bəli. Əsas hissəni landşaftdan çıxarmaq üçün inqilabi yanaşmalarımız yoxdur. Sistemlərin mikroservis arxitekturasına daha uyğun olması, sistemlərin bir-birinə təsirinin azaldılması üçün sistemli iş aparılır.
Ancaq biz əsas hissəni saxlamağı planlaşdırırıq, çünki operatorun mənzərəsində həmişə aldığımız bəzi platformalar olacaq. Yenə də sağlam bir tarazlığa ehtiyacımız var: nüvəni kəsməyə tələsməməliyik. Sistemləri yan-yana yerləşdiririk və indi belə çıxır ki, biz artıq bir çox əsas hissələrin üstündəyik. Bundan əlavə, funksionallığı inkişaf etdirərək, rabitə xidmətlərimizlə işləyən bütün kanallar üçün lazımi nümayəndəliklər yaradırıq.
Mikroxidmətləri müəssisələrə necə satmaq olar
Dmitri:
Mənə də maraqlıdır - keçid etməmiş, lakin etməyi planlaşdıranlar üçün: bu ideyanı biznesə satmaq nə qədər asan idi və bu, macəra, investisiya layihəsi idi? Yoxsa bu, şüurlu bir strategiya idi: indi mikroservislərə gedirik və budur, heç nə bizi dayandıra bilməz. Sizin üçün necə oldu?
Sergey:
Biz bir yanaşma deyil, biznes faydası satdıq. Biznesdə problem var idi və biz onu həll etməyə çalışdıq. Həmin an müxtəlif kanalların qiymətləri hesablamaq üçün müxtəlif prinsiplərdən istifadə etməsi ilə ifadə olunurdu - ayrıca aksiyalar üçün, promosyonlar üçün və s. Onu saxlamaq çətin idi, xətalar baş verdi və biz müştərilərin şikayətlərini dinlədik. Yəni bir problemin həllini satırdıq, amma platforma yaratmaq üçün pul lazım olduğu ilə gəldik. Və investisiyanın birinci mərhələsinin nümunəsindən istifadə edərək biznes nümunəsi göstərdilər: biz onu necə geri qaytarmağa davam edəcəyik və bu bizə nə etməyə imkan verəcək.
Dmitri:
Birinci mərhələnin vaxtını birtəhər qeyd etmisiniz?
Sergey:
Bəli əminəm. Biz platforma kimi nüvəni yaratmaq və pilotu sınaqdan keçirmək üçün 6 ay vaxt ayırdıq. Bu müddət ərzində pilotun konki sürməsi üçün platforma yaratmağa çalışdıq. Sonra fərziyyə təsdiqləndi və işlədiyi üçün bu, davam edə biləcəyimiz deməkdir. Onlar komandanı təkrarlamağa və gücləndirməyə başladılar - onu bunu edən ayrı bir diviziona köçürdülər.
Sonrakı iş ehtiyaclarına, imkanlarına, resursların mövcudluğuna və hazırda işdə olan hər şeyə əsaslanan sistemli işdir.
Dmitri:
TAMAM. İskəndər, nə deyirsən?
İskəndər:
Mikroservislərimiz “dəniz köpüyü”ndən yaranmışdır - resurslara qənaət, server tutumu şəklində bəzi qalıqlar və komanda daxilində qüvvələrin yenidən bölüşdürülməsi səbəbindən. Əvvəlcə bu layihəni biznesə satmadıq. Bu, həm araşdırdığımız, həm də buna uyğun inkişaf etdirdiyimiz bir layihə idi. Biz 2018-ci ilin əvvəlində başladıq və sadəcə olaraq bu istiqaməti həvəslə inkişaf etdirdik. Satışlar yeni başlayıb və biz prosesdəyik.
Dmitri:
Belə olurmu ki, bir iş sizə Google kimi şeylər etməyə icazə verir - həftədə bir pulsuz gün? Sizin belə bir istiqamətiniz varmı?
İskəndər:
Tədqiqatla eyni vaxtda biz biznes problemləri ilə də məşğul olduq, ona görə də bütün mikroservislərimiz biznes problemlərinin həllidir. Yalnız başlanğıcda biz abunəçi bazasının kiçik bir hissəsini əhatə edən mikroservislər qurduq və indi demək olar ki, bütün flaqman məhsullarda iştirak edirik.
Və maddi təsir artıq aydındır - biz köhnə yolla getmişiksə, artıq saymaq olar, məhsulun buraxılış sürətini və itirilmiş gəliri təxmin etmək olar. Davanı məhz bunun üzərində qururuq.
Mikroservislər: şırınga, yoxsa zərurət?
Dmitri:
Nömrələr rəqəmlərdir. Gəlir və ya qənaət olunan pul çox vacibdir. Qarşı tərəfə baxsanız necə olar? Görünür, mikroservislər bir tendensiyadır, şırıngadır və bir çox şirkət bundan sui-istifadə edir? Etdiyiniz və mikroservislərə tərcümə etmədiyinizi nə dərəcədə aydın şəkildə fərqləndirirsiniz? Əgər indi miras varsa, 5 ildən sonra da miras qalacaqmı? M.Video-Eldorado və MegaFon-da işləyən informasiya sistemlərinin 5 ildən sonra yaşı neçə olacaq? On illik, on beş illik informasiya sistemləri olacaq, yoxsa yeni nəsil olacaq? Bunu necə görürsünüz?
Sergey:
Mənə elə gəlir ki, çox uzaqda düşünmək çətindir. Geriyə nəzər salsaq, texnologiya bazarının maşın öyrənməsi və istifadəçinin üzlə identifikasiyası da daxil olmaqla bu şəkildə inkişaf edəcəyini kim təsəvvür edirdi? Ancaq qarşıdakı illərə baxsanız, mənə elə gəlir ki, əsas sistemlər, şirkətlərdə ERP sinifli sistemlər - onlar kifayət qədər uzun müddətdir işləyirlər.
Şirkətlərimizin kollektiv şəkildə 25 yaşı var, klassik ERP sistem mənzərəsində çox dərindir. Aydındır ki, biz oradan bəzi parçaları götürürük və onları mikroservislərdə birləşdirməyə çalışırıq, lakin əsas qalacaq. Oradakı bütün əsas sistemləri əvəz edəcəyimizi və sürətlə yeni sistemlərin digər, parlaq tərəfinə keçəcəyimizi təsəvvür etmək indi mənim üçün çətindir.
Mən müştəriyə və istehlakçıya daha yaxın olan hər şeyin ən böyük biznes faydası və dəyərinin olduğu, uyğunlaşma və sürətə, dəyişikliyə, “sınayın, ləğv edin, təkrar istifadə edin, fərqli bir şey edin”in diqqət mərkəzində olmasının tərəfdarıyam. lazımdır” – mənzərənin dəyişəcəyi yer budur. Və qutulu məhsullar oraya çox uyğun gəlmir. Ən azından biz bunu görmürük. Orada ən asan, ən sadə həllər tələb olunur.
Bu inkişafı görürük:
- əsas informasiya sistemləri (əsasən bek ofis);
- mikroservislər şəklində orta təbəqələr nüvəni birləşdirir, birləşdirir, keş yaradır və s.;
- ön xətt sistemləri istehlakçıya yönəldilmişdir;
- ümumiyyətlə bazarlara, digər sistemlərə və ekosistemlərə inteqrasiya olunmuş inteqrasiya təbəqəsi. Bu təbəqə mümkün qədər yüngül, sadədir və minimum iş məntiqini ehtiva edir.
Amma eyni zamanda köhnə prinsiplərdən lazımınca istifadə olunarsa, onlardan istifadənin davam etdirilməsinin tərəfdarıyam.
Tutaq ki, sizdə klassik müəssisə sistemi var. O, bir satıcının mənzərəsində yerləşir və bir-biri ilə işləyən iki moduldan ibarətdir. Standart inteqrasiya interfeysi də var. Niyə bunu yenidən düzəldin və ora mikroservis gətirin?
Ancaq arxa ofisdə 5 modul olduqda, onlardan məlumat parçaları bir iş prosesində toplanır və daha sonra 8-10 cəbhə sistemləri tərəfindən istifadə olunur, fayda dərhal nəzərə çarpır. Siz beş bek-ofis sistemindən götürürsünüz və biznes prosesinə yönəlmiş təcrid olunmuş bir xidmət yaradırsınız. Xidməti texnoloji cəhətdən təkmilləşdirin - belə ki, o, məlumatı yaddaşda saxlasın və nasazlığa dözümlü olsun, həmçinin sənədlər və ya biznes qurumları ilə işləsin. Və siz onu bütün qabaqcıl məhsullarla vahid prinsipə uyğun birləşdirirsiniz. Ön xətt məhsulunu ləğv etdilər - sadəcə inteqrasiyanı söndürdülər. Sabah bir mobil proqram yazmalı və ya kiçik bir veb sayt yaratmalı və funksionallığa yalnız bir hissə qoymalısınız - hər şey sadədir: onu konstruktor kimi yığdınız. Mən bu istiqamətdə daha çox inkişaf görürəm - ən azı bizdə.
İskəndər:
Sergey bizim yanaşmamızı tam təsvir etdi, təşəkkür edirəm. Sadəcə, mütləq hara getməyəcəyimizi söyləyəcəyəm - əsas hissəyə, onlayn hesablaşma mövzusuna. Yəni, reytinq və yükləmə, əslində pulu etibarlı şəkildə siləcək "böyük" bir xırmançı olaraq qalacaq. Və bu sistem tənzimləyici orqanlarımız tərəfindən sertifikatlaşdırılmağa davam edəcəkdir. Müştərilərə baxan hər şey, əlbəttə ki, mikroservislərdir.
Dmitri:
Burada sertifikatlaşdırma bir hekayədir. Yəqin ki, daha çox dəstək olacaq. Dəstək üçün az pul xərcləsəniz və ya sistem dəstək və modifikasiya tələb etmirsə, ona toxunmamaq daha yaxşıdır. Ağlabatan bir kompromis.
Etibarlı mikroservisləri necə inkişaf etdirmək olar
Dmitri:
Yaxşı. Amma yenə də maraqlanıram. İndi bir uğur hekayəsi danışırsınız: hər şey yaxşı idi, biz mikroservislərə keçdik, biznesə ideyanı müdafiə etdik və hər şey nəticə verdi. Amma başqa hekayələr də eşitmişəm.
Bir neçə il əvvəl banklar üçün yeni mikroservis platformasının hazırlanmasına iki il sərmayə qoyan İsveçrə şirkəti nəhayət layihəni bağladı. Tamamilə çökdü. Milyonlarla İsveçrə frankı xərcləndi və nəticədə komanda dağıldı - alınmadı.
Bənzər hekayələriniz olubmu? Çətinliklər olubmu və ya varmı? Məsələn, mikroxidmətlərin saxlanması və monitorinqi də şirkətin əməliyyat fəaliyyətində baş ağrısıdır. Axı, komponentlərin sayı onlarla dəfə artır. Siz bunu necə görürsünüz, burada uğursuz investisiya nümunələri olubmu? Bəs insanlara nə məsləhət görə bilərsiniz ki, belə problemlərlə qarşılaşmasınlar?
İskəndər:
Uğursuz nümunələr arasında prioritetləri dəyişdirən və layihələri ləğv edən bizneslər var. Hazırlığın yaxşı mərhələsində olduqda (əslində MVP hazırdır), biznes dedi: "Bizim yeni prioritetlərimiz var, başqa bir layihəyə keçirik və biz bunu bağlayırıq."
Mikroservislərlə bağlı heç bir qlobal nasazlığımız olmayıb. Biz dinc yatırıq, bütün BSS-yə [biznes dəstək sistemi] xidmət edən 24/7 növbəmiz var.
Və daha bir şey - qutulu məhsullara tətbiq olunan qaydalara uyğun olaraq mikroservisləri icarəyə veririk. Müvəffəqiyyətin açarı ondan ibarətdir ki, ilk növbədə, mikroservisi istehsala tam hazırlayacaq komanda toplamaq lazımdır. İnkişafın özü şərti olaraq 40% təşkil edir. Qalanları analitika, DevSecOps metodologiyası, düzgün inteqrasiyalar və düzgün arxitekturadır. Biz təhlükəsiz proqramların qurulması prinsiplərinə xüsusi diqqət yetiririk. İnformasiya təhlükəsizliyi nümayəndələri hər bir layihədə həm memarlıq planlaşdırma mərhələsində, həm də icra prosesində iştirak edirlər. Onlar həmçinin zəifliklər üçün kodu təhlil etmək üçün sistemləri idarə edirlər.
Deyək ki, biz vətəndaşlığı olmayan xidmətlərimizi yerləşdiririk - bizdə Kubernetesdə var. Bu, xidmətlərin avtomatik miqyası və avtomatik artırılması səbəbindən hər kəsə dinc şəkildə yatmağa imkan verir və növbətçilik hadisələri baş verir.
Mikroservislərimizin bütün mövcudluğu ərzində xəttimizə çatan yalnız bir və ya iki hadisə baş verib. İndi əməliyyatda heç bir problem yoxdur. Bizdə, əlbəttə ki, 200 yox, 50-yə yaxın mikroservis var, lakin onlar flaqman məhsullarda istifadə olunur. Əgər uğursuz olsaydılar, bu barədə ilk biz xəbərdar olardıq.
Mikroservislər və HR
Sergey:
Mən həmkarımın dəstəyə keçməsi ilə razıyam - işi düzgün təşkil etmək lazımdır. Amma təbii ki, mövcud olan problemlərdən danışacağam.
Birincisi, texnologiya yenidir. Bu yaxşı mənada şırıngadır və bunu başa düşəcək və yarada biləcək mütəxəssis tapmaq böyük problemdir. Resurslar uğrunda rəqabət çılğındır, ona görə də ekspertlər öz çəkilərini qızılla qiymətləndirirlər.
İkincisi, müəyyən landşaftların yaradılması və xidmətlərin sayının artması ilə təkrar istifadə problemi daim həll edilməlidir. Tərtibatçıların etməyi xoşladığı kimi: “İndi burada çox maraqlı şeylər yazaq...” Buna görə də sistem böyüyür və pul, sahiblik dəyəri və s. baxımından effektivliyini itirir. Yəni sistemin arxitekturasına təkrar istifadəni daxil etmək, xidmətlərin tətbiqi və mirasın yeni arxitekturaya köçürülməsi üçün yol xəritəsinə daxil etmək lazımdır.
Başqa bir problem - bu, özlüyündə yaxşı olsa da - daxili rəqabətdir. "Oh, burada yeni dəbli uşaqlar peyda oldular, onlar yeni dildə danışırlar." İnsanlar, təbii ki, fərqlidirlər. Java-da yazmağa alışanlar da var, Docker və Kubernetes yazıb istifadə edənlər də. Bunlar tamam başqa adamlardır, fərqli danışırlar, fərqli terminlər işlədirlər və bəzən bir-birini başa düşmürlər. Təcrübəni, bilikləri bölüşmək bacarığı və ya bilməməsi də bu mənada problemdir.
Yaxşı, resursların miqyası. “Əla, gedək! İndi biz daha sürətli, daha çox istəyirik. Nə, bacarmazsan? Bir ildə iki dəfə çox məhsul çatdırmaq mümkün deyilmi? Və niyə?" Belə böyüyən ağrılar yəqin ki, bir çox şeylər, bir çox yanaşmalar üçün standartdır və siz onları hiss edə bilərsiniz.
Monitorinqlə bağlı. Mənə elə gəlir ki, xidmətlər və ya sənaye monitorinq alətləri artıq öyrənirlər və ya həm Docker, həm də Kubernetes ilə fərqli, qeyri-standart rejimdə işləməyi bacarırlar. Beləliklə, məsələn, bütün bunların işlədiyi, yəni birləşdiyi 500 Java maşını ilə nəticələnməyəcəksiniz. Lakin bu məhsulların hələ də yetkinliyi yoxdur, onlar bundan keçməlidirlər. Mövzu həqiqətən yenidir, inkişaf etməyə davam edəcək.
Dmitri:
Bəli, çox maraqlıdır. Və bu HR-ə aiddir. Ola bilsin ki, HR prosesiniz və HR markanız bu 3 il ərzində bir az dəyişib. Fərqli səlahiyyətlərə malik başqa insanları işə götürməyə başladınız. Və yəqin ki, həm müsbət, həm də mənfi cəhətləri var. Əvvəllər blokçeyn və məlumat elmi şırınga idi və onlarda mütəxəssislər milyonlarla dəyərində idi. İndi xərclər düşür, bazar doyur və mikroservislərdə də oxşar tendensiya müşahidə olunur.
Sergey:
Bəli, tamamilə.
İskəndər:
HR sual verir: "Çəhrayı təkbuynuzunuz arxa və ön hissə arasında haradadır?" HR mikroservisin nə olduğunu başa düşmür. Biz onlara sirri danışdıq və dedik ki, backend hər şeyi edir, təkbuynuz yoxdur. Lakin HR dəyişir, tez öyrənir və əsas İT bilikləri olan insanları işə cəlb edir.
Mikroservislərin təkamülü
Dmitri:
Hədəf arxitekturasına baxsanız, mikroservislər belə bir canavar kimi görünür. Səyahətiniz bir neçə il çəkdi. Digərlərinin bir il, digərlərinin üç il var. Bütün problemləri, hədəf arxitekturasını qabaqcadan gördünüzmü, nəsə dəyişdi? Məsələn, mikroservislər vəziyyətində, şlüzlər və xidmət şəbəkələri yenidən görünür. Əvvəlcə onlardan istifadə etmisiniz, yoxsa arxitekturanın özünü dəyişmisiniz? Belə çətinlikləriniz varmı?
Sergey:
Biz artıq bir neçə rabitə protokolunu yenidən yazmışıq. Əvvəlcə bir protokol var idi, indi başqasına keçdik. Biz təhlükəsizlik və etibarlılığı artırırıq. Biz müəssisə texnologiyaları ilə başladıq - Oracle, Web Logic. İndi biz mikroservislərdə texnoloji müəssisə məhsullarından uzaqlaşır və açıq mənbə və ya tamamilə açıq texnologiyalara keçirik. Biz verilənlər bazalarından imtina edirik və bu modeldə bizim üçün daha effektiv olana keçirik. Artıq Oracle texnologiyalarına ehtiyacımız yoxdur.
Biz sadəcə bir xidmət kimi başladıq, keş-xərçəyə nə qədər ehtiyacımız olduğunu, mikroservislə əlaqə olmadıqda, lakin məlumat lazım olduqda nə edəcəyimizi və s. barədə düşünmədən başladıq. İndi arxitekturanı təsvir etmək üçün platforma hazırlayırıq xidmətlərin dilində deyil, işgüzar dildə desək, sözlə danışmağa başlayanda biznes məntiqini növbəti səviyyəyə aparın. İndi biz hərflərlə danışmağı öyrəndik və növbəti səviyyə xidmətlərin bir növ məcmuədə toplanacağı zamandır, bu artıq bir söz olduqda - məsələn, bütün məhsul kartı. O, mikroservislərdən yığılıb, lakin bunun üzərində qurulmuş API-dir.
Təhlükəsizlik çox vacibdir. Siz əlçatan olmağa başlayan kimi və bir çox maraqlı şeyləri əldə edə biləcəyiniz bir xidmətiniz olduqda və çox tez, bir neçə saniyə ərzində, onu ən təhlükəsiz olmayan şəkildə əldə etmək istəyi yaranır. Bundan uzaqlaşmaq üçün sınaq və monitorinq yanaşmalarını dəyişməli olduq. Komandanı, çatdırılma idarəetmə strukturunu, CI/CD-ni dəyişməli olduq.
Bu, təkamüldür - telefonlarda olduğu kimi, yalnız daha sürətli: əvvəlcə düyməli telefonlar var idi, sonra smartfonlar meydana çıxdı. Bazarın fərqli ehtiyacı olduğu üçün məhsulu yenidən yazdılar və yenidən dizayn etdilər. Biz belə inkişaf edirik: birinci sinif, onuncu sinif, iş.
İterativ olaraq, ildə texnologiya nöqteyi-nəzərindən bir şey, geriləmə və ehtiyaclar baxımından başqa bir şey qoyulur. Bir şeyi digərinə bağlayırıq. Komanda texniki borcun 20%-ni və komandanın texniki dəstəyinə, 80%-ni isə biznes subyektinə xərcləyir. Və biz bunu niyə etdiyimizi, niyə bu texnoloji təkmilləşdirmələri etdiyimizi, nəyə gətirib çıxaracağını anlayaraq hərəkət edirik. Bunun kimi.
Dmitri:
Sərin. MegaFon-da nə var?
İskəndər:
Mikroservislərə gəldiyimiz zaman əsas problem xaosa düşməmək idi. MegaFon-un memarlıq ofisi dərhal bizə qoşuldu, hətta təşəbbüskar və sürücü oldu - indi çox güclü bir arxitekturamız var. Onun vəzifəsi hansı hədəf modelə gedəcəyimizi və hansı texnologiyaların sınaqdan keçirilməli olduğunu anlamaq idi. Memarlıq ilə bu pilotları özümüz həyata keçirdik.
Növbəti sual: "Bütün bunları necə istifadə etmək olar?" Və daha biri: "Mikroservislər arasında şəffaf qarşılıqlı əlaqəni necə təmin etmək olar?" Xidmət şəbəkəsi bizə son sualı cavablandırmaqda kömək etdi. İstio-nu sınaqdan keçirdik və nəticələri bəyəndik. İndi biz məhsuldar zonalara yayılma mərhələsindəyik. Biz bütün çağırışlara müsbət münasibət bəsləyirik - bu, yığını daim dəyişmək, yeni bir şey öyrənmək lazımdır. Biz köhnə həllərdən istifadə etməkdə deyil, inkişaf etdirməkdə maraqlıyıq.
Dmitri:
Qızıl sözlər! Bu cür çağırışlar komandanı və biznesi ayaq üstə saxlayır və gələcəyi yaradır. GDPR məlumatların mühafizəsi üzrə baş məmurlar yaratdı və cari problemlər baş mikroservislər və memarlıq məmurlarını yaradır. Və sevindirir.
Çox müzakirə etdik. Əsas odur ki, mikroservislərin yaxşı dizaynı və arxitekturanın özü bir çox səhvlərdən qaçmağa imkan verir. Əlbəttə, proses iterativ və təkamül xarakterlidir, lakin gələcəkdir.
Bütün iştirakçılara təşəkkürlər, Sergey və Aleksandra təşəkkürlər!
Tamaşaçıların sualları
Tamaşaçılardan sual (1):
Sergey, şirkətinizdə İT menecmenti necə dəyişdi? Mən başa düşürəm ki, bir neçə sistemdən ibarət böyük yığın olduqda, onun necə idarə olunması kifayət qədər aydın və məntiqli bir prosesdir. Qısa müddət ərzində çoxlu sayda mikroservis inteqrasiya edildikdən sonra İT komponentinin idarə edilməsini necə bərpa etdiniz?
Sergey:
Mən həmkarımla razıyam ki, memarlıq dəyişikliklərin aparıcısı kimi çox vacibdir. Biz memarlıq bölməsi ilə başladıq. Memarlar eyni zamanda funksionallığın paylanmasının və onun landşaftda necə görünəcəyinə dair tələblərin sahibləridir. Beləliklə, onlar həm də bu dəyişikliklərin koordinatoru kimi çıxış edirlər. Nəticədə, biz CI/CD platformasını yaratdığımız zaman konkret çatdırılma prosesində xüsusi dəyişikliklər oldu.
Lakin standart, əsas inkişaf prinsipləri, biznes təhlili, sınaq və inkişaf ləğv edilməyib. Sadəcə sürət əlavə etdik. Əvvəllər dövrə çox vaxt aparırdı, sınaq mühitlərində quraşdırma daha çox vaxt aparırdı. İndi biznes bunun faydasını görür və deyir: "Niyə biz başqa yerlərdə də bunu edə bilmirik?"
Bu, yaxşı mənada, peyvənd şəklində bir inyeksiyaya bənzəyir: bunu belə edə bilərsiniz, amma başqa şəkildə edə bilərsiniz. Təbii ki, kadrda, səriştələrdə, bilikdə, müqavimətdə problem var.
Tamaşaçılardan sual (2):
Mikroservis arxitekturasının tənqidçiləri sınaq və inkişaf etdirmənin çətin olduğunu deyirlər. İşlərin mürəkkəbləşdiyi yerdə bu məntiqlidir. Komandanız hansı çətinliklərlə üzləşdi və onların öhdəsindən necə gəldiniz? Hər kəs üçün sual.
İskəndər:
Mikroservislərdən platformaya keçərkən çətinliklər var, lakin onları həll etmək olar.
Məsələn, biz 5-7 mikroservisdən ibarət məhsul istehsal edirik. Usta filiala keçmək üçün yaşıl işıq yandırmaq üçün bütün mikroservislər yığını üzrə inteqrasiya testlərini təmin etməliyik. Bu tapşırıq bizim üçün yeni deyildi: biz bunu BSS-də uzun müddət idi ki, satıcı bizə artıq göndərilmiş həlləri təqdim edəndə edirdik.
Bizim problemimiz isə yalnız kiçik komandadadır. Bir şərti məhsul üçün bir QA mühəndisi tələb olunur. Beləliklə, biz 5-7 mikroservis məhsulunu göndəririk, onlardan 2-3-ü üçüncü tərəflər tərəfindən hazırlana bilər. Məsələn, bizim billinq sistem satıcımız olan Mail.ru Group və MegaFon R&D-nin iştirak etdiyi məhsulumuz var. İstehsalata göndərməzdən əvvəl bunu sınaqlarla əhatə etməliyik. QA mühəndisi ay yarımdır ki, bu məhsul üzərində işləyir və komandanın qalan hissəsi onun dəstəyindən məhrumdur.
Bu mürəkkəblik yalnız miqyasla əlaqədardır. Biz başa düşürük ki, mikroservislər vakuumda mövcud ola bilməz; mütləq izolyasiya mövcud deyil. Bir xidməti dəyişdirərkən biz həmişə API müqaviləsini qorumağa çalışırıq. Başlıq altında bir şey dəyişərsə, ön xidmət qalır. Dəyişikliklər ölümcül olarsa, bir növ memarlıq transformasiyası baş verir və biz tamamilə uyğun olmayan tamamilə fərqli məlumat metamodelinə keçirik - yalnız bundan sonra v2 xidmət API spesifikasiyasının görünməsi haqqında danışırıq. Biz eyni vaxtda birinci və ikinci versiyaları dəstəkləyirik və bütün istehlakçılar ikinci versiyaya keçəndən sonra sadəcə birincisini bağlayırıq.
Sergey:
əlavə etmək istəyirəm. Mən fəsadlarla tamamilə razıyam - onlar olur. Landşaft getdikcə mürəkkəbləşir və xüsusilə sınaq üçün əlavə xərclər artır. Bununla necə məşğul olmaq olar: avtomatlaşdırılmış testə keçin. Bəli, avtotestlər və vahid testləri yazmaq üçün əlavə olaraq investisiya etməli olacaqsınız. Tərtibatçılar testdən keçmədən öhdəlik götürə bilməmələri üçün kodu dəyişdirə bilmədilər. Belə ki, hətta təkan düyməsi avtotest, vahid testi olmadan işləməsin.
Əvvəlki funksionallığı qorumaq vacibdir və bu əlavə yükdür. Bir texnologiyanı başqa bir protokola yenidən yazsanız, hər şeyi tamamilə bağlayana qədər onu yenidən yazırsınız.
Biz bəzən məqsədyönlü şəkildə başdan-başa testlər etmirik, çünki inkişafı dayandırmaq istəmirik, baxmayaraq ki, bizdə bir-birinin ardınca bir şey var. Landşaft çox böyük, mürəkkəbdir, çoxlu sistemlər var. Bəzən bu, sadəcə stublardır - bəli, təhlükəsizlik marjasını aşağı salırsınız, daha çox risk yaranır. Ancaq eyni zamanda təchizatı buraxırsınız.
İskəndər:
Bəli, avtotestlər və vahid testləri yüksək keyfiyyətli xidmət yaratmağa imkan verir. Biz vahid və inteqrasiya testləri olmadan keçə bilməyən bir boru kəmərinin tərəfdarıyıq. Biz tez-tez emulyatorları və kommersiya sistemlərini test zonalarına və inkişaf mühitlərinə sürükləməliyik, çünki bütün sistemləri test zonalarına yerləşdirmək mümkün deyil. Üstəlik, onlar sadəcə islanmırlar - biz sistemdən tam hüquqlu cavab yaradırıq. Bu, mikroservislərlə işləməyin ciddi hissəsidir və biz də buna sərmayə qoyuruq. Bu olmasa xaos yaranar.
Tamaşaçılardan sual (3):
Anladığım qədər, mikroservislər əvvəlcə ayrı bir komandadan böyüdü və indi bu modeldə mövcuddur. Onun müsbət və mənfi cəhətləri nələrdir?
Sadəcə oxşar bir hekayəmiz var: bir növ mikroservis fabriki yarandı. İndi konseptual olaraq o yerə gəldik ki, bu yanaşmanı axınlar və sistemlər üzrə istehsala genişləndiririk. Başqa sözlə, biz mikroservislərin, mikroservis modellərinin mərkəzləşdirilmiş inkişafından uzaqlaşır və sistemlərə yaxınlaşırıq.
Müvafiq olaraq, əməliyyatımız da sistemlərə gedir, yəni biz bu mövzunu mərkəzsizləşdiririk. Sizin yanaşmanız nədir və hədəf hekayəniz nədir?
İskəndər:
Siz "mikroservislər fabriki" adını ağzınızdan çıxartdınız - biz də miqyas almaq istəyirik. Birincisi, indi həqiqətən bir komandamız var. Biz MegaFon-un malik olduğu bütün inkişaf qruplarını ümumi ekosistemdə işləmək imkanı ilə təmin etmək istəyirik. İndi əlimizdə olan bütün inkişaf funksiyalarını tamamilə ələ keçirmək istəmirik. Yerli vəzifə miqyaslaşdırmaqdır, qlobal vəzifə mikroservis səviyyəsindəki bütün komandalara inkişafa rəhbərlik etməkdir.
Sergey:
Tutduğumuz yolu sizə danışacağam. Biz həqiqətən bir komanda kimi işləməyə başladıq, amma indi tək deyilik. Mən aşağıdakıların tərəfdarıyam: prosesin sahibi olmalıdır. Kimsə mikroservislərin inkişaf prosesini başa düşməli, idarə etməli, idarə etməli və qurmalıdır. O, resurslara sahib olmalı və resursların idarə edilməsi ilə məşğul olmalıdır.
Texnologiyaları, xüsusiyyətləri bilən və mikroservislərin necə qurulacağını anlayan bu resurslar məhsul komandalarında yerləşdirilə bilər. Mikroservis platformasından olan insanların mobil tətbiqetməni hazırlayan məhsul komandasında olduğu bir qarışıqımız var. Onlar oradadırlar, lakin mikroservis platformasının idarə edilməsi şöbəsinin prosesinə uyğun olaraq inkişaf meneceri ilə işləyirlər. Bu bölmə daxilində texnologiya ilə məşğul olan ayrıca komanda var. Yəni biz öz aramızda ümumi ehtiyatlar hovuzunu qarışdırırıq və onları bölərək komandalara veririk.
Eyni zamanda, proses ümumi, idarə olunan olaraq qalır, ümumi texnoloji prinsiplərə uyğun olaraq, vahid sınağı və s. - üstündə qurulan hər şeylə davam edir. Məhsul yanaşmasının müxtəlif şöbələrindən toplanmış resurslar şəklində sütunlar ola bilər.
İskəndər:
Sergey, əslində prosesin sahibisən, elə deyilmi? Tapşırığın geri qalması paylaşılır? Onun paylanmasına kim cavabdehdir?
Sergey:
Baxın: yenə qarışıqdır. Texnoloji təkmilləşdirmələr əsasında formalaşan geriləmə var - bu bir hekayədir. Layihələrdən formalaşan geriləmə var və məhsullar üzrə geriləmə var. Lakin xidmət məhsullarının hər birinə daxil edilmə ardıcıllığı və ya bu xidmətin yaradılması məhsul mütəxəssisi tərəfindən hazırlanır. O, İT direktorluğunda deyil, xüsusi olaraq oradan uzaqlaşdırılıb. Amma mənim adamlarım mütləq eyni proses üzrə işləyirlər.
Müxtəlif istiqamətlərdə geriləmənin - dəyişikliklərin geridə qalan hissəsinin sahibi müxtəlif insanlar olacaq. Texnoloji xidmətlərin əlaqəsi, onların təşkili prinsipi - bütün bunlar İT-də olacaq. Mən platforma və resurslara da sahibəm. Yuxarıdakı geriləmə və funksional dəyişikliklərə və bu mənada memarlığa aiddir.
Tutaq ki, biznes deyir: "Biz bu funksiyanı istəyirik, yeni məhsul yaratmaq istəyirik - krediti yenidən qaytarmaq." Cavab veririk: "Bəli, yenidən edəcəyik." Memarlar deyirlər: "Gəlin fikirləşək: kreditin harasında mikroservislər yazacağıq və bunu necə edəcəyik?" Sonra biz onu layihələrə, məhsullara və ya texnologiya yığınına bölürük, komandalara yerləşdiririk və həyata keçiririk. Siz daxili məhsul yaratdınız və bu məhsulda mikroxidmətlərdən istifadə etmək qərarına gəldinizmi? Biz deyirik: "İndi bizdə olan köhnə sistemlər və ya cəbhə sistemləri bu mikroservislərə keçməlidir." Memarlar deyirlər: “Beləliklə, ön xətt məhsulların içərisində texnoloji geriləmə - mikroservislərə keçid. get". Məhsul mütəxəssisləri və ya biznes sahibləri nə qədər tutumun ayrıldığını, nə vaxt və nə üçün ediləcəyini başa düşürlər.
Müzakirənin sonu, amma hamısı deyil
mailto:CLOUD konfransı təşkil edildi .
Biz başqa tədbirlər də edirik - məs. @Kubernetes Meetup, biz həmişə əla natiqlər axtarırıq:
- Telegram kanalımızda @Kubernetes və digər @Meetup xəbərlərini izləyin
- @Meetups-dan birində danışmaqla maraqlanırsınız? üçün sorğu buraxın
Mənbə: www.habr.com