25 aprel kuni biz Mail.ru Group-da bulutlar va atrof-muhit haqida konferentsiya o'tkazdik - . Bir nechta diqqatga sazovor joylar:
- Asosiy — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center va Yandex.Cloud bulutli bozorimizning o‘ziga xos xususiyatlari va ularning xizmatlari haqida gapirdi;
- Bitrix24 dan hamkasblar ular qanday qilib aytishdi ;
- Leroy Merlin, Otkritie, Burger King va Schneider Electric qiziqarli narsalarni taqdim etdi — ularning biznesi IT oldiga qanday vazifalar qo‘yadi va qaysi texnologiyalar, shu jumladan bulutli texnologiyalar, ular eng istiqbolli deb bilishadi.
Mailto:CLOUD konferensiyasidagi barcha videolarni tomosha qilishingiz mumkin , va bu erda siz mikroservislar haqidagi muhokama qanday o'tganini o'qishingiz mumkin. MegaFon biznes tizimlari tadqiqot va rivojlantirish markazi rahbari Aleksandr Deulin va M.Video-Eldorado guruhining axborot texnologiyalari direktori Sergey Sergeev monolitlardan xalos bo'lishning muvaffaqiyatli holatlari bilan o'rtoqlashdi. Shuningdek, biz IT strategiyasi, jarayonlar va hatto HR bilan bog'liq masalalarni muhokama qildik.
Panel ishtirokchilari
- Sergey Sergeev, Guruh CIO "M.Video-Eldorado";
- Aleksandr Deulin, biznes tizimlarini tadqiq qilish va rivojlantirish markazi rahbari MegaFon;
- Moderator - Dmitriy Lazarenko, PaaS yo'nalishi boshlig'i Mail.ru bulutli echimlar.
Aleksandr Deulinning nutqidan keyin u M.Video-Eldorado'dan Sergey Sergeev va Mail.ru Cloud Solutions muhokamasi moderatori Dmitriy Lazarenko tomonidan muhokama uchun qo'shildi.
Quyida biz siz uchun muhokamaning stenogrammasini tayyorladik, ammo videoni ham tomosha qilishingiz mumkin:
Mikroservislarga o'tish bozor ehtiyojlariga javobdir
Dmitriy:
Mikroservislarga o'tishda muvaffaqiyatli tajribangiz bormi? Va umuman olganda: mikroservislardan foydalanish yoki monolitlardan mikroservislarga o'tishning eng katta biznes foydasini qayerda ko'rasiz?
Sergey:
Biz mikroservislarga o'tishda allaqachon qandaydir yo'lni bosib o'tdik va bu yondashuvdan uch yildan ko'proq vaqt davomida foydalanmoqdamiz. Mikroservislarga bo'lgan ehtiyojni oqlagan birinchi ehtiyoj bu turli xil front-end mahsulotlarini orqa ofis bilan cheksiz integratsiyalashuvi edi. Va har safar biz u yoki bu xizmatning ishlashi uchun o'z qoidalarimizni amalga oshirib, qo'shimcha integratsiya va rivojlanishni amalga oshirishga majbur bo'ldik.
Bir nuqtada, biz tizimlarimizning ishlashini va funksionallikning chiqishini tezlashtirishimiz kerakligini angladik. O'sha paytda mikroservislar va mikroservis yondashuvi kabi tushunchalar bozorda allaqachon mavjud edi va biz buni sinab ko'rishga qaror qildik. Bu 2016 yilda boshlangan. Keyin platforma yotqizildi va birinchi 10 ta xizmat alohida guruh tomonidan amalga oshirildi.
Birinchi xizmatlardan biri, eng og'ir yuklangan, bu narxlarni hisoblash xizmati edi. Har safar istalgan kanalga, M.Video-Eldorado kompaniyalar guruhiga, xoh u veb-saytmi, xoh chakana savdo doʻkoni boʻlsin, u yerda mahsulotni tanlang, veb-saytda yoki “Savat”dagi narxni koʻring, avtomatik ravishda narxlanadi. bitta xizmat tomonidan hisoblab chiqilgan. Bu nima uchun kerak: bundan oldin har bir tizimda aktsiyalar bilan ishlashning o'z tamoyillari mavjud edi - chegirmalar va boshqalar. Bizning orqa ofisimiz narxlash bilan shug'ullanadi; chegirma funksiyasi boshqa tizimda amalga oshiriladi. Bu markazlashtirilgan bo'lishi va biznes-jarayon shaklida noyob, ajratiladigan xizmatni yaratish kerak edi, bu bizga buni amalga oshirishga imkon beradi. Biz deyarli shunday boshladik.
Birinchi natijalarning qiymati juda katta edi. Birinchidan, biz alohida va jamlangan holda ishlashimizga imkon beruvchi ajratiladigan ob'ektlarni yaratishga muvaffaq bo'ldik. Ikkinchidan, biz ko'proq tizimlar bilan integratsiyalashuv nuqtai nazaridan egalik narxini kamaytirdik.
So'nggi uch yil ichida biz uchta frontal tizimni qo'shdik. Ularni kompaniya ko'tara oladigan darajada resurslar bilan ta'minlash qiyin edi. Shuning uchun bozorga tezlik, ichki xarajatlar va samaradorlik nuqtai nazaridan javob beradigan yangi savdo nuqtalarini izlash vazifasi paydo bo'ldi.
Mikroservislarga o'tish muvaffaqiyatini qanday o'lchash mumkin
Dmitriy:
Mikroservislarga o'tishdagi muvaffaqiyat qanday aniqlanadi? Har bir kompaniyada "avval" nima edi? O'tishning muvaffaqiyatini aniqlash uchun qanday ko'rsatkichdan foydalandingiz va uni aslida kim aniqlagan?
Sergey:
Avvalo, u IT doirasida yangi imkoniyatlarni “qulfdan ochish” imkonini beruvchi vosita sifatida tug'ilgan. Biz bozor muammolariga javob berib, nisbatan bir xil pul evaziga hamma narsani tezroq qilishimiz kerak edi. Endi muvaffaqiyat turli tizimlar tomonidan qayta ishlatiladigan xizmatlar sonida, jarayonlarni o'zaro birlashtirishda namoyon bo'ladi. Hozir shunday, lekin o'sha paytda platforma yaratish va biz buni amalga oshirishimiz mumkin bo'lgan gipotezani tasdiqlash imkoniyati bo'ldi, u samara beradi va biznesni hisoblaydi.
Aleksandr:
Muvaffaqiyat - bu ichki tuyg'u. Biznes har doim ko'proq narsani xohlaydi va bizning orqada qolganligimiz muvaffaqiyatning dalilidir. Menga shunday tuyuladi.
Sergey:
Ha roziman. Uch yil ichida bizda ikki yuzdan ortiq xizmatlar va orqada qolganlar mavjud. Jamoa ichidagi resurslarga bo'lgan ehtiyoj faqat o'sib bormoqda - har yili 30% ga. Bu odamlar his qilgani uchun sodir bo'lmoqda: bu tezroq, u boshqacha, turli xil texnologiyalar mavjud, bularning barchasi rivojlanmoqda.
Mikroservislar keladi, lekin yadro qoladi
Dmitriy:
Bu rivojlanishga sarmoya kiritadigan cheksiz jarayonga o'xshaydi. Biznes uchun mikroservislarga o'tish allaqachon tugaganmi yoki yo'qmi?
Sergey:
Javob berish juda oson. Nima deb o'ylaysiz: telefonlarni almashtirish cheksiz jarayonmi? Biz har yili telefon sotib olamiz. Va mana shunday: tezlik, bozorga moslashish uchun zarurat bor ekan, ba'zi o'zgarishlar talab qilinadi. Bu biz standart narsalardan voz kechamiz degani emas.
Ammo biz bir vaqtning o'zida hamma narsani qayta tiklay olmaymiz. Bizda ilgari mavjud bo'lgan eski, standart integratsiya xizmatlari mavjud: korporativ avtobuslar va boshqalar. Lekin orqada qolayotgan ishlar ham bor, ehtiyoj ham bor. Mobil ilovalar soni va ularning funksional imkoniyatlari ortib bormoqda. Shu bilan birga, hech kim sizga 30% ko'proq pul beriladi, deb aytmaydi. Ya'ni, bir tomondan doimo ehtiyojlar, ikkinchi tomondan esa samaradorlikni izlash mavjud.
Dmitriy:
Hayot yaxshi holatda. (kuladi)
Aleksandr:
Umuman olganda, ha. Bizda asosiy qismni landshaftdan olib tashlash uchun inqilobiy yondashuvlar yo'q. Tizimlarni mikroservis arxitekturasiga koʻproq mos kelishi uchun parchalash, tizimlarning bir-biriga taʼsirini kamaytirish boʻyicha tizimli ishlar olib borilmoqda.
Ammo biz asosiy qismni saqlashni rejalashtirmoqdamiz, chunki operator landshaftida har doim biz sotib oladigan platformalar bo'ladi. Shunga qaramay, bizga sog'lom muvozanat kerak: biz yadroni kesishga shoshilmasligimiz kerak. Biz tizimlarni yonma-yon joylashtiramiz va endi biz ko'plab asosiy qismlarning tepasida ekanligimiz ma'lum bo'ldi. Bundan tashqari, funksionallikni rivojlantirib, biz aloqa xizmatlarimiz bilan ishlaydigan barcha kanallar uchun kerakli vakolatxonalarni yaratamiz.
Mikroservislarni korxonalarga qanday sotish kerak
Dmitriy:
Meni ham qiziqtiradi - o'tmagan, lekin qilishni rejalashtirayotganlar uchun: bu g'oyani biznesga sotish qanchalik oson edi va bu sarguzasht, investitsiya loyihasimi? Yoki bu ongli strategiya bo'lganmi: endi biz mikroservislarga boryapmiz va tamom, hech narsa bizni to'xtata olmaydi. Siz uchun qanday bo'ldi?
Sergey:
Biz yondashuvni emas, balki biznes foydasini sotdik. Biznesda muammo bor edi va biz uni hal qilishga harakat qildik. O'sha paytda u turli kanallar narxlarni hisoblashda turli xil printsiplardan foydalanganligi bilan ifodalangan edi - aktsiyalar uchun alohida-alohida, aksiyalar uchun va hokazo. Uni saqlash qiyin edi, xatolar yuzaga keldi va biz mijozlarning shikoyatlarini tingladik. Ya'ni, biz muammoning yechimini sotayotgan edik, lekin biz platforma yaratish uchun pul kerakligi bilan keldik. Va ular investitsiyaning birinchi bosqichi misolida biznes misolini ko'rsatdilar: biz uni qanday qoplashni davom ettiramiz va bu bizga nima qilish imkonini beradi.
Dmitriy:
Birinchi bosqich vaqtini qandaydir tarzda yozib oldingizmi?
Sergey:
Ha albatta. Biz yadroni platforma sifatida yaratish va uchuvchini sinab ko'rish uchun 6 oy vaqt ajratdik. Bu vaqt ichida biz uchuvchi konkida uchadigan platforma yaratishga harakat qildik. Keyin gipoteza tasdiqlandi va u ishlayotganligi sababli, biz davom etishimiz mumkinligini anglatadi. Ular jamoani takrorlash va kuchaytirishni boshladilar - ular buni alohida bo'limga o'tkazishdi.
Keyinchalik biznes ehtiyojlari, imkoniyatlar, resurslarning mavjudligi va hozirda ishlayotgan barcha narsalarga asoslangan tizimli ish keladi.
Dmitriy:
KELISHDIKMI. Aleksandr, nima deysiz?
Aleksandr:
Bizning mikroservislarimiz "dengiz ko'pikidan" paydo bo'ldi - resurslarni tejash, server sig'imi va jamoa ichidagi kuchlarni qayta taqsimlash ko'rinishidagi ba'zi qoldiqlar tufayli. Dastlab biz ushbu loyihani biznesga sotmadik. Bu biz ikkalamiz ham tadqiq qilgan va shunga mos ravishda ishlab chiqqan loyiha edi. Biz 2018 yil boshida boshladik va shunchaki ishtiyoq bilan ushbu yo'nalishni rivojlantirdik. Sotish endigina boshlandi va biz bu jarayondamiz.
Dmitriy:
Biznes sizga Google kabi ishlarni haftada bir bo'sh kun qilish imkonini beradimi? Sizda shunday yo'nalish bormi?
Aleksandr:
Tadqiqotlar bilan bir vaqtda biz biznes muammolari bilan ham shug'ullanganmiz, shuning uchun bizning barcha mikroservislarimiz biznes muammolarini hal qilishdir. Faqat boshida biz abonentlar bazasining kichik qismini qamrab olgan mikroservislarni qurdik va hozir biz deyarli barcha flagman mahsulotlarda mavjudmiz.
Va moddiy ta'sir allaqachon aniq - biz allaqachon hisoblashimiz mumkin, agar biz eski yo'ldan yurgan bo'lsak, mahsulotni ishga tushirish tezligi va yo'qolgan daromadni hisoblash mumkin. Biz ishni shu asosda qurmoqdamiz.
Mikroservislar: shov-shuv yoki zaruratmi?
Dmitriy:
Raqamlar raqamlardir. Va daromad yoki saqlangan pul juda muhim. Agar boshqa tarafga qarasangiz nima bo'ladi? Aftidan, mikroservislar tendentsiya, shov-shuv va ko'plab kompaniyalar undan suiiste'mol qilishyaptimi? Mikroservislarga nima qilayotganingizni va tarjima qilmayotganingizni qanchalik aniq farqlaysiz? Agar hozir meros bo'lsa, 5 yildan keyin ham merosga ega bo'lasizmi? 5 yildan keyin M.Video-Eldorado va MegaFonda ishlaydigan axborot tizimlarining yoshi nechada bo'ladi? O'n yillik, o'n besh yillik axborot tizimlari bo'ladimi yoki yangi avlod bo'ladimi? Bunga qanday qaraysiz?
Sergey:
Menimcha, juda uzoqda o'ylash qiyin. Agar orqaga nazar tashlasak, texnologiya bozori shu tarzda, jumladan, mashinani o'rganish va foydalanuvchini yuzma-yuz identifikatsiyalash orqali rivojlanishini kim tasavvur qilgan? Ammo kelgusi yillarga nazar tashlasangiz, menimcha, asosiy tizimlar, kompaniyalardagi korporativ ERP-sinf tizimlari - ular ancha vaqtdan beri ishlamoqda.
Bizning kompaniyalarimiz 25 yoshda bo'lib, klassik ERP tizimiga juda chuqur kiradi. Biz u erdan ba'zi qismlarni olib, ularni mikroservislarga birlashtirishga harakat qilayotganimiz aniq, ammo yadro qoladi. U yerdagi barcha asosiy tizimlarni almashtirib, tezda yangi tizimlarning boshqa, yorqin tomoniga o‘tishimizni tasavvur qilish men uchun hozir qiyin.
Men mijoz va iste'molchiga yaqinroq bo'lgan hamma narsa biznesning eng katta foydasi va qadriyati, moslashuvchanlik va tezlikka, o'zgarishga, "sinab ko'ring, bekor qiling, qayta ishlating, boshqacha qiling"ga e'tibor qaratilishi tarafdoriman. kerak bo'ladi - bu erda landshaft o'zgaradi. Va qutidagi mahsulotlar u erga juda mos kelmaydi. Hech bo'lmaganda biz buni ko'rmayapmiz. U erda eng oson, eng oddiy echimlar talab qilinadi.
Biz ushbu rivojlanishni ko'ramiz:
- asosiy axborot tizimlari (asosan bek ofis);
- mikroservislar ko'rinishidagi o'rta qatlamlar yadroni birlashtiradi, birlashtiradi, kesh yaratadi va hokazo;
- oldingi tizimlar iste'molchiga qaratilgan;
- odatda bozorlar, boshqa tizimlar va ekotizimlarga integratsiyalashgan integratsiya qatlami. Ushbu qatlam imkon qadar engil, sodda va minimal biznes mantiqini o'z ichiga oladi.
Lekin shu bilan birga eski tamoyillardan to‘g‘ri foydalanilsa, ulardan foydalanishda davom etish tarafdoriman.
Aytaylik, sizda klassik korporativ tizim mavjud. U bitta sotuvchining landshaftida joylashgan va bir-biri bilan ishlaydigan ikkita moduldan iborat. Bundan tashqari, standart integratsiya interfeysi mavjud. Nega buni qayta tiklab, mikroservisni u yerga olib keling?
Ammo orqa ofisda 5 ta modul mavjud bo'lsa, ulardan ma'lumotlar bo'laklari biznes jarayoniga to'planadi va undan keyin 8-10 ta oldingi tizimlar foydalanadi, foyda darhol seziladi. Siz beshta bek-ofis tizimidan olib, biznes jarayoniga qaratilgan alohida xizmatni yaratasiz. Xizmatni texnologik jihatdan ilg'or qiling - u ma'lumotlarni keshlashi va xatolarga chidamli bo'lishi, shuningdek hujjatlar yoki tadbirkorlik sub'ektlari bilan ishlashi uchun. Va siz uni barcha oldingi mahsulotlar bilan yagona printsipga muvofiq birlashtirasiz. Ular oldingi mahsulotni bekor qilishdi - ular shunchaki integratsiyani o'chirib qo'yishdi. Ertaga siz mobil ilova yozishingiz yoki kichik veb-sayt yaratishingiz va faqat bitta qismini funksionallikka qo'yishingiz kerak - barchasi oddiy: siz uni konstruktor kabi yig'dingiz. Men bu yo‘nalishda ko‘proq rivojlanishni ko‘ryapman – hech bo‘lmaganda mamlakatimizda.
Aleksandr:
Sergey bizning yondashuvimizni to'liq tasvirlab berdi, rahmat. Men faqat qaerga bormasligimizni aytaman - asosiy qismga, onlayn hisob-kitob mavzusiga. Ya'ni, reyting va zaryadlash, aslida, pulni ishonchli tarzda hisobdan chiqaradigan "katta" xirmon bo'lib qoladi. Va bu tizim bizning nazorat organlari tomonidan sertifikatlashda davom etadi. Mijozlarga qaraydigan hamma narsa, albatta, mikroservislardir.
Dmitriy:
Bu erda sertifikatlash bitta hikoya. Ehtimol, ko'proq qo'llab-quvvatlash. Agar siz qo'llab-quvvatlashga ozgina pul sarflasangiz yoki tizim qo'llab-quvvatlash va o'zgartirishni talab qilmasa, unga tegmaslik yaxshiroqdir. Mantiqiy kelishuv.
Ishonchli mikroservislarni qanday ishlab chiqish kerak
Dmitriy:
Yaxshi. Lekin men hali ham qiziqaman. Endi siz muvaffaqiyat hikoyasini aytasiz: hamma narsa yaxshi edi, biz mikroservislarga o'tdik, biznesga g'oyani himoya qildik va hamma narsa amalga oshdi. Ammo men boshqa hikoyalarni eshitganman.
Bir necha yil oldin, banklar uchun yangi mikroservis platformasini ishlab chiqishga ikki yil sarmoya kiritgan Shveytsariya kompaniyasi oxir-oqibat loyihani yopdi. To'liq qulab tushdi. Ko'p millionlab Shveytsariya franki sarflandi va oxir-oqibat jamoa tarqalib ketdi - bu ish bermadi.
Sizda ham shunga o'xshash hikoyalar bo'lganmi? Qiyinchiliklar bo'lganmi yoki bormi? Misol uchun, mikroservislarni saqlash va monitoring ham kompaniyaning operatsion faoliyatida bosh og'rig'i hisoblanadi. Axir, komponentlar soni o'nlab marta ortadi. Siz buni qanday ko'rasiz, bu erda investitsiyalarning muvaffaqiyatsiz misollari bo'lganmi? Va odamlarga bunday muammolarga duch kelmasliklari uchun nima maslahat bera olasiz?
Aleksandr:
Muvaffaqiyatsiz misollar qatoriga korxonalarning ustuvorliklarini o'zgartirishi va loyihalarni bekor qilish kiradi. Tayyorlikning yaxshi bosqichida (aslida MVP tayyor), biznes shunday dedi: "Bizda yangi ustuvorliklar bor, biz boshqa loyihaga o'tmoqdamiz va biz buni yopamiz."
Mikroservislar bilan bizda global nosozliklar bo'lmadi. Biz tinch uxlaymiz, bizda butun BSS [biznesni qo'llab-quvvatlash tizimi] ga xizmat ko'rsatadigan 24/7 navbatchi navbatimiz bor.
Yana bir narsa - biz mikroservislarni qutiga solingan mahsulotlarga tegishli qoidalarga muvofiq ijaraga beramiz. Muvaffaqiyat kaliti shundaki, siz birinchi navbatda mikroservisni ishlab chiqarishga to'liq tayyorlaydigan jamoani yig'ishingiz kerak. Rivojlanishning o'zi shartli ravishda 40% ni tashkil qiladi. Qolganlari analitika, DevSecOps metodologiyasi, to'g'ri integratsiya va to'g'ri arxitektura. Biz xavfsiz ilovalarni yaratish tamoyillariga alohida e'tibor beramiz. Axborot xavfsizligi vakillari har bir loyihada arxitekturani rejalashtirish bosqichida ham, amalga oshirish jarayonida ham ishtirok etadilar. Shuningdek, ular zaifliklar uchun kodni tahlil qilish tizimlarini boshqaradi.
Aytaylik, biz fuqaroligi bo'lmagan xizmatlarimizni joylashtiramiz - bizda ular Kubernetesda mavjud. Bu xizmatlarning avtomatik o'lchami va avtomatik ko'tarilishi tufayli hammaga tinch uxlash imkonini beradi va navbatchi smenada hodisalar sodir bo'ladi.
Mikroxizmatlarimiz mavjud bo'lgan davrda bizning liniyamizgacha yetib borgan bir yoki ikkita voqea sodir bo'lgan. Endi operatsiya bilan bog'liq muammolar yo'q. Bizda, albatta, 200 emas, balki 50 ga yaqin mikroservislar mavjud, ammo ular flagman mahsulotlarda qo'llaniladi. Agar ular muvaffaqiyatsizlikka uchrasa, biz bu haqda birinchi bo'lib bilib olamiz.
Mikroservislar va HR
Sergey:
Men hamkasbimning qo'llab-quvvatlashga o'tish haqidagi fikriga qo'shilaman - ishni to'g'ri tashkil qilish kerak. Lekin men sizga, albatta, mavjud muammolar haqida aytib beraman.
Birinchidan, texnologiya yangi. Bu yaxshi ma'noda shov-shuv va buni tushunadigan va yarata oladigan mutaxassisni topish katta muammo. Resurslar uchun raqobat aqldan ozgan, shuning uchun mutaxassislar oltinga arziydi.
Ikkinchidan, muayyan landshaftlarning yaratilishi va xizmatlar sonining ko'payishi bilan qayta foydalanish muammosi doimiy ravishda hal qilinishi kerak. Ishlab chiquvchilar qilishni yoqtirganidek: "Keling, hozir bu erda juda ko'p qiziqarli narsalarni yozaylik ..." Shu sababli, tizim o'sib boradi va pul, egalik qiymati va hokazolar nuqtai nazaridan samaradorligini yo'qotadi. Ya'ni, tizim arxitekturasiga qayta foydalanishni kiritish, uni xizmatlarni joriy etish va merosni yangi arxitekturaga o'tkazish bo'yicha yo'l xaritasiga kiritish kerak.
Yana bir muammo - bu o'ziga xos tarzda yaxshi bo'lsa ham - ichki raqobat. "Oh, bu erda yangi moda yigitlari paydo bo'ldi, ular yangi tilda gapirishadi." Albatta, odamlar boshqacha. Java-da yozishga odatlanganlar va Docker va Kubernetes-ni yozadigan va ishlatadiganlar bor. Bular mutlaqo boshqa odamlar, ular boshqacha gapiradi, turli atamalarni qo'llaydi va ba'zan bir-birini tushunmaydi. Amaliyot, bilim almashish qobiliyati yoki qobiliyatsizligi ham shu ma'noda muammodir.
Xo'sh, resurslarni ko'paytirish. “Ajoyib, ketaylik! Va endi biz tezroq, ko'proq narsani xohlaymiz. Nima, qila olmaysizmi? Bir yilda ikki barobar ko'p yetkazib berish mumkin emasmi? Nega?" Bunday o'sib borayotgan og'riqlar, ehtimol, ko'p narsalar, ko'plab yondashuvlar uchun standartdir va siz ularni his qilishingiz mumkin.
Monitoring haqida. Menimcha, xizmatlar yoki sanoat monitoring vositalari allaqachon Docker va Kubernetes bilan boshqa, nostandart rejimda ishlashni o'rganmoqda yoki ishlashga qodir. Shunday qilib, masalan, siz bularning barchasi ishlaydigan 500 ta Java mashinalariga ega bo'lmaysiz, ya'ni u birlashadi. Ammo bu mahsulotlar hali ham etuklikka ega emas; ular buni boshdan kechirishlari kerak. Mavzu haqiqatan ham yangi, u rivojlanishda davom etadi.
Dmitriy:
Ha, juda qiziq. Va bu HR uchun amal qiladi. Ehtimol, sizning HR jarayoningiz va HR brendingiz ushbu 3 yil ichida biroz o'zgargan. Siz turli xil vakolatlarga ega bo'lgan boshqa odamlarni yollashni boshladingiz. Va, ehtimol, ijobiy va salbiy tomonlari ham bor. Ilgari blokcheyn va ma'lumotlar fanlari shov-shuv bo'lgan va ulardagi mutaxassislar millionlab baholangan. Endi narx pasayib bormoqda, bozor to'yingan bo'lib bormoqda va mikroservislarda ham xuddi shunday tendentsiya mavjud.
Sergey:
Ha, mutlaqo.
Aleksandr:
HR savol beradi: "Sizning pushti yagona shoxingiz orqa va old tomon o'rtasida qayerda?" HR mikroservis nima ekanligini tushunmaydi. Biz ularga sirni aytdik va ularga backend hamma narsani qilganini va bitta shoxli shoxcha yo'qligini aytdik. Ammo HR o'zgarmoqda, tez o'rganmoqda va IT bo'yicha asosiy bilimlarga ega bo'lgan odamlarni ishga yollamoqda.
Mikroservislarning evolyutsiyasi
Dmitriy:
Agar siz maqsadli arxitekturaga qarasangiz, mikroservislar shunday yirtqich hayvonga o'xshaydi. Sizning sayohatingiz bir necha yil davom etdi. Boshqalarida bir yil, boshqalarda uch yil bor. Siz barcha muammolarni, maqsadli arxitekturani oldindan ko'rganmisiz, biror narsa o'zgarganmi? Misol uchun, mikroservislar bo'lsa, shlyuzlar va xizmat ko'rsatish tarmoqlari endi yana paydo bo'ladi. Siz ularni boshida ishlatdingizmi yoki arxitekturani o'zgartirdingizmi? Sizda shunday qiyinchiliklar bormi?
Sergey:
Biz allaqachon bir nechta aloqa protokollarini qayta yozdik. Avvaliga bitta protokol bor edi, endi boshqasiga o'tdik. Biz xavfsizlik va ishonchlilikni oshiramiz. Biz korporativ texnologiyalardan boshladik - Oracle, Web Logic. Endi biz mikroservislardagi texnologik korxona mahsulotlaridan voz kechib, ochiq manba yoki butunlay ochiq texnologiyalarga o'tmoqdamiz. Biz ma'lumotlar bazalaridan voz kechamiz va ushbu modelda biz uchun samaraliroq bo'lgan narsaga o'tamiz. Bizga endi Oracle texnologiyalari kerak emas.
Biz oddiygina xizmat sifatida ish boshladik, bizga kesh qanchalik zarurligi, mikroservis bilan aloqa yo‘q bo‘lganda, lekin ma’lumotlar kerak bo‘lganda nima qilishimiz va hokazolar haqida o‘ylamay turibmiz. Hozir biz arxitekturani tavsiflash uchun platforma ishlab chiqmoqdamiz. xizmatlar tilida emas, balki biznes tilida, so'z bilan gaplasha boshlaganimizda, biznes mantiqini keyingi bosqichga olib chiqing. Endi biz harflar bilan gapirishni o'rgandik va keyingi bosqichda xizmatlar qandaydir agregatga yig'iladi, bu allaqachon so'z bo'lganda - masalan, butun mahsulot kartasi. U mikroservislardan yig'ilgan, ammo buning ustiga qurilgan API.
Xavfsizlik juda muhim. Siz kirish imkoniyatiga ega bo'lishingiz va siz juda tez, bir soniya ichida juda ko'p qiziqarli narsalarni olishingiz mumkin bo'lgan xizmatga ega bo'lishingiz bilan, uni eng xavfsiz bo'lmagan tarzda olish istagi paydo bo'ladi. Bundan qochish uchun biz sinov va monitoringga yondashuvni o'zgartirishimiz kerak edi. Biz jamoani, etkazib berishni boshqarish tuzilmasini, CI/CDni o'zgartirishimiz kerak edi.
Bu evolyutsiya - telefonlar kabi, faqat tezroq: avval tugmachali telefonlar, keyin smartfonlar paydo bo'ldi. Ular mahsulotni qayta yozdilar va qayta ishlab chiqdilar, chunki bozor boshqa ehtiyojga ega edi. Biz shunday rivojlanamiz: birinchi sinf, o'ninchi sinf, ish.
Takroriy ravishda, har yili texnologiya nuqtai nazaridan nimadir, orqada qolish va ehtiyojlar nuqtai nazaridan boshqa narsa belgilanadi. Biz bir narsani boshqasiga bog'laymiz. Jamoa 20% texnik qarz va jamoani texnik qo'llab-quvvatlashga, 80% tadbirkorlik sub'ektiga sarflaydi. Va biz buni nima uchun qilayotganimizni, nima uchun bu texnologik yaxshilanishlarni amalga oshirayotganimizni va ular nimaga olib kelishini tushunib harakat qilamiz. Shunga o'xshash.
Dmitriy:
Ajoyib. MegaFon-da nima bor?
Aleksandr:
Mikroservislarga kelganimizda asosiy qiyinchilik tartibsizlikka tushib qolmaslik edi. MegaFon arxitektura idorasi darhol bizga qo'shildi, hatto tashabbuskor va haydovchiga aylandi - endi bizda juda kuchli arxitektura mavjud. Uning vazifasi qanday maqsadli modelga borishimizni va qanday texnologiyalarni sinovdan o'tkazish kerakligini tushunish edi. Arxitektura bilan biz bu uchuvchilarni o'zimiz olib bordik.
Keyingi savol: "Unda bularning barchasidan qanday foydalanish kerak?" Va yana biri: "Mikroservislar o'rtasidagi shaffof o'zaro ta'sirni qanday ta'minlash mumkin?" Xizmat tarmog'i bizga oxirgi savolga javob berishga yordam berdi. Biz Istio-ni sinovdan o'tkazdik va natijalar yoqdi. Hozir biz ishlab chiqarish zonalariga chiqish bosqichidamiz. Biz barcha qiyinchiliklarga ijobiy munosabatdamiz - biz doimo stackni o'zgartirishimiz, yangi narsalarni o'rganishimiz kerakligi. Biz eski yechimlardan foydalanishdan emas, ishlab chiqishdan manfaatdormiz.
Dmitriy:
Oltin so'zlar! Bunday qiyinchiliklar jamoa va biznesni oyoq osti qiladi va kelajakni yaratadi. GDPR ma'lumotlarni himoya qilish bo'yicha bosh mutasaddilarni yaratdi va hozirgi muammolar bosh mikroservislar va arxitektura xodimlarini yaratadi. Va mamnun.
Biz ko'p muhokama qildik. Asosiysi, mikroservislarning yaxshi dizayni va arxitekturaning o'zi ko'p xatolardan qochish imkonini beradi. Albatta, jarayon iterativ va evolyutsion, lekin bu kelajak.
Barcha ishtirokchilarga rahmat, Sergey va Aleksandrga rahmat!
Tomoshabinlardan savollar
Tomoshabinlar savoli (1):
Sergey, kompaniyangizda IT menejmenti qanday o'zgardi? Bir nechta tizimlarning katta to'plami mavjud bo'lganda, uni qanday boshqarish juda aniq va mantiqiy jarayon ekanligini tushunaman. Qisqa vaqt ichida juda ko'p miqdordagi mikroservislar integratsiyalashgandan so'ng IT komponentining boshqaruvini qanday qayta qurdingiz?
Sergey:
Men hamkasbimning arxitektura o‘zgarishlarning haydovchisi sifatida juda muhim ekanligi haqidagi fikriga qo‘shilaman. Biz arxitektura bo'limiga ega bo'lishdan boshladik. Arxitektorlar bir vaqtning o'zida funksionallikni taqsimlash va uning landshaftda qanday paydo bo'lishiga qo'yiladigan talablarning egalaridir. Shunday qilib, ular ushbu o'zgarishlarning muvofiqlashtiruvchisi sifatida ham harakat qilishadi. Natijada, biz CI/CD platformasini yaratganimizda, ma'lum bir etkazib berish jarayoniga o'ziga xos o'zgarishlar kiritildi.
Ammo standart, asosiy rivojlanish tamoyillari, biznesni tahlil qilish, sinovdan o'tkazish va ishlab chiqish bekor qilinmagan. Biz shunchaki tezlikni qo'shdik. Ilgari, tsikl juda ko'p vaqtni oladi, sinov muhitiga o'rnatish juda ko'p vaqtni oladi. Endi biznes foydani ko'radi va: "Nega biz boshqa joylarda ham shunday qila olmaymiz?"
Bu, yaxshi ma'noda, emlash ko'rinishidagi in'ektsiyaga o'xshaydi: siz buni shunday qilishingiz mumkin, lekin siz buni boshqa yo'l bilan qilishingiz mumkin. Albatta, kadrlarda, malakada, bilimda, qarshilikda muammo bor.
Tomoshabinlar savoli (2):
Mikroservis arxitekturasi tanqidchilari sinov va ishlab chiqish qiyinligini aytishadi. Ishlar murakkablashsa, bu mantiqiy. Sizning jamoangiz qanday qiyinchiliklarga duch keldi va ularni qanday engdingiz? Hamma uchun savol.
Aleksandr:
Mikroservislardan platformaga o'tishda qiyinchiliklar mavjud, ammo ularni hal qilish mumkin.
Masalan, biz 5-7 mikroservisdan iborat mahsulot tayyorlayapmiz. Asosiy filialga o'tish uchun yashil chiroqni yoqish uchun biz butun mikroservislar stekida integratsiya testlarini taqdim etishimiz kerak. Bu vazifa biz uchun yangilik emas edi: biz buni BSSda uzoq vaqt davomida bajargan edik, o'shanda sotuvchi bizga allaqachon jo'natilgan yechimlarni yetkazib bergan edi.
Bizning muammomiz esa faqat kichik jamoada. Bitta shartli mahsulot uchun bitta QA muhandisi kerak. Shunday qilib, biz 5-7 ta mikroservis mahsulotini jo'natamiz, ulardan 2-3 tasi uchinchi shaxslar tomonidan ishlab chiqilishi mumkin. Masalan, bizning billing tizim sotuvchimiz Mail.ru Group va MegaFon R&D ishtirok etadigan mahsulotimiz bor. Uni ishlab chiqarishga jo'natishdan oldin biz buni sinovlar bilan qoplashimiz kerak. QA muhandisi bu mahsulot ustida bir yarim oy ishlamoqda, qolgan jamoa esa uning yordamisiz qolgan.
Bu murakkablik faqat masshtablashdan kelib chiqadi. Biz mikroservislar vakuumda mavjud bo'lmasligini tushunamiz; mutlaq izolyatsiya mavjud emas. Bitta xizmatni o'zgartirganda, biz doimo API shartnomasini saqlab qolishga harakat qilamiz. Agar kaput ostida biror narsa o'zgarsa, oldingi xizmat qoladi. Agar o'zgarishlar halokatli bo'lsa, qandaydir me'moriy o'zgarishlar sodir bo'ladi va biz butunlay boshqa ma'lumotlar metamodeliga o'tamiz, bu mutlaqo mos kelmaydi - shundan keyingina biz v2 xizmati API spetsifikatsiyasi paydo bo'lishi haqida gapiramiz. Biz bir vaqtning o'zida birinchi va ikkinchi versiyalarni qo'llab-quvvatlaymiz va barcha iste'molchilar ikkinchi versiyaga o'tgandan so'ng, biz birinchisini yopamiz.
Sergey:
Men qo'shmoqchiman. Men asoratlar haqida mutlaqo qo'shilaman - ular sodir bo'ladi. Landshaft murakkablashmoqda va qo'shimcha xarajatlar, ayniqsa, sinovlar uchun ortib bormoqda. Buni qanday hal qilish kerak: avtomatlashtirilgan testga o'tish. Ha, siz avtotestlar va birlik testlarini yozishga qo'shimcha sarmoya kiritishingiz kerak bo'ladi. Shunday qilib, ishlab chiquvchilar sinovdan o'tmasdan turib, kodni o'zgartira olmadilar. Shunday qilib, hatto bosish tugmasi ham avtotestsiz, birlik sinovisiz ishlamaydi.
Oldingi funksionallikni saqlab qolish muhim va bu qo'shimcha xarajatlardir. Agar siz texnologiyani boshqa protokolga qayta yozsangiz, hamma narsani to'liq yopmaguningizcha uni qayta yozasiz.
Biz ba'zida qasddan oxirigacha test o'tkazmaymiz, chunki biz rivojlanishni to'xtatmoqchi emasmiz, garchi bizda ham birin-ketin narsa bor. Landshaft juda katta, murakkab, ko'plab tizimlar mavjud. Ba'zan bu shunchaki qoralamalar - ha, siz xavfsizlik chegarasini pasaytirasiz, ko'proq xavf paydo bo'ladi. Lekin ayni paytda siz ta'minotni qo'yib yuborasiz.
Aleksandr:
Ha, avtotestlar va birlik testlari yuqori sifatli xizmatni yaratishga imkon beradi. Biz birlik va integratsiya sinovlarisiz o'tib bo'lmaydigan quvur liniyasi tarafdorimiz. Biz ko'pincha emulyatorlar va tijorat tizimlarini sinov zonalari va ishlab chiqish muhitlariga sudrab borishimiz kerak, chunki barcha tizimlarni sinov zonalariga joylashtirish mumkin emas. Bundan tashqari, ular shunchaki namlanmaydi - biz tizimdan to'liq javob beramiz. Bu mikroservislar bilan ishlashning jiddiy qismidir va biz ham unga sarmoya kiritamiz. Busiz tartibsizlik yuzaga keladi.
Tomoshabinlar savoli (3):
Men tushunganimdek, mikroservislar dastlab alohida jamoadan paydo bo'lgan va hozir ushbu modelda mavjud. Uning qanday ijobiy va salbiy tomonlari bor?
Bizda xuddi shunday voqea bor: mikroservislar zavodi paydo bo'ldi. Endi biz kontseptual tarzda ishlab chiqarishga ushbu yondashuvni oqimlar va tizimlar bo'yicha kengaytiramiz degan nuqtaga keldik. Boshqacha qilib aytganda, biz mikroservislar, mikroservis modellarining markazlashtirilgan rivojlanishidan uzoqlashmoqdamiz va tizimlarga yaqinlashmoqdamiz.
Shunga ko'ra, bizning faoliyatimiz tizimlarga ham o'tadi, ya'ni biz ushbu mavzuni markazsizlashtirmoqdamiz. Sizning yondashuvingiz qanday va maqsadli hikoyangiz nima?
Aleksandr:
Siz "mikroservislar zavodi" nomini og'zingizdan chiqarib tashladingiz - biz ham kengayishni xohlaymiz. Birinchidan, hozir bizda bitta jamoa bor. Biz MegaFon-ga ega bo'lgan barcha rivojlanish guruhlarini umumiy ekotizimda ishlash imkoniyati bilan ta'minlamoqchimiz. Biz hozir mavjud bo'lgan barcha ishlab chiqish funksiyalarini to'liq egallab olmoqchi emasmiz. Mahalliy vazifa - miqyoslash, global vazifa - mikroservis darajasidagi barcha jamoalar uchun rivojlanishni boshqarish.
Sergey:
Men sizlarga biz bosib o'tgan yo'lni aytib beraman. Biz haqiqatan ham bir jamoa bo'lib ishlay boshladik, ammo hozir biz yolg'iz emasmiz. Men quyidagilar tarafdoriman: jarayonning egasi bo'lishi kerak. Kimdir mikroservislarni ishlab chiqish jarayonini tushunishi, boshqarishi, nazorat qilishi va qurishi kerak. U resurslarga ega bo'lishi va resurslarni boshqarish bilan shug'ullanishi kerak.
Texnologiyalarni, o'ziga xos xususiyatlarni biladigan va mikroservislarni qanday yaratishni tushunadigan ushbu resurslar mahsulot guruhlarida joylashgan bo'lishi mumkin. Bizda mikroservis platformasidagi odamlar mobil ilovani yaratuvchi mahsulot jamoasida bo'lgan aralash mavjud. Ular bor, lekin ular mikroservis platformasini boshqarish bo'limi jarayoniga muvofiq o'zlarining rivojlanish menejeri bilan ishlaydi. Ushbu bo'linmada texnologiya bilan shug'ullanadigan alohida jamoa mavjud. Ya'ni, biz umumiy resurslarni o'zimizga aralashtiramiz va ularni jamoalarga ajratamiz.
Shu bilan birga, jarayon umumiy, boshqariladigan bo'lib qoladi, u umumiy texnologik printsiplarga muvofiq davom etadi, birlik sinovi va boshqalar - tepada qurilgan barcha narsalar. Mahsulot yondashuvining turli bo'limlaridan to'plangan resurslar shaklida ustunlar bo'lishi mumkin.
Aleksandr:
Sergey, siz aslida jarayonning egasisiz, to'g'rimi? Vazifalar roʻyxati umumiymi? Uning taqsimlanishi uchun kim javobgar?
Sergey:
Qarang: mana yana aralash. Texnologik takomillashtirish asosida shakllangan orqada qolish bor - bu bitta hikoya. Loyihalar bo'yicha ishlab chiqilgan va mahsulotlar bo'yicha orqada qolish mavjud. Lekin har bir xizmat mahsulotiga joriy etish yoki ushbu xizmatni yaratish ketma-ketligi mahsulot mutaxassisi tomonidan ishlab chiqiladi. U IT direksiyasida yo'q, uni maxsus ravishda olib tashlashgan. Lekin mening odamlarim, albatta, xuddi shu jarayon bo'yicha ishlaydi.
Turli yo'nalishdagi orqada qolganlarning egasi - o'zgarishlarning orqasida - har xil odamlar bo'ladi. Texnologik xizmatlarning ulanishi, ularni tashkil etish printsipi - bularning barchasi ITda bo'ladi. Menda platforma va resurslar ham bor. Yuqori qismida orqada qolish va funktsional o'zgarishlar va shu ma'noda arxitekturaga tegishli.
Aytaylik, biznes shunday deydi: "Biz bu funktsiyani xohlaymiz, biz yangi mahsulotni yaratmoqchimiz - kreditni qayta rasmiylashtirmoqchimiz." Biz javob beramiz: "Ha, biz buni qayta qilamiz." Arxitektorlar: "Kelinglar, o'ylab ko'raylik: kreditda biz mikroservislarni qayerda yozamiz va buni qanday qilamiz?" Keyin biz uni loyihalar, mahsulotlar yoki texnologiya to'plamiga ajratamiz, uni guruhlarga joylashtiramiz va amalga oshiramiz. Siz ichki mahsulot yaratdingizmi va ushbu mahsulotda mikroservislardan foydalanishga qaror qildingizmi? Biz aytamiz: "Endi bizda mavjud bo'lgan eski tizimlar yoki oldingi tizimlar ushbu mikroservislarga o'tishi kerak." Arxitektorlar shunday deyishadi: “Shunday qilib: oldingi mahsulotlar ichidagi texnologik orqada - mikroservislarga o'tish. Boring". Va mahsulot mutaxassislari yoki biznes egalari qancha quvvat ajratilganligini, qachon amalga oshirilishini va nima uchun ekanligini tushunishadi.
Munozaraning oxiri, lekin hammasi emas
mailto:CLOUD konferensiyasi tashkil etildi .
Biz boshqa tadbirlarni ham qilamiz - masalan. @Kubernetes uchrashuvi, biz har doim ajoyib ma'ruzachilarni qidiramiz:
- Telegram kanalimizda @Kubernetes va boshqa @Meetup yangiliklarini kuzatib boring
- @Meetups dan birida nutq so'zlamoqchimisiz? uchun so'rov qoldiring
Manba: www.habr.com