Zamanlanmış görevler, bir satış altyapısının en sessiz parçasıdır. Çalıştıklarında kimse fark etmez; durduklarında ise stok senkronize olmaz, bekleyen siparişler kapanmaz, kur güncellenmez, terk edilmiş sepet e-postası gitmez. Çoğu işletme sahibi bunu hafta sonu bir bayinin şikâyetiyle öğrenir ve ilk baktığı yer panelin "görevler" ekranı olur. Ekran yeşildir, "her 5 dakikada" yazar, her şey yolunda görünür.
Burada kritik bir yanılgı var: panelde tanımlı bir görev, çalışan bir görev değildir. Panel yalnızca ne yapılması gerektiğini bilir; onu gerçekten tetikleyen mekanizma sunucudadır ve o mekanizma çoğu zaman sessizce ölür. Bu yazıda bir e-pin satış scripti kurulumunda cron'un neden çalışmadığını sırayla eleyeceğiz ve görevlerin bir daha fark edilmeden durmaması için kurman gereken izleme düzenini anlatacağım.
Görev tanımlı ama tetikleyici var mı?
İlk ayrımı netleştirmeden hiçbir şey çözülmez. İki ayrı dünya var: scriptin kendi görev listesi ve sunucunun zamanlayıcısı. Script içindeki liste bir yapılacaklar defteridir. Sunucudaki zamanlayıcı ise bu defteri belirli aralıklarla açıp okuyan kişidir. Kimse defteri açmıyorsa, defterin ne kadar düzenli olduğu önemsizdir.
Bunu doğrulamanın yolu, görevlerin son çalışma zamanına bakmaktır. Tüm görevlerde son çalışma boş ya da günler öncesiyse, sorun görevlerde değil tetikleyicinin hiç kurulmamış veya silinmiş olmasındadır. Barındırma paneli taşındığında, hesap yenilendiğinde veya dosyalar yeni bir dizine kopyalandığında zamanlayıcı kaydı çoğu zaman geride kalır ve kimse kontrol etmez.
PHP'yi web sunucusundan değil komut satırından çağırıyorsun: bu her şeyi değiştirir
Zamanlanmış işler tarayıcı üzerinden değil komut satırından koşar. Bu ortam web ortamından farklıdır: farklı bir yapılandırma dosyası, farklı eklenti kümesi, farklı bellek ve süre sınırları, farklı çalışma dizini ve çok daha kısıtlı ortam değişkenleri. Web tarafında sorunsuz çalışan bir epin yazılım görevi, komut satırında eksik bir eklenti yüzünden ilk satırda düşebilir.
En sık görülen üç tuzak şunlardır. Birincisi, komutta genel bir php çağrısı kullanmak; sunucuda birden fazla sürüm varsa yanlış sürüm seçilir. İkincisi, göreli dosya yolu vermek; çalışma dizini beklediğin yer olmadığı için dosya bulunamaz. Üçüncüsü, komut satırında yasaklanmış fonksiyonlara bağımlı olmak. Çözüm hepsinde aynı: sürümü açıkça belirten tam yorumlayıcı yolu ve tam betik yolu kullan.
| Belirti | Olası neden | Nasıl doğrulanır | Çözüm |
|---|---|---|---|
| Hiçbir görev hiç çalışmamış | Zamanlayıcı kaydı yok | Sunucudaki görev listesini listele | Tetikleyiciyi tam yollarla yeniden kur |
| Görev anında bitiyor, iş yapılmıyor | Yanlış PHP sürümü veya eksik eklenti | Komutu elle çalıştır, çıktıyı oku | Sürümü açık belirten tam yorumlayıcı yolu |
| Dosya bulunamadı hatası | Göreli yol ve farklı çalışma dizini | Çalışma dizinini yazdır | Betikte kök dizini sabitle |
| Görev başlıyor ama yarıda kesiliyor | Süre veya bellek sınırı | Son işlenen kaydı bul | İşi küçük yığınlara böl |
| Görevler birbirini bekliyor | Üst üste binme, kilit yok | Aynı anda kaç örnek koşuyor | Dosya kilidiyle tek örnek garantisi |
| Saatler yanlış tetikleniyor | Sunucu ve uygulama saat dilimi farklı | Her iki tarafın saatini karşılaştır | Saat dilimini tek noktada sabitle |
| Hata var ama hiç görünmüyor | Çıktı boşluğa yönlendirilmiş | Yönlendirme ifadesini incele | Çıktıyı kalıcı bir günlüğe yaz |
Üst üste binen görevler: sessiz ölümün en yaygın biçimi
Beş dakikada bir koşan bir görev, bazı günlerde yedi dakika sürer. Zamanlayıcı beklemez; yenisini başlatır. İki örnek aynı kayıtlar üzerinde çalışır, veritabanı kilitleri birikir, süre daha da uzar, üçüncüsü başlar. Kısa süre içinde onlarca örnek birbirini bekler ve sistem bunu "cron çalışmıyor" olarak yansıtır. Gerçekte cron fazlasıyla çalışıyordur.
Doğru desen basittir: her görev başlarken kendine ait bir kilit alır, alamıyorsa hiçbir şey yapmadan çıkar ve bittiğinde kilidi bırakır. Kilit dosyasına başlangıç zamanı da yazılırsa, sıkışmış bir örneği makul bir eşikten sonra temizlemek mümkün olur. Olgun bir dijital ürün satış scripti bu tek örnek garantisini görev çatısının içinde barındırır; her göreve tek tek eklemeyi sana bırakmaz.
Cron arızalarının kök neden dağılımı
- Ortam ve yol hataları 40%
- Üst üste binme ve kilitlenme 30%
- Sınır aşımı ve yarıda kesilme 20%
- Saat dilimi ve zamanlama 10%
Hataları görmüyorsan, olmadıklarını sanırsın
Zamanlanmış görevlerin en tehlikeli alışkanlığı, çıktının tamamen bastırılmasıdır. Gelen e-posta bildirimlerinden rahatsız olan çoğu kişi tüm çıktıyı boşluğa yönlendirir. O andan sonra görev her koşuşunda ölümcül hata verse bile hiçbir iz kalmaz. Ekran sessizdir, senin için "her şey normal" demektir.
Yapılması gereken şey çıktıyı susturmak değil, yönlendirmektir. Her görev kendi günlüğüne başlangıç zamanını, işlediği kayıt sayısını, süresini ve varsa hata özetini yazmalı. Bunun üstüne bir de görev tablosuna son başarılı çalışma zamanı düşülmeli. Bu iki kayıt birlikte, hangi görevin ne zaman ve neden durduğunu tahmine gerek bırakmadan söyler.
Kalp atışı kurmadıysan arızayı hep müşteriden öğrenirsin
Görevlerin durduğunu üç gün sonra öğrenmenin tek nedeni, kimsenin onları izlememesidir. Çözüm şaşırtıcı derecede basittir: her görev başarıyla bittiğinde bir kalp atışı kaydı bırakır; ayrı ve çok basit bir denetleyici, beklenen aralığın iki katı süredir atış gelmeyen görevleri sana bildirir. Böylece "cron çalışmıyor" cümlesini müşteriden değil sistemden duyarsın.
İkinci güvenlik kemeri, önemli görevleri tek zamanlayıcıya bağımlı bırakmamaktır. Kritik akışlar için ek bir tetikleyici yolu bırakılır; bu yol yalnızca gizli bir anahtarla çağrılabilir, çağrı sayısı sınırlanır ve her çağrı günlüğe yazılır. Böylece barındırma tarafındaki zamanlayıcı kaybolsa bile ana akış durmaz. Ciddi bir e-pin satış yazılımı bu yedekli tetiklemeyi standart olarak sunar.
Önce komutu elle çalıştır ve çıktıyı oku. Elle çalışıyor ama zamanlayıcıyla çalışmıyorsa sorun kesinlikle ortamdadır: yol, sürüm, izin veya çalışma dizini. Elle de çalışmıyorsa sorun betiğin kendisindedir. Bu tek ayrım arama alanını yarıya indirir.
Bir daha aynı yere düşmemek için hangi kuralları koymalısın?
Zamanlanmış görevler, kurulduktan sonra unutulmaya en müsait bileşendir. Bu yüzden onları kendi kendini bildiren yapılar haline getirmek gerekir. Aşağıdaki listeyi kurulumuna uygula; her satır, gece yarısı gelen bir şikâyeti önleyen somut bir önlemdir.
| # | Kontrol | Neyi önler | Sıklık |
|---|---|---|---|
| 1 | Tam yorumlayıcı ve tam betik yolu kullanılıyor | Yanlış sürüm ve dosya bulunamadı | Kurulumda |
| 2 | Komut satırı eklentileri doğrulandı | İlk satırda sessiz ölüm | Kurulumda |
| 3 | Her görevde tek örnek kilidi var | Üst üste binme ve kilitlenme | Kurulumda |
| 4 | Çıktı kalıcı günlüğe yazılıyor | Görünmez hatalar | Kurulumda |
| 5 | Son başarılı çalışma zamanı kaydediliyor | Teşhis körlüğü | Sürekli |
| 6 | Kalp atışı denetleyicisi bildirim gönderiyor | Geç fark etme | Sürekli |
| 7 | Uzun işler yığınlara bölünmüş | Süre ve bellek kesilmeleri | Kurulumda |
| 8 | Saat dilimi tek noktadan sabit | Yanlış saatte tetikleme | Kurulumda |
| 9 | Kritik akışlar için yedek tetikleyici | Tek noktaya bağımlılık | Kurulumda |
Zamanlanmış görevler kendini bildirmiyorsa yoktur
Pinova'nın görev çatısı tek örnek kilidi, görev bazlı günlük, son çalışma takibi ve kalp atışı bildirimi ile gelir. Ayrıntıları özellikler bölümünde, paketleri fiyat bölümünde inceleyebilirsin.
Panelde görev tanımlı görünüyor, neden çalışmıyor?
Panel yalnızca görevin tanımını tutar; onu tetikleyen zamanlayıcı sunucu tarafındadır. Sunucudaki kayıt silinmiş veya hiç kurulmamışsa panel yeşil görünmeye devam eder ama hiçbir şey koşmaz.
Komutu elle çalıştırınca çalışıyor, zamanlayıcıyla çalışmıyor. Nedeni ne?
Neredeyse her zaman ortam farkıdır: farklı PHP sürümü, farklı çalışma dizini, eksik ortam değişkeni veya izin problemi. Tam yollar kullanmak ve betikte kök dizini sabitlemek çoğu vakayı çözer.
Görevleri ne sıklıkta çalıştırmalıyım?
Sipariş durumu ve teslimat gibi kritik işler için bir ile beş dakika arası uygundur. Rapor ve temizlik işleri saatlik veya günlük olabilir. Önemli olan sıklık değil, görevin süresinin aralığından kısa olmasıdır.
Tek zamanlayıcıya güvenmek riskli mi?
Evet. Barındırma tarafındaki bir değişiklik zamanlayıcıyı sessizce düşürebilir. Kritik akışlar için anahtarla korunan yedek bir tetikleme yolu ve kalp atışı izlemesi bu riski ortadan kaldırır.
Zamanlanmış görevler bir dijital ürün satış yazılımı için motorun yağ pompasıdır: görünmez, ama durduğu anda her şey sıcak çalışmaya başlar. Yukarıdaki dokuz maddeyi kendi kurulumunda tek tek işaretle, ardından görev günlüğü ve kalp atışı izlemesinin doğru kurulmuş halini canlı demo üzerinde incele ve arızayı müşteriden önce görmenin nasıl bir şey olduğunu dene.