Canary deployment, dokuz saatlik mutabakat verisini bozan bir sürümü onayladı

Ne oldu

Sergey Shinder'ın dev.to'da yayınladığı bir postmortem'e göre, güçlü bir sicile sahip bir canary deployment sistemi, üretim verisini sessizce bozan bir sürümü onayladı. Kurulum sağlam görünüyordu: trafiğin yüzde beşi on beş dakika boyunca canary pod'larına yönlendiriliyor, hata oranı ve p95 gecikmesi baseline pod'larıyla otomatik olarak karşılaştırılıyor ve insan müdahalesi olmadan sürüm yayına alınıyor ya da geri alınıyordu. Altı ay boyunca dört hatalı sürümü reddetmişti. Sonra gece mutabakat işinin dokuz saatini bozan bir değişikliği geniş marjlarla geçiştirdi.

Canary neden hatayı hiç görmedi

Sorunlu sürüm, paylaşımlı bir serializer'ın nullable bir decimal'ı işleme biçimini değiştirmişti. Senkron API bu kod yolunu neredeyse hiç kullanmıyordu. Bu yolu sürekli kullanan iş yükü, mutabakat topic'ini 01:00'de boşaltan batch consumer'dı. Canary, 14:30'da HTTP trafiğinin tekdüze rastgele bir örneği üzerinde çalıştığı için on beş dakikasını, değişikliğin hiç dokunmadığı bir kod yolunu ölçerek geçirdi.

Canary'nin hatayı yakalayamamasının yapısal bir nedeni de vardı: canary pod'ları bilinçli olarak Kafka consumer grubunun dışında tutuluyordu. Bu dışlama, analiz sırasında yinelenen işlemeyi önlemek için erken aşamada eklenmişti; Shinder bunu o dönem için makul bir tercih olarak nitelendiriyor, ancak bu durum sistemin asenkron yarısının kapıya yapısal olarak görünmez olması anlamına geliyordu. Sürüm, fiilen hizmetin yaptığı işin kabaca üçte biri üzerinden değerlendirilmişti.

İnceleme iki kör nokta daha ortaya çıkardı. Otomatik analiz yalnızca HTTP durum kodlarına ve gecikmeye bakıyordu; yapılan işin doğru olup olmadığına dair hiçbir ölçüt yoktu — yanlış rakamlarla 200 yanıtları döndüren bir servis kusursuz puan alırdı. Ayrıca sistemin sıra dışı payload'larının çoğu tek bir kurumsal müşteriden geliyordu ve on beş dakikalık bir pencerede alınan tekdüze bir örnek bu trafiği neredeyse hiç içermiyordu.

Ekip neleri değiştirdi

Düzeltme çalışması her boşluğu doğrudan ele alıyor. Canary pod'ları artık Kafka consumer grubuna küçük ve sınırlı bir partition payıyla katılıyor; böylece asenkron iş de analize dahil ediliyor. Orijinal dışlamaya neden olan yinelenen işleme riski, consumer'ları dışlamak yerine idempotent hale getirerek çözülüyor.

Batch iş, önceki gecenin mesajlarını canary üzerinde yeniden oynatan ve çıktıyı baseline ile karşılaştıran bir shadow mode kazandı. Bu yeniden oynatma dokuz dakikada tamamlanıyor ve artık bir release gate olarak hizmet veriyor. Otomatik analiz, işletme metrikleriyle — üretilen mutabakatlar, eşleşen toplamlar, reddedilen kayıtlar — genişletildi; böylece yalnızca erişilebilirlik ve hız değil, doğruluk da ölçülüyor. Son olarak, kurumsal müşterinin gerçek payload biçimleri modellenerek oluşturulmuş bir dizi sentetik istek her sürümde canary'ye gönderiliyor; böylece en nadir giriş desenleri de temsil ediliyor.

Neden önemli

Postmortem'in temel dersi şu: bir canary yalnızca gerçekte aldığı trafiği değerlendirebilir. Bir sürüm, canary'nin erişemediği bir kod yolunu değiştiriyorsa — bir async consumer, zamanlanmış bir batch iş, nadir bir payload biçimi — yeşil karar o yolun onayı değildir; onay kılığına girmiş bir çekimserliktir.

Birçok üretim servisi senkron API'ler ile mesaj odaklı iş yüklerinin melezidir ve HTTP metrikleri etrafında kurulmuş canary araçları tam olarak bu kör noktayı miras alır. Sessiz veri bozulması ayrıca durum kodu ve gecikme panellerinin yakalamaya en az hazır olduğu hata sınıfıdır: temeldeki rakamlar yanlışken her sinyal sağlıklı görünür. Progressive delivery yürüten her ekip için pratik çıkarımlar şunlardır: canary'leri consumer grupları dahil tüm trafik yollarına katılmalarını sağlamak ve operasyonel metrikleri shadow replay ve işletme düzeyinde karşılaştırmalar gibi çıktı doğrulamasıyla eşleştirmek.