İnternetteki üretkenlik gurularının “sabah 5’te kalk, buzlu suya gir, 2 saat meditasyon yap, sonra vizyon panona bak” tavsiyelerini her gördüğümde gülüyorum. 20 yıldır bu sektörde kod yazan, sunucu ayağa kaldıran, gece yarısı gelen disk doluluk alarmlarıyla uykusu bölünen biri olarak söylüyorum: Bu teoriler gerçek hayatta, özellikle de bizim meslekte çalışmıyor. Gecenin bir köründe PostgreSQL WAL bloat yüzünden replikasyon patlamışsa ve sen ancak sabaha karşı yatağa girebilmişsen, birkaç saat sonra uyanıp soğuk duş almak seni disiplinli bir mühendis yapmaz; sadece uykusuz, verimsiz ve hata yapmaya açık bir mühendis yapar.
Benim için sabah rutini, askeri bir disiplinle her gün aynı saatte robot gibi uyanmak değil, sistemin ve kendi biyolojimin ihtiyaçlarına göre esneyebilen, pragmatik bir “uptime” yönetimidir. Bu yazıda, sabahları nasıl bir yaklaşımla güne başladığımı, hangi araçları kullandığımı ve kararlarımı neye göre verdiğimi kendi deneyimlerimle anlatacağım.
Bir Sistemcinin Biyolojik Saati: Cron Job vs Event-Driven Tetikleyiciler
Yıllarca kendimi sabah insanı olmaya zorladım. “Başarılı insanlar erken kalkar” mitine inanıp alarmı her gün 06:00’ya kurduğum bir dönem oldu. Sonuç ne mi oldu? Gün içinde yazdığım kodların kalitesi düştü, Nginx konfigürasyonlarında basit hatalar yapmaya başladım ve daha da kötüsü, akşam saat 16:00’dan sonra beynim tamamen duruyordu. Sonra fark ettim ki, insan biyolojisini sabit bir cron job gibi çalıştırmaya çalışmak, esneklikten uzak bir sistem mimarisi tasarlamak gibidir.
Bunun yerine güne “event-driven” (olay güdümlü) yaklaşmaya başladım. Eğer bir önceki gece üretim ERP’sinin canlıya geçişi veya bir veri tabanı göçü (migration) yoksa, uykumu tam alıp 08:00’de uyanmak benim için en verimli tetikleyicidir. Ancak gece bir incident yaşanmışsa, uyanma saatimi esnetip biyolojik bataryamı doldurmak zorundayım.
# Kendimi zorladığım verimsiz "Sabit Cron" modeli (Tavsiye etmiyorum)
00 06 * * * /usr/bin/wake_up --force-cold-shower --ignore-sleep-debt
# Gerçekçi ve sürdürülebilir "Event-Driven" modelim
@reboot /usr/bin/evaluate_sleep_quality.sh && /usr/bin/start_day.shGerçek bir mühendis için önemli olan kaçta uyandığı değil, uyandıktan sonraki ilk saatlerde odaklanma kalitesidir. Eğer güne yarı dolu bir bataryayla başlıyorsam, o gün yazacağım kodların teknik borcu (technical debt) bana ileride daha fazla mesai olarak geri döner. Daha önce teknik borç yönetimi üzerine yazdığım gibi, aceleyle ve yorgun kafayla verilen kararlar her zaman daha pahalıya patlar.
İlk 2 Saat Kuralı: Log Analizi mi, Kod mu, Yoksa Sadece Kahve mi?
Güne başlar başlamaz bilgisayarı açıp e-postaları veya Slack mesajlarını okumak, başkalarının ajandasına teslim olmak demektir. Ben ilk 2 saatimi tamamen dış dünyaya kapatıyorum. Bu süre zarfında ne telefonuma bakarım ne de kurumsal iletişim kanallarını açarım. Bu süreyi ikiye bölüyorum: ilk 30 dakika sistemlerin genel durumunu kontrol etmek, geri kalan 90 dakika ise derin odaklanma gerektiren işleri yapmak.
Güne başlar başlamaz ilk yaptığım şey, kendi yazdığım küçük bir bash script yardımıyla kritik sunucuların ve servislerin durumunu gösteren bir özet raporu okumaktır. Buna “sabah vizitesi” diyorum.
# Çıktı ortama göre değişir; format kabaca şöyle
=== SİSTEM SAĞLIK RAPORU ===
[OK] PostgreSQL Master : Bağlantı sayısı + WAL write lag normal
[OK] Redis Cache : Bellek kullanımı eşik altında (OOM Policy: volatile-lru)
[WARN] Nginx Reverse Proxy: 5xx oranında hafif artış (502 hataları)
[OK] Background Workers : Tüm systemd unit'leri çalışıyor
============================Bu raporu gördükten ve sistemlerin stabil çalıştığından emin olduktan sonra kahvemi alıp en zor göreve odaklanıyorum. Bu bir AI modelinin prompt optimizasyonu olabilir, karmaşık bir SQL sorgusunun index analizi olabilir veya bir mobil uygulamanın native bridge entegrasyonu olabilir. Beynin en temiz olduğu bu ilk saatleri e-posta yanıtlayarak harcamak, kaynakları çok kötü yönetmektir.
Esnekliğin Sınırları: “On-Call” Gecelerinden Sonra Sabah Rutini Nasıl Patlar?
Teoride her şey harika görünebilir ancak bir sistemcinin hayatı her zaman planlandığı gibi gitmez. Bir keresinde, kendi geliştirdiğim bir yan ürünün backend sunucusunda gece yarısından sonra bir bellek sızıntısı (memory leak) alarmı aldım. Sunucudaki cgroup limitleri (memory.high) devreye girmiş ve container’lar ardı ardına restart olmaya başlamıştı.
O gece sabaha karşı saatlerce logları inceledim, sorunun Redis bağlantı havuzunun (connection pool) düzgün kapatılmamasından kaynaklandığını buldum ve yamayı geçtim. Şimdi, böyle bir gecenin sabahında erkenden kalkıp “disiplin” adına uzun bir koşuya çıkmaya çalışmak deliliktir.
// O gece aldığım kritik hata loglarından biri (değerler temsilîdir)
{
"level": "FATAL",
"message": "Out of memory: Killed process (python3) ...",
"cgroup": "docker/backend"
}Böyle durumlarda benim rutin uyguladığım “Olağanüstü Hal (OHAL) Protokolü” devreye girer:
- Gecikmeli Başlangıç: Sabah uyanma saatimi en az 2 saat ileriye kaydırırım.
- Sıfır Toplantı: O günkü tüm senkron toplantıları iptal eder veya asenkron yazışmaya çeviririm.
- Düşük Bilişsel Yük: O gün yeni bir mimari tasarlamak yerine, sadece rutin log takipleri, dokümantasyon güncellemeleri veya basit refactoring işleri yaparım.
Bu esneklik, kendime tanıdığım bir ayrıcalık değil, sistemin sürdürülebilirliği için zorunlu bir karardır. Kendini yıpratan bir mühendis, production ortamında hata yapmaya en yakın mühendistir.
Rutinleri Otomatize Etmek: Sabahları Karar Yorgunluğunu Azaltan Scriptler
Pragmatik bir mühendis, tekrarlayan her işi otomatize etme eğilimindedir. Sabahları hangi web sitelerine bakacağımı, hangi logları kontrol edeceğimi tek tek düşünmek yerine, her sabah bilgisayarımı açtığımda çalışan küçük bir otomasyon scriptim var.
Bu script, benim için gerekli terminal sekmelerini açıyor, Docker container’larının durumunu kontrol ediyor ve yerel geliştirme ortamımı (development environment) ayağa kaldırıyor.
# ~/bin/morning_spinup.py
import subprocess
import os
def check_local_env():
print("[*] Yerel servisler kontrol ediliyor...")
# Docker Compose servislerini başlat
subprocess.run(["docker", "compose", "-f", "/home/mustafa/projects/docker-compose.yml", "up", "-d"])
# PostgreSQL bağlantısını test et
pg_status = subprocess.run(["pg_isready", "-h", "localhost", "-p", "5432"], capture_output=True, text=True)
if "accepting connections" in pg_status.stdout:
print("[OK] PostgreSQL hazır.")
else:
print("[ERROR] PostgreSQL başlatılamadı!")
def open_workspaces():
print("[*] Geliştirme ortamları açılıyor...")
# Sık çalıştığım projelerin dizinlerini VS Code ile aç
os.system("code /home/mustafa/projects/production-erp")
os.system("code /home/mustafa/projects/my-side-project")
if __name__ == "__main__":
check_local_env()
open_workspaces()
print("[SUCCESS] Sabah çalışma ortamı hazır. İyi çalışmalar, Mustafa.")Bu script sayesinde, bilgisayarın başına geçip “Hangi projede kalmıştım? Servisler ayakta mı?” diye düşünerek harcayacağım o ilk dakikaları ve en önemlisi zihinsel enerjiyi kendime saklıyorum. Bilgisayarı açıyorum, scripti çalıştırıyorum, kahvemi alıp geliyorum ve her şey hazır beni bekliyor.
Daha önce geliştirici üretkenliği konusunda bahsettiğim gibi, otomasyon sadece sunucuları yönetmek için değil, kendi günlük operasyonlarımızı yönetmek için de en güçlü silahımızdır.
Pragmatik Mühendisin Dengesi: Benim Haftalık “Uptime” Tablom
Kendi hayatımı da bir sistem gibi izlemeyi seviyorum. Tabii ki her günün metriğini tutacak kadar obsesif değilim ama haftalık bazda kendime biçtiğim bazı “SLA” (Service Level Agreement) değerleri var. Aşağıdaki tablo, benim hayat kalitesini ve iş üretkenliğini dengede tutmak için kullandığım pragmatik hedefleri gösteriyor.
| Metrik (SLA) | Yaklaşık Hedef | Tolere Edilebilir Sapma | Açıklama |
|---|---|---|---|
| Uyku Kalitesi (7+ saat) | Günlerin büyük çoğunluğu | Incident geceleri | Zihinsel netlik için taviz verilmez eşik. |
| Deep Work (Odaklanmış Çalışma) | Haftada birkaç sağlam blok | Toplantı yoğunluğu | Sabah ilk 2 saatlik blokların toplamı. |
| Ekran Dışı Zaman (Digital Detox) | Her gün bir miktar | Yoğun günler | Göz ve zihin sağlığı için zorunlu. |
| Fiziksel Aktivite | Haftada birkaç gün | Yoğun deploy haftası | Genelde akşam yürüyüşleri veya esneme. |
Eğer uyku eşiğim üst üste birkaç hafta belirgin biçimde altına düşerse, sistemde “bellek sızıntısı” var demektir. Hemen iş yükümü gözden geçirir, yeni özellikleri (features) dondurur ve kendimi bakıma alırım. Tıpkı bir sunucuya bakım modu (maintenance mode) almak gibi.
Net Pozisyonum: Disiplin Araçtır, Esneklik İse Hayatta Kalma Becerisidir
Sabah rutinleri konusunda net pozisyonum şudur: Disiplin, esnekliği yönetebildiğiniz sürece değerlidir. Kendinizi körü körüne askeri disiplin kurallarına hapsetmek, değişen şartlara uyum sağlayamayan, kırılgan (fragile) bir yazılım mimarisi tasarlamaktan farksızdır.
Gerçek bir pragmatik mühendis; ne zaman sıkı çalışacağını, ne zaman dinleneceğini, ne zaman sistem odasında sabahlayıp ne zaman sabah alarmını kapatıp uyuyacağını bilen kişidir. Kendi biyolojinizi ve işinizin dinamiklerini iyi tanıyın. Başkalarının sabah rutinlerini kopyalamak yerine, kendi “uptime” gereksinimlerinize uygun, esnek ve sürdürülebilir bir rutin geliştirin.
Bir sonraki yazıda, üretim ortamlarında yaşadığım bir diğer ilginç vaka analizini ele alacağım. Görüşmek üzere.