On-call, çoğu kurumda “birileri telefonu tutsun” diye başlatılır ve zamanla tükenmişlik üreten bir döngüye dönüşür. Halbuki iyi tasarlanmış bir on-call sistemi, sadece incident’e müdahale etmeyi değil; incident sayısını ve müdahale maliyetini de düşürür. İşin sırrı, rotasyon çizelgesinde değil; escalation zinciri, alarm kalitesi ve runbook disiplinindedir.
Bu yazıda, sahada işe yarayan on-call tasarım prensiplerini ve uygulanabilir bir çerçeveyi anlatıyorum.
On-call’un hedefi: “sürekli uyanık olmak” değil, “hızlı toparlanmak”
On-call’un üç çıktısını ölçmeden iyileştirme yapamazsın:
- MTTA/MTTR: Alarmı alma ve toparlanma süreleri
- Alarm kalitesi: actionability oranı (müdahale gerektiren / gerektirmeyen)
- Toil: tekrarlayan manuel işler ve gece müdahaleleri
Rotasyon: adalet + sürdürülebilirlik
Pratik bir başlangıç şablonu:
- Birincil (primary): müdahaleyi başlatır
- İkincil (secondary): gerektiğinde devreye girer, bilgi/deneyim yedekler
- Incident Commander (ops lider): P1/P0’da karar ve iletişimi yönetir (her zaman on-call değil)
Rotasyon tasarımında iki kuralı sabit tutarım:
- Arka arkaya on-call minimum olsun (uyku borcu)
- Sekonder rolü “sadece bekleme” değil; öğrenme ve yük paylaşımı olsun
Escalation zinciri: süreler ve sahiplik net olmalı
Escalation için tek hedef: “alarm boşlukta kalmasın”.
Örnek zincir:
- Primary: 5 dk içinde ack
- Secondary: +5 dk
- IC / Team Lead: +10 dk
- Geniş çağrı (war room): +15 dk (P1 kriteri)
Bu süreler, sistemin kritikliği ve ekip büyüklüğüne göre ayarlanır. Ama hangi süre olursa olsun, yazılı ve otomatik olmalıdır.
Alarm kalitesi: runbook ile birlikte yaşar
Actionable alarm için minimum içerik standardı:
- Ne bozuldu? (SLO/SLI)
- Etki nedir? (kullanıcı, gelir, kritik süreç)
- İlk 3 kontrol adımı (runbook linki)
- Geri dönüş planı / feature flag bilgisi (varsa)
Alarmın içinde runbook yoksa, on-call “arama motoru” olur.
Runbook disiplini: kısa, net, uygulanabilir
İyi runbook formatı:
- Triage: 3–5 hızlı kontrol (dashboard/link)
- Mitigation: güvenli ilk hamleler (rate-limit, rollback, failover)
- Escalation: kim, ne zaman çağrılır
- Delil: hangi log/metric saklanır, postmortem için ne toplanır
Runbook’lar doküman arşivi değil; yaşayan operasyondur. Her P1 sonrası runbook güncellenmiyorsa, aynı hatayı tekrar edersin.
Pager yorgunluğunu azaltmak: toil bütçesi yaklaşımı
Benim sahada gördüğüm en hızlı iyileştirme, “toil bütçesi” belirlemek:
- Haftalık belirli saat: alarm tuning + otomasyon
- “En çok çağıran 5 alarm” listesi
- Her alarm için: nedeni, aksiyon, çözüm sahibi, hedef tarih
Bu disiplin oturunca, on-call bir “kriz nöbeti” değil; sistemin güvenilirliğini artıran bir geri bildirim mekanizmasına dönüşür.
Sonuç
On-call, doğru tasarlanırsa ekipleri yıpratan bir zorunluluk değil; operasyonel olgunluk inşa eden bir pratik olur. Rotasyon adaleti, escalation netliği, alarm kalitesi ve runbook disiplini birlikte çalıştığında hem MTTR düşer hem de ekiplerin “sakin” kalma kapasitesi yükselir. Operasyonel liderliğin en görünmez ama en kritik katkısı, bu sistemin sürdürülebilir kalmasını sağlamaktır.