Burada ne görüyorsunuz

Saniyede altı yüz request, kullanıcılardan ağırlıklı bir router üzerinden akıyor. Deploy ettiğinde v2 tek bir pod’da başlıyor ve trafiğin %1’ini alıyor; her adım birkaç saniye bekletiliyor, bir analiz çalışması onu izliyor, sonra ağırlık artıyor — %5, %25, %50, %100 — ve canary büyüdükçe stable pod’lar küçülüyor. Bu, dakikalardan saniyelere sıkıştırılmış bir Argo Rollouts ya da Flagger canary’sinin şekli.

Ham hata oranı değil, burn rate

Analiz error budget dilinde konuşuyor. %99.5 başarı SLO’suyla request’lerin %0.5’inin başarısız olmasına izin var; 10×’lik bir burn rate, v2’nin bu bütçeyi on kat hızlı harcadığı anlamına geliyor. Rollout hızlı bir burn’de (son 10 sn’de >10×), yavaş bir burn’de (v2’nin sunduğu her şeyde >2×) ya da v2’nin p95’i stable sürümün 1.25 katını aştığında duruyor. Çok az veriyle karar vermeyi de reddediyor: trafiğin %1’inde ilk karar çoğu zaman “belirsiz” — bu dürüst bir cevap, otuz request %0.1 ile %1.5’i ayırt edemez.

Sinsi bug neden daha ileri gidiyor

500’ler bug’ını eklersen hızlı burn alarmı ilk ya da ikinci adımda tetikleniyor; hatayı sadece bir avuç kullanıcı görüyor. Sinsi bug’ı eklersen genelde %1’den rahatça geçiyor — örnek çok küçük — ve bir iki adım sonra yavaş burn penceresine takılıyor. Canary’nin gerçek trade-off’u bu: küçük ilk adımlar etki alanını sınırlıyor ama ne kadar şey öğrenebileceğini de sınırlıyor; bu yüzden iyi rollout’lar onları uzun pencereli kontrollerle eşleştirir.

Karşılaştırma için blue/green

Stratejiyi blue/green’e çevir: yeni sürüm boştaki bir ortamda ayağa kalkıyor, smoke test’lerinden geçiyor (neredeyse hep geçer) ve router trafiğin %100’ünü bir anda çeviriyor. Rollback anında — geri çevirmen yeterli — ama analiz karar verene kadar her kullanıcı yeni sürüme maruz kalmış oluyor. Aynı bug ile iki stratejide v2’de hata sayacını karşılaştır. Buradaki bütün sayılar simülasyon; eşikler yaygın SRE çok pencereli burn rate alarmlarını yansıtıyor.