Canary — yangi dasturiy versionni barcha foydalanuvchiga birdan tarqatmasdan, avval kichik traffic yoki instance guruhida ishga tushirib kuzatish usuli. To‘liq atama canary deployment yoki canary release. Maqsad productiondagi muammoni kichik ta’sir doirasida aniqlashdir.
Nom tarixan xavfli gazni erta sezish uchun konlarda ishlatilgan kanareykaga qiyoslanadi.
Asosiy g‘oya
Productionda bir vaqtning o‘zida:
- stable version;
- canary version
ishlaydi.
Trafficning masalan 1% qismi canaryga yuboriladi.
Metriclar yaxshi bo‘lsa ulush bosqichma-bosqich oshiriladi.
Muammo topilsa traffic stable versionga qaytariladi.
Rollout bosqichlari
Oddiy rollout:
internal
→ 1%
→ 5%
→ 25%
→ 50%
→ 100%
Har bosqich orasida kuzatuv va minimal vaqt bo‘ladi.
Traffic hajmi juda kam bo‘lsa statistik xulosa uchun event yetarli bo‘lmasligi mumkin.
Traffic routing
Routing quyidagilar orqali bajarilishi mumkin:
- load balancer;
- service mesh;
- ingress;
- API gateway;
- feature flag;
- CDN;
- application router.
Rule request percentage, header, cookie, account yoki regionga tayanishi mumkin.
Random canary
Requestlarning tasodifiy foizi yangi versionga boradi.
Sodda va umumiy metric uchun qulay.
Biroq ayni user ketma-ket ikki versionga tushishi mumkin.
Session state va UI consistency muammosi yuz beradi.
Cohort canary
Ma’lum user yoki tenant guruhi doim canary versionga tushadi.
Masalan:
Bu user tajribasini izchil saqlaydi.
Cohort representative bo‘lishi kerak.
Instance canary
Yangi version kam sonli instance’da ishlaydi.
Load balancer traffic beradi.
Agar request stateless bo‘lsa sodda.
Shared database va queue sabab canaryning side effectlari stable versionga ta’sir qilishi mumkin.
Metric
Kuzatiladi:
- error rate;
- latency;
- saturation;
- CPU;
- memory;
- restart;
- conversion;
- payment success;
- complaint;
- data consistency.
Faqat infrastructure metric yetarli emas.
Business metric regressiyasi ham muhim.
Baseline comparison
Canary metriclari ayni vaqtdagi stable version bilan solishtiriladi.
Bu traffic, kun va tashqi servisdagi umumiy o‘zgarishlarni ajratishga yordam beradi.
Kecha bilan bugunni solishtirish seasonality sabab noto‘g‘ri bo‘lishi mumkin.
Automated analysis
Deployment platform threshold va statistik qoidalar asosida rolloutni davom ettirishi yoki to‘xtatishi mumkin.
Masalan:
error rate canary > stable + limit
bo‘lsa rollback.
False positive va false negative ehtimoli hisobga olinadi.
Rollback
Canary yomon bo‘lsa yangi instance o‘chirilib, traffic stablega qaytariladi.
Rollback tez bo‘lishi kerak.
Database migration backward-compatible bo‘lmasa oldingi code ishlamasligi mumkin.
Shuning uchun schema o‘zgarishi expand-migrate-contract usulida bajariladi.
Database
Stable va canary bir database’dan foydalansa schema ikkala versionga mos bo‘ladi.
Avval yangi nullable column qo‘shiladi.
Keyin code ikki formatni qo‘llaydi.
Barcha instance yangilangandan keyin eski column olib tashlanadi.
Queue va event
Canary yangi event format yuborsa stable consumer uni tushunmasligi mumkin.
Event versioni va backward compatibility kerak.
Bir message’ni ikki version qayta ishlamasligi uchun routing aniq bo‘ladi.
Side effect rollbackdan keyin avtomatik bekor bo‘lmaydi.
Stateful service
Session yoki in-memory state bo‘lsa userni bir versionga sticky routing qilish kerak bo‘lishi mumkin.
Distributed state formatlari compatible bo‘ladi.
Stateful database migration canary deploymentni murakkablashtiradi.
Feature flag bilan farqi
Canary code version trafficini ajratadi.
Feature flag ayni version ichida funksiyani yoqadi yoki o‘chiradi.
Ikkalasi birga ishlashi mumkin:
- code avval canary;
- feature internal cohort;
- keyin kengaytirish.
Blue-green bilan farqi
Blue-green ikki to‘liq environment yaratib trafficni bir martada yoki tez almashtiradi.
Canary trafficni bosqichma-bosqich oshiradi.
Canary production signalini erta oladi, blue-green rollbackni sodda qiladi.
Dark launch
Yangi code productionda ishlaydi, ammo userga natija ko‘rsatilmaydi.
Request shadow tarzda yangi service’ga yuborilishi mumkin.
Natija stable output bilan solishtiriladi.
Side effectlar o‘chiriladi.
Duration
Canary juda qisqa bo‘lsa kam uchraydigan bug ko‘rinmaydi.
Juda uzoq bo‘lsa release sekinlashadi.
Davomiylik traffic hajmi, batch job, cron, timezone va business cycle’ga bog‘liq.
Bir kunlik billing jarayoni uchun bir necha minut yetarli emas.
Observability
Canary requestlari version label bilan trace, log va metricda ajratiladi.
Aks holda xato qaysi versionga tegishli ekanini bilib bo‘lmaydi.
Deployment ID, commit va config metadata sifatida saqlanadi.
Blast radius
Canaryning maqsadi ta’sir doirasini cheklash.
Ammo shared database corruption yoki global external request kichik trafficdan ham katta zarar keltirishi mumkin.
High-risk operation uchun sandbox, dry-run yoki approval qo‘shimcha kerak.
Sample size
Canary 1% traffic olsa ham absolyut request soni juda kichik bo‘lishi mumkin. Error rate bo‘yicha qaror minimal event va confidence talabiga ega. Kam trafficli service’da vaqt yoki internal cohort kengaytiriladi.
User tajribasi
Canary user yangi UI’ni ko‘rib, keyingi requestda stable UI’ga qaytsa flow buziladi. Sticky cohort yoki feature flag versionlar orasidagi izchillikni saqlaydi.
Stop condition
Rolloutdan oldin aniq shart belgilanadi: qaysi metricda to‘xtaydi, kim qaror beradi va rollback qancha vaqtda bajariladi. Incident paytida yangi qoidani o‘ylab topish kech bo‘ladi.
Bog‘liq tushunchalar
Canary deployment, Progressive delivery, Traffic splitting, Rollout, Rollback, Feature flag, Blue-green deployment, Observability, Deployment strategy, Production testing