Panelde "Bir Hata Oluştu" Yazan Her Ekranın Arkasında Kaybettiğin Para Var: Hata İzleme Kurmadan E-Pin Scripti Çalıştırma

Çoğu bayi hataların kendisine geldiğini sanır. Müşteri yazar, destek talebi açılır, sen bakarsın, düzeltirsin. Bu döngü içinde işleyen bir sistem var gibi görünür. Ama sahadaki gerçek oran acıdır: hata yaşayan her yirmi müşteriden yalnızca biri sana yazar. Diğer on dokuzu sekmeyi kapatır, aynı ürünü başka yerden alır ve bir daha dönmez. Yani destek kutunda gördüğün hata sayısı, gerçek hata sayısının yüzde beşidir.

Hata izleme sistemi tam olarak bu karanlık yüzde doksan beşi aydınlatmak için kurulur. İyi kurulmuş bir e-pin scripti hatayı ekrana "bir hata oluştu" diye yazıp geçmez; olayı yakalar, parmak izini alır, kaç kullanıcıyı etkilediğini sayar ve para kaybına yol açan türden olduğunda seni uyarır. Bu yazıda, ölçüsüz log tutmaktan gerçek bir hata izleme hattına geçişi adım adım kuruyoruz.

Log tutmakla hata izlemek neden aynı şey değil?

Log tutmak olayları sırayla bir dosyaya yazmaktır. Hata izlemek ise olayları gruplayıp saymaktır. Aradaki fark, elinde 90 bin satırlık bir metin dosyası olmasıyla "şu üç hata bu hafta 1.240 kullanıcıyı etkiledi" cümlesi arasındaki farktır. Birincisi arşiv, ikincisi karar.

Gruplama işini yapan şey parmak izidir: hata sınıfı, mesajın değişkenlerden arındırılmış hali, oluştuğu dosya ve satır birleştirilip tek bir imza üretilir. Aynı imzanın bin kere tekrarlaması bin kayıt değil, sayacı bine çıkmış tek bir kayıt olur. Böylece ekranında yüz binlerce satır değil, üzerinde çalışılabilir on-on beş başlık durur.

Bir dijital ürün satış yazılımı için bu ayrım hayati, çünkü e-ticarette hataların çoğu tekrar edendir. Aynı tedarikçi zaman aşımı, aynı geçersiz kupon kodu, aynı oturum çakışması. Saymadan bakarsan hepsi ayrı bir olay gibi görünür ve önemsizleri kovalarken satışı bitiren hatayı kaçırırsın.

Hangi hatayı görmezden gelebilirsin, hangisi acil?

Bütün hatalar eşit değildir. Bir kullanıcının olmayan sayfaya girmesi hatadır ama iş kaybı değildir. Ödeme başlatırken tedarikçi anahtarının reddedilmesi ise doğrudan gelir kaybıdır. Bu yüzden hata izlemenin ikinci direği önem sınıflandırmasıdır ve bunu teknik şiddetle değil, paraya yakınlıkla yapmalısın.

Pratik kural şudur: hata kullanıcının ödeme yolculuğunda hangi adımda oluştu? Ürün görüntülemede oluşan hata yüksek hacimli ama düşük etkili olabilir. Sepet ve ödeme adımında oluşan hata düşük hacimli ama yüksek etkilidir. Teslimat aşamasında oluşan hata ise en pahalısıdır, çünkü para alınmış ama ürün verilmemiştir.

Hatayı yakalarken kullanıcıya ne göstereceksin?

Teknik ekip hatanın ayrıntısını ister, müşteri ise ne yapacağını. Bu ikisini karıştırmak iki yönlü zarar üretir: ekrana yığın izini basarsan sistemini saldırganlara açarsın, "bir hata oluştu" yazarsan müşteriyi yalnız bırakırsın. Doğru yol ortadadır: her hataya bir olay numarası ver, kullanıcıya o numarayı ve tek cümlelik yönlendirmeyi göster, ayrıntıyı sadece kendi tarafında sakla.

Bu numaranın değeri destek masasında ortaya çıkar. Müşteri "EP-7F42 hatası aldım" dediğinde, o kaydı saniyede bulur, hangi siparişte hangi adımda ne olduğunu görürsün. Hata mesajını tarif etmeye çalışan müşteriyle geçen yirmi dakikalık yazışma ortadan kalkar. Ciddi bir epin yazılım kurulumunda olay numarası, sipariş numarası kadar temel bir alandır.

Bağlam olmadan hata kaydı neden hiçbir işe yaramaz?

"Undefined index" yazan bir kayıt sana hiçbir şey söylemez. Aynı kayıt, yanında sipariş numarası, kullanıcı kimliği, ödeme sağlayıcısı, ürün grubu, tarayıcı bilgisi ve o anki istek yükü ile gelirse on dakikada çözülür. Hata izlemenin gerçek işi yakalamak değil, yeniden üretilebilir hale getirmektir.

Bağlam toplarken tek kırmızı çizgi gizliliktir. Kart bilgisi, tam kimlik numarası, oturum anahtarı ve tedarikçi API anahtarı asla hata kaydına düşmemelidir. Bunları toplamadan önce maskele. Aksi halde güvenlik ihlali kaynağın, güvenlik aracın olur.

İkinci kural örneklemedir. Saniyede yüz kez tekrar eden bir ön yüz hatası sunucunu boğabilir. Aynı imzayı dakikada en fazla birkaç kez tam bağlamla kaydet, gerisini sadece sayaca ekle. Sayaç etkiyi gösterir, örnek kayıt sebebi gösterir; ikisi birden yeterlidir.

Hangi eşikte alarm, hangi eşikte sessizlik?

Her hatada telefon çalarsa hata izleme üç günde kapanır. Alarmı mutlak sayıya değil orana ve yeniliğe bağla. Yeni bir hata imzası ilk kez göründüğünde bildirim gönder; bu genellikle bir sürümün bozduğu şeydir. Bilinen bir imzanın hacmi normalin beş katına çıktığında bildirim gönder; bu genellikle dış servisin bozulduğu andır.

Kritik kategorilerde ise tek olay yeter: teslimat başarısızlığı bir kez olsa bile alarm çalmalıdır, çünkü karşılığında ödemesini yapmış bir müşteri bekliyor. Pinova bu ayrımı hazır getirir; teslimat ve ödeme hataları ayrı bir kanaldan, gürültülü kategoriler ise gün sonu özetinden akar.

Kurduktan sonra bu sistemi nasıl yaşatacaksın?

Hata izleme, kurulumdan çok bakım disiplinidir. Haftada bir kez, yirmi dakika ayırıp ilk beş imzaya bakmak yeterlidir. Her oturumda üç karar verirsin: düzelt, görmezden gel, ya da gürültüyse filtrele. Bu rutin işlediğinde altı hafta içinde toplam hata hacmin yarıya iner ve geriye kalanlar gerçekten anlamlı olanlar olur.

Bir de sürüm bağı kur. Her kayda çalışan sürüm numarasını yaz. Böylece yeni bir güncellemenin ardından hata grafiği yukarı kırıldığında, sebebi tahmin etmek zorunda kalmazsın; hangi sürümün neyi bozduğunu doğrudan görürsün.

Hata izleme, kurduğun anda değil ilk kez bir kaybı önlediğinde kendini amorti eder. Gruplanmış hata ekranını, olay numarası akışını ve kritik kategori alarmlarını gerçek veriyle görmek istersen canlı demo panelinde dolaş, özellikler bölümünde teknik başlıkları karşılaştır ve gerekirse lisans adımına geç.