Kendi geliştirdiğimiz açık kaynaklı hafıza aracı, her açılışta “59 oturum hâlâ işlenmedi” diye uyarıyordu. Uyarıları tek tek elden geçiriyorduk, sayı düşmüyordu. Ölçtüğümüzde şu çıktı: 59 uyarının 58'i sahteydi. Bu yazı, o hatayı nasıl bulduğumuzu ve daha önemlisi — bir uyarının sürekli yanlış bağırmasının neden gürültüden çok daha pahalı olduğunu anlatıyor. Rakamların tamamı kendi sistemimizde ölçülmüştür.
1. Şikâyet: “Kapatıyorum ama sayı düşmüyor”
Aracın işi basit: her çalışma oturumunun sonunda öğrenilenleri kalıcı hafızaya işlemek. İşlenmemiş bir oturum kalırsa bir sonraki açılışta uyarıyor. Sağlıklı bir tasarım — ta ki uyarı doğru şeyi saymayı bırakana kadar.
Kullanıcının tarifi netti: oturumlar tek tek kontrol edilmiş, hepsi kapatılmış, buna rağmen sayı her gün artıyordu. Bu tarif tek başına teşhisin yarısını veriyor: kullanıcının davranışı sonucu değiştirmiyorsa, sorun kullanıcının yaptığı yerde değildir.
2. Ölçüm: 59 uyarının 58'i boş dosyayı işaret ediyordu
Uyarıyı üreten kod, hafıza dizinindeki satırları sayıyordu. Ama o satır her oturum açılışında koşulsuz yazılıyordu — oturumda bir şey yapılıp yapılmadığına bakılmadan. Yani uyarı şu soruyu cevaplıyordu: “bir satır yazılmış mı?” Oysa sorulması gereken soru şuydu: “işlenecek bir iş var mı?”
Ölçülen tablo
- Uyarının söylediği: 59 işlenmemiş oturum
- İçi tamamen boş olan: 58
- Gerçekten iş içeren: 1
- Günlük çöp üretimi: 10–19 boş kayıt (338 kaydın 255'i boştu)
Kullanıcının oturumları özenle kapatması neden işe yaramıyordu? Çünkü çöp kapanışta değil, açılışta doğuyordu. Kapanışı ne kadar düzgün yaparsanız yapın, bir sonraki açılış yeni bir satır ekliyordu.
3. Asıl zarar gürültü değil, gürültünün sakladığı şey
Buraya kadarı bir konfor sorunu gibi duruyor. Değildi.
Düzeltilmiş ölçüm çalıştırıldığında, aylar önce elle yapılmış bir temizlikte “boş kayıt” diye etiketlenmiş 7 KB'lık gerçek bir çalışma notu ortaya çıktı. İçinde canlı bir müşteri sisteminde yapılmış bir arama-zaman aşımı düzeltmesinin tüm teknik detayı vardı: kök neden, uygulanan çözüm, ölçülen sonuçlar ve bir daha aynı hataya düşmemek için çıkarılmış ders.
O not kayıp değildi — ama görünmezdi. 58 sahte uyarının arasında duran tek gerçek uyarıyı kimse okumaz.
Buradaki asıl ilke
Sürekli yanlış bağıran bir uyarı, okuyanı “buna bakma” diye eğitir. Bir süre sonra o uyarı ekranda vardır ama sistemde yoktur. En pahalı hatalar, alarmın çalmadığı yerlerde değil, alarmın çaldığı ama artık kimsenin bakmadığı yerlerde olur.
4. Doğru refleks: alarmı kısmak değil, ölçümü düzeltmek
Bu noktada iki yol var. Kolay olanı uyarıyı susturmak ya da eşiği yükseltmek. O yol sorunu görünmez yapar, çözmez.
Yaptığımız şey ölçümün kendisini değiştirmek oldu. “Oturum açıldı” ile “oturum iş üretti” artık iki ayrı gerçek. Uyarı sadece ikincisine bakıyor; boş kayıtlar ise otomatik toplanıyor — kaydı oluşturan mekanizma, kayıt boş çıktığında onu geri almakla da yükümlü.
Bir yan bulgu, tasarımın başka bir zayıf noktasını gösterdi: temizliği yalnız kapanışa bağlamak yetmiyor. Ölçtük — 338 kaydın 88'inde (%26) kapanış hiç çalışmamıştı; çökme, uygulama kapatma, ani sonlandırma. Bu yüzden aynı temizlik açılışta da koşuyor.
5. İkinci ders: kapıyı sınayın, sonra kapının kendisini sınayın
Düzeltmeyi yaptıktan sonra 59 vakalık bir test paketi yazdık ve hepsi geçti. Ama geçen bir test paketi tek başına hiçbir şey kanıtlamaz — test yanlış şeyi ölçüyor olabilir.
Bu yüzden ikinci bir araç yazdık: kaynak koda bilerek gerçek kusur enjekte edip test paketinin kırmızı yandığını doğrulayan, sonra dosyayı bayt-bayt geri koyan bir koşum. Sonuç öğreticiydi — ilk turda iki tane kör kol yakaladı. İkisi de kodda duruyordu, ikisi de hiçbir şey ölçmüyordu. Biri, veri kaybını önlemek için yazılmış bir korumaydı ve hiç sınanmamıştı: test, sıkıştırmanın başarısız olduğu bir senaryoyu hiç kurmuyordu, dolayısıyla koruma silinse bile paket yeşil kalıyordu.
Bir doğrulama kapısına sorulacak üç soru
- Doğru şeyi mi ölçüyor? (bizim vakamızda: hayır — satır sayıyordu, iş değil)
- Bozunca kırmızı yanıyor mu? (negatif test — kapının bozulabildiğini kanıtlar)
- Kaç örneği kapsamına almadı? (bu üçüncüsü hemen her zaman atlanır)
Kapsam sayısı yazılmayan bir “0 hata” sıfır bilgi taşır. “0 hata bulundu” ile “338 kaydın 338'i tarandı, 0 hata bulundu” aynı cümle değildir.
6. Üçüncü ders: sınanamayanı “doğrulandı” diye yazmayın
Enjeksiyon koşumunda bir koruma, tek bir kusurla izole edilemedi — sınamak için aynı anda ikinci bir kusur gerekiyordu. Burada iki seçenek vardı: eşiği gevşetip “hepsi doğrulandı” demek, ya da olduğu gibi yazmak.
Raporda o satır “SINANMADI” olarak duruyor ve gerekçesi koşumdan önce yazıldı. Ölçümden sonra eşiği gevşetmek, ölçümü yapmamakla aynı kapıya çıkar — üstelik yapılmış gibi görünür, ki bu daha kötüdür.
7. Sonuçlar
Aynı kök sebep ikinci bir şikâyeti de açıkladı: işlem komutu yavaşlamış ve pahalılaşmıştı. Sebep, tek bir statü satırını değiştirmek için sistemin koca indeks dosyalarını baştan sona okumak zorunda kalmasıydı. Bu mekanik iş yapay zekâdan alınıp doğrudan koda verildi.
Önce → sonra (ölçülmüş)
- Uyarı: 59 (&%98'i sahte) → 3 (hepsi gerçek)
- Boş kayıt: 338 kaydın 255'i → 84 kaydın 1'i
- İşlem komutunun zorunlu okuması: ~41.400 birim → 0 (artık kod yapıyor)
- Yedek disk alanı: 1.038,9 MB → 797,5 MB (kayıpsız sıkıştırma)
- Kaybedilen gerçek kayıt: 83 kaydın 83'ü duruyor — sıfır kayıp
Silinen her dosya önce arşive kopyalandı, bayt-bayt karşılaştırıldı, ancak ondan sonra aslı kaldırıldı. İnsan notu taşıyan hiçbir satıra dokunulmadı. Geri alma talimatı arşivin içinde duruyor.
8. Bunun sizin işinizle ilgisi
Bu bir hafıza aracının hikâyesi ama sorun ona özgü değil. Aynı kalıp her yerde çıkar:
- Sürekli kırmızı yanan bir izleme paneli — ekip bakmayı bırakmışsa panel çalışmıyor demektir
- Hiç okunmayan hata e-postaları — gerçek arıza da aynı klasöre düşer
- “Zaten hep uyarı verir” denen bir rapor — o cümle söylendiği anda rapor ölmüştür
- Yıllardır sorunsuz çalışan bir arka plan görevi — “aylardır çalışıyor” bir güvenlik kanıtı değildir; ölçülmemiş yük veri büyüdükçe sessizce eşiği geçer
Ortak çözüm de aynı: uyarının sesini değil, ölçtüğü şeyi düzeltin. Ve düzelttikten sonra kapıyı bilerek bozup kırmızı yandığını görün — yoksa elinizde yeşil ışık yakan ama hiçbir şey ölçmeyen bir gösterge kalır, ki bu göstergenin hiç olmamasından kötüdür.
Kod açık kaynak
Bu yazıda anlatılan araç DS-ReCall ve MIT lisansıyla herkese açık. Düzeltmenin tamamı, ölçümler, test paketi ve kusur enjekte eden negatif koşum dâhil sürüm notlarında duruyor.
Sık sorulan sorular
Yanlış pozitif uyarı neden bu kadar tehlikeli?
Çünkü insanı eğitir. Bir uyarı defalarca boş çıkarsa okuyan kişi ona bakmayı bırakır — ve o noktadan sonra uyarı ekranda görünse bile sistemde yoktur. Bizim vakamızda 59 uyarının 58'i sahteydi ve aralarındaki tek gerçek uyarı, 7 KB'lık gerçek bir çalışma kaydı, aylarca fark edilmedi. Zarar gürültünün kendisi değil, gürültünün sinyali gizlemesidir.
Sürekli uyarı veren bir sistemi susturmak çözüm mü?
Hayır. Susturmak ya da eşiği yükseltmek sorunu görünmez yapar, ortadan kaldırmaz — ve sonraki gerçek arızayı da aynı anda saklar. Doğru hamle uyarının ölçtüğü şeyi düzeltmektir. Bizim vakamızda uyarı “bir satır yazılmış mı” diye soruyordu; sorması gereken “işlenecek iş var mı” idi. Ölçüt düzelince sayı kendiliğinden 59'dan 3'e indi ve kalan 3'ün üçü de gerçekti.
Testlerim geçiyorsa sistem doğru çalışıyor demek değil mi?
Değil. Geçen bir test, yanlış şeyi ölçüyor da olabilir. Bunu anlamanın tek yolu kodu bilerek bozup testin kırmızı yandığını görmektir. Biz bunu otomatikleştirdik ve ilk turda iki tane kör kol çıktı: kodda duran ama hiçbir şey ölçmeyen iki koruma. Biri veri kaybını önlemek içindi ve hiç sınanmamıştı. Bir de üçüncü soru var, neredeyse hep atlanır: test kaç örneği kapsamına almadı?
Eski verileri temizlerken neyi garantiye almak gerekir?
Silmeden önce doğrulanmış bir kopyanın var olduğunu. Bizim temizliğimizde her dosya önce arşive kopyalandı, geri okundu, bayt-bayt karşılaştırıldı ve ancak ondan sonra aslı kaldırıldı; yedekler ise hiç silinmedi, yalnız sıkıştırıldı. İnsan eliyle yazılmış not taşıyan hiçbir kayda dokunulmadı — boş bir dosyayı silmek güvenlidir, birinin notunu silmek değildir. Sonuçta 83 gerçek kaydın 83'ü yerinde kaldı.
“Aylardır sorunsuz çalışıyor” bir güvence midir?
Hayır. Ölçülmemiş bir yük, veri büyüdükçe sessizce eşiği geçer; yavaşlama kademeli olur, çöküş ani. Bu araçta günde 10–19 boş kayıt aylarca kimseyi rahatsız etmedi, ta ki uyarı okunamaz hâle gelene kadar. Kalıcı çözüm, işin maliyetini bir kez ölçmek ve o ölçümü sürekli görünür bir yere bağlamaktır.
Bu yazıdaki sayıların tamamı kendi sistemimizde, 7 Ağustos 2026'da ölçülmüştür. Bayt ve dosya sayıları doğrudan ölçümdür; işleme maliyeti (“birim”) yaklaşık bir çeviriyle verilmiştir, tam sayım değildir. Düzeltmenin kaynak kodu, test paketi ve sürüm notları GitHub'da açık.