Çoğu kişi e-pin panelini kurduğu gün işin bittiğini sanır. Tema oturmuş, ödeme geçidi bağlanmış, ürünler yüklenmiş, ilk test siparişi düşmüş. Vitrin çalışıyor, demek ki sistem çalışıyor. Oysa bir e-pin scripti tek motorla dönmez; iki ayrı motorla döner. Birincisi müşterinin tıkladığı web katmanıdır, ikincisi ise kimsenin görmediği zamanlayıcı katmanıdır. İkincisi durduğunda site hâlâ "açık" görünür, ödeme sayfası hâlâ çalışır, ama içeride hiçbir şey ilerlemez.
İfşa kısmı şu: satıcıların önemli bir bölümü cron görevlerini hiç kurmuyor. Kuranların bir kısmı da yanlış PHP yolu, yanlış sistem kullanıcısı veya yanlış periyotla kuruyor. Sonuç hep aynı biçimde ortaya çıkar: gündüz her şey normaldir, çünkü trafik var ve bazı görevler istek üstünde tetiklenir; gece yarısı trafik kesildiğinde bekleyen siparişler, tedarikçi senkronizasyonu, iade kontrolleri ve e-posta kuyruğu olduğu yerde kalır. Sabah "dün akşamki siparişim gelmedi" mesajıyla uyanırsın. Bu yazıda bir dijital ürün satış scripti için cron katmanını sıfırdan, doğru sırayla ve izlenebilir biçimde nasıl kuracağını anlatıyorum.
Cron'u "ek özellik" sanıyorsun, aslında satışın kalp atışı
Panel arayüzü senin gördüğün yüzdür; cron ise nabızdır. Bir müşteri ödemeyi tamamladığında akış genellikle şöyle biter: ödeme geçidi bildirimi düşer, sipariş "ödendi" durumuna geçer, sonra teslimat kuyruğuna girer. Kuyruğu boşaltan şey web isteği değil, zamanlanmış görevdir. Aynı şey stok senkronizasyonu, tedarikçi bakiye kontrolü, düşük stok uyarısı, fatura numaralandırma, terk edilmiş sepet hatırlatması ve günlük temizlik işleri için de geçerlidir.
Buradaki tuzak, geliştiricinin "ihtiyat amaçlı" koyduğu yedek tetikleyicilerdir. Birçok epin yazılım kurulumunda kuyruk, ziyaretçi sayfa açtığında da bir miktar işlenir. Bu yüzden cron hiç kurulmasa bile gündüz sistem sağlıklı görünür. Gerçek testi gece yapmalısın: saat 03:00'te sipariş ver, sekmeyi kapat ve hiçbir sayfa açmadan bekle. Teslimat 60 saniye içinde düşmüyorsa cron katmanın yok demektir, çalışıyor sanıyorsundur.
Hangi görevler gerçekten zamanlanmalı, hangileri süs?
Her görev eşit değildir. Bazıları gecikirse müşteri fark etmez, bazıları gecikirse doğrudan iade talebi doğurur. Kurulumu yaparken önce kritiklik sırasına göre yaz, sonra periyotları belirle. Aşağıdaki tablo, tipik bir e-pin satış scripti için sağlıklı bir başlangıç şemasıdır.
| Görev | Önerilen periyot | Kritiklik | Gecikirse ne olur? |
|---|---|---|---|
| Sipariş / teslimat kuyruğu işleyici | Her dakika | Çok yüksek | Ödeme alındı, kod gitmedi; iade ve şikâyet |
| Ödeme durumu doğrulama (bekleyenler) | 5 dakika | Yüksek | Bildirim kaçan siparişler askıda kalır |
| Tedarikçi stok ve fiyat senkronizasyonu | 10-15 dakika | Yüksek | Stokta olmayan ürünü satarsın, zararına satış |
| E-posta / SMS kuyruğu gönderimi | 2-5 dakika | Orta | Kod teslim olur ama müşteri haberdar olmaz |
| Düşük stok ve bakiye uyarıları | Saatlik | Orta | Kritik ürün sessizce tükenir |
| Oturum, geçici dosya ve log temizliği | Günlük (gece) | Düşük | Disk şişer, panel yavaşlar |
| Rapor derleme ve özet e-posta | Günlük 08:00 | Düşük | Yönetim körleşir, karar gecikir |
Dikkat etmen gereken nokta, her şeyi "her dakika"ya bağlama isteğidir. Tedarikçi API'sini dakikada bir dövmek genellikle oran sınırına (rate limit) çarpar ve IP'n geçici olarak engellenir. Kritik olanı sık, ağır olanı seyrek çalıştır; ağır işleri ayrıca gece penceresine kaydır.
Cron kaynaklı arızaların kök nedeni dağılımı
- Yanlış PHP yolu / eksik ortam 40%
- Görev hiç kurulmamış 30%
- Üst üste binme, kilit yok 20%
- Zaman dilimi hatası 10%
Web cron mu, sistem cron mu? İkisi aynı şey değil
İki yöntem var ve aralarındaki fark, arızaların yarısını açıklar. Birinci yöntem web cron'dur: bir URL'yi gizli anahtarla çağırırsın, örneğin curl -s "https://alanadin.com/cron.php?key=UZUN_GIZLI_ANAHTAR". Paylaşımlı hostingte kolaydır ama web sunucusunun zaman aşımına, bellek sınırına ve eş zamanlı istek limitine tabidir. Uzun süren bir senkronizasyon 30 saniyede kesilir ve yarım kalır.
İkinci yöntem sistem cron'dur: PHP'yi komut satırından çağırırsın. Zaman aşımı yoktur, bellek sınırı ayrıdır, hata çıktısı doğrudan dosyaya akar. Doğru kayıt şöyle görünür: * * * * * /usr/local/bin/php -q /home/kullanici/public_html/cron/queue.php >> /home/kullanici/logs/queue.log 2>&1. Buradaki üç detay hayat kurtarır: PHP'nin tam yolu (sadece php yazarsan sunucuda eski bir 7.x sürümü çalışabilir), betiğin tam yolu (cron senin ev dizininde değildir) ve çıktının log'a yönlendirilmesi. Son parçayı atlarsan hata mesajları ya sistem postasına gider ya buharlaşır; ikisi de aynı kapıya çıkar, yani hiçbir şey görmezsin.
Cron kaydını yazmadan önce SSH veya panel terminalinden which php yerine php -v ve ls /usr/local/bin/php* çıktısına bak. Sunucuda çoğu zaman birden fazla sürüm bulunur ve cron, web'in kullandığı sürümü otomatik olarak miras almaz. Betik web'de çalışıp cron'da "syntax error" veriyorsa suçlu neredeyse her zaman budur.
Üst üste binme: çift teslimatın asıl sebebi
Kuyruk işleyicisini dakikada bir çalıştırıyorsun ve bir gün tedarikçi API'si yavaşlıyor. Görev 90 saniye sürüyor; ikinci kopya birinci bitmeden başlıyor. İki kopya aynı siparişi görüyor ve aynı e-pini iki defa teslim ediyor. Bu, doğrudan para kaybıdır ve genellikle "script hatalı" diye yorumlanır; oysa eksik olan tek satırlık bir kilittir.
En pratik çözüm işletim sistemi düzeyinde kilitlemedir: * * * * * /usr/bin/flock -n /tmp/pnv_queue.lock /usr/local/bin/php /yol/cron/queue.php >> /yol/logs/queue.log 2>&1. flock -n, kilit meşgulse ikinci kopyayı sessizce iptal eder. Uygulama tarafında ise sipariş satırlarını SELECT ... FOR UPDATE veya durum damgası ("işleniyor" + zaman) ile işaretlemek gerekir. Pinova gibi olgun bir e-pin yazılımı bu korumayı kendi kuyruk katmanında taşır; yine de sunucu tarafındaki kilidi eklemek ikinci bir emniyet kemeridir ve maliyeti yoktur. Yazılımın kuyruk ve teslimat mimarisini özellikler bölümünde inceleyebilirsin.
Zaman dilimi, kullanıcı ve izin: sessiz üç tuzak
Sistem cron'u sunucunun saatiyle çalışır, PHP ise date.timezone ayarıyla. İkisi farklıysa "her gece 03:00" dediğin rapor 00:00'da koşar ve önceki günün son üç saatini dışarıda bırakır. Rakamlar tutmaz, sen de veritabanını suçlarsın. Çözüm basit: cron kaydında saat mantığına güvenme, betiğin içinde zaman aralığını açıkça Europe/Istanbul'a sabitle.
İkinci tuzak kullanıcıdır. Cron'u root ile kurarsan oluşturduğu dosyalar root'a ait olur; web sunucusu sonra bu dosyaları okuyamaz veya yazamaz. Sipariş PDF'i üretilir ama müşteri indiremez. Kural: cron'u web sunucusunun çalıştığı kullanıcıyla aynı hesaptan kur. Üçüncü tuzak da izinlerdir; cron/ klasörünün dışarıdan doğrudan çağrılamaması, anahtar denetiminin ve php_sapi_name() kontrolünün bulunması gerekir. Aksi halde kuyruk uç noktanı bulan biri onu saniyede yüzlerce kez tetikleyerek sunucunu boğabilir.
Kurulum sonrası kontrol listesi ve sessiz ölümü duyma yöntemi
Cron'un en kötü özelliği sessiz ölmesidir. Bir gün hosting firması PHP sürümünü yükseltir, yol değişir, görev çalışmaz ve kimse bir şey görmez. Bu yüzden her kritik görev bittiğinde bir kalp atışı bırakmalı: veritabanına son çalışma zamanı yazmalı, panelde kırmızı bir uyarı göstermeli ve tercihen harici bir izleme servisine ping atmalı. Kural şu: "çalıştı" bildirimini izlemeye çalışma, çalışmadı durumunu alarma bağla.
| Kontrol | Nasıl doğrulanır | Beklenen sonuç | Durum |
|---|---|---|---|
| PHP ikilisinin tam yolu | Cron satırındaki yolu terminalde elle çalıştır | Betik hatasız biter, log'a satır düşer | Zorunlu |
| Log yönlendirmesi | 2>&1 ile dosyaya yazılıyor mu? | Her koşuda tarih damgalı kayıt | Zorunlu |
| Kilitleme | Görevi iki terminalde aynı anda başlat | İkincisi devreye girmez | Zorunlu |
| Gece teslimat testi | Trafik yokken sipariş ver, sayfa açma | 60-120 sn içinde teslim | Zorunlu |
| Kalp atışı kaydı | Panelde son çalışma zamanı görünüyor mu? | Sapma 2 periyodu geçmiyor | Önerilir |
| Zaman dilimi tutarlılığı | Sunucu saati ile rapor aralığını karşılaştır | Fark yok | Önerilir |
| Uç nokta güvenliği | Anahtarsız URL'yi tarayıcıdan çağır | 403 veya boş yanıt | Zorunlu |
| Ağır görevlerin gece penceresi | Rapor ve temizlik saatlerini ayır | Yoğun saatte CPU tepesi yok | Önerilir |
Bu listeyi kurulum gününde bir kez geçirmek, sonraki altı ayın destek yükünü ciddi biçimde düşürür. Özellikle "gece teslimat testi" satırını atlama; tek başına en çok gizli arızayı açığa çıkaran adım odur.
Kuyruğu kendi başına ayakta tutan bir altyapı istiyorsan
Pinova, sipariş kuyruğu, tedarikçi senkronizasyonu ve kalp atışı izlemesini hazır getirir; sen sadece tek bir cron satırı kurarsın. Paketleri ve fiyatlandırmayı incele.
Paylaşımlı hostingte sistem cron kurulamıyorsa ne yapmalıyım?
cPanel veya benzeri panellerin "Cron Jobs" bölümü zaten sistem cron'udur; sadece arayüzden yönetilir. Hiç erişimin yoksa web cron kullan, ama uzun görevleri küçük parçalara böl ve her çağrıda sınırlı sayıda kayıt işle. Böylece zaman aşımına yakalanmazsın.
Dakikada bir çalışan görev sunucumu yorar mı?
Doğru yazılmış bir kuyruk işleyici, yapacak iş yoksa milisaniyeler içinde çıkar. Yük, periyottan değil, her koşuda gereksiz sorgu ve dış API çağrısı yapılmasından doğar. Boş kuyrukta erken çıkış mantığı varsa dakikalık tetikleme rahatça kaldırılır.
Cron çalıştığını nasıl kesin olarak anlarım?
Log dosyasına bakmak yeterli değildir, çünkü dosya eskiyse fark etmezsin. Panelde "son çalışma" damgasını göster ve iki periyot geçtiği halde güncellenmediyse uyarı üret. Harici bir kalp atışı izleme servisi eklersen sunucu tamamen düştüğünde bile haberdar olursun.
Birden fazla cron görevini tek satırda birleştirmek doğru mu?
Hayır. Birleştirirsen ağır bir görev, kritik kuyruk işleyicisini bekletir ve biri hata verdiğinde diğerleri de koşmaz. Her görev kendi kaydında, kendi periyodunda ve kendi kilidiyle çalışmalı; sadece log dosyalarını ortak tutabilirsin.
Cron katmanı, e-pin işinde görünmeyen ama en pahalı parçadır: doğru kurulduğunda hiç konuşulmaz, yanlış kurulduğunda her şey onun yüzünden konuşulur. Kuyruk işleyiciyi kilitle, PHP yolunu doğrula, saati sabitle ve kalp atışını izle. Bu dört adımı hazır getiren bir altyapıyı kendi gözünle görmek istersen canlı demo üzerinden sipariş akışını baştan sona takip edebilir, teslimatın arka planda nasıl ilerlediğini kendi testinle doğrulayabilirsin.