Cron ile ilgili en yaygın yanılgı şudur: "Kurdum, çalışıyor, bir daha bakmam gerekmez." Oysa zamanlanmış görevlerin doğası tam tersidir. Bir cron görevi bozulduğunda ekrana kırmızı bir hata basmaz, müşteri seni aramaz, sunucu bir uyarı göndermez. Sadece yapması gereken şeyi yapmaz ve bunu günlerce sessizce sürdürür. Sonucu ancak dolaylı olarak fark edersin: bir bayi "ödemem geçti ama kod gelmedi" diye yazar, kur bir haftalık eski çıkar, rapor rakamları tutmaz.
Bir e-pin satış scriptinde cron üzerinde duran işler tam olarak paranın aktığı yerdir: bekleyen siparişleri işlemek, tedarikçi stoğunu senkronize etmek, ödeme durumunu doğrulamak, kuru güncellemek, iade süresi geçen kaydı kapatmak. Bunlardan biri sessizce dururken site mükemmel çalışır görünür. Bu yazıda kaçan görevleri nasıl tespit edeceğini, hangi durumda alarm kuracağını ve görevleri baştan nasıl "kendini ihbar eden" hâle getireceğini anlatıyorum.
Bir cron görevi tam olarak nasıl sessizce ölür?
Ölüm nedenleri sandığından çeşitlidir. En basiti yol değişikliğidir: PHP sürümünü yükselttin, çalıştırılabilir dosyanın yolu değişti, görev artık "komut bulunamadı" diyerek çıkıyor. İkincisi izin sorunudur; dosya sahibi değişmiş, görev okuma yetkisi bulamıyor. Üçüncüsü bellek ya da süre sınırıdır; iş yükü büyüdükçe görev yarıda kesilmeye başlar ve her seferinde ilk yüz kaydı işleyip ölür.
Daha kurnaz olanı ise kısmi başarısızlıktır. Görev çalışır, çıkış kodu sıfır döner, her şey yolunda görünür; ama içindeki tedarikçi çağrısı zaman aşımına uğramıştır ve hiçbir sipariş işlenmemiştir. Çıkış koduna bakan bir izleme burada seni kurtarmaz. Bu yüzden "görev koştu mu?" sorusu yeterli değildir; "görev işini yaptı mı?" sorusunu sormak zorundasın.
Neden ilk yapman gereken şey her koşuyu kaydetmek?
Görünürlük olmadan güvenilirlik olmaz. Her cron görevi, başlangıcında ve bitişinde veritabanına tek bir satır yazmalı: görev adı, başlangıç zamanı, bitiş zamanı, işlenen kayıt sayısı, durum ve varsa hata mesajı. Bu tablo, sonradan kurulacak her alarmın temelidir. Üstelik maliyeti neredeyse sıfırdır; günde birkaç yüz satır hiçbir sistemi zorlamaz.
Bu kaydı tuttuğun anda üç soruyu anında yanıtlayabilir hâle gelirsin: görev en son ne zaman çalıştı, ortalama ne kadar sürüyor, kaç kayıt işliyor. Kaçan görevi yakalamak da bu noktadan sonra basit bir karşılaştırmaya döner. Ciddi bir dijital ürün satış yazılımında bu görev kayıt tablosu ve yönetim panelindeki durum ekranı standart gelir; kendi kodunu yazıyorsan ilk eklemen gereken şey budur.
| Görev | Önerilen sıklık | Kaçırılırsa etkisi | Alarm eşiği |
|---|---|---|---|
| Bekleyen sipariş işleme | Her dakika | Ödemesi alınmış sipariş teslim edilmez | 5 dakika koşu yoksa |
| Ödeme durumu doğrulama | 2-5 dakika | Geçen ödeme siparişe bağlanmaz | 15 dakika koşu yoksa |
| Tedarikçi stok senkronu | 10-15 dakika | Tükenmiş ürün satılır | 45 dakika koşu yoksa |
| Döviz kuru güncelleme | Saatte bir | Kâr marjı erir veya fiyat şişer | 3 saat koşu yoksa |
| Bayi bakiye mutabakatı | Günde bir | Muhasebe farkı birikir | 36 saat koşu yoksa |
| Yedekleme | Günde bir | Geri dönüş noktası kaybolur | 30 saat koşu yoksa |
| Eski oturum ve geçici dosya temizliği | Günde bir | Disk dolar, site durur | 48 saat koşu yoksa |
Kalp atışı izlemesi kurmadan neden hiçbir şey garanti değil?
Kayıt tutmak geçmişi anlatır, alarm ise geleceği korur. Mantık şu: görev başarıyla bittiğinde bir izleme servisine "yaşıyorum" sinyali gönderir. Beklenen süre içinde sinyal gelmezse servis sana haber verir. Kritik nokta şudur: kontrol eden taraf, izlenen sunucunun dışında olmalıdır. Sunucu tamamen kapandıysa, o sunucuda çalışan bir kontrol betiği de kapalıdır ve hiç kimse bir şey fark etmez.
Dış servis kullanmak istemiyorsan en azından ikinci bir noktadan kontrol et: farklı bir sunucudaki basit bir görev, senin sitenin durum adresini çağırıp en son koşu zamanlarını okusun ve eşik aşıldıysa mesaj göndersin. Bildirim kanalı olarak e-posta yerine anlık mesajlaşma tercih et; e-posta gecikir, spam klasörüne düşer, gece görülmez. Bir sipariş kuyruğunun durduğunu on iki saat sonra öğrenmek, hiç öğrenmemekle neredeyse aynıdır.
İncelenen cron arızalarının kök nedenleri
- Yanlış yol, izin veya sürüm değişikliği 45%
- Zaman aşımı ve bellek sınırı 25%
- Üst üste binen koşu ve kilit yokluğu 20%
- Sunucu saati ve zaman dilimi hatası 10%
Üst üste binen görevler neden kaçan görevden daha pahalı?
Her dakika çalışan bir sipariş işleme görevi düşün. Bir gün kuyruk büyüdü ve görev doksan saniye sürmeye başladı. Artık her dakika yeni bir kopya başlıyor ve önceki henüz bitmemiş. On dakika sonra on kopya aynı kayıtlar üzerinde yarışıyor. Sonuç: aynı siparişe iki kod tahsis edilir, aynı bakiye iki kez düşülür, sunucu yükü çığ gibi büyür. Kaçan görev satışı geciktirir; üst üste binen görev muhasebeyi bozar.
Çözüm her görevi tek koşumlu hâle getirmektir. Görev başlarken bir kilit alır, alamıyorsa sessizce çıkar. Kilit bir dosya kilidi olabilir, veritabanında atomik bir kayıt olabilir, bellek tabanlı bir anahtar olabilir. Hangi yöntemi seçersen seç iki şart vardır: kilidin bir zaman aşımı olmalı, yoksa çöken bir koşu kilidi sonsuza kadar tutar; ve kilit, iş bittiğinde hata durumunda bile mutlaka bırakılmalı.
Bir görev tüm kuyruğu bitirmeye çalışmasın; her koşuda sabit sayıda kayıt işleyip çıksın. Böylece zaman aşımına uğramaz ve kesilse bile bir sonraki koşu kaldığı yerden devam eder. Uzun tek koşu, güvenilirliğin en büyük düşmanıdır.
Zaman dilimi ve sunucu saati seni nasıl aldatır?
Görev gece üçte çalışsın diye ayarladın, ama sunucu farklı bir zaman diliminde. Günlük raporun kesim saati kayıyor, ciro yanlış güne yazılıyor, kampanya bitişi bir saat sarkıyor. Daha kötüsü, uygulamanın zaman dilimi ile sistem saati farklı olduğunda görev kayıtlarındaki zaman damgaları da yanıltıcı hâle gelir ve sorunu ararken saatler harcarsın.
Kural basittir: sunucu ve uygulama aynı zaman dilimini kullansın, veritabanına tüm zamanları tek ve tutarlı biçimde yaz, kullanıcıya gösterirken çevir. Ayrıca saat senkronizasyon servisinin çalıştığından emin ol; kayan bir sistem saati, imza ve zaman damgası doğrulaması yapan ödeme servislerinde doğrudan reddedilmeye yol açar. Bu ayrıntıyı kontrol etmek beş dakika sürer, atlamanın bedeli bir günlük satıştır.
24 saatte kurulabilecek bir denetim planı nasıl olur?
Her şeyi aynı anda mükemmelleştirmeye çalışma. Önce görünürlük, sonra alarm, en son iyileştirme. Aşağıdaki kontrol listesini sırayla uygula; ilk dört madde tek bir akşamda tamamlanabilir ve zaten en büyük riski ortadan kaldırır. Kalan maddeler ise sistemi "kendini ihbar eden" bir yapıya dönüştürür. İşin mantığını ve panel tarafındaki görev ekranını merak ediyorsan özellikler sayfasına bakabilirsin.
| Adım | Ne yapılacak | Doğrulama | Öncelik |
|---|---|---|---|
| 1 | Tüm cron tanımlarını listele ve tek dosyada belgele | Listede olmayan görev kalmadı | Kritik |
| 2 | Her göreve başlangıç-bitiş kaydı ekle | Tabloda son 24 saatin satırları var | Kritik |
| 3 | Her göreve zaman aşımlı kilit koy | Görevi elle iki kez çalıştır, ikincisi çıkıyor | Kritik |
| 4 | Kritik üç görev için dış kalp atışı alarmı kur | Görevi kasten durdur, bildirim geliyor | Kritik |
| 5 | İşlenen kayıt sayısı sıfırsa uyarı üret | Boş koşu uyarısı tetikleniyor | Yüksek |
| 6 | Görevleri parti hâlinde çalışacak şekilde böl | Ortalama süre sınırın altında | Yüksek |
| 7 | Sunucu saati ve zaman dilimini eşitle | Sistem ve uygulama aynı saati raporluyor | Yüksek |
| 8 | Panelde tek ekranda görev durumu göster | Yeşil-kırmızı özet bakışta okunuyor | Orta |
Görev kuyruğunun durduğunu müşteriden öğrenme
Kilitleme, koşu kaydı ve durum ekranı hazır gelen bir e-pin yazılımı ile otomasyonu güvenle arkada bırak.
Paylaşımlı hostingde dakikalık cron yoksa ne yapmalıyım?
Panelde en sık beş dakika veriliyorsa, görevi kendi içinde döngüye alıp kısa aralıklarla birkaç parti işletebilirsin. Alternatif olarak dış bir zamanlayıcı servis, korumalı bir tetikleme adresini istediğin sıklıkta çağırabilir.
Görev çalışıyor ama hiçbir şey işlemiyorsa nasıl anlarım?
Koşu kaydına işlenen kayıt sayısını yaz. Kuyrukta bekleyen iş varken sayı sıfır dönüyorsa bu bir arızadır; çıkış kodu sıfır olsa da uyarı üretmelisin.
Kilit için hangi yöntem en güvenli?
Tek sunucuda dosya kilidi yeterlidir ve bedavadır. Birden fazla sunucu varsa paylaşılan bir kaynakta atomik kayıt gerekir. Her iki durumda da kilide zaman aşımı koy, aksi halde çöken bir koşu görevi kalıcı olarak bloke eder.
Alarmı e-posta ile kurmak yeterli mi?
Kritik görevler için değil. E-posta gecikir ve gözden kaçar. Sipariş işleme veya ödeme doğrulama gibi görevlerde anlık mesaj bildirimi kullan; günlük temizlik işleri için e-posta yeterlidir.
Otomasyon, çalıştığını kanıtlayabildiğin sürece güvenilirdir. Görev kaydı, kilit ve dış alarm üçlüsünü kurduğunda cron artık belirsiz bir kara kutu olmaktan çıkar ve panelde okunabilir bir duruma dönüşür. Bu yapının hazır hâlini görmek, görev durum ekranının nasıl okunduğunu denemek istersen canlı demo üzerinden yönetim tarafını gez; uygun paketi ise fiyat tablosunda karşılaştırabilirsin.