Engineering On-Call: Hayatta Kalmak ve Geliştirmek

On-call'a çağrı geliyor: gece 03:14. Phone uyandırıyor, sistem alert veriyor, kullanıcılar etkileniyor. Yatağından çıkıp laptop başına geçiyorsun.

Bu, 6 yıldır iGaming platformunun on-call rotasyonunda yaşadığım sahnenin yüzlerce versiyonu. Doğru kurulmuş bir on-call kültürüyle, doğru kurulmamış bir kültür arasındaki fark, ekibin ömrünü belirler.

İşte öğrendiklerim.

On-call neden var

İlk olarak: on-call gönüllü değildir, görevdir. Production sistemlerde 24/7 yanıt verecek birinin olması, sistemin stabilitesinin koşulu.

Ama "sırayla biri 24/7 ayık olsun" demek değil. İyi bir on-call:

• Çoğunlukla sessiz geçer (alert yok demek)
• Çağrı geldiğinde belirsizlikle değil hazırlıkla karşılanır
• Sürekli pratiği iyileştirir (her incident, gelecekteki çağrı sayısını azaltır)

Rotasyon hijyeni

İyi rotasyonun özellikleri:

Yeterli kişi sayısı. Minimum 4 kişi. 3 ile yapmaya çalışırsan, biri tatildeyken kalan ikisi her hafta nöbet tutar — burnout garanti. 4 ile herkes ayda bir hafta. Daha azı tehlikeli.

Açık handoff. Hafta bittiğinde devreden çıkan kişi → giren kişiye yazılı handoff. Ne oldu bu hafta, hangi alarm hâlâ flaky, hangi servis dikkat gerektiriyor. 5 dakikalık doc, 30 dakikalık incident'ı önler.

Compensated. On-call yapana ödeme veya izin günü verilir. Bu rotasyonun bir maliyetinin tanınmasıdır. Ücretsiz on-call zaman içinde "neden hep ben yapıyorum" mırıltılarına dönüşür.

Severity-aware. Her alert sirena değildir. Tier 1 (revenue etkili, anında müdahale): telefon. Tier 2 (kullanıcı etkili, saatler içinde): e-posta. Tier 3 (gelecekteki risk): sabah bakılır. Aynı urgency'yle alarm spamlamak ekibi vurdumduymaz yapar — alert fatigue.

İlk gün için kit

Yeni on-call kişisi için runbook olmalı. Liste:

• En sık 5 alert ve ilk müdahale adımları
• Sistem mimarisi diagram'ı (basit, akış)
• Kritik servislerin sahibi (gece kim aranır)
• Rollback prosedürleri (hangi servis nasıl rollback'lenir)
• "Help! Bu nedir?" linkleri (Grafana, Sentry, log sistemi)

Bu doc'u her on-call kişisi haftada bir günceller. 6 ay içinde kendiliğinden zenginleşir.

Çağrı geldiğinde — ilk 5 dakika

Telefon çaldı. Yapılacaklar:

1. Kahve veya su — 30 saniye. Beyni uyandır, sakinleşmeden harekete geçme.
2. Alarmı oku — ne, ne kadar kötü, ne zaman başladı? 30 saniye.
3. Slack'te incident kanalı — "#inc-..." aç, "alarmı aldım, bakıyorum" yaz. 30 saniye.
4. Dashboard'lara bak — error rate, latency, traffic. Trend ne? 2 dakika.
5. Karar: çözebilir miyim 15 dakikada, ya da escalate mi gerek? 30 saniye.

Bu 5 dakika, sonraki saati belirler. Acele etme — yanlış aksiyon, doğru aksiyondan beter.

Ne zaman escalate edilir

Tek başına panikleyip yanlış aksiyon almak yerine escalate etmek profesyonelliktir. Ne zaman:

• Sistemi tanımıyorsan (yeni katıldın, bu servis hiç dokunmadığın)
• Etki büyük ve büyüyor (revenue, multi-service)
• 30 dakikadır debug ediyorsun, ilerleme yok
• Karar etkileri büyük (DB rollback, region failover)

Escalate'te utanç yok. Yanlış aksiyon almak utançtır.

Post-incident — protected time

Incident bittiğinde post-mortem. Bu, opsiyonel değil zorunlu pratik. Sahasında öğrenilen ders, doc olmazsa unutulur.

Post-mortem yapma kuralları:

• Blameless: kim yanlış yaptı değil, sistem nasıl yanlış davranmaya izin verdi
• 48 saat içinde yapılır (taze hafıza)
• Action item'ları sahiplenilir: her aksiyonun sahibi + tarihi
• Düzenli takip: aylık olarak action item'lar gözden geçirilir, açık kalanlar adres edilir

Post-mortem doc'u commit edilir (repo'ya). Yıllar sonra "şu hata daha önce olmuştu" arandığında bulunur.

Rotasyon nasıl iyileşir

Her hafta sonu, biten on-call kişisi yazısı:

• Bu hafta kaç alert geldi
• Hangileri yanlış pozitifti (alert geldi ama gerçek sorun değildi)
• Hangileri yeni alarmtı (daha önce görülmemiş)
• Hangi alarmın eşiği yanlış (sürekli triggerla­yor ama gerçek sorun yok)

Bu data ekibe gider. Aylık olarak:

• Yanlış pozitiflerin alarm threshold'u yükseltilir
• Yeni alarmlar runbook'a eklenir
• Tekrarlayan incident'ler için otomasyon yazılır

Bu disiplin yoksa, on-call sadece "yangın söndürmek" olur. Olduğunda, sistem zamanla daha sağlam olur.

Burnout sinyalleri

On-call burnout sinyalleri:

• Telefon zili sesinde fizyolojik tepki (kalp atışı yükselmesi)
• "Beni rahat bıraksanız" kişisel iletişim seviyesinde
• Hafta sonu paranoya, "yine bir şey olur"
• Pazartesi sabah motivasyon yok

Bu sinyaller varsa, konuş. Manager'la, ekiple. Belki rotasyon dengesizliği var, belki belirli alarm sürekli aynı kişiye düşüyor, belki sistemin kendisi çok kırılgan.

Burnout'u tek başına çözemezsin. Erken yakalanırsa rotasyon ayarlanır, sistem iyileştirilir, kişi geri gelir. Geç yakalanırsa kişi gider.

Sonuç

On-call iyi yapılırsa, mühendislerin en hızlı geliştiği yerdir. Production sistem davranışını gerçek zamanlı görmek, hiçbir kitabın öğretemeyeceği şeyleri öğretir.

Kötü yapılırsa, ekibi tüketen ve insanları sektörden uzaklaştıran şeydir. Aradaki fark teknoloji değil — rotasyon hijyeni + post-incident disiplini + insan bilinci.

Bu üçünü kuran ekipte 5 yıl on-call yapmak mümkün ve sağlıklı. Kuramayan ekipte 1 yıl yapmak zor.