Canary deployment — yangi dastur versiyasini avval foydalanuvchi yoki trafikning kichik qismiga chiqarib, real muhitdagi natijalar asosida rolloutni kengaytirish usulidir. Nomi shaxtadagi xavfni erta sezish uchun ishlatilgan canary qushidan olingan. Maqsad nuqsonning ta’sir doirasini cheklab, production signalini olishdir.
Canary guruhini tanlash
Trafik tasodifiy foiz, ichki xodim, ma’lum tenant, hudud yoki qurilma bo‘yicha ajratilishi mumkin. Tasodifiy taqsimot umumiy ko‘rsatkichni solishtirishga qulay, ammo juda kichik guruh kam uchraydigan xatoni ko‘rsatmasligi mumkin. Yuqori riskli mijozlar birinchi guruhga tasodifan tushmasligi uchun biznes cheklovi qo‘llanadi.
Session davomida foydalanuvchi versiyalar orasida sakramasligi kerak bo‘lsa sticky routing ishlatiladi. Stateful protocol, WebSocket va background job uchun oddiy HTTP foizi yetarli emas; workloadning routing birligi aniq belgilanadi.
Nazorat guruhi
Canary natijasi eski stable versiya bilan bir vaqt va o‘xshash trafikda solishtiriladi. Faqat “error 1 foiz” qiymati normal baseline 0,1 yoki 2 foiz ekanini aytmaydi. Control va canary o‘rtasidagi request mix, region va instance resursi farqi hisobga olinadi.
Deploymentdan oldin observability dashboard va querylar tayyorlanadi. Version label metric, log va tracega qo‘shiladi. Aks holda xato qaysi releasega tegishli ekanini ajratish qiyin.
Tahlil mezonlari
Error rate, p95/p99 latency, CPU, memory va restart texnik signallardir. Conversion, payment success yoki user abandonment biznes regressiyasini ko‘rsatadi. Guardrail metric xavfsizlik va umumiy xizmat sog‘ligini, primary metric esa o‘zgarish maqsadini baholaydi.
Threshold, observation window va minimal sample size rolloutdan oldin belgilanadi. Bir necha daqiqalik yaxshi natija memory leakni ko‘rsatmasligi mumkin. Juda uzoq kutish esa deliveryni sekinlashtiradi. Xavf va trafik hajmiga mos bosqichlar tanlanadi.
Kengaytirish va to‘xtatish
Canary muvaffaqiyatli bo‘lsa trafik 1, 5, 25, 50 va 100 foiz kabi bosqichlarda oshirilishi mumkin. Har bosqichda yangi kuzatuv oynasi boshlanadi. Progressive delivery controller analysis natijasi asosida avtomatik promote yoki abort qilishi mumkin.
Mezon buzilsa canaryga yangi trafik to‘xtatiladi va stable versiyaga qaytariladi. Rollback database migration, queue message yoki tashqi side effectni bekor qilmasligi mumkin. Forward fix yoki kompensatsiya rejasi zarur.
Cheklovlar
Canary barcha xatoni topmaydi. Schema incompatibility eski va yangi instance parallel ishlaganda darhol namoyon bo‘lishi mumkin. Rare workflow kichik guruhga tushmasligi, background migration esa butun databasega ta’sir qilishi mumkin. Pre-production testlar baribir talab qilinadi.
Bir canary instance boshqa hardware yoki nodega tushsa natija versiya emas, infratuzilma farqini aks ettiradi. Placement va resource configuration taqqoslanadigan bo‘lishi kerak.
Database va queue
Canary bir xil databasega yozsa yangi schema eski stable versiya bilan mos bo‘lishi kerak. Queue consumerlarda xabar bir canaryga tasodifiy tushishi foizli HTTP trafikdan farq qiladi. Consumer group partition assignmenti canaryga katta yoki kichik ulush berishi mumkin. Message version va dead-letter natijasi alohida kuzatiladi.
Cache ta’siri
Canary yangi cache key yoki serialization formatidan foydalansa stable instance uni o‘qiy olmasligi mumkin. Shared cachedagi warming farqi latency taqqoslashni buzadi. Versionlangan key va bir xil warm-up oynasi ishlatiladi. Cache hit ratio release labeli bo‘yicha o‘lchanadi.
Statistik xatolar
Ko‘p metricni bir vaqtda kuzatish tasodifiy false alarm ehtimolini oshiradi. Primary va guardrail mezonlar oldindan tanlanadi. Past trafikda confidence yetarli bo‘lmasa manual judgment cheklovi hisobotda ko‘rsatiladi; “xato ko‘rinmadi” muvaffaqiyatning kuchli dalili emas.
Bog‘liq tushunchalar
Progressive delivery, Traffic splitting, Rollout, Rollback, Feature flag, Control group, Observability