Bu Hafta Ne Bozdum? Tecrübenin Çetin Yolu

20 yıldır bu işi yapıyorum, sistem mimarisi ve operasyonun her kademesinde bulundum. Ama size bir sır vereyim mi? Hâlâ her hafta bir şeyler bozuyorum. Evet, yanlış duymadınız. Bazen ufak, bazen can sıkıcı, bazen de “vay be, bunu nasıl atladım” dedirten hatalar yapıyorum. Asıl mesele bir şeyleri bozmaktan kaçınmak değil; çünkü bu neredeyse imkansız. Mesele, bozduğun şeyi ne kadar hızlı anladığın, nasıl tamir ettiğin ve en önemlisi, o hatadan ne öğrendiğin.

Kariyerimin en pahalı hatası bir kod satırı ya da yanlış bir komut değildi; çoğu zaman “evet” dediğim, ama sonradan altından kalkması güç projelere girişmekti. Ama bu hafta yaşadığım durum, daha mikro ölçekte, bir sistem yöneticisinin günlük hayatındaki “bozma” döngüsünün iyi bir örneği oldu.

Bozmak Bir Sanat mı, Yoksa Kaçınılmaz Bir Sonuç mu?

Mühendislikte mükemmeliyetçilik peşinde koşarken, sıfır hata beklentisiyle yaşamak bence gerçek dışı. Sistemler karmaşıklaştıkça, farklı bileşenler bir araya geldikçe, etkileşimler arttıkça, insan faktörünü de işin içine katınca hata yapma olasılığı katlanarak artıyor. Hatta bazı “bozma” durumları, yeni bir şeyler denerken, limitleri zorlarken ortaya çıkıyor. Bu, inovasyonun ve öğrenmenin ayrılmaz bir parçası.

Benim için “bozmak”, genellikle bir sistemin sınırlarını anlamanın veya gözden kaçırdığım bir detayı fark etmenin en hızlı yolu oluyor. Bazen bir yapılandırma değişikliği, bazen yeni bir özelliğin devreye alınması, bazen de sadece bir optimizasyon çabası, beklenmedik sonuçlara yol açabiliyor. Önemli olan, bu durumları birer felaket yerine, birer öğrenme fırsatı olarak görmek.

En Son Ne Bozdum? Bir SystemD Timer Macerası

Geçen ay, kendi yan ürünümün arka planında çalışan, belirli aralıklarla finansal verileri toplayıp işleyen bir systemd timer’ı üzerinde çalışıyordum. Bu timer, Python ile yazılmış küçük bir script’i çağırıyordu. Script’in görevi basitti: Harici bir API’den veri çek, işe, veritabanına yaz. Basit görünen bu işlem, küçük bir hatam yüzünden baş ağrısına dönüştü.

Problemin semptomu şuydu: Sabah kalktığımda dashboard’daki bazı verilerin güncellenmediğini gördüm. İlk kontrolüm journalctl -u benim-servisim.timer oldu. Timer’ın çalıştığını, fakat systemd unit’inin sık sık yeniden başladığını fark ettim. Loglarda OOM-killed mesajları dikkatimi çekti.

systemctl status benim-servisim.service
journalctl -u benim-servisim.service

İncelemeye başladığımda, script’in içinde belirli bir koşulda uzunca bir time.sleep() komutu kullandığımı gördüm. Amacım, harici API’nin rate limit’lerine takılmamaktı. Fakat bu script’i bir systemd servisi olarak çalıştırırken, servis tanımında oldukça düşük bir MemoryHigh yumuşak limiti belirlemiştim. Normalde script bu limitin altında çalışıyordu, ancak veriyi işlediği anlarda hafıza kullanımı bu limiti aşıyordu. systemd de, servisi OOM-killed olarak işaretleyip yeniden başlatıyordu.

Çözüm aslında basitti: sleep komutunu kaldırıp, API’nin rate limit’lerini kontrol eden daha akıllı bir polling-wait mekanizması ekledim. Yani, API’den bir hata kodu geldiğinde veya bir sonraki isteği ne zaman yapabileceğimi belirten bir header olduğunda beklemeyi dinamik hale getirdim. Ayrıca, systemd unit tanımındaki MemoryHigh değerini biraz daha esnek hale getirdim ve Restart=on-failure yerine Restart=on-abnormal kullandım ki beklenmedik çıkışlar daha iyi yönetilsin.

Bozduklarımdan Çıkan Dersler

Bu tür durumlar bana sürekli olarak bazı temel prensipleri hatırlatıyor:

• Gözlemlenebilirlik (Observability): Sistemlerimde yeterli metrik, log ve trace yoksa, hata ayıklama süreci bir kabusa dönüşüyor. journald ve Prometheus metrikleri olmasaydı bu sorunu bulmak çok daha uzun sürerdi.
• İzlenebilirlik (Monitoring): Anomali tabanlı izleme, bir şeyler “bozulmadan” önce bile sinyal verebilir. OOM-killed logları, aslında bir anormallikti ve hemen alarm tetiklemesi gerekiyordu.
• Idempotency: Her operasyonun birden fazla kez çalıştırıldığında aynı sonucu verecek şekilde tasarlanması kritik. Benim senaryomda veri işleme idempotent olduğu için, servis yeniden başlasa da veri bozulmadı, sadece gecikti.
• Basitlik ve Açıklık: Bir çözüm ne kadar basitse, o kadar az hata barındırır ve o kadar kolay anlaşılır. Sabit bir sleep süresi yerine, dinamik bir strateji her zaman daha iyidir.
• Hata Yapmaktan Çekinme: Hata yapmak insan doğasında var. Önemli olan hatayı kabul etmek, hızlıca öğrenmek ve aynı hatayı bir daha yapmamak için sistemler kurmak.

Hata Kültürü ve Büyüme

Bir üretim firmasının ERP’sini geliştirirken, bir bankanın iç platformunda çalışırken veya kendi yan ürünümün backend’inde dahi, hata yapma lüksümüz her zaman var. Mesele, bu hataların maliyetini minimize etmek ve onlardan maksimum faydayı sağlamak. Bir ekipte veya bireysel kariyerde, hataları gizlemek yerine açıkça tartışmak ve çözüm üretmek, en hızlı öğrenme ve gelişme yoludur.

Benim için “Bu hafta ne bozdum?” sorusu, aslında “Bu hafta ne öğrendim?” sorusunun bir diğer yüzü. Her hata, beni bir sonraki adıma daha bilinçli ve daha yetkin bir şekilde hazırlıyor. Bu, yıllar içinde işin bana öğrettiği en değerli derslerden biri.

Peki sen ne düşünüyorsun? Senin en pahalı hatan neydi ve ondan ne öğrendin? Yorumlarda paylaşmaktan çekinme.