"Bu istek neden bu modele gitti?" sorusuna bir model adıyla cevap verilemez. O ad yalnızca sonucu gösterir. Asıl soru, başka bir aday varken hangi bilgi ve hangi kuralın bu sonucu doğurduğudur.
Karar izi, incelemeyi tahminden çıkarıp belirli bir isteğin değerlendirilmesine bağlar. Kullanıcıya görünen bir hatayı araştırırken de bir politika değişikliğini incelerken de aynı sıra işe yarar: isteği bul, görülen girdiyi anla, kararı oku, uygulamayı kontrol et.
İstek kimliğiyle başlayın
Önce zaman aralığını ve istek kimliğini sabitleyin. Aynı kullanıcının birkaç saniye içinde yaptığı iki çağrı farklı sinyallere, prompt sürümlerine veya sağlayıcı durumlarına denk gelebilir.
Modelion yanıtındaki Modelion-Request-Id bu eşleştirme için kullanılır. Modelion-Decision ise yanıtla gelen kısa karar özetidir. Özet hızlı incelemeyi destekler; ayrıntılı araştırmada tam iz üzerinden ilerlemek gerekir.
Aşağıdaki liste bir API yanıtı değil, inceleme sırasıdır:
İstek kimliği
→ değerlendirmeye giren sinyaller
→ değerlendirilen politika katmanları
→ eşleşen kurallar ve kazanan karar
→ kalan rota adayları
→ uygulanması gereken yükümlülükler
Sonuçtan önce sinyale bakın
Bir kuralın eşleşmemesi, kuralın yanlış yazıldığı anlamına gelmeyebilir. Beklenen sinyal hiç üretilmemiş, kullanılamaz durumda gelmiş veya farklı bir sınıflandırmayla kaydedilmiş olabilir.
Örneğin "kişisel veri bulunmadı" ile "tarayıcı sonucu yok" aynı durum değildir. İkisini tek bir olumsuz değer olarak yorumlamak, değerlendirme sırasında eksik olan bilgiyi sonradan görünmez kılar.
İnceleme sırasında beklediğiniz sinyali değil, politikanın gerçekten gördüğü sinyali esas alın. Prompt hydration sıralaması gibi bir aşama hatası, kararın kendisi tutarlı olsa bile yanlış sonuca neden olabilir.
Eşleşen her kural kazanmaz
Modelion'un izinde kazanan kuralın yanında eşleşip kaybeden kurallar da incelenebilir. Bu ayrım, "kural devreye girmedi" gibi belirsiz açıklamaları daraltır.
| Gözlem | Sıradaki soru |
|---|---|
| Kural eşleşmedi | Girdi ve koşul beklediğimiz gibi mi? |
| Kural eşleşti ama kazanmadı | Öncelik ve katman birleşimi ne yaptı? |
| Kural kazandı, sonuç beklenmiyor | Rota kısıtları ve yükümlülükler nasıl uygulandı? |
Amaç yalnızca bir kural adı bulmak değildir. Kararın oluştuğu zinciri açıklayabilmektir.
Karar ile yürütmeyi ayırın
Politika bir maskeleme yükümlülüğü ürettiğinde, inceleme yalnızca "redact" etiketini görmekle bitmez. İlgili yürütme kanıtı üzerinden yükümlülüğün uygulanıp uygulanmadığına bakılmalıdır.
Aynı şekilde aday havuzunun daralması ile belirli bir sağlayıcının çağrılması ayrı aşamalardır. Politika kararı uygun adayları belirlerken çalışma anındaki sağlayıcı durumu da yürütmenin sonucunu etkileyebilir. Olayı açıklarken bu iki aşamayı birbirinin yerine kullanmayın.
Kayıt hattının da sınırları olmalı
Karar girdileri hassas bilgi içerebilir. OPA'nın karar logları dokümanı da kayıtlar dışarı gönderilmeden önce alanların silinmesi veya maskelenmesi için ayrı bir mekanizma tanımlar. OPA decision logs.
Kendi inceleme akışınızda erişim kapsamını, saklama süresini ve paylaşılacak alanları belirleyin. Bir hata raporuna tam payload eklemek yerine istek kimliği ve gerekli karar kanıtıyla başlayın.
İyi bir karar izi, aynı isteği tekrar tekrar çalıştırmadan ne olduğunu açıklamaya yardımcı olur. İnceleme sonunda yalnızca "hangi model?" değil, "hangi bilgiyle, hangi kurala göre ve hangi yükümlülüklerle?" sorularını da yanıtlayabilmelisiniz.
