Mahsulotda sinov: Canary Deployment

Kanareyka - doimiy qo'shiq aytadigan kichik qush. Bu qushlar metan va uglerod oksidiga sezgir. Havodagi ortiqcha gazlarning kichik konsentratsiyasidan ham ular ongini yo'qotadilar yoki o'lishadi. Oltin qazuvchilar va konchilar qushlarni konga olib ketishdi: kanareykalar qo'shiq aytayotganda, siz ishlashingiz mumkin, agar jim bo'lsangiz - shaxtada gaz bor va ketish vaqti keldi. Konchilar minalardan tirik chiqib ketish uchun kichik bir qushni qurbon qilishdi.

Shunga o'xshash amaliyot IT sohasida o'zini topdi. Masalan, xizmat yoki ilovaning yangi versiyasini undan oldin sinovdan o'tkazgan holda ishlab chiqarishga joylashtirish standart vazifasida. Sinov muhiti juda qimmat bo'lishi mumkin, avtomatlashtirilgan testlar siz xohlagan hamma narsani qamrab olmaydi va sinovdan o'tmaslik va sifatni qurbon qilish xavfli. Bu erda Canary Deployment yondashuvi foydali bo'ladi, bu erda haqiqiy ishlab chiqarish trafigi yangi versiyaga yo'naltiriladi. Yondashuv yordam beradi ishonch bilan yangi versiyani tekshiring ishlab chiqarish uchun, katta ish uchun ozgina qurbon qilish. Yondashuv qanday ishlashi, nima foydali va uni qanday amalga oshirish haqida batafsilroq ma'lumot beradi Andrey Markelov (Andrey_V_Markelov), Infobip kompaniyasida amalga oshirish misolida.

Andrey Markelov - Infobip kompaniyasining dasturiy ta'minot bo'yicha yetakchi muhandisi, 11 yildan beri moliya va telekommunikatsiyalar sohasida Java dasturlarini ishlab chiqmoqda. Ochiq kodli mahsulotlarni ishlab chiqadi, Atlassian hamjamiyatida faol ishtirok etadi va Atlassian mahsulotlari uchun plaginlarni yozadi. Prometey, Doker va Redisning xushxabarchisi.

Infobip haqida

Bu global telekommunikatsiya platformasi bo'lib, banklar, chakana sotuvchilar, onlayn-do'konlar va transport kompaniyalariga o'z mijozlariga SMS, push, xatlar va ovozli xabarlar orqali xabarlar yuborish imkonini beradi. Bunday biznesda mijozlar xabarlarni o'z vaqtida olishlari uchun barqarorlik va ishonchlilik muhimdir.

Infobip IT infratuzilmasi raqamlarda:

• Dunyo bo'ylab 15 ta ma'lumotlar markazlari;
• 500 ta noyob xizmatlar mavjud;
• 2500 ta xizmatlar, bu buyruqlardan ancha ko'p;
• 4,5 TB oylik trafik;
• 4,5 milliard telefon raqamlari;

Biznes o'sib bormoqda va shu bilan birga relizlar soni. sarflaymiz Kuniga 60 ta nashrchunki mijozlar ko'proq xususiyat va quvvatni xohlashadi. Ammo bu qiyin - xizmatlar juda ko'p, ammo buyruqlar kam. Ishlab chiqarishda xatosiz ishlashi kerak bo'lgan kodni tezda yozishingiz kerak.

Relizlar

Odatiy nashr shunday bo'ladi. Masalan, A, B, C, D va E xizmatlari mavjud bo'lib, ularning har biri alohida guruh tomonidan ishlab chiqilgan.

Bir nuqtada, A xizmati jamoasi yangi versiyani o'rnatishga qaror qiladi, ammo B, C, D va E xizmatlari guruhlari bu haqda bilishmaydi. A xizmat guruhi qanday harakat qilishining ikkita varianti mavjud.

Tutadi bosqichma-bosqich chiqarish: birinchi navbatda bitta versiyani, keyin esa ikkinchisini almashtiring.

Ammo ikkinchi variant ham bor: buyruq qo'shimcha quvvatlar va mashinalarni topadi, yangi versiyani o'rnating va keyin marshrutizatorni almashtiring va versiya ishlab chiqarish uchun ishlay boshlaydi.

Har qanday holatda, versiya sinovdan o'tgan bo'lsa ham, joylashtirishdan keyin deyarli har doim muammolar mavjud. Siz qo'lda sinab ko'rishingiz mumkin, siz buni avtomatik ravishda qilishingiz mumkin, siz sinovdan o'tkaza olmaysiz - har qanday holatda muammolar paydo bo'ladi. Ularni hal qilishning eng oson va eng to'g'ri yo'li ishchi versiyaga qaytishdir. Shundagina siz zararni, sabablarini aniqlashingiz va ularni tuzatishingiz mumkin.

Xo'sh, biz nimani xohlaymiz?

Bizga muammolar kerak emas. Agar mijozlar ularni bizdan tezroq topsa, bu ularning obro'siga putur etkazadi. Shuning uchun biz kerak muammolarni mijozlarga qaraganda tezroq toping. Proaktiv ishlagan holda, biz zararni minimallashtiramiz.

Shu bilan birga, biz xohlaymiz joylashtirishni tezlashtirishShunday qilib, bu tez, oson, tabiiy va jamoaning bosimisiz sodir bo'ladi. Muhandislar, DevOps muhandislari va dasturchilari himoyalangan bo'lishi kerak - yangi versiyaning chiqarilishi stressli. Jamoani sarflab bo'lmaydi, biz intilamiz inson resurslaridan oqilona foydalanish.

Joylashtirish muammolari

Mijoz trafigini oldindan aytib bo'lmaydi. Mijoz trafigining qachon eng past bo'lishini oldindan aytib bo'lmaydi. Mijozlar o‘z kampaniyalarini qayerda va qachon boshlashlarini bilmaymiz – ehtimol bugun kechqurun Hindistonda, ertaga Gonkongda. Katta vaqt farqini hisobga olsak, hatto soat 2 da joylashtirish mijozlarga ta'sir qilmasligiga kafolat bermaydi.

Provayder muammolari. Messenjerlar va provayderlar bizning hamkorlarimizdir. Ba'zan ular yangi versiyalarni o'rnatish paytida xatolarga olib keladigan nosozliklar mavjud.

Tarqalgan jamoalar. Mijoz tomoni va orqa tomonni ishlab chiqadigan jamoalar turli vaqt zonalarida. Shu sababli ular ko'pincha o'zaro kelisha olmaydilar.

Ma'lumotlar markazlarini sahnada takrorlab bo'lmaydi. Bitta ma'lumot markazida 200 ta raf mavjud - siz buni qum qutisida taxminan takrorlay olmaysiz.

To'xtash vaqtlariqabul qilib bo'lmas! Masalan, biz 99,99% ishlayotganimizda xatolik byudjetiga egamiz, qolgan foiz esa “xato marjasi”. 100% ishonchlilikka erishish mumkin emas, lekin tushish va ishlamay qolish vaqtini doimiy ravishda kuzatib borish muhimdir.

Klassik yechimlar

Xatolarsiz kod yozing. Men yosh dasturchi bo'lganimda, menejerlar menga xatosiz chiqarishni iltimos qilishdi, ammo bu har doim ham mumkin emas.

Testlarni yozing. Sinovlar ishlaydi, lekin ba'zida biznes xohlagan tarzda emas. Pul ishlash sinovlarning ishi emas.

Sahnada sinov. Infobip-dagi 3,5 yillik faoliyatim davomida men sahnaning holati hech bo'lmaganda qisman ishlab chiqarish bilan mos kelishini ko'rmaganman.

Biz hatto bu g'oyani rivojlantirishga harakat qildik: avval bizda sahna, keyin pre-produktsiya, keyin esa oldindan ishlab chiqarish bor edi. Ammo bu ham yordam bermadi - ular hatto hokimiyatda ham mos kelmadilar. Sahna bilan biz asosiy funksionallikni kafolatlay olamiz, lekin u yuk ostida qanday ishlashini bilmaymiz.

Chiqarish uni ishlab chiqqan tomonidan amalga oshiriladi. Bu yaxshi amaliyot: kimdir sharh nomini o'zgartirsa ham, uni darhol ishlab chiqarishga qo'shadi. Bu mas'uliyatni rivojlantirishga yordam beradi va kiritilgan o'zgarishlarni unutmaydi.

Qo'shimcha asoratlar ham mavjud. Ishlab chiquvchi uchun hamma narsani qo'lda tekshirish uchun ko'p vaqt sarflash juda qiyin.

Kelishilgan nashrlar. Ushbu variant odatda rahbariyat tomonidan taklif etiladi: "Keling, har kuni yangi versiyalarni sinab ko'rishingiz va qo'shishingiz bilan rozi bo'laylik." Bu ishlamaydi: har doim hamma uchun buyruq kutadi yoki aksincha.

Tutun sinovlari

Joylashtirish muammolarimizni hal qilishning yana bir usuli. Oldingi misolda, A jamoasi yangi versiyani o'rnatmoqchi bo'lganida, tutun sinovlari qanday ishlashini ko'rib chiqing.

Birinchidan, jamoa ishlab chiqarishga bitta nusxani joylashtiradi. Masxarabozlardan misol uchun xabarlar real trafikni simulyatsiya qiladioddiy kundalik trafikni moslashtirish uchun. Agar hamma narsa yaxshi bo'lsa, jamoa yangi versiyani foydalanuvchi trafigiga o'tkazadi.

Ikkinchi variant - joylashtirish qo'shimcha temir bilan. Jamoa uni ishlab chiqarish uchun sinovdan o'tkazadi, keyin o'tadi va hamma narsa ishlaydi.

Tutun sinovlarining kamchiliklari:

• Sinovlarga ishonish mumkin emas. Ishlab chiqarishdagi kabi trafikni qayerdan olish mumkin? Siz kecha yoki bir hafta oldin foydalanishingiz mumkin, lekin u har doim ham hozirgisiga mos kelmaydi.
• Saqlash qiyin. Faol yozuvlar omborga yuborilganda siz sinov hisoblarini yuritishingiz, har bir joylashtirishdan oldin ularni doimiy ravishda qayta o'rnatishingiz kerak bo'ladi. Bu o'z sinov muhitida test yozishdan ko'ra qiyinroq.

Bu erda yagona bonus ishlashini tekshirish mumkin.

Kanareykalarni chiqaradi

Tutun testlarining kamchiliklari tufayli biz kanareykalar relizlaridan foydalanishni boshladik.

Konchilar gazlar darajasini ko'rsatish uchun kanareykalardan qanday foydalanganiga o'xshash amaliyot ITga yo'l topdi. Biz ruxsat beramiz yangi versiyaga haqiqiy ishlab chiqarish trafigiXizmat darajasi kelishuviga (SLA) javob berishga urinayotganda. SLA - bu bizning "xato qilish huquqimiz" bo'lib, biz uni yiliga bir marta (yoki boshqa vaqt davomida) ishlatishimiz mumkin. Agar hamma narsa yaxshi bo'lsa, biz ko'proq trafikni qo'shamiz. Aks holda, oldingi versiyalarni qaytaramiz.

Amalga oshirish va nuanslar

Biz kanareykalarni chiqarishni qanday amalga oshirdik? Misol uchun, bir guruh mijozlar bizning xizmatimiz orqali xabarlar yuborishadi.

Joylashtirish quyidagicha davom etadi: biz balanser ostidan bitta tugunni olib tashlaymiz (1), versiyani o'zgartiramiz (2) va ba'zi trafikni alohida ajratamiz (3).

Umuman olganda, bitta foydalanuvchi baxtsiz bo'lsa ham, guruhdagi hamma baxtli bo'ladi. Agar hamma narsa yaxshi bo'lsa, biz barcha versiyalarni o'zgartiramiz.

Ko'p hollarda mikroservislar qanday ko'rinishini sxematik tarzda ko'rsataman.

Service Discovery va yana ikkita xizmat mavjud: S1N1 va S2. Birinchi xizmat (S1N1) ishga tushganda Service Discovery haqida xabar beradi va Service Discovery uni eslab qoladi. Ikki tugunli ikkinchi xizmat (S2N1 va S2N2) ishga tushganda Service Discovery haqida xabar beradi.

Birinchisi uchun ikkinchi xizmat server sifatida ishlaydi. Birinchisi, Service Discovery-dan o'z serverlari haqida ma'lumot so'raydi va uni qabul qilganda, ularni qidiradi va tekshiradi ("salomatlik tekshiruvi"). U tekshirganda, u ularga xabar yuboradi.

Kimdir ikkinchi xizmatning yangi versiyasini o'rnatmoqchi bo'lsa, u Service Discovery-ga ikkinchi tugun kanareyka tugun bo'lishini aytadi: unga kamroq trafik yuboriladi, chunki joylashtirish hozir amalga oshiriladi. Biz kanareyka tugunini balanslashtiruvchi ostidan olib tashlaymiz va birinchi xizmat unga trafik jo'natmaydi.

Biz versiyani o'zgartiramiz va Service Discovery ikkinchi tugun endi kanareyka ekanligini biladi - siz unga kamroq yuk berishingiz mumkin (5%). Har bir narsa yaxshi bo'lsa, biz versiyani o'zgartiramiz, yuklarni qaytaramiz va ishlaymiz.

Bularning barchasini amalga oshirish uchun bizga kerak:

• muvozanatlash;
• monitoringchunki har bir foydalanuvchi nimani kutayotgani va xizmatlarimiz qanday ishlashini batafsil bilish muhim;
• versiya tahliliyangi versiya ishlab chiqarishda qanchalik yaxshi ishlashini tushunish;
• avtomatlashtirish - biz joylashtirish ketma-ketligini yozamiz (joylashtirish quvur liniyasi).

Balanslash

Bu biz o'ylashimiz kerak bo'lgan birinchi narsa. Ikkita muvozanat strategiyasi mavjud.

Eng oddiy variant qachon bitta tugun har doim kanareykadir. Ushbu tugun har doim kamroq trafik oladi va biz undan joylashtirishni boshlaymiz. Muammolar bo'lsa, biz uning ishini joylashtirishdan oldin va uning davomida solishtiramiz. Misol uchun, agar 2 barobar ko'proq xato bo'lsa, zarar 2 barobar oshdi.

O'rnatish jarayonida kanareyka tugunlari o'rnatiladi. Joylashtirish tugagach va biz undan kanareyka tugunining holatini olib tashlasak, trafik balansi tiklanadi. Kamroq mashinalar bilan biz adolatli taqsimot olamiz.

Monitoring

Kanareykalarning asosiy toshi relizlar. Biz buni nima uchun qilayotganimizni va qanday ko'rsatkichlarni to'plashni xohlayotganimizni aniq tushunishimiz kerak.

Xizmatlarimizdan to'playdigan ko'rsatkichlarga misollar.

• Xatolar soni, ular jurnallarga yoziladi. Bu hamma narsa kerakli darajada ishlayotganining aniq ko'rsatkichidir. Umuman olganda, bu yaxshi ko'rsatkich.
• So'rovni bajarish vaqti (kechikish). Har bir inson bu ko'rsatkichni kuzatib boradi, chunki hamma tez ishlashni xohlaydi.
• Navbat hajmi (o'tkazish).
• Bir soniyada muvaffaqiyatli javoblar soni.
• Barcha so'rovlarning 95% bajarilish vaqti.
• Biznes ko'rsatkichlari: ma'lum bir vaqt yoki foydalanuvchining ishdan chiqishida biznes qancha pul topishi. Bizning yangi versiyamiz uchun ushbu ko'rsatkichlar muhandislar qo'shganidan muhimroq bo'lishi mumkin.

Eng mashhur monitoring tizimlarida ko'rsatkichlarga misollar.

Hisoblagich. Bu ba'zi ortib borayotgan qiymat, masalan, xatolar soni. Ushbu ko'rsatkichni interpolyatsiya qilish va diagrammani o'rganish oson: kecha 2 ta xatolik bor edi, bugun esa 500, ya'ni nimadir noto'g'ri ketdi.

Bir daqiqada yoki soniyada xatolar soni hisoblagich yordamida hisoblanishi mumkin bo'lgan eng muhim ko'rsatkichdir. Ushbu ma'lumotlar tizimning masofadan turib qanday ishlashi haqida aniq tasavvur beradi. Ishlab chiqarish tizimining ikkita versiyasi uchun soniyada xatolar sonining grafigi misolini ko'rib chiqing.

Birinchi versiyada bir nechta xatolar bor edi, ehtimol audit ishlamadi. Ikkinchi versiyada hamma narsa ancha yomonroq. Muammolar borligini aniq aytishimiz mumkin, shuning uchun biz ushbu versiyani orqaga qaytarishimiz kerak.

O'lchov. Ko'rsatkichlar Counter-ga o'xshaydi, lekin biz ko'payishi yoki kamayishi mumkin bo'lgan qiymatlarni yozamiz. Masalan, so'rovni bajarish vaqti yoki navbat hajmi.

Grafikda kechikish misoli ko'rsatilgan. Grafik versiyalar o'xshashligini ko'rsatadi, siz ular bilan ishlashingiz mumkin. Ammo diqqat bilan qarasangiz, qiymat qanday o'zgarishini ko'rishingiz mumkin. Agar foydalanuvchilar qo'shilganda so'rovni bajarish vaqti oshsa, u holda muammolar mavjudligi darhol aniq bo'ladi - ilgari bunday emas edi.

Xulosa. Biznes uchun eng muhim ko'rsatkichlardan biri bu foizlardir. Ko'rsatkich shuni ko'rsatadi 95% hollarda tizimimiz biz xohlagancha ishlaydi. Agar biror joyda muammolar bo'lsa, qabul qilishimiz mumkin, chunki biz umumiy tendentsiyani tushunamiz, hamma narsa qanchalik yaxshi yoki yomon.

asboblar

ELK Stack. Siz Elasticsearch yordamida kanareykalarni qo'llashingiz mumkin - voqealar sodir bo'lganda unga xatolar yozamiz. Eng oddiy API chaqiruvi yordamida siz istalgan vaqtda xatolar sonini olishingiz va oldingi segmentlar bilan solishtirishingiz mumkin: GET /applg/_cunt?q=level:errr.

Prometey. U Infobipda o'zini yaxshi ko'rsatdi. Bu sizga ko'p o'lchovli ko'rsatkichlarni amalga oshirish imkonini beradi, chunki teglar ishlatiladi.

Biz foydalanishimiz mumkin level, instance, service, ularni bir tizimda birlashtiring. Yordam bilan offset siz, masalan, bir hafta oldingi qiymatning qiymatini faqat bitta buyruq bilan ko'rishingiz mumkin GET /api/v1/query?query={query}qayerda {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

Versiya tahlili

Bir nechta versiya strategiyalari mavjud.

Faqat kanareyka tugunlarining ko'rsatkichlarini ko'ring. Eng oddiy variantlardan biri: yangi versiyani joylashtirish va faqat ishni o'rganish. Ammo agar muhandis bu vaqtda sahifalarni asabiy ravishda qayta yuklagan holda jurnallarni o'rganishni boshlasa, unda bu yechim boshqalardan farq qilmaydi.

Kanar tugun boshqa har qanday tugun bilan taqqoslanadi. Bu to'liq trafikda ishlaydigan boshqa misollar bilan taqqoslash. Misol uchun, agar kichik trafik bilan ishlar yomonroq bo'lsa yoki haqiqiy misollardan yaxshiroq bo'lmasa, unda biror narsa noto'g'ri.

Kanareyka tuguni o'tmishda o'zi bilan taqqoslanadi. Kanareykaga ajratilgan tugunlarni tarixiy ma'lumotlar bilan solishtirish mumkin. Misol uchun, agar bir hafta oldin hamma narsa yaxshi bo'lsa, hozirgi vaziyatni tushunish uchun biz ushbu ma'lumotlarga e'tibor qaratishimiz mumkin.

Avtomatlashtirish

Biz muhandislarni qo‘lda taqqoslashdan ozod qilmoqchimiz, shuning uchun avtomatlashtirishni amalga oshirish muhim. O'rnatish quvuri odatda quyidagicha ko'rinadi:

• boshlaymiz;
• balanslashtiruvchi ostidagi tugunni olib tashlang;
• kanareyka tugunini o'rnatish;
• cheklangan miqdordagi trafik bilan balanserni yoqing;
• solishtiring.

Ushbu bosqichda biz amalga oshiramiz avtomatik taqqoslash. Bu qanday ko'rinishi mumkin va nima uchun bu joylashtirishdan keyin tekshirishdan ko'ra yaxshiroq, keling, Jenkins misolini ko'rib chiqaylik.

Bu Groovyga boradigan quvur.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

Bu erda tsiklda biz yangi tugunni bir soat davomida solishtiramiz. Agar kanareyka jarayoni jarayonni hali tugatmagan bo'lsa, biz funktsiyani chaqiramiz. U hamma narsa yaxshi yoki yo'qligini aytadi: def isOk = compare(srv, canary, time, base, offset, metrics).

Agar hammasi yaxshi bo'lsa - sleep DEFAULT SLEEP, masalan, bir soniya va davom eting. Agar yo'q bo'lsa, chiqing - tarqatish muvaffaqiyatsiz tugadi.

Ko'rsatkich tavsifi. Keling, funktsiya qanday ko'rinishini ko'rib chiqaylik compare DSL misolida.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

Aytaylik, biz xatolar sonini solishtiramiz va biz oxirgi 5 daqiqada soniyada xatolik sonini bilmoqchimiz.

Bizda ikkita qiymat bor: tayanch va kanareyka tugunlari. Kanareyka tugunining qiymati joriy hisoblanadi. Asosiy - baseValue har qanday boshqa kanar bo'lmagan tugunning qiymati. Biz qadriyatlarni o'z tajribamiz va kuzatishlarimiz asosida o'rnatgan formula bo'yicha bir-birimiz bilan taqqoslaymiz. Qiymat bo'lsa canaryValue yomon, keyin joylashtirish muvaffaqiyatsiz tugadi va biz orqaga qaytamiz.

Bularning barchasi nima uchun kerak?

Bir kishi yuzlab va minglab ko'rsatkichlarni tekshira olmaydiayniqsa, buni tezda bajarish uchun. Avtomatik taqqoslash barcha ko'rsatkichlarni tekshirishga yordam beradi va muammolarni tezda xabardor qiladi. Ogohlantirish vaqti juda muhim: agar oxirgi 2 soniya ichida biror narsa yuz bergan bo'lsa, zarar 15 daqiqa oldin sodir bo'lgandek katta bo'lmaydi. Kimdir muammoni sezmaguncha, qo'llab-quvvatlash xizmatiga yozmaguncha va orqaga qaytish uchun bizga yordam bermaguncha, siz mijozlarni yo'qotishingiz mumkin.

Agar jarayon o'tgan bo'lsa va hamma narsa yaxshi bo'lsa, biz boshqa barcha tugunlarni avtomatik ravishda joylashtiramiz. Bu vaqt ichida muhandislar hech narsa qilmaydi. Faqat kanareykani ishga tushirganda, ular qanday ko'rsatkichlarni olish kerakligini, qancha vaqt davomida taqqoslashni va qanday strategiyani qo'llashni hal qilishadi.

Muammolar mavjud bo'lsa, biz kanareyka tugunini avtomatik ravishda orqaga qaytaramiz, oldingi versiyalar ustida ishlaymiz va topilgan xatolarni tuzatamiz. Ko'rsatkichlarga ko'ra, ularni topish va yangi versiyadagi zararni ko'rish oson.

To'siqlar

Albatta, buni amalga oshirish oson emas. Avvalo, sizga kerak umumiy monitoring tizimi. Muhandislarning o'z ko'rsatkichlari bor, qo'llab-quvvatlash va tahlilchilar turli ko'rsatkichlarga ega, korxonalar esa uchinchisiga ega. Umumiy tizim biznes va rivojlanishning umumiy tilidir.

Amalda sinab ko'rish kerak metrik barqarorlik. Tekshirish tushunishga yordam beradi sifatni ta'minlash uchun zarur bo'lgan minimal ko'rsatkichlar to'plami nima.

Bunga qanday erishish mumkin? O'rnatish vaqtida emas, kanareyka xizmatidan foydalaning. Biz eski versiyaga ma'lum bir xizmatni qo'shamiz, u istalgan vaqtda istalgan ajratilgan tugunni qabul qilishi, tarqatmasdan trafikni kamaytirishi mumkin. Taqqoslaganimizdan so'ng: biz xatolarni o'rganamiz va sifatga erishganimizda o'sha chiziqni qidiramiz.

Biz kanareykalarning relizlaridan qanday foyda oldik?

Xatolardan zararlanish foizi minimallashtirildi. O'rnatish xatolarining aksariyati ba'zi ma'lumotlar yoki ustuvorlikdagi nomuvofiqliklarga bog'liq. Bunday xatolar ancha kam, chunki biz muammoni birinchi soniyalarda hal qila olamiz.

Optimallashtirilgan jamoaviy ish. Yangi boshlanuvchilar "xato qilish huquqiga" ega: ular xato qilishdan qo'rqmasdan ishlab chiqarishga o'tishlari mumkin, qo'shimcha tashabbus, ishlashga rag'bat mavjud. Agar biror narsani sindirishsa, u tanqidiy bo'lmaydi va xato qilgan kishi ishdan bo'shatilmaydi.

Avtomatlashtirilgan joylashtirish. Bu avvalgidek qo'lda bajariladigan jarayon emas, balki haqiqiy avtomatlashtirilgan jarayon. Ammo bu ko'proq vaqt talab etadi.

Ta'kidlangan muhim ko'rsatkichlar. Biznes va muhandislardan boshlab butun kompaniya mahsulotimizda nima muhimligini, qanday ko'rsatkichlarni, masalan, foydalanuvchilar oqimi va oqimini tushunadi. Biz jarayonni nazorat qilamiz: ko'rsatkichlarni sinovdan o'tkazamiz, yangilarini kiritamiz, samaraliroq daromad keltiradigan tizimni yaratish uchun eskilari qanchalik ishlashini ko'ramiz.

Bizga yordam beradigan juda ko'p ajoyib amaliyot va tizimlar mavjud. Shunga qaramay, bizda yordam beradigan tizim bormi yoki yo'qligidan qat'i nazar, biz professional bo'lishga va o'z ishimizni yaxshi bajarishga intilamiz.

Muhandislik yondashuvlari va amaliyotlari - TechLead Conf-ning asosiy yo'nalishi. Agar siz texnik mukammallikka erishish yo'lida muvaffaqiyatga erishgan bo'lsangiz va bunda sizga nima yordam berganini aytib berishga tayyor bo'lsangiz, - hisobot uchun ariza berish.

Biz rejalashtirmoqdamiz Tech Lead Conf 8-iyun. Hozir konferentsiyada ishtirok etish borasida qaror qabul qilish qiyinligini tushunamiz. Shu bilan birga, biz karantin professional muloqot va rivojlanishni to'xtatish uchun sabab emas deb hisoblaymiz. Shuning uchun, har qanday holatda, biz texnik rahbarning vazifalari va ularni hal qilish usullarini muhokama qilish yo'lini topamiz - agar kerak bo'lsa, biz Internetga o'tamiz va u erda tarmoqni o'rnatamiz!

Manba: www.habr.com