Cron ve saat dilimleri: İşiniz neden yanlış zamanda tetikleniyor?

İşiniz "birdenbire çökmedi"; siz Brasilia saatini düşünürken UTC'de tetiklendi. Yaz saati uygulamasına (hala mevcut olan) kadar, Kubernetes Linux'tan başka bir cron lehçesi konuşana ve yanlış alandaki bir "*", aylık temizliği her dakika bir fırtınaya dönüştürene kadar planlama önemsiz görünüyor. Bu kılavuz; alanları, saat dilimi sorunlarını ve platform farklılıklarını ve tarayıcıdaki ifadeleri Safe Local Tools ile doğrulamanın neden genel sitelere dahili cron yapıştırmayı önlediğini kapsar.

Bir Paragrafta Cron (Ve Lehçeler Neden Farklılaşıyor)

Klasik cron'un beş alanı vardır: dakika, saat, ayın günü, ay, haftanın günü. Bazı sistemler saniye veya yıl ekler. Her alan "*", virgüllü listeler, tireli aralıklar ve eğik çizgili adımları kabul eder.

Evrensel bir cron yoktur. Linux crontab, "@hourly" kısayolları, Quartz, AWS EventBridge ve Kubernetes CronJob, sözdizimini farklı şekillerde genişletir veya kısıtlar. Aralarında kopyalayıp yapıştırmak klasik bir olay kaynağıdır.

UTC ve yerel: bir bağlantı seçin ve belgeleyin

Sunucular genellikle UTC'de çalışır; insanlar Amerika/Sao_Paulo'da plan yapıyor. Bu ara, baharda bir saatin "eksik" olduğu, yerel saati safça seviyorsanız sonbaharda yinelenen çalışmalar ve yılda iki kez "yerel saat 9" uyarılarının yapıldığına dair raporlar üretir.

İyi uygulama: yapılandırmada süreleri UTC'de saklayın; IANA tabanını kullanarak arayüzde iş bölgesindeki yaklaşan uygulamaları gösterin.

Haftanın günü × ayın günü etkileşimleri ve "*/5" tuzağı

Bazı motorlar DOW ve DOM'u VEYA olarak değerlendirir, bazıları ise AND olarak davranır; her zaman sonraki N çalıştırmayı yazdırır. Dakika alanındaki */5 her beş dakikada bir; saat alanında her beş saatte bir. "Beş saatte beş" beklentisiyle */5 * * * * yapıştıran herkes çığ yaratır.

Kubernetes'te: eşzamanlılık politikası ('Yasak', 'İzin Ver', 'Değiştir'), 'startingDeadlineSeconds' kullanılamama durumunda yürütmeleri atlamak ve nesneyi silmeden zamanlamayı kapatmak, cron dizesi kadar önemli olan 'askıya almak'.

Yaz saati uygulaması ve gözlemlenebilirlik

İlkbaharda, var olmayan yerel programların açık bir politikaya ihtiyacı vardır; sonbaharda, tekrarlanan saatler, yükün yan etkisi varsa çalıştırma kimliğiyle tekilleştirme gerektirir.

'last_success_timestamp' süresini izleyin ve sessizlik beklenen aralığın iki katını aşarsa uyarı verin; cron sessizliği veri hatlarına olan güveni aşındırır.

İstemcide çalışan Safe Local Tools'ta doğrulama, dahili iş adlarını ve hassas ifadeleri üçüncü taraf ayrıştırıcılara gönderemediğinizde kullanışlıdır.

Okunabilir belgeler ve güvenlik

Cron'u bölge ve sahip yorumlarıyla birlikte README'ye kaydedin. Cron'u uzaktan kod yürütme olarak değerlendirin: CronJob'u, eklenen gizli dizileri ve çalışan çıkışını kimin düzenleyeceğini kontrol edin. Kurumsal takvim kuralları için (son iş günü), saf cron yeterli değildir; imkansız ifadeleri zorlamamak için ek kütüphaneye veya hizmete ihtiyaç duyduğunuzda kaydedin.

Mikro hizmetlerde, her periyodik görev, bir sonraki görevden önce tamamlanması gereken tek bir cron işareti olmamalıdır: geri çekilmeli kuyruklar genellikle, önceki yürütme aralığın ötesine geçtiğinde başarısız olan bir çalışandan daha iyi bir şekilde varyasyonu emer. Sağlıklı bir model, cron'u yalnızca işi sıraya koymak ve kuyrukları ayrı ayrı ölçmek için kullanmaktır.

Entegrasyonlar Windows Görev Zamanlayıcı, SQL Server Agent ve Kubernetes CronJob'u çaprazladığında, zaman dilimi, lehçe, patlama yarıçapı ve zamanlama kanalı sütunlarıyla tek bir zamanlama kaydı tutun; aksi takdirde çağrı ekibi, eksik raporu gerçekte hangi sistemin tetiklediğini bulmak için zaman kaybeder.

Hızlı tablo (UTC, beş alan — lehçeyi kontrol edin)

Niyet	Örnek	Notlar
Günlük 09:00 UTC	0 9 * * *	9. dakikayla karıştırmayın
Hafta içi 09:00 UTC	0 9 * * 1-5	0 veya 7 = Pazar; lehçeye bağlıdır
Her 15 dakikada bir	*/15 * * * *	Garanti çalışma süresi < 15 dakika
Ayın ilk günü gece yarısı	0 0 1 * *	Aralıklı koşuları izleyin

Üretime başvurmadan önce her satırı platformunuzun gerçek lehçesine çevirin.

Staging ve üretimi ayıran saat kümesi seçimleri (örneğin tüm süreleri UTC olarak sabitleme, arayüzde yalnızca okunabilir yerel zaman gösterme) zamanla bozulmaz dokümantasyona bağlanır; aksi halde yaz saati çıkışından iki hafta sonra hatırlanmayan bir varsayım, karanlıkta kalan SLA’ların kök nedeni olabilir. Kısa yaşam döngülü özelliklere yaklaşık çalıştırma tarihlerini doğrudan doğrulama PR’ına gömerek ve loglarda hem epoch hem ISO UTC çıktısı bırakarak geçişleri gözlemleyebilirsiniz.

tzdata yükseltmelerinden sonra özellikle Avrupa ve Amerika politikalarında ani kural değişikliklerinde “ifade değişmedi ama zaman kaydı” sınıflandırması görülür; bu yüzden yılda en az iki kez dağıtılmış gerçek lehçe ile bir sonraki koşunun yerel zaman damgasını doğrulayın ve yaklaşık çalıştırma sırasına karşı izleme eşiklerini yeniden ayarlamayı unutmayın.

Cron ile yaşanan çoğu sürpriz aslında yapılandırma yüzündendir: doğru lehçeyi seçin, zamanı UTC'ye bağlayın, bir sonraki koşuyu grafik olarak öngörün ve özellikle yaz/kış saati haftalarını gözünüzün önünde tutun. İmaj yükseltmelerinden sonra zaman damgası sapması veya NTP düzeltmelerinden görülen sıçramalarda bildiriminizi yeniden derecelendirdiğinizden emin olun; aksi takdirde izleme hep “bir saat fazla uyuyor” gibi görünür. Dahili ifadeleri dış dünyaya sızdırmadan ön görmek gerektiğinde Cron ifade ayrıştırıcısını deneyin →