Nöbetçi Alarm Yorgunluğu ve Eyleme Dönüştürülebilir Alarm Hijyeni

Senior (L5)

⚡ÖZET VE TEKNİK CEVAP

Alarm yorgunluğu sistem güvenilirliği için en büyük tehditlerden biridir: Bir nöbetçi gece boyunca kritik olmayan uyarılarla ('CPU %82 oldu', 'Disk %75 doldu', 'Cron uyarısı') onlarca kez uyandırıldığında reflekslerini kaybeder ve en sonunda gerçek bir P0 çöküşünü uykusunda kaçırır. Google SRE alarm doktrinine göre altın kural şudur: Bir insanı yatağından kaldıran HER alarm acil, doğrudan kullanıcıyı etkileyen veya hata bütçesini tüketen bir sorun olmalı ve İSTİSNASIZ çalışan bir runbook linki içermelidir. 15 dakika içinde anlık bir insan müdahalesi gerektirmeyen hiçbir durum nöbetçiyi aramamalı; günlük Slack özetine veya Jira'ya gitmelidir. Gürültülü alarmları acımasızca silme politikası nöbetçilerin sağlığını korur ve MTTR'ı düşürür.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Alarm mimarisi telemetriyi üç ayrı kanala ayırmalıdır:

Telefonla Uyandırma (Paging): Hata bütçesi tüketim hızının 14,4 katı aşması (aylık bütçenin %2'sinin 1 saatte erimesi), ödeme başarı oranının <%99 olması veya kullanıcı p95 gecikmesinin >2 sn çıkması.

Bilet / Mesai Slack Bildirimi (Asenkron): Diskin 3 hafta sonra dolacak olması, önemsiz bir replikanın yeniden başlaması.

Pano / Pasif İzleme (Sessiz): Anlık CPU ve bellek grafikleri. PagerDuty yükünde güncel bir runbook_url linki içermeyen alarmlar CI/CD testlerinde otomatik reddedilmelidir.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Mikroservis, veritabanı, Kubernetes ve bulut altyapısında 7/24 nöbet (on-call) tutan tüm mühendislik ekipleri.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

✓
Bir mühendisin gece anlık disk sıçramaları yüzünden 45 kez aranması sonucu PagerDuty'yi 4 saatliğine sessize alması ve tam bu sırada ana ödeme veritabanı çöktüğünde kimsenin duymaması
✓
gece 3'te uyanan mühendisin Alert-HighCPU-Service-B adlı, ne işe yaradığı ve runbook'u olmayan anlamsız bir alarmla baş başa kalması

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

✓
PagerDuty raporlarında nöbetçi başına vardiyada >10 alarm düşmesi
✓
nöbet anketlerinde yüksek kaygı ve uyku bozukluğu çıkması
✓
alarmların %50'sinden fazlasının hiçbir işlem yapılmadan doğrudan kapatılması (no-op)

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

✓
Her hafta 'Nöbet Devir Toplantısı' yaparak çalan tüm alarmları denetleyin
✓
aksiyon gerektirmeyen her alarmı acımasızca silin veya bilete dönüştürün
✓
'Nöbetçi Yük Bütçesi' (24 saatte maksimum 2 alarm) hedefi koyun
✓
sebeplere (ham CPU) değil semptomlara (kullanıcı SLO'ları) alarm kurun

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Alarmları katı şekilde filtrelemek nöbetçileri korur ve gürültüyü bitirir; ancak mühendislerin hassas SLO ve hata bütçesi hesaplamaları yapmasını gerektirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir e-ticaret platformunda nöbetçiler 80 servis yüzünden haftada 120 kez aranıyordu. Ekip semptom tabanlı alarm modeline geçti: 400 adet ham CPU/bellek alarmını sildi; yerine kullanıcı API'lerini izleyen ve zorunlu runbook linki olan 6 adet hata bütçesi alarmı koydu. Haftalık çağrı sayısı 120'den 4'e indi, mühendis istifaları durdu ve her gelen alarma güvenilip anında müdahale edildiği için MTTR %55 kısaldı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma

Nöbetçi çağrı alarmlarının (paging alerts) 'Altın Kuralı' nedir?

İnsanı uyandıran her alarm acil, aksiyonu belli, kullanıcıyı/SLO'yu etkileyen ve doğrudan bir runbook içeren bir durum olmalıdır.

Ekipler neden sebeplere (CPU/Bellek) değil semptomlara (SLO) alarm kurmalıdır?

Çünkü kullanıcılar normal hız alıyorsa CPU'nun %90 olması zararsızdır; semptoma alarm kurmak yalnızca kullanıcı mağdur olduğunda nöbetçiyi uyandırmayı garanti eder.

Nöbetçi Alarm Yorgunluğu ve Eyleme Dönüştürülebilir Alarm Hijyeni — Sıkça Sorulan Sorular

Bir nöbet vardiyasında sağlıklı bir 'Alarm Yükü' hedefi nedir?

Google SRE standartları, mühendisin toparlanabilmesi ve postmortem yazabilmesi için 24 saatlik vardiyada en fazla 2 alarm hedefler.

Bir haftada 10 kez çalan ancak hiçbir insan müdahalesi gerektirmeyen bir alarma ne yapılmalıdır?

Derhal nöbetçi çağrılarından silinmeli veya günlük rapora çevrilmelidir; insanları uyandırmaya hakkı yoktur.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

▸
Every page must be urgent, actionable, linked to a runbook, and impact user SLOs.
▸
Alert on symptoms (user errors/latency) rather than causes (raw CPU/memory).
▸
Target pager load is <2 pages per 24-hour shift.
▸
Noisy, non-actionable alarms must be aggressively deleted during weekly handoffs.

Yaygın Yanılgılar

✗
Yanılgı: More alerts mean a safer system (Gerçek: Too many alerts guarantee alert fatigue and missed outages).
✗
Yanılgı: 90% CPU utilization always requires waking up an engineer (Gerçek: If user requests succeed within SLA, high CPU is healthy efficiency).

Karar Kılavuzu & Önceliklendirme

Audit all PagerDuty alerts to enforce mandatory runbook links. Delete any alert that has triggered without requiring manual action.

Doğrulanmış Kaynaklar & Referanslar

[OFFICIAL_DOCUMENTATION]My Philosophy on Alerting: SRE Principles and Alert Fatigue— Rob Ewaschuk / Google SRE

Bu sayfadaki teknik terimler

Runbook