Yeni bir politika kuralı yazdınız. Örnek isteklerde beklediğiniz sonucu veriyor. Sıradaki soru, kuralın doğru görünmesi değil; gerçek trafikle karşılaştığında hangi davranışları değiştireceği.
Shadow mod bu soruyu, kullanıcıya uygulanan kararı değiştirmeden araştırma imkânı verir. Mevcut karar işlemeye devam ederken aday politika da değerlendirilir. İki karar arasındaki fark, devreye alma kararının girdisi olur.
Önce beklenen farkı tarif edin
Bir maskeleme kuralı ekliyorsanız mevcut davranışla tamamen aynı sonuç beklemiyorsunuz. Bazı isteklerde yeni bir yükümlülük doğması, değişikliğin amacı. Bu yüzden "eski ve yeni karar aynı mı?" sorusunun yanına "fark beklediğimiz isteklerde mi oluştu?" sorusunu koymak gerekir.
Kuralı çalıştırmadan önce kısa bir kabul tablosu yazın:
| İstek grubu | Beklenen değişiklik | İncelenecek kanıt |
|---|---|---|
| Hedef veri türü bulunan istek | Maskeleme yükümlülüğü eklenir | Tespit sinyali ve yükümlülük |
| Hedef veri bulunmayan istek | Rota aynı kalır | Önceki ve aday karar |
| Tarayıcı sonucu bulunmayan istek | Belirlenmiş hata davranışı uygulanır | Sinyalin kullanılabilirlik durumu |
Bu tablo bir ürün yapılandırması değil, test planıdır. Ekiplerin aynı sonucu farklı yorumlamasını önler.
Ayrışmaları etkilerine göre ayırın
Bir modelin değişmesi ile bir isteğin reddedilmesi aynı etkiyi yaratmaz. Maskelemenin eklenmesi, önbelleğin kapanması ve aday havuzunun daralması da ayrı ayrı incelenmeli.
Modelion'da karar birden fazla eksende konuşur. Shadow incelemesinde yalnızca son model adına bakmak, bu değişikliklerin bir kısmını görünmez bırakır. Sonuç aynı modele gitse bile gönderilen metin veya uygulanacak yükümlülük değişmiş olabilir.
İnceleme kuyruğunu önce reddetmeler ve kısıt ihlalleri, sonra rota değişiklikleri, ardından diğer yükümlülükler şeklinde düzenlemek iyi bir başlangıçtır. Her farkın beklenen davranışla ilişkisini kaydedin.
Trafiğin hangi kısmını görmediğinizi bilin
Test penceresinde gece trafiği yoksa mesai dışı bir kural hakkında yeterli veri toplamamış olabilirsiniz. Aynı durum az kullanılan bir model, yeni bir prompt sürümü veya seyrek çalışan bir ekip için de geçerli.
Genel uyum oranının yanında organizasyon, sanal anahtar, prompt sürümü ve istek türü bazında dağılıma bakın. Örnek sayısı çok az olan grupları "sorunsuz" olarak işaretlemek yerine ayrıca belirtin. Sıfır hata, bazen yalnızca sıfır örnek demektir.
Kararın maliyetini de ölçün
Mantıksal doğruluk, çalışma maliyetini açıklamaz. Aynı sonucu üreten iki kuralın değerlendirme süreleri farklı olabilir. Modelion'un yayınlama aşamasındaki değerlendirme maliyeti kontrolü ile trafik üzerindeki shadow incelemesi farklı soruları yanıtlar; ikisine de ihtiyaç vardır.
OPA da politika performansının gerçek girdilerle ölçülmesini ve karşılaştırmalı testlerle izlenmesini önerir. OPA politika performansı dokümanı.
Devreye almadan önce geri dönüşü yazın
Hangi sürümün uygulanacağını, kimlerin ayrışmaları inceleyeceğini ve hangi durumda önceki sürüme dönüleceğini belirleyin. "Sorun olursa bakarız" yerine somut bir koşul kullanın: beklenmeyen reddetmeler, kritik bir grubun kapsam dışında kalması veya değerlendirme maliyetinde açıklanamayan artış.
Shadow mod bir onay damgası değildir. Gerçek isteklerden öğrenilen, sınırları belli bir denemedir. Son karar, bu denemenin hangi davranış değişikliğini gösterdiğine dayanmalı.
