Dostlar, kafayı yemek üzereyim. Ufak bir otomasyon, tüm sunucu grubunu nasıl diz çöktürür, onu gördüm. Olay şu: Canlı sistemde çalışan kritik bir servisimiz var. Ben de "iyi bir ops mühendisi" gibi, bu servisin sağlığını kontrol eden bir health check botu yazayım dedim. Basit mantık: Her 30 saniyede bir /health endpoint'ine istek at, cevap vermezse veya status code 200 değilse, servisi otomatik restartla.
Python:
if response.status_code != 200:
os.system("sudo systemctl restart my-critical-service")
Her şey güllük gülistanlık gidiyordu, ta ki bir gece veritabanı bağlantısında geçici bir sıkıntı olana kadar. Servis, DB'ye bağlanamayınca /health endpoint'i 500 hatası döndürmeye başladı. Botumuz da sadık bir nefer gibi, "Aa 200 değil, restart!" dedi. Servis restart oldu, başladı, ama DB sorunu devam ettiği için yine 500 döndürdü. Bot yine restart attı. Bu böyle saniyeler içinde bir restart seli oluşturdu.
Monitoringe baktığımda gördüğüm manzara şok ediciydi. CPU %100, memory tükenmek üzere. Her restart, servisin tam yüklenmesine fırsat vermeden yeni bir restart prosesi başlatıyordu. Sunucu, onlarca aynı servis instance'ını kaldıramadı ve komple yattı. Meğerse ben, kendi kendini besleyen bir restart fırını kodlamışım. StackOverflow'da bile böyle saçma bir hatayı kimse paylaşmamıştı, şaka gibi.
Neyse ki canlı sistemde değil, staging'de denk gelmişiz. Çözüm olarak botu baştan yazdım. Artık:
1. İlk hatada hemen restart atmıyor, 3 kez arka arkaya kontrol ediyor.
2. Restart attıktan sonra, servisin ayağa kalkması için 2 dakikalık bir grace period (lütuf süresi) bekliyor.
3. Eğer ardışık restart sayısı artarsa, bekleme süresini katlayarak artırıyor (exponential backoff).
Python:
failed_checks = 0
while failed_checks < 3:
if not check_health():
failed_checks += 1
else:
failed_checks = 0
time.sleep(30)
Siz de böyle "iyi niyetli" ama sonu felaketle biten otomasyonlar yazdınız mı? Bu tarz health check logic'lerinde daha temiz, daha güvenli bir pattern kullanan var mı aranızda? Anlatın da bir daha aynı hataya düşmeyelim.