Çoğu bayi, sitesinin ayakta olup olmadığını anlamanın yolunun tarayıcıda ana sayfayı açmak olduğunu sanır. Ana sayfa açılıyorsa her şey yolunda, açılmıyorsa sunucu çökmüş. Oysa e-pin işinde en pahalı kesintiler ana sayfayı hiç etkilemez: ana sayfa pırıl pırıl yüklenir, kategori sayfaları gezilir, sepete ürün eklenir ve sadece ödeme dönüşü ile stok teslimi arasındaki o üç saniyelik kanal sessizce kopmuştur. Müşteri parayı ödemiştir, kodu alamamıştır ve senin panelinde hiçbir kırmızı ışık yanmaz.
Gerçek şu: bir e-pin satış scripti tek parça değildir. Web sunucusu, veritabanı, ödeme sağlayıcısı, tedarikçi API'si, SMS/mail çıkışı ve cron işçisi ayrı ayrı yaşayan altı organdır. Altısından biri durduğunda site "açık" görünmeye devam eder. Bu yüzden profesyonel bir e-pin yazılımı kurulumunda ilk yapılan iş tasarım değil, nabız ölçümüdür. Bu yazıda kesintiyi müşteriden önce görmenin, doğru uç noktaları seçmenin ve gece 3'te telefonunu doğru sebeple çaldırmanın sistemini kuruyoruz.
Ana sayfa açılıyor diye siten çalışıyor mu gerçekten?
HTTP 200 dönmesi, işinin yürüdüğü anlamına gelmez. PHP çalışıyor, şablon basılıyor, hatta önbellekten servis ediliyor olabilir. Veritabanı bağlantısı düşmüşse ana sayfa önbellekten gelir, ürün listesi boş görünür ve müşteri "stok yok" sanıp gider. Yani en tehlikeli kesinti, dışarıdan bakınca kesinti gibi durmayan kesintidir.
Bunun çözümü, izlemeyi ana sayfadan alıp işin kalbine taşımaktır. Scriptin içine, dışarıya kapalı ama izleme aracına açık bir sağlık uç noktası koyarsın. Bu uç nokta sadece "ben ayaktayım" demez; veritabanına gerçek bir sorgu atar, bir tedarikçi bakiyesi okur, kuyrukta bekleyen sipariş sayısını sayar ve sonucu makine okunur biçimde döner. Böylece tek bir istek, altı organın hepsini yoklar.
Uç noktanın kuralı katıdır: hızlı olmalı, yazma işlemi yapmamalı, tahmin edilemez bir adreste durmalı ve bozukken 200 dönmemelidir. Sağlık kontrolünün en sık yapılan hatası, her şey yanmışken bile gururla "OK" yazan bir sayfa yazmaktır.
Hangi uç noktayı, hangi sıklıkla yoklamalısın?
İzlemenin maliyeti sıklıkla artar, faydası ise doğru seçimle artar. Ödeme dönüş adresini 30 saniyede bir yoklamak mantıklıdır; çünkü orada yaşanan bir dakikalık arıza doğrudan tahsil edilmiş ama teslim edilmemiş sipariş demektir. Buna karşılık blog sayfasını beş dakikada bir kontrol etmek yeterlidir. İzleme bütçesini paranın aktığı yola harca.
Bir dijital ürün satış scripti için asgari izleme seti şudur: sağlık uç noktası, sepet/ödeme başlatma akışı, ödeme sağlayıcısından gelen bildirim adresi, tedarikçi API yanıt süresi, cron işçisinin son çalışma zamanı ve SSL sertifikası kalan gün sayısı. Bu altısı kurulduğunda kesintilerin büyük bölümünü müşteri değil sen görürsün.
| İzlenen nokta | Kontrol sıklığı | Sağlıklı eşik | Kaçırılırsa bedeli |
|---|---|---|---|
| Sağlık uç noktası | 60 saniye | 200 + yanıt < 800 ms | Tüm site erişilemez, satış sıfır |
| Ödeme bildirim adresi | 30 saniye | 200, kuyruk gecikmesi < 60 sn | Tahsil edilen ama teslim edilmeyen sipariş |
| Tedarikçi API | 2 dakika | Yanıt < 3 sn, hata < %1 | Otomatik teslimat durur, manuel yığın oluşur |
| Cron işçisi kalp atışı | 5 dakika | Son çalışma < 10 dk önce | Sipariş kuyrukta bekler, iade talebi gelir |
| Veritabanı bağlantısı | 60 saniye | Aktif bağlantı < %70 limit | Boş kategori, "stok yok" görünümü |
| SSL sertifikası | Günlük | Kalan gün > 14 | Tarayıcı uyarısı, dönüşümün çökmesi |
Kalp atışı mantığını kurmadan cron'a güvenmek neden intihar?
Cron işleri sessizce ölmenin ustasıdır. PHP belleği taşar, kilit dosyası kalır, sunucu yeniden başlar ve cron bir daha hiç çalışmaz. Kimse fark etmez; çünkü hata mesajı üretmeden durmak hata üretmekten sessizdir. Buna karşı tek koruma ters mantıkla izlemedir: cron çalıştığında bir zaman damgası yazar, izleme aracı da "bu damga tazelenmiyorsa alarm ver" der.
Bu yaklaşımın güzelliği, cron'un başarısını değil sessizliğini alarma çevirmesidir. Bir e-pin satış yazılımı kurarken her zamanlanmış iş için ayrı damga tut: sipariş teslim işçisi, stok senkronizasyonu, bakiye kontrolü, fatura gönderimi, yedekleme. Hepsi tek damgayı paylaşırsa biri öldüğünde diğerleri onu gizler.
Bayi kesintilerinin gerçek kaynak dağılımı
- Tedarikçi ve ödeme API'si 45%
- Cron ve kuyruk durması 25%
- Veritabanı ve kaynak limiti 20%
- Ağ, DNS ve sertifika 10%
Alarmı kime, nasıl ve kaç kere çaldırmalısın?
İzlemenin öldüğü yer alarm yorgunluğudur. Gün içinde on dört bildirim alan kişi on beşinciyi okumaz. Bu yüzden alarmı iki katmana ayır: uyandıran ve bilgilendiren. Ödeme akışı ve sağlık uç noktası uyandırır; telefonla, sesle, tekrar tekrar. Tedarikçi yavaşlığı ya da sertifika süresi bilgilendirir; tek bir mesajla, sabaha kalabilir.
İkinci kural teyittir. Tek başarısız istekle alarm çaldırırsan ağdaki bir hıçkırık seni gece uyandırır. Üç ardışık başarısızlık ve iki farklı konumdan doğrulama iste. Üçüncü kural iyileşme bildirimi göndermektir: sorunun bittiğini bilmeden sabaha kadar telefona bakan insan, ertesi gün satış yapamaz.
Kesinti olduğunda müşteriye ne göstereceksin?
İzleme sadece seni bilgilendirmek için değil, müşteriyi yönetmek için de vardır. Sağlık kontrolü tedarikçi API'sinin düştüğünü gördüğü anda, ilgili ürün grubunu otomatik olarak "geçici olarak teslim edilemiyor" durumuna alabilirsin. Böylece müşteri parayı ödeyip beklemek yerine, ödemeden önce durumu görür. Alınmamış sipariş, iade edilen siparişten her zaman kârlıdır.
Pinova'nın yaklaşımı burada net: izleme verisini yalnızca bir gösterge tablosu süsü olarak tutmaz, otomatik kararlara bağlar. Yavaşlayan tedarikçi yedeğine düşer, ölçüm eşiği aşıldığında manuel teslim kuyruğu açılır ve müşteriye gerçek durum gösterilir. İzleme, raporlama işi olmaktan çıkıp çalışma zamanı savunması haline gelir.
Nereden başlamalısın: üç günlük kurulum planı
Birinci gün ölçümü kur: sağlık uç noktası, cron kalp atışları ve dış izleme hesabı. İkinci gün eşikleri kalibre et; bir gün gerçek trafikle çalıştırıp normal yanıt sürelerini gör, eşiği ortalamanın iki katına koy. Üçüncü gün senaryo tatbikatı yap: veritabanı şifresini bilinçli olarak boz, tedarikçi anahtarını geçersiz kıl, cron'u durdur ve alarmların gerçekten geldiğini doğrula.
Bu tatbikat adımını atlayan bayilerin yarısı, gerçek kesinti gününde alarmın hiç kurulu olmadığını öğrenir. Test edilmemiş izleme, izleme değildir.
| Kontrol maddesi | Durum | Sorumlu | Doğrulama yöntemi |
|---|---|---|---|
| Gizli sağlık uç noktası yayında | Zorunlu | Teknik | Bozuk DB ile 503 döndüğü görüldü |
| Her cron için ayrı kalp atışı | Zorunlu | Teknik | Cron durdurulup alarm alındı |
| Ödeme bildirim adresi izleniyor | Zorunlu | İşletme | 30 sn aralıkla kayıt görülüyor |
| İki katmanlı alarm ayrımı | Zorunlu | İşletme | Kritik sesli, diğeri mailde |
| Tedarikçi düşünce otomatik ürün kapatma | Önerilir | Teknik | Anahtar bozuldu, ürün kapandı |
| SSL ve alan adı süre takibi | Önerilir | İşletme | 14 gün öncesi uyarı testi |
| Aylık kesinti raporu | Önerilir | İşletme | Uptime yüzdesi arşivde |
Sadece "OK" dönen bir sayfa işe yaramaz. Uç nokta veritabanı gecikmesini, kuyruk uzunluğunu, son cron zamanını ve tedarikçi durumunu ayrı alanlar halinde dönerse, alarm geldiğinde neye bakacağını bilerek müdahale edersin; on beş dakikayı arıza aramaya değil çözmeye harcarsın.
Nabzı ölçen bir altyapıyla sat
Pinova, sağlık kontrolü, kalp atışı takibi ve tedarikçi düşünce otomatik koruma davranışını kutudan çıktığı gibi getirir. Kesintiyi müşterinden önce görmek için sıfırdan sistem yazman gerekmez.
Sağlık kontrolü uç noktasını herkese açık bırakmak riskli mi?
Evet. İçinde sürüm, kuyruk ve bağlantı bilgileri olduğu için tahmin edilemez bir adres ve gizli anahtar şartıdır. İzleme aracına anahtarı ver, geri kalan tüm isteklere 404 dön.
Ücretsiz izleme servisleri e-pin işi için yeterli mi?
Başlangıç için yeterli olabilir ama çoğu 5 dakikadan sık kontrol yapmaz. Ödeme akışı gibi kritik noktalarda 30-60 saniyelik kontrol gerekir; orada ücretli plan ya da kendi sunucundan ikinci bir kontrol devreye girmelidir.
Kesinti yaşandığında müşteriye haber vermek güven kaybettirir mi?
Tersine. Sessiz kalıp teslim etmemek güven kaybettirir. "Tedarikçi kaynaklı gecikme var, siparişin kuyrukta" diyen otomatik bilgilendirme, iade talebini ve olumsuz yorumu ciddi biçimde azaltır.
Kaç kesintiye kadar normal sayılır?
Aylık %99,5 çalışma süresi yaklaşık 3,5 saatlik kesintiye denk gelir ve bu e-pin işi için yüksektir. Hedefi %99,9 koy, ama daha önemlisi kesintinin ne kadar sürede fark edildiğini ölç; fark etme süresi 5 dakikanın altına inmelidir.
İzleme, sonradan eklenen bir eklenti değil; altyapının ilk günden taşıdığı bir alışkanlıktır. Hangi uç noktaların hazır izlendiğini, kalp atışı ekranının nasıl göründüğünü ve tedarikçi düştüğünde ürünlerin nasıl otomatik korunduğunu kendi gözünle görmek istersen canlı demo üzerinden panele gir, özellikler listesinde teknik başlıkları karşılaştır; sonra fiyat tarafına bakarsın.