Banki.ru portalining operatsiyalar bo'yicha direktori Andrey Nikolskiy o'tgan yilgi anjumanda so'zga chiqdi etim xizmatlari haqida: infratuzilmada etimni qanday aniqlash mumkin, nega etim xizmatlari yomon, ular bilan nima qilish kerak va hech narsa yordam bermasa nima qilish kerak.
Kesik ostida hisobotning matnli versiyasi mavjud.
Salom hamkasblar! Mening ismim Andrey, men Banki.ru saytida operatsiyalarni boshqaraman.
Bizda katta xizmatlar bor, bular shunday monolit xizmatlar, klassikroq ma'noda xizmatlar mavjud va juda kichiklari bor. Men ishchi-dehqon terminologiyasida aytamanki, agar xizmat oddiy va kichik bo'lsa, u mikro, agar u juda oddiy va kichik bo'lmasa, u shunchaki xizmatdir.
Xizmatlarning afzalliklari
Men xizmatlarning afzalliklarini tezda ko'rib chiqaman.
Birinchisi - masshtablash. Siz tezda xizmatda biror narsa qilishingiz va ishlab chiqarishni boshlashingiz mumkin. Siz trafikni oldingiz, xizmatni klonladingiz. Sizda ko'proq trafik bor, siz uni klonladingiz va u bilan yashadingiz. Bu yaxshi bonus va, qoida tariqasida, biz boshlaganimizda, bu biz uchun eng muhim narsa deb hisoblangan, nima uchun bularning barchasini qilyapmiz.
Ikkinchidan, alohida rivojlanish, agar sizda bir nechta ishlab chiqish guruhlari bo'lsa, har bir jamoada bir nechta turli ishlab chiquvchilar va har bir jamoa o'z xizmatini ishlab chiqadi.
Jamoalar bilan bir nuance bor. Ishlab chiquvchilar boshqacha. Va bor, masalan, . Men buni birinchi marta Maksim Dorofeev bilan ko'rganman. Ba'zida qor parchalari ba'zi jamoalarda bo'ladi, boshqalarda emas. Bu kompaniya bo'ylab ishlatiladigan turli xizmatlarni biroz notekis qiladi.
Rasmga qarang: bu yaxshi ishlab chiquvchi, uning qo'llari katta, u juda ko'p ish qila oladi. Asosiy muammo - bu qo'llar qaerdan keladi.
Xizmatlar turli vazifalar uchun ko'proq mos keladigan turli xil dasturlash tillaridan foydalanishga imkon beradi. Ba'zi xizmatlar Go'da, ba'zilari Erlang'da, ba'zilari Ruby'da, nimadir PHP'da, nimadir Python'da. Umuman olganda, siz juda kengroq kengaytirishingiz mumkin. Bu erda ham nuanslar mavjud.
Xizmatga yo'naltirilgan arxitektura birinchi navbatda devoplarga tegishli. Ya'ni, agar sizda avtomatlashtirish bo'lmasa, joylashtirish jarayoni yo'q, agar siz uni qo'lda sozlasangiz, sizning konfiguratsiyalaringiz xizmat ko'rsatish misolidan misolga o'zgarishi mumkin va biror narsa qilish uchun u erga borishingiz kerak, keyin siz do'zaxdasiz.
Misol uchun, sizda 20 ta xizmat bor va siz qo'lda joylashtirishingiz kerak, sizda 20 ta konsol bor va siz bir vaqtning o'zida ninja kabi "enter" tugmasini bosasiz. Bu unchalik yaxshi emas.
Agar sizda testdan so'ng xizmatingiz bo'lsa (agar test mavjud bo'lsa, albatta) va siz uni ishlab chiqarishda ishlashi uchun fayl bilan tugatishingiz kerak bo'lsa, men siz uchun yomon xabarim ham bor.
Agar siz Amazonning ma'lum xizmatlariga tayansangiz va Rossiyada ishlasangiz, ikki oy oldin sizda "Atrofdagi hamma narsa yonmoqda, men yaxshiman, hammasi zo'r".
Biz joylashtirishni avtomatlashtirish uchun Ansible, konvergentsiya uchun qo'g'irchoq, joylashtirishni avtomatlashtirish uchun Bamboo va barchasini qandaydir tarzda tasvirlash uchun Confluence dan foydalanamiz.
Men bu haqda batafsil toβxtalib oβtirmayman, chunki hisobot texnik tatbiq haqida emas, balki koβproq oβzaro taβsir amaliyoti haqida.
Misol uchun, serverdagi Qo'g'irchoq Ruby 2 bilan ishlashda muammolarga duch keldik, lekin ba'zi ilovalar Ruby 1.8 uchun yozilgan va ular birgalikda ishlamaydi. U yerda nimadir notoβgβri ketmoqda. Ruby-ning bir nechta versiyasini bitta mashinada ishlatishingiz kerak bo'lganda, siz odatda muammolarga duch kelasiz.
Misol uchun, biz har bir ishlab chiquvchiga platformani beramiz, unda bizda mavjud bo'lgan hamma narsa, ishlab chiqilishi mumkin bo'lgan barcha xizmatlar mavjud bo'lib, u izolyatsiya qilingan muhitga ega bo'lib, uni buzishi va xohlaganicha qurishi mumkin.
Sizga u erda biror narsani qo'llab-quvvatlaydigan maxsus tuzilgan paket kerak bo'ladi. Bu juda qiyin. Men Docker tasvirining og'irligi 45 GB bo'lgan hisobotni tingladim. Linuxda, albatta, bu oddiyroq, u erda hamma narsa kichikroq, lekin hali ham bo'sh joy bo'lmaydi.
Xo'sh, qarama-qarshi bog'liqliklar mavjud, agar loyihaning bir qismi bitta versiyadagi kutubxonaga bog'liq bo'lsa, loyihaning boshqa qismi boshqa versiyaga bog'liq bo'lsa va kutubxonalar umuman birga o'rnatilmagan.
Bizda PHP 5.6 da sayt va xizmatlar bor, ulardan uyalamiz, lekin nima qilishimiz mumkin? Bu bizning yagona saytimiz. PHP 7 da saytlar va xizmatlar bor, ular ko'proq, biz ulardan uyalmaymiz. Va har bir ishlab chiquvchining o'z bazasi bor, u erda u xursandchilik bilan ko'radi.
Agar siz kompaniyada bitta tilda yozsangiz, unda bitta ishlab chiquvchiga uchta virtual mashina normal tuyuladi. Agar sizda turli xil dasturlash tillari bo'lsa, vaziyat yomonlashadi.
Sizda bu borada saytlar va xizmatlar mavjud, keyin Go uchun boshqa sayt, Ruby uchun bitta sayt va yon tomonda boshqa Redis mavjud. Natijada, bularning barchasi qo'llab-quvvatlash uchun katta maydonga aylanadi va har doim uning bir qismi sinishi mumkin.
Shuning uchun, biz dasturlash tilining afzalliklarini turli ramkalardan foydalanish bilan almashtirdik, chunki PHP ramkalari butunlay boshqacha, ular turli xil imkoniyatlarga, turli jamoalarga va turli xil yordamga ega. Va siz xizmatni yozishingiz mumkin, shunda sizda bunga tayyor narsa bor.
Har bir xizmatning o'z jamoasi bor
Bir necha yil davomida kristallangan bizning asosiy ustunligimiz shundaki, har bir xizmatning o'z jamoasi mavjud. Bu katta loyiha uchun qulay, siz hujjatlarga vaqtni tejashingiz mumkin, menejerlar o'z loyihasini yaxshi bilishadi.
Siz qo'llab-quvvatlash xizmatidan osongina topshiriqlarni yuborishingiz mumkin. Misol uchun, sug'urta xizmati buzildi. Va darhol sug'urta bilan shug'ullanadigan jamoa uni tuzatish uchun ketadi.
Yangi xususiyatlar tezda yaratilmoqda, chunki sizda bitta atom xizmati mavjud bo'lsa, siz tezda biror narsani burab qo'yishingiz mumkin.
Xizmatingizni buzganingizda va bu muqarrar ravishda sodir bo'ladi, siz boshqa odamlarning xizmatlariga ta'sir qilmadingiz va boshqa jamoalarning ishlab chiquvchilari sizga bit bilan yugurib kelishmaydi va: "Ay-oy, buni qilmang" deyishmaydi.
Har doimgidek, nuances bor. Bizda barqaror jamoalar bor, menejerlar jamoaga mixlangan. Aniq hujjatlar bor, menejerlar hamma narsani diqqat bilan kuzatib boradilar. Menejerga ega bo'lgan har bir jamoa bir nechta xizmatlarga ega va ma'lum bir malaka nuqtasi mavjud.
Agar jamoalar suzayotgan bo'lsa (biz buni ba'zan ishlatamiz), "yulduzli xarita" deb nomlangan yaxshi usul mavjud.
Sizda xizmatlar va odamlar ro'yxati bor. Yulduzcha bu odamning ushbu xizmatning mutaxassisi ekanligini, kitob esa bu xizmatni o'rganayotganligini bildiradi. Shaxsning vazifasi bukletni yulduzchaga o'zgartirishdir. Va agar xizmat oldida hech narsa yozilmagan bo'lsa, unda muammolar boshlanadi, men bundan keyin gaplashaman.
Etim xizmatlari qanday namoyon bo'ladi?
Birinchi muammo, infratuzilmangizda etim xizmatini olishning birinchi usuli - bu odamlarni ishdan bo'shatishdir. Hech kimning biznesi vazifalarni baholashdan oldin belgilangan muddatlarga to'g'ri kelganmi? Ba'zan shunday bo'ladiki, muddatlar qat'iy va hujjatlarni rasmiylashtirish uchun vaqt etarli emas. "Biz xizmatni ishlab chiqarishga topshirishimiz kerak, keyin uni qo'shamiz."
Agar jamoa kichik bo'lsa, hamma narsani yozadigan bitta ishlab chiquvchi bor, qolganlari qanotlarda. "Men asosiy arxitekturani yozdim, keling, interfeyslarni qo'shamiz." Keyin bir nuqtada menejer, masalan, ketadi. Va bu davrda, menejer ketgan va yangisi hali tayinlanmagan bo'lsa, ishlab chiquvchilar xizmat qaerga ketayotganini va u erda nima sodir bo'lishini o'zlari hal qilishadi. Va biz bilganimizdek (bir nechta slaydlarga qaytaylik), ba'zi jamoalarda qor parchasi odamlari bor, ba'zida qor parchalari jamoasi etakchilik qiladi. Keyin u ishdan ketadi va biz yetimlik xizmatini olamiz.
Shu bilan birga, qo'llab-quvvatlash va biznesning vazifalari yo'qolib qolmaydi; Agar xizmatni ishlab chiqish jarayonida arxitektura xatolari mavjud bo'lsa, ular ham orqada qoladi. Xizmat asta-sekin yomonlashmoqda.
Yetimni qanday aniqlash mumkin?
Ushbu ro'yxat vaziyatni yaxshi tasvirlaydi. Kim ularning infratuzilmasi haqida biror narsa o'rgandi?
Hujjatlashtirilgan ishlov berish haqida: xizmat mavjud va umuman olganda, u ishlaydi, u bilan qanday ishlash bo'yicha ikki sahifali qo'llanma bor, lekin uning ichida qanday ishlashini hech kim bilmaydi.
Yoki, masalan, qandaydir havolani qisqartiruvchi mavjud. Misol uchun, bizda hozirda turli xizmatlarda turli maqsadlarda foydalaniladigan uchta havolani qisqartiruvchi mavjud. Bu faqat oqibatlar.
Endi men ravshanlarning sardori bo'laman. Nima qilishim kerak? Birinchidan, xizmatni boshqa menejerga, boshqa jamoaga o'tkazishimiz kerak. Agar sizning jamoangiz rahbari hali tark etmagan bo'lsa, unda bu boshqa jamoada, xizmat etimga o'xshashligini tushunganingizda, bu haqda hech bo'lmaganda nimanidir tushunadigan odamni kiritishingiz kerak.
Asosiysi: sizda qon bilan yozilgan transfer protseduralari bo'lishi kerak. Bizning holatda, men buni odatda kuzatib boraman, chunki bularning barchasi ishlashim kerak. Menejerlar uni tezda etkazib berishlari kerak va keyinchalik u bilan nima sodir bo'lishi endi ular uchun unchalik muhim emas.
Yetim qilishning keyingi usuli - "Biz buni autsorsing qilamiz, tezroq bo'ladi va keyin uni jamoaga topshiramiz". Hammaning jamoada qandaydir rejalari, navbati borligi aniq. Ko'pincha biznes mijozi autsorser kompaniyaning texnik bo'limi bilan bir xil narsani qiladi deb o'ylaydi. Garchi ularning motivatorlari boshqacha bo'lsa ham. Autsorsingda g'alati texnologik echimlar va g'alati algoritmik echimlar mavjud.
Misol uchun, bizda turli xil kutilmagan joylarda Sfenks bo'lgan xizmat bor edi. Nima qilishim kerakligini keyinroq aytib beraman.
Autsorserlar o'z-o'zidan yozilgan ramkalarga ega. Bu avvalgi loyihadan nusxa ko'chirish bilan yalang'och PHP bo'lib, u erda siz har xil narsalarni topishingiz mumkin. Ba'zi bir fayldagi bir nechta satrlarni o'zgartirish uchun ba'zi murakkab Bash skriptlaridan foydalanish kerak bo'lganda, joylashtirish skriptlari katta kamchilikdir va bu joylashtirish skriptlari uchinchi skript tomonidan chaqiriladi. Natijada siz joylashtirish tizimini o'zgartirasiz, boshqa narsani tanlaysiz, sakrab chiqasiz, lekin sizning xizmatingiz ishlamaydi. Chunki u erda turli papkalar orasiga yana 8 ta havola qo'yish kerak edi. Yoki mingta yozuv ishlaydi, lekin yuz mingtasi endi ishlamaydi.
Men kapitanlikni davom ettiraman. Autsorsing xizmatini qabul qilish majburiy tartibdir. Kimdir hech qachon autsorsing xizmati kelgan va hech qayerda qabul qilinmaganmi? Bu, albatta, etim xizmati kabi mashhur emas, lekin baribir.
Xizmatni tekshirish, xizmatni ko'rib chiqish, parollarni o'zgartirish kerak. Ular bizga xizmat ko'rsatganida bizda shunday holat bo'lgan edi, "agar login == 'admin' && password == 'admin'..." administrator paneli mavjud, bu kodda to'g'ri yozilgan. Biz o'tiramiz va o'ylaymiz va odamlar buni 2018 yilda yozishadimi?
Saqlash hajmini tekshirish ham zaruriy narsadir. Ushbu xizmatni biron bir joyda ishlab chiqarishga qo'yishdan oldin, yuz minglab yozuvlarda nima bo'lishini ko'rib chiqishingiz kerak.
Xizmatni yaxshilash uchun yuborishda uyat bo'lmasligi kerak. βBiz bu xizmatni qabul qilmaymiz, bizda 20 ta vazifa bor, ularni bajaring, keyin qabul qilamizβ desangiz, bu normal holat. Menejer o'rnatayotganingiz yoki biznes pulni behuda sarflayotganligi sizning vijdoningizga zarar keltirmasligi kerak. Keyin biznes ko'proq pul sarflaydi.
Bizda tajribaviy loyihani autsorsing qilishga qaror qilgan holimiz bor edi.
U o'z vaqtida yetkazib berildi va bu yagona sifat mezoni edi. Shuning uchun biz boshqa uchuvchi loyihani yaratdik, u endi uchuvchi ham emas edi. Bu xizmatlar qabul qilindi va ma'muriy yo'llar bilan mana sizning kodingiz, mana jamoangiz, mana sizning menejeringiz deyishdi. Xizmatlar aslida daromad keltira boshlagan. Shu bilan birga, aslida ular hali ham etim, ularning qanday ishlashini hech kim tushunmaydi va menejerlar o'z vazifalarini rad etish uchun qo'llaridan kelganini qiladilar.
Yana bir ajoyib tushuncha bor - partizan taraqqiyoti. Ba'zi bo'lim, odatda marketing bo'limi, gipotezani sinab ko'rishni xohlasa va butun xizmatni autsorsingga buyuradi. Unga tirbandlik boshlanadi, ular hujjatlarni yopadilar, pudratchi bilan hujjatlarni imzolaydilar, ishga kirishadilar va: "Do'stlar, bizda bu erda xizmat bor, u allaqachon trafik bor, bizga pul olib keladi, buni qabul qilaylik", deyishadi. Biz: "Oppa, bu qanday bo'lishi mumkin?"
Va etim xizmatini olishning yana bir usuli: ba'zi bir jamoa to'satdan ortiqcha yuk bo'lib qolsa, rahbariyat: "Keling, bu jamoaning xizmatini boshqa jamoaga o'tkazamiz, uning yuki kichikroq" deydi. Va keyin biz uni uchinchi jamoaga o'tkazamiz va menejerni almashtiramiz. Va nihoyat, bizda yana bir yetim bor.
Yetimlarning muammosi nima?
Kim bilmaydi, bu Shvetsiyada ishlab chiqarilgan Wasa jangovar kemasi, u ishga tushirilgandan 5 daqiqa o'tgach cho'kib ketganligi bilan mashhur. Aytgancha, Shvetsiya qiroli buning uchun hech kimni qatl qilmadi. Uni bunday kemalarni qurishni bilmagan ikki avlod muhandislari qurgan. Tabiiy ta'sir.
Aytgancha, kema bundan ham battarroq cho'kib ketishi mumkin edi, masalan, qirol allaqachon bo'ronda qayerdadir uning ustiga minib olganida. Shunday qilib, u darhol cho'kib ketdi, Agilening so'zlariga ko'ra, erta muvaffaqiyatsizlikka uchragan yaxshi.
Agar biz erta muvaffaqiyatsizlikka uchrasak, odatda hech qanday muammo bo'lmaydi. Masalan, qabul qilish paytida u qayta ko'rib chiqish uchun yuborilgan. Ammo agar biz ishlab chiqarishda muvaffaqiyatsizlikka uchragan bo'lsak, pul investitsiya qilinganida, muammolar bo'lishi mumkin. Natijalar, ular biznesda deyilganidek.
Nima uchun etim xizmatlari xavfli:
- Xizmat to'satdan uzilishi mumkin.
- Xizmatni ta'mirlash uzoq vaqt talab etadi yoki umuman ta'mirlanmaydi.
- Xavfsizlik muammolari.
- Yaxshilash va yangilanishlar bilan bog'liq muammolar.
- Agar muhim xizmat buzilgan bo'lsa, kompaniya obro'siga putur etkazadi.
Etim xizmatlari bilan nima qilish kerak?
Men yana nima qilishni takrorlayman. Birinchidan, hujjatlar bo'lishi kerak. Banki.ru-dagi 7 yil menga testerlar ishlab chiquvchilarning so'zlarini qabul qilmasliklari kerakligini va operatsiyalar hammaning so'zlarini qabul qilmasliklarini o'rgatdi. Biz tekshirishimiz kerak.
Ikkinchidan, o'zaro ta'sir diagrammalarini yozish kerak, chunki unchalik yaxshi qabul qilinmagan xizmatlarda hech kim aytmagan bog'liqliklar mavjud. Misol uchun, ishlab chiquvchilar xizmatni ba'zi Yandex.Maps yoki Dadata kalitlariga o'rnatdilar. Sizda bepul chegara tugadi, hamma narsa buzildi va nima bo'lganini umuman bilmaysiz. Bunday rakelarning barchasini tavsiflash kerak: xizmat Dadata, SMS va boshqa narsalarni ishlatadi.
Uchinchidan, texnik qarz bilan ishlash. Agar siz biron bir qo'ltiq tayoqchasini qilsangiz yoki xizmatni qabul qilsangiz va biror narsa qilish kerakligini aytsangiz, bu bajarilganiga ishonch hosil qilishingiz kerak. Chunki o'shanda kichik tuynuk unchalik kichik emasligi ma'lum bo'lishi mumkin va siz undan tushib ketasiz.
Arxitektura vazifalari bilan biz Sfenks haqida hikoya qildik. Xizmatlardan biri ro'yxatlarni kiritish uchun Sfenksdan foydalangan. Faqat sahifalangan ro'yxat, lekin u har kecha qayta indekslanadi. U ikkita indeksdan yig'ilgan: bitta kattasi har kecha indekslanadi, shuningdek, unga vidalanadigan kichik indeks ham bor edi. Har kuni, 50% portlash ehtimoli bor yoki yo'q, indeks hisoblash paytida qulab tushdi va bizning yangiliklarimiz bosh sahifada yangilanishni to'xtatdi. Indeksni qayta indekslash uchun dastlab 5 daqiqa kerak bo'ldi, keyin indeks o'sdi va bir nuqtada uni qayta indekslash uchun 40 daqiqa keta boshladi. Biz buni kesib tashlaganimizda, biz yengil nafas oldik, chunki biroz ko'proq vaqt o'tishi va indeksimiz to'liq vaqtda qayta indekslanishi aniq edi. Bu bizning portalimiz uchun muvaffaqiyatsiz bo'ladi, sakkiz soat davomida hech qanday yangilik yo'q - tamom, biznes to'xtadi.
Yetimlar xizmati bilan ishlashni rejalashtirish
Aslida, buni qilish juda qiyin, chunki devops aloqa bilan bog'liq. Siz hamkasblaringiz bilan yaxshi munosabatda bo'lishni xohlaysiz va siz hamkasblaringiz va menejerlaringizni tartibga solish bilan urganingizda, ular buni qiladigan odamlarga nisbatan qarama-qarshi his-tuyg'ularga ega bo'lishi mumkin.
Ushbu barcha fikrlarga qo'shimcha ravishda, yana bir muhim narsa bor: har bir muayyan xizmat uchun, joylashtirish tartibining har bir alohida bo'limi uchun aniq odamlar javobgar bo'lishi kerak. Odamlar yo'q bo'lganda va siz boshqa odamlarni jalb qilishingiz kerak bo'lsa, bu masalani o'rganish qiyin bo'ladi.
Agar bularning barchasi yordam bermagan bo'lsa va sizning etim xizmatingiz hali ham etim bo'lsa, uni hech kim o'z zimmasiga olishni xohlamaydi, hujjatlar yozilmagan bo'lsa, ushbu xizmatga chaqirilgan jamoa hech narsa qilishdan bosh tortsa, oddiy yo'l bor - qayta tiklash. hamma narsa.
Ya'ni, siz xizmatga qo'yiladigan talablarni yangidan qabul qilasiz va g'alati texnologik echimlarsiz, yaxshiroq platformada yangi xizmatni yozasiz. Va sizlar unga jangda hijrat qilasizlar.
Bizda Yii 1 da xizmatni qabul qilib, uni yanada rivojlantira olmasligimizni anglab yetdik, chunki Yii 1 da yaxshi yoza oladigan dasturchilarimiz tugab qoldi. Barcha dasturchilar Symfony XNUMX da yaxshi yozishadi. Nima qilish kerak? Biz vaqt ajratdik, jamoa ajratdik, menejerni ajratdik, loyihani qayta yozdik va unga trafikni muammosiz o'tkazdik.
Shundan so'ng, eski xizmat o'chirilishi mumkin. Bu mening eng sevimli protsedura bo'lib, siz konfiguratsiyani boshqarish tizimidan biron bir xizmatni olib tashlashingiz va tozalashingiz kerak, keyin ishlab chiquvchilarning izlari qolmasligi uchun ishlab chiqarilgan barcha mashinalar o'chirilganligini ko'rishingiz kerak. Repozitoriy Gitda qoladi.
Bu men gaplashmoqchi bo'lgan narsa, men muhokama qilishga tayyorman, mavzu holivar, ko'pchilik unda suzgan.
Slaydlarda tillarni birlashtirganingiz aytilgan. Misol sifatida rasmlarning o'lchamlarini o'zgartirish edi. Haqiqatan ham uni bir til bilan cheklash kerakmi? Chunki PHP-da tasvir o'lchamini o'zgartirish, aslida Golangda amalga oshirilishi mumkin.
Aslida, bu barcha amaliyotlar kabi ixtiyoriydir. Ehtimol, ba'zi hollarda, bu hatto istalmagan. Ammo shuni tushunishingiz kerakki, agar sizda 50 kishidan iborat kompaniyada texnik bo'lim bo'lsa, ulardan 45 nafari PHP mutaxassislari, yana 3 nafari Python, Ansible, Puppet va shunga o'xshash narsalarni biladigan devoplar va ulardan faqat bittasi ba'zilarida yozadi. til o'lchamini o'zgartirish xizmatiga o'ting, keyin u chiqib ketganda, tajriba u bilan birga ketadi. Va shu bilan birga, siz ushbu tilni biladigan, ayniqsa kamdan-kam bo'lsa, bozorga xos ishlab chiquvchini izlashingiz kerak bo'ladi. Ya'ni, tashkiliy nuqtai nazardan, bu muammoli. Devops nuqtai nazaridan, siz xizmatlarni joylashtirish uchun foydalanadigan tayyor o'yin kitoblari to'plamini klonlashingiz shart emas, balki ularni qayta yozishingiz kerak bo'ladi.
Biz hozirda Node.js-da xizmat yaratmoqdamiz va bu har bir dasturchi uchun alohida tilga ega bo'lgan yaqin platforma bo'ladi. Lekin biz o'tirdik va o'yin shamga arziydi, deb o'yladik. Ya'ni, bu siz o'tirib, o'ylashingiz kerak bo'lgan savol.
Xizmatlaringizni qanday nazorat qilasiz? Jurnallarni qanday yig'ish va nazorat qilish kerak?
Biz Elasticsearch-da jurnallarni yig'amiz va ularni Kibana-ga joylashtiramiz va bu ishlab chiqarish yoki sinov muhitiga qarab, u erda turli kollektorlardan foydalaniladi. Qayerdadir Lumberjack, boshqa joyda boshqa narsa, esimda yo'q. Va ba'zi xizmatlarda hali ham Telegrafni o'rnatadigan va boshqa joyda alohida suratga oladigan ba'zi joylar mavjud.
Qo'g'irchoq va Ansible bilan bir xil muhitda qanday yashash kerak?
Aslida, bizda hozir ikkita muhit mavjud, biri Qo'g'irchoq, ikkinchisi Ansible. Biz ularni duragaylash ustida ishlayapmiz. Ansible - dastlabki sozlash uchun yaxshi ramka, Qo'g'irchoq - dastlabki sozlash uchun yomon ramka, chunki u to'g'ridan-to'g'ri platformada amaliy ishlarni talab qiladi va Qo'g'irchoq konfiguratsiya konvergentsiyasini ta'minlaydi. Bu shuni anglatadiki, platforma o'zini dolzarb holatda ushlab turadi va ansibilizatsiyalangan mashina yangilanib turishi uchun siz har doim ma'lum bir chastotada o'yin kitoblarini ishga tushirishingiz kerak. Farqi shunda.
Muvofiqlikni qanday saqlaysiz? Ansible va Puppet-da konfiguratsiyalaringiz bormi?
Bu bizning katta dardimiz, biz qo'llarimiz bilan uyg'unlikni saqlab qolamiz va bularning barchasidan qandaydir bir joyga o'tish haqida o'ylaymiz. Ma'lum bo'lishicha, Puppet paketlarni chiqaradi va u erda ba'zi havolalarni saqlaydi va Ansible, masalan, kodni chiqaradi va u erda eng so'nggi dastur konfiguratsiyasini sozlaydi.
Taqdimot Ruby ning turli versiyalari haqida edi. Qanday yechim?
Biz buni bir joyda uchratganmiz va buni doimo boshimizda saqlashimiz kerak. Biz shunchaki Ruby-da ishlaydigan ilovalarga mos kelmaydigan qismini o'chirib qo'ydik va uni alohida saqladik.
Bu yilgi konferentsiya 7 dekabr kuni Texnopolisda bo'lib o'tadi. Hisobotlarga arizalarni 11-noyabrgacha qabul qilamiz. Agar siz gaplashmoqchi bo'lsangiz, bizga.
Ishtirokchilar uchun ro'yxatga olish ochiq, bizga qo'shiling!
Manba: www.habr.com