Loyihaning yangi versiyasini ishlab chiqarishga olib kirish, joylashtirish tezligi va yechim ishonchliligi o'rtasida ehtiyotkorlik bilan muvozanatni talab qiladi. Slack tezkor iteratsiyalarni, qisqa fikr almashish davrlarini va foydalanuvchi so'rovlariga tezkor javobni qadrlaydi. Bundan tashqari, kompaniyada iloji boricha samarali bo'lishga intilayotgan yuzlab dasturchilar bor.
Tarjimasi bugun biz nashr etayotgan material mualliflarining taʼkidlashicha, bunday qadriyatlarga rioya qilishga intilayotgan va shu bilan birga oʻsib borayotgan kompaniya loyihalarni joriy etish tizimini doimiy ravishda takomillashtirishi kerak. Kompaniya ish jarayonlarining shaffofligi va ishonchliligiga sarmoya kiritishi kerak, bu esa ushbu jarayonlar loyiha miqyosiga mos kelishini ta'minlashi kerak. Bu erda biz Slack-da ishlab chiqilgan ish oqimlari va kompaniyani bugungi kunda mavjud bo'lgan loyihalarni joylashtirish tizimidan foydalanishga olib kelgan ba'zi qarorlar haqida gaplashamiz.
Loyihani joylashtirish jarayonlari bugungi kunda qanday ishlaydi
Slack-dagi har bir PR (pull so'rovi) kod ko'rib chiqilishi va barcha testlardan muvaffaqiyatli o'tishi kerak. Ushbu shartlar bajarilgandan keyingina dasturchi o'z kodini loyihaning asosiy bo'limiga birlashtirishi mumkin. Biroq, bu kod Shimoliy Amerika vaqti bilan faqat ish soatlarida joylashtiriladi. Natijada, xodimlarimiz o‘z ish joylarida bo‘lgani uchun biz har qanday kutilmagan muammolarni hal qilishga to‘liq tayyormiz.
Har kuni biz 12 ga yaqin rejalashtirilgan joylashtirishni amalga oshiramiz. Har bir joylashtirish vaqtida dasturchi yangi qurilmani ishlab chiqarishga kiritish uchun javobgar bo'ladi. Bu ko'p bosqichli jarayon bo'lib, montajni ishlab chiqarishga muammosiz olib kirishni ta'minlaydi. Ushbu yondashuv tufayli biz xatolarni barcha foydalanuvchilarga ta'sir qilishdan oldin aniqlashimiz mumkin. Agar juda ko'p xatolar bo'lsa, yig'ilishni joylashtirish orqaga qaytarilishi mumkin. Chiqarishdan keyin ma'lum bir muammo aniqlansa, uni tuzatish osonlikcha chiqarilishi mumkin.
Loyihalarni joylashtirish uchun Slack-da foydalaniladigan Checkpoint tizimining interfeysi
Yangi nashrni ishlab chiqarishga joylashtirish jarayonini to'rt bosqichdan iborat deb hisoblash mumkin.
▍1. Chiqarish filialini yaratish
Har bir reliz yangi reliz filiali bilan boshlanadi, bu bizning Git tariximizdagi nuqtadir. Bu sizga nashrga teglar belgilash imkonini beradi va relizni ishlab chiqarishga tayyorlash jarayonida topilgan xatolarni jonli ravishda tuzatishingiz mumkin bo'lgan joyni taqdim etadi.
▍2. Sahnalashtirish muhitida joylashtirish
Keyingi qadam, yig'ilishni staging serverlarida joylashtirish va loyihaning umumiy ishlashi uchun avtomatik sinovni o'tkazish (tutun sinovi). Sting muhiti tashqi trafikni qabul qilmaydigan ishlab chiqarish muhitidir. Ushbu muhitda biz qo'shimcha qo'lda test o'tkazamiz. Bu bizga o'zgartirilgan loyihaning to'g'ri ishlashiga qo'shimcha ishonch beradi. Ushbu ishonch darajasini ta'minlash uchun faqat avtomatlashtirilgan testlar etarli emas.
▍3. Sinov va kanareykalar muhitida joylashtirish
Ishlab chiqarishga o‘rnatish bizning ichki Slack ish maydonlarimizga xizmat ko‘rsatadigan xostlar to‘plami tomonidan taqdim etilgan sinov muhitidan boshlanadi. Biz juda faol Slack foydalanuvchilari bo'lganimiz sababli, ushbu yondashuvni qo'llash bizga joylashtirishning boshida ko'plab xatolarni aniqlashga yordam berdi. Tizimning asosiy funksionalligi buzilmaganligiga ishonch hosil qilganimizdan so'ng, montaj kanareyka muhitida joylashtiriladi. Bu ishlab chiqarish trafigining taxminan 2% ni tashkil etadigan tizimlarni ifodalaydi.
▍4. Sekin-asta ishlab chiqarishga chiqarish
Agar yangi nashr uchun monitoring ko'rsatkichlari barqaror bo'lsa va loyihani kanareyka muhitida joylashtirgandan so'ng biz hech qanday shikoyat qilmagan bo'lsak, biz ishlab chiqarish serverlarini asta-sekin yangi versiyaga o'tkazishni davom ettiramiz. Joylashtirish jarayoni quyidagi bosqichlarga bo'linadi: 10%, 25%, 50%, 75% va 100%. Natijada, biz asta-sekin ishlab chiqarish trafigini tizimning yangi versiyasiga o'tkazishimiz mumkin. Shu bilan birga, agar biron bir anomaliya aniqlansa, vaziyatni o'rganishga ulguramiz.
▍O'rnatish vaqtida biror narsa noto'g'ri bo'lsa-chi?
Kodga o'zgartirishlar kiritish har doim xavf tug'diradi. Ammo biz yangi nashrni ishlab chiqarishga kiritish jarayonini boshqaradigan, monitoring ko'rsatkichlarini kuzatadigan va kodni chiqaradigan dasturchilar ishini muvofiqlashtiradigan yaxshi o'qitilgan "joylashtirish bo'yicha rahbarlar" mavjudligi tufayli buni uddalaymiz.
Agar biror narsa noto'g'ri bo'lsa, biz muammoni imkon qadar tezroq aniqlashga harakat qilamiz. Biz muammoni o'rganamiz, xatolarga sabab bo'lgan PRni topamiz, uni orqaga qaytaramiz, yaxshilab tahlil qilamiz va yangi tuzilmani yaratamiz. To'g'ri, ba'zida muammo loyiha ishlab chiqarishga kirgunga qadar sezilmaydi. Bunday vaziyatda, eng muhimi, xizmatni tiklashdir. Shuning uchun, muammoni o'rganishni boshlashdan oldin, biz darhol oldingi ish tuzilishiga qaytamiz.
Joylashtirish tizimining qurilish bloklari
Keling, loyihani joylashtirish tizimi asosidagi texnologiyalarni ko'rib chiqaylik.
▍Tezkor joylashtirish
Yuqorida tavsiflangan ish jarayoni, orqaga qarab, biroz aniq ko'rinishi mumkin. Ammo bizning joylashtirish tizimimiz darhol bunday bo'lib qolmadi.
Kompaniya ancha kichik bo'lganida, bizning butun ilovamiz 10 ta Amazon EC2 nusxasida ishlashi mumkin edi. Bunday vaziyatda loyihani qo'llash barcha serverlarni tezda sinxronlashtirish uchun rsync-dan foydalanishni anglatadi. Ilgari, yangi kod ishlab chiqarishdan atigi bir qadam narida edi, bu sahna muhiti bilan ifodalanadi. Assambleyalar shunday muhitda yaratildi va sinovdan o'tkazildi, keyin esa to'g'ridan-to'g'ri ishlab chiqarishga o'tdi. Bunday tizimni tushunish juda oson edi, bu har qanday dasturchiga istalgan vaqtda yozgan kodini joylashtirish imkonini berdi.
Ammo mijozlarimiz soni ortgan sari loyihani qo‘llab-quvvatlash uchun zarur bo‘lgan infratuzilma ko‘lami ham ortib bordi. Ko'p o'tmay, tizimning doimiy o'sishini hisobga olgan holda, serverlarga yangi kodlarni yuborishga asoslangan bizning joylashtirish modelimiz endi o'z ishini qilmadi. Ya'ni, har bir yangi serverni qo'shish joylashtirishni yakunlash uchun zarur bo'lgan vaqtni ko'paytirishni anglatadi. Hatto rsync-dan parallel foydalanishga asoslangan strategiyalar ham ma'lum cheklovlarga ega.
Biz eski tizimdan boshqacha tarzda ishlab chiqilgan butunlay parallel joylashtirish tizimiga o'tish orqali bu muammoni hal qildik. Ya'ni, endi biz sinxronizatsiya skriptidan foydalangan holda serverlarga kod yubormadik. Endi har bir server mustaqil ravishda yangi assambleyani yuklab oldi, chunki konsul kaliti o'zgarishini kuzatish orqali buni qilish kerak. Serverlar kodni parallel ravishda yukladilar. Bu bizga tizimning doimiy o'sishi sharoitida ham yuqori tezlikni qo'llash imkonini berdi.
1. Ishlab chiqarish serverlari Konsul kalitini nazorat qiladi. 2. Asosiy o'zgarishlar, bu serverlarga yangi kodni yuklab olishni boshlashlari kerakligini aytadi. 3. Serverlar dastur kodi bilan tarball fayllarni yuklab olishadi
▍Atomni joylashtirish
Ko'p bosqichli joylashtirish tizimiga erishishimizga yordam bergan yana bir yechim atomni joylashtirish edi.
Atom o'rnatishlardan foydalanishdan oldin, har bir tarqatish ko'p sonli xato xabarlariga olib kelishi mumkin. Gap shundaki, yangi fayllarni ishlab chiqarish serverlariga nusxalash jarayoni atomik emas edi. Bu funksiyalarning o'zi mavjud bo'lgunga qadar yangi funksiyalar deb ataladigan kod mavjud bo'lgan qisqa vaqt oynasiga olib keldi. Bunday kod chaqirilganda, bu ichki xatolar qaytarilishiga olib keldi. Bu muvaffaqiyatsiz API so'rovlarida va buzilgan veb-sahifalarda namoyon bo'ldi.
Ushbu muammo ustida ishlagan jamoa uni "issiq" va "sovuq" kataloglar tushunchasini kiritish orqali hal qildi. Issiq katalogdagi kod ishlab chiqarish trafigini qayta ishlash uchun javobgardir. Va "sovuq" kataloglarda, tizim ishlayotgan paytda kod faqat foydalanishga tayyorlanmoqda. Joylashtirish vaqtida yangi kod foydalanilmagan sovuq katalogga ko'chiriladi. Keyin, serverda faol jarayonlar bo'lmasa, bir lahzali katalog almashinuvi amalga oshiriladi.
1. Ilova kodini "sovuq" katalogga ochish. 2. Tizimni "issiq" bo'ladigan "sovuq" katalogga o'tkazish (atom operatsiyasi)
Natijalar: diqqatni ishonchlilikka o'tkazish
2018 yilda loyiha shu qadar kengaydiki, juda tez joylashtirish mahsulot barqarorligiga zarar etkaza boshladi. Bizda juda ilg'or joylashtirish tizimi bor edi, unga ko'p vaqt va kuch sarfladik. Biz qilishimiz kerak bo'lgan narsa - joylashtirish jarayonlarimizni qayta qurish va yaxshilash edi. Biz juda katta kompaniyaga aylandik, uning ishlanmalari butun dunyoda uzluksiz aloqalarni tashkil qilish va muhim muammolarni hal qilish uchun ishlatilgan. Shuning uchun ishonchlilik bizning e'tiborimiz markaziga aylandi.
Biz yangi Slack relizlarini joylashtirish jarayonini xavfsizroq qilishimiz kerak edi. Bu ehtiyoj bizni joylashtirish tizimimizni yaxshilashga olib keldi. Aslida, biz yuqorida ushbu takomillashtirilgan tizimni muhokama qildik. Tizimning chuqurligida biz tez va atomik joylashtirish texnologiyalaridan foydalanishda davom etamiz. Joylashtirish usuli o'zgardi. Bizning yangi tizimimiz yangi kodlarni turli darajalarda, turli muhitlarda bosqichma-bosqich joylashtirishga mo'ljallangan. Endi biz avvalgidan ko'ra ilg'or qo'llab-quvvatlash vositalari va tizim monitoringi vositalaridan foydalanamiz. Bu bizga xatolarni oxirgi foydalanuvchiga yetib borishdan ancha oldin aniqlash va tuzatish imkoniyatini beradi.
Ammo biz u erda to'xtab qolmaymiz. Biz yanada ilg'or yordamchi vositalar va ishni avtomatlashtirish vositalaridan foydalangan holda ushbu tizimni doimiy ravishda takomillashtiramiz.
Hurmatli o'quvchilar! Yangi loyiha relizlarini joylashtirish jarayoni siz ishlayotgan joyda qanday ishlaydi?
Manba: www.habr.com
