Çoğu e-pin satıcısı, sisteminin ne zaman bozulduğunu müşteri destek kutusundan öğrendiğini sanmaz ama gerçek tam olarak bu. Sabah 03:40'ta bir bayi API'sinin sertifikası düşer, senin panelin siparişi "beklemede" bırakır, kimse fark etmez. Saat 09:00'da WhatsApp'a "kodum gelmedi" mesajları dolar ve sen altı saatlik bir arızayı, altı saat sonra kovalamaya başlarsın. Bu gecikmenin adı teknik borç değil; doğrudan iade, doğrudan itibar kaybı.
Burada anlatacağım şey bir moda kavram değil. Hata takip sistemi, yani uygulamanın kendi kusurunu kendi raporlaması, ciddi bir e-pin satış scripti ile amatör bir kurulum arasındaki en net sınırdır. Pinova gibi lisanslı bir dijital ürün satış yazılımı kullanıyor olman tek başına yetmez; o yazılımın ürettiği sinyalleri nereye akıttığın, kimin gördüğü ve hangi eşikte alarm çaldığı seni gerçek anlamda korur. Aşağıda bu katmanı sıfırdan kurmanın mantığını, hangi hataların gerçekten para kaybettirdiğini ve neyi asla loglamaman gerektiğini konuşacağız.
Neden "hata yok" dediğin panelde aslında onlarca hata birikiyor?
Bir e-pin panelinde hatalar iki sınıfa ayrılır: gürültülü olanlar ve sessiz olanlar. Gürültülü hata beyaz ekrandır, 500 sayfasıdır, ödeme sayfasının açılmamasıdır; bunları müşteri de görür, sen de görürsün. Asıl tehlike sessiz olanlardadır. Bayi API'si HTTP 200 döner ama gövdede "stok yok" yazar; senin kodun 200'ü başarı sayar ve siparişi teslim edilmiş işaretler. Kullanıcı boş bir kod alır. Ya da kuyruk işçisi bir istisna yüzünden durur, sipariş tablosunda 40 kayıt "işleniyor" statüsünde çürür.
Bu yüzden hata takip mantığını "çöktü mü" sorusu üzerine değil, "beklenen sonuç gerçekleşti mi" sorusu üzerine kurmalısın. İyi bir e-pin yazılımı her kritik adımı bir sözleşme gibi tanımlar: ödeme onaylandıysa 60 saniye içinde bir kod ataması olmalı. Olmadıysa bu bir hatadır, kod hiç istisna fırlatmasa bile. Sessiz başarısızlığı hata sayan tek yaklaşım budur ve panelinde bunu kuran satıcı, rakiplerinin fark etmediği kaçakları bir haftada kapatır.
Hangi olayları izlemelisin, hangilerini görmezden gelmelisin?
Her şeyi loglamak, hiçbir şeyi loglamamakla neredeyse aynı sonucu verir: kimse bakmaz. Bu yüzden olayları etki ve aciliyet eksenine göre ayırmak gerekiyor. Kullanıcı parolasını üç kez yanlış girdi diye alarm kurmak, gerçek bir teslimat arızası sırasında bildirimlere körleşmene yol açar. Aşağıdaki tablo, canlı bir epin yazılım kurulumunda hangi sinyalin hangi kanala gitmesi gerektiğini gösteriyor.
| Olay | Sınıf | Kanal | Eşik | Kimde biter |
|---|---|---|---|---|
| Ödeme onaylı, kod atanmadı | Kritik | Telefon + Telegram | 1 vaka | Sahip / teknik |
| Bayi API zaman aşımı | Kritik | Telegram | 5 dk içinde 3 vaka | Teknik |
| Kuyruk işçisi durdu | Kritik | Telefon | 2 dk sinyalsizlik | Teknik |
| Stok eşiği altına düştü | Uyarı | E-posta | <10 adet | Operasyon |
| Ödeme sağlayıcı imza hatası | Uyarı | Telegram | saatte 5 vaka | Teknik |
| 404 / bozuk bağlantı | Bilgi | Panel raporu | haftalık özet | Pazarlama |
| Hatalı giriş denemesi | Bilgi | Güvenlik logu | IP bazlı 20 | Operasyon |
Log kaydını nasıl yazarsan ertesi gün işine yarar?
Serbest metin log, gece yarısı hiçbir işe yaramaz. "Hata oluştu" satırı sana kaç kişinin etkilendiğini, hangi üründe olduğunu, hangi sağlayıcının cevap vermediğini söylemez. Bunun yerine her kaydı makinenin de okuyabileceği alanlara böl: zaman damgası, olay kodu, sipariş numarası, kullanıcı kimliği, ürün kimliği, sağlayıcı adı, süre, sonuç ve bir korelasyon kimliği. O korelasyon kimliği bir siparişin ödemeden teslimata kadar bıraktığı tüm izleri tek komutla birleştirmenin anahtarıdır.
Kritik kural: log bir müşteri veri deposu değildir. Kart bilgisi, tam e-pin kodu, oturum jetonu, parola özeti asla log satırına düşmemeli. E-pin kodunu maskeleyerek yaz, sadece son dört karakteri tut; böylece "kod boş mu geldi" sorusunu cevaplarken kimseyi riske atmazsın. Bir dijital ürün satış scripti için kod sızdıran bir log dosyası, çökmüş bir siteden çok daha pahalı bir olaydır.
E-pin panellerinde kaydedilen hataların dağılımı
- Bayi / sağlayıcı entegrasyonu 42%
- Ödeme bildirimi ve doğrulama 28%
- Sunucu, kuyruk ve kaynak 18%
- Arayüz ve kullanıcı akışı 12%
Alarm yorgunluğuna düşmeden bildirimi nasıl kurarsın?
Bildirim kurmanın en kolay yolu her hataya mesaj atmaktır; en hızlı pişmanlık da budur. Üçüncü günün sonunda Telegram grubunu sessize alırsın ve sistem artık teoride izlenmektedir. Doğru düzen üç kademelidir. Birinci kademe otomatik onarımdır: geçici bir ağ hatasında sipariş yeniden denenir, kimseye haber verilmez. İkinci kademe toplu bildirimdir: aynı hata beş dakikada üç kez tekrarlarsa tek bir özet mesaj gider. Üçüncü kademe insanı uyandırmaktır ve yalnızca para ya da teslimat durduğunda devreye girer.
Bunu kurarken parmak izi mantığını kullan: aynı dosya, aynı satır, aynı sağlayıcı ve aynı mesaj bir gruba düşer. Aynı gruptan gelen ikinci bin hata, bin ayrı bildirim değil bir sayaçtır. Pinova tarafında bu düzeni yapılandırırken bir de "bastırma penceresi" tanımla; bilinen bir bakım saatinde alarm kapansın, saat dolunca kendiliğinden geri açılsın. Böylece alarma tekrar güvenmeye başlarsın.
Her 5 dakikada bir çalışan tek bir kontrol yaz: "ödemesi onaylanmış ama 10 dakikadır kodu atanmamış sipariş var mı?". Bu tek sorgu, gelişmiş izleme araçlarının çoğundan daha fazla para kurtarır çünkü doğrudan müşterinin hissettiği şeyi ölçer.
Hata kaydından iade ve destek akışına nasıl köprü kurulur?
Hata takibi teknik bir hobi değil, operasyonel bir süreçtir. Bir arıza kaydı oluştuğunda otomatik olarak üç şeyin tetiklenmesi gerekir: etkilenen siparişlerin listesi, müşteriye gidecek şeffaf bilgilendirme ve olay kapandıktan sonra yazılacak kısa bir not. Etkilenen sipariş listesini elle çıkarmak zorunda kalıyorsan, sistemin tasarımı eksik demektir; korelasyon kimliğiyle bu liste saniyede gelir.
Müşteriyi önceden bilgilendirmenin dönüşüme etkisi sandığından büyük. "Sağlayıcı kaynaklı gecikme yaşanıyor, kodun 30 dakika içinde hesabına düşecek, düşmezse ücret otomatik iade edilecek" mesajı, sessizliğe kıyasla iade taleplerini gözle görülür biçimde azaltır. Olay kapandığında yazdığın üç satırlık not ise en değerli varlığın olur: aynı hata altı ay sonra tekrarladığında çözümü aramakla vakit kaybetmezsin. İşte e-pin satış yazılımı seçerken sorman gereken soru bu: bu sistem bana olay geçmişi bırakıyor mu, yoksa her arıza sıfırdan mı yaşanıyor?
Kurulumun doğru yapıldığını nasıl doğrularsın?
İzleme katmanının en ironik özelliği şudur: test edilmeyen alarm, olmayan alarmdır. Kurulumun ardından bilinçli olarak arıza üret. Bayi API adresini kasten yanlış yaz, kuyruk işçisini durdur, sahte bir ödeme bildirimi gönder. Alarmın kaç saniyede geldiğini, doğru kişiye ulaştığını ve mesajın içinde sipariş numarası olup olmadığını ölç. Ayda bir kez bu provayı tekrarlayan satıcı, gerçek kriz anında hazırlıklı olan tek satıcıdır.
| Kontrol maddesi | Nasıl doğrulanır | Sıklık | Durum |
|---|---|---|---|
| Yapılandırılmış log formatı | Tek satır JSON okunabiliyor mu | Kurulumda | Zorunlu |
| Korelasyon kimliği | Bir siparişin tüm izi tek sorguda çıkıyor mu | Kurulumda | Zorunlu |
| Hassas veri maskesi | Loglarda tam kod / kart aranıyor | Aylık | Zorunlu |
| Sessiz teslimat kontrolü | Bekleyen sipariş sorgusu 5 dk'da çalışıyor | Sürekli | Zorunlu |
| Alarm provası | Kasıtlı arıza + süre ölçümü | Aylık | Önerilir |
| Log saklama süresi | Disk dolmadan döngü (rotation) var mı | Haftalık | Önerilir |
| Olay notu arşivi | Son 10 arızanın kaydı duruyor mu | Aylık | Önerilir |
Arızayı müşteriden önce gören panele geç
Pinova, teslimat kontrollerini, olay kayıtlarını ve bildirim kademelerini hazır sunan lisanslı bir e-pin satış scriptidir. Özellikleri ve lisans paketlerini incele, kurulumu tek günde tamamla.
Hata takip sistemi için ayrı bir sunucu şart mı?
Hayır. Başlangıç için aynı sunucuda dosya tabanlı yapılandırılmış log ve düzenli çalışan kontrol sorguları yeterlidir. Günlük sipariş adedi yükseldiğinde log arşivini ayrı bir depoya taşımak mantıklı olur, ama ilk gün bunun için beklemene gerek yok.
Log dosyaları diski doldurursa ne olur?
Site yazma yapamaz hale gelir ve sipariş kaydı bile düşmeyebilir. Bu yüzden döngüsel arşivleme kur: günlük dosya, sıkıştırma ve 30-90 gün sonra silme. Panelde disk doluluk oranı için de ayrı bir uyarı eşiği tanımla.
Hangi hataları müşteriye göstermeliyim?
Teknik ayrıntıyı asla. Kullanıcıya yalnızca durumu ve bir sonraki adımı söyle: gecikme var, tahmini süre şu, çözülmezse iade otomatik. Dosya yolu, sorgu metni veya sağlayıcı adı içeren hata mesajları hem güven kırar hem güvenlik riski yaratır.
Mevcut e-pin scriptime sonradan eklenebilir mi?
Evet, çoğu durumda kod tabanına dokunmadan bir sarmalayıcı katmanla eklenebilir. Kritik adımlara kayıt noktaları koymak ve bekleyen siparişleri tarayan bir kontrol görevi tanımlamak, ilk aşamanın tamamını oluşturur.
Hata takibi, panelinin en görünmez ama en kârlı parçasıdır: müşteri onu hiç fark etmez, çünkü işi tam olarak müşterinin hiçbir şey fark etmemesini sağlamaktır. Bu katmanın hazır kurulu geldiği bir altyapıyı kendi gözünle görmek istersen özellik listesini ve lisans seçeneklerini incele, ardından canlı demo üzerinde bir sipariş oluşturup kayıtların nasıl aktığını kendin takip et.