Sağlayıcı sürüm değişimi, en az izlenen üretim riski

Tez#

Yazılım ekipleri değişiklik riskini yönetmek için olgun bir düzen kurdu: her değişiklik bir gözden geçirmeden geçiyor, testler koşuyor, aşamalı yayım yapılıyor, geri alma yolu hazır tutuluyor. Bu düzenin dayandığı varsayım, değişikliklerin ekibin kontrolünde olması.

Dil modeli kullanan bir sistemde bu varsayım kısmen geçersiz. Sistemin davranışını en çok belirleyen bileşen dışarıda ve o bileşen sizden izin almadan değişiyor. Bir sağlayıcı aynı sürüm etiketi altında bir güncelleme yapabiliyor, bir güvenlik ayarını sıkılaştırabiliyor, bir sürümü kullanımdan kaldırma takvimine alabiliyor. Bu değişikliklerin hiçbiri sizin dağıtım hattınızdan geçmiyor; dolayısıyla test kapılarınız devreye girmiyor. Sonuç, kendi kodunda hiçbir değişiklik yapmamış bir ekibin bir sabah farklı davranan bir ürünle karşılaşması.

Bağlam: dört değişim türü#

Sağlayıcı tarafındaki değişiklikler tek bir türde değil ve her biri farklı bir hazırlık gerektiriyor.

Dördüncü satırın pratik hâli şöyle: bir sağlayıcı belirli bir konudaki hassasiyeti artırıyor ve sizin ürününüzde o konuyla ilgili meşru sorular reddedilmeye başlıyor. Sistem hata vermiyor, çökmüyor, gecikmiyor — yalnızca bazı kullanıcılar cevap alamıyor. Teknik panolarda hiçbir şey kırmızıya dönmüyor; sorun ancak kullanıcı şikâyetiyle ya da ret oranı ayrıca izleniyorsa fark ediliyor.

Kanıt: değişimi yakalayan asgari düzen#

Bu riski yönetmek yeni bir altyapı gerektirmiyor; var olan değerlendirme setinin farklı bir tetikleyiciyle koşmasını gerektiriyor.

• Zamanlı regresyon koşusu: değerlendirme seti yalnızca kod değişikliğinde değil, düzenli aralıklarla da koşmalı. Kod değişmediği hâlde skorun düşmesi, sağlayıcı değişiminin imzası.
• Sürüm etiketini sabitleme: mümkün olan her yerde belirli bir sürüm sabitlenmeli; takma ad kullanmak habersiz güncellemeye açık kapı bırakıyor.
• Ret oranı izleme: reddedilen isteklerin oranı bir ölçü olarak panoda bulunmalı. Sessiz sıkılaşmayı yalnızca bu yakalıyor.
• Çıktı biçimi izleme: şema geçme oranı, sürüm değişiminde en hızlı bozulan ölçü.
• Soyutlama katmanı: model çağrısı tek bir yerden geçmeli ki sağlayıcı ya da sürüm değişimi tek noktadan yapılabilsin.
• Göç tatbikatı: alternatif bir modele geçmek ne kadar sürer? Bu soru bir kez denenmeden cevaplanamıyor.
• Sürüm kayıt defteri: hangi tarihte hangi sürüm kullanıldı? Bir davranış değişimini tarihlendirmenin tek yolu.

Birinci madde bu listenin en yüksek getirili tek adımı. Değerlendirme seti çoğu ekipte yalnızca kod değişikliğinde koşuyor; oysa sağlayıcı değişimi kod değişikliği olmadan geliyor. Aynı seti günlük ya da haftalık koşmak ek bir set kurmayı gerektirmiyor, yalnızca tetikleyiciyi değiştiriyor — ve kod değişmeden düşen bir skor, doğrudan sağlayıcı tarafına işaret ediyor.

Mekanizma: neden fark edilmiyor#

Bu riskin izlenmemesinin nedeni panoların yanlış kurulmuş olması değil; panoların doğru ama eksik kurulmuş olması. Klasik izleme, hata ve gecikme üzerine kurulu.

Sağlayıcı değişimi ise genellikle ne hata ne gecikme üretiyor. Model çalışıyor, hızlı cevap veriyor, biçim doğru — yalnızca cevabın içeriği farklı. Bu, klasik izlemenin göremediği bir bozulma sınıfı: hizmet sağlıklı, çıktı değişmiş. İkinci neden, değişimin etkisinin dağınık olması: bozulma tüm isteklerde değil belirli bir alt kümede görünüyor ve toplam ölçüler bunu seyreltiyor. Üçüncü neden atıf zorluğu: bir kalite şikâyeti geldiğinde ekibin ilk baktığı yer kendi son değişiklikleri oluyor ve kendi tarafında bir değişiklik bulamadığında şikâyet genellikle tek seferlik sayılıyor. Sürüm kayıt defteri olmadığında bu şikâyetleri bir tarihle eşleştirmek de mümkün olmuyor.

Karşı görüş#

Üç itiraz var. Birincisi: sağlayıcılar sabit sürümler sunuyor; sürümü sabitleyen bir ekip bu riskten korunuyor. İkincisi: günlük regresyon koşusu maliyetli ve çoğu ekip için gereksiz. Üçüncüsü: sağlayıcı güncellemeleri genellikle iyileştirme; kaygı abartılı.

Sürümü sabitlemiştik ve güvendeyiz sanıyorduk. Sonra o sürümün kullanımdan kaldırma takvimi geldi ve üç ay içinde geçiş yapmamız gerekti. Soyutlama katmanımız yoktu; geçiş altı hafta sürdü.

Birinci itiraz kısmen doğru ve alıntı sınırını gösteriyor: sürüm sabitlemek habersiz güncellemeye karşı koruyor ama kullanımdan kaldırmaya karşı korumuyor. Sabit sürüm süresiz değil; her sabitleme bir gün zorunlu bir göçe dönüşüyor. İkinci itiraz haklı ve ölçek küçültülebilir: günlük değil haftalık, tam set değil küçük bir alt küme yeterli — kritik olan tetikleyicinin kod değişikliğinden bağımsız olması. Üçüncü itiraz genel olarak doğru ama yönü önemsiz: bir güncelleme genel kaliteyi yükseltirken sizin belirli akışınızı bozabiliyor, çünkü sizin akışınız modelin belirli bir davranış örüntüsüne dayanıyor. İyileşme ile uyumluluk farklı şeyler.

Sınırlar ve belirsizlik#

Bu analiz belirli sağlayıcıların politikalarına dair iddia taşımıyor.

• Sağlayıcı politikaları farklı: sürüm sabitleme ve bildirim süreleri sağlayıcıya ve plana göre değişiyor.
• Habersiz değişimin sıklığı ölçülemiyor: kurum dışından bu sıklığı belirlemenin bir yolu yok.
• Regresyon koşusunun maliyeti sete bağlı: büyük setlerde düzenli koşu kayda değer bir maliyet üretiyor.
• Soyutlama katmanının kapsamı tartışmalı: fazla soyutlama sağlayıcıya özgü yeteneklerden yararlanmayı engelliyor.

Sonuç#

Kendi kodunun her satırını test eden bir ekip, sisteminin en belirleyici bileşenini hiç test etmeden bırakabiliyor. Sağlayıcı değişimi dağıtım hattından geçmediği için hiçbir kapıda yakalanmıyor ve klasik izleme onu göremiyor — çünkü hizmet sağlıklı, yalnızca çıktı değişmiş.

Düzeltmenin en yüksek getirili adımı yeni bir sistem kurmak değil: var olan değerlendirme setini kod değişikliğinden bağımsız bir tetikleyiciyle koşturmak. Kod değişmeden düşen bir skor doğrudan sağlayıcı tarafına işaret ediyor. Buna ret oranı izleme, sürüm kayıt defteri ve bir kez denenmiş bir göç tatbikatı eklendiğinde risk yönetilebilir hâle geliyor. Sürüm sabitlemek ise yeterli değil: her sabitleme bir gün zorunlu bir göçe dönüşüyor.

Ne yapmalı?#

1. 1Değerlendirme setini zamanlı koşturun

   Kod değişmeden düşen skor, sağlayıcı değişiminin imzası. Haftalık ve küçük bir alt küme yeterli.

2. 2Sürümü sabitleyin ama göçü planlayın

   Sabitleme habersiz güncellemeye karşı koruyor, kullanımdan kaldırmaya karşı korumuyor.

3. 3Ret oranını panoya koyun

   İçerik ayarı sıkılaştığında sistem hata vermiyor; yalnızca bazı kullanıcılar cevap alamıyor.

4. 4Şema geçme oranını izleyin

   Yapılandırılmış çıktı, sürüm değişiminde en hızlı bozulan ölçü.

5. 5Model çağrısını tek noktadan geçirin

   Soyutlama katmanı olmadan geçiş haftalar sürüyor; olduğunda saatler.

6. 6Sürüm kayıt defteri tutun

   Hangi tarihte hangi sürüm kullanıldı? Bir davranış değişimini tarihlendirmenin tek yolu.