Çoğu satıcı şunu sanır: panel açılıyorsa, ana sayfa yükleniyorsa ve sepete ürün ekleniyorsa sistem sağlıklıdır. Oysa dijital ürün satışında en pahalı arızalar tam olarak sitenin ayakta göründüğü anlarda yaşanır. Ödeme sağlayıcısı bildirim gönderir, senin tarafında bir satır kod patlar, sipariş "beklemede" kalır; müşteri parasını ödediği halde kodunu almaz. Ekran kararmaz, 500 hatası kimseye görünmez, sadece bir kişi WhatsApp'tan yazar: "abi kod gelmedi". Sen de o mesajı gördüğünde aynı hatanın kaçıncı kez tekrarlandığını bilmezsin.
İşte hata izleme servisi (error tracking) denen şey burada devreye girer ve amacı log dosyası okumak değil. Amaç, uygulamanın içindeki her istisnayı, yavaş sorguyu ve başarısız dış çağrıyı zaman damgası, kullanıcı bağlamı ve tekrar sayısıyla birlikte tek bir panele taşımaktır. İyi kurulmuş bir e-pin scripti hatayı kendi kendine haber verir. Kötü kurulmuş bir kurulumda ise sen hatayı müşteriden, müşteri de hatayı iade talebiyle öğrenir. Bu yazıda Pinova gibi lisanslı bir dijital ürün satış yazılımı üzerinde hata izlemenin nasıl kurulduğunu, nelerin loglanmayacağını ve gürültüyü nasıl susturacağını adım adım anlatıyorum.
"Site çalışıyor" neden sistemin sağlıklı olduğu anlamına gelmez?
Dijital ürün satışı, klasik e-ticaretten farklı olarak zincirleme çalışır: ziyaretçi sipariş verir, ödeme geçidi onay gönderir, script stoktan kod ayırır, teslimat e-postası veya panel bildirimi tetiklenir, fatura kaydı düşer. Bu beş halkanın herhangi biri koparsa ön yüz hiçbir şey belli etmez. Kullanıcı yine "siparişiniz alındı" ekranını görür. Bu yüzden izlemeyi sadece HTTP durum kodlarına bağlamak yetersizdir; iş akışının her adımına ölçüm koymak gerekir. Pinova mimarisinde bunu düşünmenin pratik yolu şu: her kritik adım ya bir "başarılı" olayı yazar ya da bir istisna fırlatır. Arada kalan hiçbir durum kabul edilmez. Sessizlik bir sonuç değildir, sessizlik bir arızadır.
Hata izleme servisi bir e-pin panelinde tam olarak neyi yakalar?
Yakalanan olayları dört gruba ayırmak işini kolaylaştırır. Birincisi yakalanmamış istisnalar: PHP fatal error, tip uyuşmazlığı, null nesne üzerinde metot çağırma. İkincisi yakalanmış ama anlamlı olan hatalar: tedarikçi API'sinin 403 dönmesi, stok yetersizliği, imza doğrulama başarısızlığı. Üçüncüsü performans olayları: 3 saniyenin üstünde süren sipariş kaydetme, kilitlenen tablo, patlayan sorgu sayısı. Dördüncüsü ön yüz hataları: ödeme adımında JavaScript'in kırılması yüzünden butonun hiç çalışmaması. Dördüncüsü çoğu epin yazılım kurulumunda tamamen atlanır; oysa dönüşüm kaybının sessiz kaynağı genelde tam olarak orasıdır. Tarayıcı hatasını göremezsen, kullanıcının neden ödemeye geçmediğini de asla bilemezsin.
| Hata sınıfı | Müşteri tarafındaki belirti | Ticari etki | İzlemede aranacak sinyal |
|---|---|---|---|
| Ödeme bildirimi (webhook) düşmesi | Ödedi, sipariş beklemede kaldı | Doğrudan iade ve itiraz riski | Aynı uç noktada tekrarlayan 5xx ve imza hatası |
| Tedarikçi API zaman aşımı | "Teslimat kuyrukta" mesajı uzuyor | Geç teslim, kötü yorum | Ortalama yanıt süresinde ani sıçrama |
| Stok ayırma yarış durumu | Aynı kod iki kişiye gidiyor | Çifte teslim, doğrudan zarar | Benzersizlik ihlali / kilit hatası |
| Şablon veya çeviri hatası | Sayfa yarım yükleniyor | Terk edilen sepet | Tek bir görünüm dosyasında yığılan istisna |
| Ön yüz script kırılması | Butona basıyor, bir şey olmuyor | Sessiz dönüşüm kaybı | Tarayıcı-sürüm bazlı tekil hata kümesi |
| Cron/kuyruk durması | Otomatik teslimat hiç çalışmıyor | Kitlesel gecikme | Beklenen olayın hiç gelmemesi (heartbeat) |
Entegrasyonu bir akşamda nasıl kurarsın?
Kurulum sırası önemlidir, çünkü yanlış sırayla başlarsan panelin ilk gün binlerce anlamsız olayla dolar ve sen de bildirimleri kapatırsın. Doğru sıra şudur: önce SDK'yı yükle ve yalnızca yakalanmamış istisnaları topla. İkinci adımda her olaya bağlam ekle: sipariş numarası, kullanıcı kimliği (adı değil, kimliği), ödeme yöntemi, ürün tipi. Üçüncü adımda ortam etiketi koy; canlı ile test ortamı aynı projeye akarsa hiçbir uyarıya güvenemezsin. Dördüncü adımda sürüm etiketi (release) gönder, böylece "bu hata dün gece yaptığım güncellemeyle mi geldi" sorusuna iki saniyede cevap verirsin. Beşinci adımda uyarı kanalını bağla: e-posta değil, Telegram veya Slack. Altıncı adımda kuyruk ve cron işlerine kalp atışı (heartbeat) ekle; çünkü hiç çalışmayan bir iş hiç hata da fırlatmaz.
İzleme kurulmuş e-pin panellerinde yakalanan olayların dağılımı
- Ödeme ve bildirim zinciri 45%
- Tedarikçi / dış API 25%
- Kod, şablon ve ön yüz 20%
- Sunucu ve altyapı 10%
Gürültüyü nasıl susturursun: örnekleme, gruplama ve sessiz saatler
Hata izlemenin en büyük düşmanı hata değil, alarm yorgunluğudur. Bir bot sitede olmayan sayfaları taradığında yüzlerce 404 üretir; bunları hata saymak panelini çöplüğe çevirir. Bu yüzden üç filtre kur. Birincisi yoksay listesi: bot kaynaklı 404'ler, kullanıcı iptali, beklenen doğrulama hataları. İkincisi parmak izi gruplama: aynı kök nedenli olayları tek bir başlık altında topla, sayaç artsın ama bildirim bir kez gelsin. Üçüncüsü eşik tabanlı uyarı: "bir hata olduğunda haber ver" yerine "aynı hata 5 dakikada 10 kez olduğunda haber ver". Bunun tek istisnası para akışıdır: ödeme ve teslimat zincirindeki her tekil hata, ilk tekrarında bile anında bildirim almalıdır. İyi bir e-pin satış scripti zaten bu iki sınıfı ayrı kanala verecek şekilde yapılandırılabilir.
KVKK ve stok güvenliği: loglara asla ne yazılmaz?
Burada yapılan hata onarılamaz. Hata izleme servisi üçüncü taraf bir sunucudur ve oraya gönderdiğin her şey senin kontrolünden çıkar. Dolayısıyla hiçbir koşulda olay gövdesine e-pin kodunun kendisi, kupon serisi, kart bilgisi, API anahtarı, oturum çerezi veya ham istek gövdesi konmaz. Bunun yerine maskeleme kuralı yazarsın: alan adları eşleşen her değer sabit bir yer tutucuyla değiştirilir. Kullanıcıyı tanımlamak için e-posta değil iç kimlik numarası gönderilir; gerekirse destek ekibi o numarayı kendi panelinden çözer. Ayrıca veri saklama süresini 30-90 gün aralığında sınırlandır, eski olayların otomatik silinmesini aç ve panele erişimi yalnızca teknik sorumluya ver. Aydınlatma metnine de bu servisin bir işleyen olarak kullanıldığını yazmayı unutma.
| Kontrol adımı | Neden gerekli | Doğrulama yöntemi | Durum |
|---|---|---|---|
| SDK canlı ve test ortamına ayrı etiketle kuruldu | Sahte uyarıları engeller | Test ortamından bilinçli hata fırlat | Zorunlu |
| Sipariş numarası bağlam olarak ekleniyor | Hatayı müşteriyle eşleştirmek için | Örnek olayda alanı gör | Zorunlu |
| Hassas alan maskeleme kuralı yazıldı | Kod ve anahtar sızmasını önler | Ödeme akışını test edip olayı incele | Zorunlu |
| Sürüm (release) bilgisi gönderiliyor | Regresyonu anında bulmak için | Güncelleme sonrası yeni sürüm görünmeli | Önerilir |
| Cron ve kuyruk kalp atışı tanımlı | Hiç çalışmayan işi yakalar | Cron'u kasten durdur, uyarı gelsin | Zorunlu |
| Para akışı için ayrı acil kanal | Kritik hatayı gürültüden ayırır | Webhook imzasını bozup dene | Zorunlu |
| Saklama süresi ve erişim yetkisi sınırlı | KVKK uyumu | Proje ayarlarını ekran görüntüsüyle arşivle | Zorunlu |
Canlıda sahte bir sipariş oluştur, ardından ödeme bildirimini kasten bozuk imzayla gönder. Uyarı telefonuna bir dakika içinde düşmüyorsa entegrasyon bitmemiştir; kurulum değil, sadece kütüphane yüklemesi yapmış olursun.
Hata izlemeyi karara nasıl çevirirsin?
Panel dolmaya başladıktan sonra iş asıl orada başlar. Haftada bir kez ilk beş hata kümesini açıp şu üç soruyu sor: bu hata para akışını etkiliyor mu, kaç farklı kullanıcıyı etkiliyor, kök nedeni bizde mi tedarikçide mi? Birinci sorunun cevabı "evet" olan her şey aynı gün çözülür. Kök nedeni tedarikçide olanlar için otomatik yeniden deneme ve yedek tedarikçi devreye alma mantığı yazılır. Geriye kalanlar sürüm planına girer. Bu ritmi üç ay sürdürdüğünde dijital ürün satış scripti üzerindeki kronik arızaların çoğunun aslında beş altı kök nedenden kaynaklandığını görürsün; hepsini tek tek kapattığında destek yükün belirgin şekilde düşer. Ölçmeye başladığın gün, tahmin etmeyi bırakırsın.
Hataları sen değil, sistemin haber versin
Pinova'nın olay günlüğü, sipariş bağlamı ve dış servis izleme noktaları hata izleme entegrasyonu için hazır gelir. Teknik özellikleri incele, lisans paketlerini karşılaştır.
Hata izleme servisi siteyi yavaşlatır mı?
Doğru kurulduğunda hayır. Olaylar arka planda, isteğin dışında gönderilir ve performans izlemesi örnekleme oranıyla sınırlandırılır. Yavaşlama şikayetlerinin neredeyse tamamı, her isteği tam izleme ile kaydeden hatalı yapılandırmadan doğar.
Ücretsiz planlar bir e-pin paneli için yeter mi?
Başlangıç için çoğu zaman yeter. Aylık olay kotası dolmasın diye 404 ve bot gürültüsünü baştan filtrelersen, orta ölçekli bir panel ücretsiz kotada rahatça çalışır. Kota dolduğunda ilk kısıtlanacak şeyi kendin seç: performans izlemesi kısılır, istisnalar asla kısılmaz.
Sunucu loglarım var, ayrıca servise ne gerek var?
Log dosyası pasiftir; birinin açıp okumasını bekler. İzleme servisi ise olayı gruplar, tekrar sayısını tutar, sürümle ilişkilendirir ve seni uyarır. Aradaki fark, hatayı dört saat sonra öğrenmekle dokuz dakikada öğrenmek arasındaki farktır.
Tedarikçi kaynaklı hataları da izlemeli miyim?
Kesinlikle. Dış API yanıt süresi ve hata oranı, teslimat gecikmelerinin en büyük sebebidir. Bu veriyi biriktirmek ayrıca tedarikçiyle yapacağın görüşmede elini güçlendirir; iddia yerine ölçüm gösterirsin.
Hata izleme, panelinin üstüne takılan bir süs değil; satışını ayakta tutan sigorta poliçesidir. Kurulumu bir akşam sürer, kazandırdığı ise her ay sessizce kaybettiğin siparişlerdir. Pinova'nın olay akışını, sipariş bağlamını ve teslimat zincirini kendi gözünle görmek istersen canlı demo üzerinden bir sipariş oluştur, arka plandaki kayıtların nasıl işlendiğini adım adım takip et; ardından lisans adımına geçtiğinde neyi satın aldığını tam olarak biliyor olacaksın.