Making Failure Diagnosis Reliable with Pensive AI · Netflix Technology Blog
Netflix’te data ve ML kullanıcıları her gün milyonlarca workload çalıştırıyor (Titus, Spark, Trino, Druid gibi motorlarda) ve pik günlerde yaklaşık 100.000 tanesi başarısız oluyor. Başarısızlık yalnızca başlangıç: birinin birkaç log arasında faydalı sinyali bulması, sebebin kendi kodunda mı platformda mı olduğuna karar vermesi ve yeniden deneme, yeniden yapılandırma ya da yükseltme kararı vermesi gerekiyor. İlk çözüm Pensive idi: başarısız workload loglarını toplayıp regex ve elle yazılmış Java kurallarıyla hataları çıkaran ve sınıflandıran, yeniden deneme ya da düzeltme önerisini Maestro gibi ürünlere ileten bir auto-diagnosis sistemi. Başarısızlıkların yaklaşık yüzde 50’sini self-service ve bazen otomatik yaptı. Ama kurallar yalnızca bilinen kalıplarda çalışıyor: kapsam, birinin yeni bir hata kalıbını fark edip kural yazması ve engine ile log formatları değiştikçe güncel tutmasıyla büyüyor. Üç aylık bir dönemde Pensive yaklaşık yedi milyon sınıflandırma yaptı ve yarısı ‘unknown’ kovasına düştü.
Pensive AI’nın hedefi, modeli logların önüne koymak değil; kapsamı deterministik parçaları bırakmadan genişletmek. Yazının tasarım ilkesi: AI’ı deterministik süreçlerin etrafına sarmak, bu da geniş kapsam, düşük gecikme, kontrollü maliyet ve yazılım yaşam döngüsü boyunca kolay bakım sağlıyor. İki yol var ve birbirini tamamlıyor: error extraction her başarısızlıkta otomatik çalışıyor (hızlı ilk bakış, düşük maliyet) ve on-demand debugging kullanıcı istediğinde loglardaki semptomlara bakıp LLM’in kendi bilgisi ve reasoning’iyle daha derin kök neden analizi yapıyor (biraz daha yüksek gecikme ve maliyet).
Bölüm 1: faydalı hatayı bulmak. Eski kurallar kesin ama her biri belirli bir log şeklini yakalıyor (ör. bir Spark container’ın bellek sınırını aşması için bir regex). Pensive AI kuralı olmayan hataları da buluyor ve bir platform yükseltmesinden sonra şekli değişen tanıdık hatalara uyum sağlıyor. Mühendislik açısından öğretici bir karar: çıktı token’ı üretmek girdi token’ı okumaktan çok daha yavaş olduğundan, uzun hata mesajlarını model yeniden yazarsa pahalı ve yavaş olurdu. Bu yüzden her logun satırları numaralandırılıyor ve modele {lineNumber, text} kayıtları veriliyor; model metni kopyalamak yerine hangi satırların hata olduğunu döndürüyor. Log kaynağı başına çağrılar paralel çalışıyor ve hepsi Maestro’nun timeout’unun içinde belirlenmiş tek bir deadline’ı paylaşıyor; süreyi kaçıran çağrı sonuçtan çıkarılıyor ve hepsi beklenmiyor. Veri sözleşmesi de yeniden tasarlandı: eski model tek bir düz hata string’iydi, yenisi her log kaynağı için bir hata listesi ve kaynağa derin bağlantılar döndürüyor.
Bölüm 2: tam teşhis ve ürün deneyimi. Pensive AI Debugging, başarısız bir step attempt’i analiz edip kök neden ve önerilen düzeltmeleri sunuyor; programatik API’lerden, MCP’den ve ürün arayüzünden (Data Portal) erişiliyor. Üretimi onlarca saniye ile bir dakika arası sürebildiğinden isteğe bağlı çalıştırılıyor. Bu seçim cache için sağlam bir birim yaratıyor: her debugging cevabı step attempt’e göre cache’leniyor; ikinci istek yeni bir AI çağrısı değil bir key-value okuması. Cache’lenmiş cevabı oku, yoksa üret ya da var olanı yeniden üretip üzerine yaz şeklinde üç başlatma biçimi var; arayüz ve programatik kullanım için farklı ihtiyaçları karşılıyor.
Erken sonuçlar. AI error extraction artık başarısızlıkların yüzde 100’ünü kapsıyor (eski Pensive’in unknown dediği hatalar dahil). Pensive AI’ı kullanmayan başarısız step attempt’lerde, kullananlara göre ortalama yüzde 321 daha fazla manuel debug-log inceleme eylemi görüldü; yazı bunun nedensel bir iddia değil gözlemsel bir karşılaştırma olduğunu özellikle belirtiyor. Göç hâlâ sürüyor: yeni AI hata alanını şimdilik Data Portal’ın başarısız Maestro step arayüzü okuyor, diğer yüzeyler sırada.
Öne çıkanlar
- LLM’i deterministik sistemin yerine değil, onun kapsamını genişletmek için etrafına koy.
- Output token’ı pahalıdır: modele metni kopyalatmak yerine satır numarası döndürt.
- Paralel çağrıları ortak bir deadline’a bağla; geç kalanı sonuçtan çıkar, hepsini bekleme.
- Pahalı analizi isteğe bağlı yap, sonucunu cache’le; ucuz ilk bakışı her hatada otomatik çalıştır.
- Kendi sonucunu abartma: gözlemsel karşılaştırmayı nedensel gibi sunma.
Neden önemli?
‘Logu LLM’e ver, cevap versin’ demo’da çalışır, ölçekte maliyet, gecikme ve tutarsızlıkla patlar. Bu yazı bir LLM özelliğini production’da sürdürülebilir kılan mühendislik kararlarını gösteriyor: sınırlı çıktı, deadline, cache, ve eski sistemle yan yana çalışan bir göç.
Pratikte
Bir log analizi ya da debugging asistanı yazarsan üç kuralı baştan uygula. (1) Logu satır numarasıyla modele ver ve modelden yalnızca ilgili satır numaralarını ve kısa bir açıklamayı JSON olarak iste; metni modele yeniden yazdırma. (2) Hata imzasını (örneğin istisna sınıfı ve ilk stack frame) anahtar yapıp sonucu cache’le: aynı hata ikinci kez gelince LLM çağırma. (3) Bilinen sık hataları regex ile çöz, LLM’i yalnızca ‘unknown’ kovasına çağır ve kovanın oranını izle; bu oran düşüyorsa sistem işe yarıyor demektir.
Sözlük
- error extraction
- Uzun bir log içinden hatayı açıklayan satırları ayıklayıp çıkarma.
- deadline
- Bir işlemin tamamlanması gereken, sonrasında sonucun beklenmediği süre sınırı.
- root cause analysis
- Bir arızanın görünen belirtisinden değil asıl nedeninden başlayarak çözümleme.
- self-service
- Kullanıcının başka bir ekibe başvurmadan sorunu kendi başına çözebilmesi.
How Ultrafast cut incident investigation from hours to minutes at OpenAI
OpenAI, Codex’in yüksek hızlı modu Ultrafast’i iç kullanım örneği olarak anlatıyor (kendi ürününü anlatan bir yazı; abartı payı olabilir). Mühendisler için incident response’ta varsayılan olmuş: bir şey bozulduğunda dakikalarca cevap beklemek sorunu büyütüyor. Bir mühendis incident için bir Slack kanalı açıp Codex’i olayı izlemesi, araştırması ve gelen soruları yanıtlaması için görevlendiriyor ve ‘birçok olası nedeni aynı anda arayabildiğini’ söylüyor. Bir güvenlik mimarı, yapılandırılmış ve yapılandırılmamış veriyi toplayıp normalleştirme ve bağlam verme işinin bir iki saatten 10-15 dakikaya, bazen neredeyse gerçek zamana indiğini aktarıyor.
Yazının asıl gözlemi hız eşiği: bir mühendis bir AI cevabı 30 saniyeden uzun sürerse Slack’e bakıp bir iş arkadaşına sorduğunu, ama işlerinin çoğunun artık bu eşiğin altında kaldığını söylüyor. Başka bir mühendis eskiden Codex’e bir şey sorup aynı anda kendisi de bakmak zorunda kaldığını, artık odağını bölmeden beklediğini anlatıyor. Bu tür testler iç kullanıcı anlatılarına dayanıyor; bağımsız ölçüm değil.
Öne çıkanlar
- Yanıt süresi bir eşiğin altına inince insanlar aracı beklemek yerine kullanır; eşik yaklaşık 30 saniye olarak anlatılıyor.
- Incident’ta birden çok hipotezi aynı anda aramak, tek tek denemekten hızlıdır.
- İç kullanıcı anlatıları değerli ipuçlarıdır ama ölçüm değildir.
Pratikte
Incident ya da debugging için bir araç yazarsan ‘ilk anlamlı cevap’ süresini ölç ve 30 saniyenin altını hedefle. Hız için model boyutunu küçültmeden önce bağlamı kısalt ve aramaları paralelleştir: aynı soruyu log, metrik ve son deploy’lar için eşzamanlı sormak çoğu zaman en büyük kazanç.
Sözlük · 2 terim
- incident response
- Üretimdeki bir arızayı tespit etme, teşhis etme ve giderme süreci.
- latency
- Bir isteğin gönderilmesi ile cevabın gelmesi arasındaki süre.
Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang
8 Eylül 2026’da bir güvenlik araştırmacısı Cloudflare’i, Workers AI’daki GLM-5.3 modelinde 27 Ağustos’tan beri süren bir tenant isolation sorunu konusunda uyardı. 27 Ağustos ile 9 Eylül arasında bu modeli kullanan az sayıda müşteri, kendilerinden az önce aynı modele gönderilmiş başka müşterilerin isteklerinden veri içeren cevaplar aldı. Etkilenen cevap sayısı 155; hepsi 681.280 token’dan uzun prompt’lara verilen cevaplardı. Cloudflare olay ilan ettikten sonra 40 dakika içinde modeli kapattı, düzeltilmiş konfigürasyon ve yamalı inference engine ile aynı gün geri açtı ve başka bir Workers AI modelinin etkilenmediğini doğruladı. Kasıtlı istismar kanıtı bulunmadı.
Kök neden iki sorunun birleşimi. Birincisi yanlış konfigürasyon: model 1.048.576 token’lık bir context window ile deploy edilmişti ama prefill GPU’larındaki KV cache havuzu yalnızca 681.280 token alıyordu. Ekip bu uyumsuzluğu lansmandan önce biliyordu; engine’in sığmayan prompt’lar için hata döndüreceğini varsaydı ve uzun context testleri başarılı cevap verdi. Testlerin açığı: yalnızca HTTP durum kodlarını ve engine performansını doğruladılar, model çıktısının tutarlılığını değil. İkincisi SGLang’deki bir bug (disaggregated prefill/decode modunda): havuza sığmayan bir prompt reddedilip tek token’lık bir yer tutucuyla değiştiriliyordu, ama isteği iptal edip istemciye hata döndürmek yerine prefill bu yer tutucu için KV cache üretip decode node’una aktarıyordu. Decode node’u ‘transfer tamamlandı’ mesajını alıp prefill’in önceki isteklerin KV cache’ini bu isteğin tam prompt’uyla ezdiğini varsayıyordu; oysa önceki durumun büyük kısmı yerinde kalmıştı. Decode, önceki isteklerden kalan eski sayfalara attend ederek cevap üretti.
Arka planda iki ayrıntı var: KV cache GPU belleğinde sabit boyutlu sayfalardan oluşan paylaşımlı bir havuz ve sayfalar istekler arasında sıfırlanmıyor, bir sonraki istek üzerine yazıyor. Ayrıca havuz boyutu bir konfigürasyon değeri değil: SGLang, model ağırlıkları yüklendikten sonra kalan GPU belleğine göre başlangıçta belirliyor; modelin duyurulan context uzunluğu ise ayrı bir değer ve hiçbir şey ikisinin uyuşmasını zorlamıyor.
Düzeltme iki katmanlı. Konfigürasyonda havuz tam context’i taşıyacak biçimde büyütüldü (GLM 5.2 konfigürasyonuna uyarlanarak prefill havuzu yaklaşık 2,04 milyon token’a, context uzunluğunun kabaca iki katına çıktı); böylece geçerli bir prompt her zaman havuza sığıyor ve reddetme yoluna hiç girilmiyor. Engine tarafında da reddetme yolu güvenli hâle getirildi, çünkü yalnızca havuz boyutuna güvenmek kırılgan: quantization, tensor parallelism ya da model sürümü değişince havuz boyutu fark edilmeden değişebilir. SGLang v0.5.21 bu bug’ı düzeltti. İki değişiklik de araştırmacının yeniden üretim betiği ve Cloudflare’in kendi canary-marker testleriyle doğrulandı; ayrıca artık çalışan engine’den KV havuz boyutunun context uzunluğuna göre kontrol edilmesi dağıtımdan önce zorunlu.
Öne çıkanlar
- Bir sistemin kabul ettiği girdi sınırı (context window) ile kaynağının gerçek kapasitesi (KV cache havuzu) ayrı değerlerdir; ikisini yayın öncesi karşılaştır.
- HTTP 200 dönmek doğru olduğu anlamına gelmez: testler çıktının içeriğini ve tutarlılığını doğrulamalı (canary marker).
- Paylaşımlı bellek sayfalarının istekler arasında sıfırlanmaması, bir hata durumunda tenant’lar arası sızıntıya dönüşebilir.
- ‘Engine bir hata döndürür’ varsayımını test etmeden güvenme; hata yolunu da bir ürün özelliği gibi doğrula.
- Çift katmanlı düzeltme (konfigürasyon + engine) tek bir ayara güvenmekten sağlamdır.
Pratikte
Kendi sistemlerinde üç şeyi kontrol et. (1) Bir kaynağın (bağlantı havuzu, bellek, token bütçesi) boyutu ile kabul ettiğin girdi sınırı birbiriyle uyumlu mu? Başlangıçta bir assertion ile ikisini karşılaştır ve uyumsuzsa servisi başlatma. (2) Hata yolunu test et: limiti aşan bir girdi gönderip sistemin gerçekten hata döndürdüğünü ve başka bir isteğin verisini sızdırmadığını doğrula. (3) Çok kiracılı bir sistemde bir tenant’a ait ‘canary’ bir string yaz ve başka bir tenant’ın cevaplarında görünmediğini otomatik test et.
Sözlük · 5 terim
- KV cache
- Transformer’ın daha önce işlediği token’lar için tuttuğu key/value tensörleri; yeniden hesaplamayı önler.
- tenant isolation
- Aynı altyapıyı paylaşan müşterilerin verilerinin birbirinden ayrı kalması.
- context window
- Bir modelin tek seferde işleyebildiği en büyük token sayısı.
- prefill/decode disaggregation
- Prompt’u işleme (prefill) ve token üretme (decode) aşamalarını farklı donanımlarda çalıştırma.
- canary marker
- Bir sızıntıyı tespit etmek için bilerek yerleştirilen, kolay tanınan sahte bir veri parçası.