Sessiz Hatalar: Hata İzleyiciniz Size Neden Yalan Söylüyor?

Her mühendislik ekibinin aşina olduğu bir sahne var: Hata izleyicin sessin, RUM paneline bakıyorsun her şey normal görünüyor, ama dönüşüm hunin bir anda yüzde 15 düştü. Hiç hata yok. Hiç exception yok. Panele baktığında kırmızı bir şey yok. Sadece... bozuk.

İşte sessiz başarısızlıklar dünyası—fırlatılmayan hatalar.

"Hata Yok" ile "Her Şey Çalışıyor" Arasındaki Uçurum

Geleneksel izleme sistemleri çökmeleri yakalar. JavaScript exception'ları, sunucu hataları, timeout başarısızlıkları—bunlar izleme panelini yılbaşı ağacı gibi aydınlatır. Peki ya checkout akışında API 200 OK döndürüyor ama veri yapısı değişmiş ve hiçbir şey işlenmiyor? Ya da A/B testinde B varyantında bir buton teknik olarak render oluyor ama görünmez bir z-index katmanının arkasında kalmış?

Hata izleyicin hiçbir şey görmüyor. RUM, "checkout'ı bırakan kullanıcı"yı görüyor. Aslında ne olduğuna dair en ufak bir fikrin yok.

Yıllardır geliştiricileri çıldırtan bu izleme boşluğu. CI'da yeşil ışık yakan testler yazmak için saatler harcıyoruz, ta ki production trafiği hayal bile edemediğimiz edge case'leri ortaya çıkarana kadar. Sentetik izleme, gerçek kullanıcıların ne yaptığını taklit edemez.

Assertler: Artık Gerçek Kullanıcılar Doğruluyor

Ya test yazar gibi assertion yazabilseydin, ama gerçek kullanıcılar bunları production'da doğrulasa?

Bu, giderek popülerlik kazanan yeni bir yaklaşımın temel fikri. Kod çökmesini beklemek yerine, HTML'ine assertion'ları—özelliklerin beklendiği gibi çalıştığını doğrulayan yapılandırılmış kontrolleri—yerleştiriyorsun. Bu assertion'lar sessizce bekliyor, ta ki gerçek kullanıcılar gerçek oturumlarında tetiklesin.

Bir kullanıcı "Sepete Ekle"ye tıkladığında, assertion'un ateşleniyor. Sepet sayısının arttığını, fiyatın yeniden hesaplandığını ve uyguladıkları indirim kodunun toplama yansıdığını doğruluyor. Bunlardan biri başarısız olursa, stack trace almıyorsun—yapılandırılmış bir gerçek alıyorsun: hangi assertion'ın başarısız olduğu, bozuk kodu hangi release'in gönderdiği ve hangi kullanıcı grubunun etkilendiği.

"Release Başına, Kohort Başına" Neden Her Şeyi Değiştiriyor?

Sihir sadece hataları yakalamakta değil. Bağlamda.

Geleneksel hata takibi sana hacim veriyor: "Saat 3'te 500 hataları patladı." Yapılandırılmış assertion'lar sana anlam veriyor: "v2.3 kohortundaki iOS Safari kullanıcılarının yüzde 34'ünde indirim hesaplama assertion'ı başarısız oldu."

Bu ayrım, hata ayıklamayı kökten değiştiriyor. Oturum kayıtlarını karıştırmak veya sorunları manuel olarak yeniden üretmek yerine, production başarısızlığından belirli bir release'te belirli kullanıcılar için bozulan belirli özelliğe doğrudan bir hat çekiyorsun.

Yeni bir versiyon deploy ettiğinde, hangi assertion'ların başarısız olmaya başladığını anında görebiliyorsun. Bir A/B testi çalıştırdığında, her varyantın gerçekten amaçlandığı gibi çalıştığını—sadece çökmeyecek şekilde yüklendiğini değil—doğrulayabiliyorsun.

Agent İş Akışı: Başarısızlıktan Çözüme

İşte AI destekli geliştirme açısından işlerin ilginçleştiği yer. Bir assertion başarısız oldu mu, iş akışı neredeyse şiirsel bir verimlilik kazanıyor.

v6.0.0 production'a girdi. Gerçek kullanıcılar etkileşime başladı. Assertion ateşlendi ve bir regresyon tespit etti. Nöbetçi mühendisi log'larda debelenmek üzere çağırmak yerine, bir agent yapılandırılmış hata verisini alıyor. Assertion bağlamına dayanarak sorunu tanılamak için bir tool çağrısı. Ardından düzeltmeyle birlikte bir draft PR açıyor.

Assertion geçiyor. Regresyon kapanıyor.

Bu bilim kurgu değil—araçların gittiği yön bu. İzleme sistemin kodunun dilini konuşabildiğinde (raw hatalar değil, assertion'lar), AI agent'lar bu bilgi üzerinde gerçekten anlamlı action alabiliyor.

Performans: Mazeret Yok

Kendini tatmin edecek her izleme çözümü, bundle'ındaki varlığını haklı çıkarmak zorunda. Bu alandaki en iyi araçlar gzipped olarak 8-12KB civarında geliyor, script tag veya npm ile ekleniyor ve tek satırla initialize oluyor.

Performans etkisi? Pratikte sıfır. Bu araçlar kullanıcılar için görünmez olacak şekilde tasarlandı. İnteraksiyon gecikmesi yok, minimal heap overhead ve kritik olarak—Core Web Vitals'ını batıracak sıfır uzun task.

Kullanıcıların aynı deneyimi alıyor. Ekibin görünürlük kazanıyor.

Geri Bildirim Döngüsünü Kapatmak

Gerçek değer teknik kadar felsefi de. Reaktif izlemeden (bir şey kırıldı, bul gitsin) proaktif doğrulamaya (ne çalışması gerektiğini beyan ettik ve doğruladık) geçiyoruz.

Testlerini yaz. Kodunu ship et. Ama şimdi production davranışı hakkında assertion'larını da beyan et ve gerçek kullanıcı oturumlarının bunları sürekli doğrulamasına izin ver.

Sessiz hatalar bir gecede kaybolmayacak. Ama doğru araçlarla, en azından onları gelip gelmediğini görebileceksin.

HTML'ini assertion'larla donatmayı düşünüyor musun? Testing ile production izleme arasındaki boşluğu kapatmak hakkında düşüncelerini paylaş—bu zorluğu bugün ekiplerin nasıl ele aldığını gerçekten merak ediyorum.