Ö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
1. Temel Çalışma Mekanizması
Alarm mimarisi telemetriyi üç ayrı kanala ayırmalıdır: (1) 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ı. (2) Bilet / Mesai Slack Bildirimi (Asenkron): Diskin 3 hafta sonra dolacak olması, önemsiz bir replikanın yeniden başlaması. (3) 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
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ı
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
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
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)
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 Örneği)
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ırmaNöbetçi çağrı alarmlarının (paging alerts) 'Altın Kuralı' nedir?
Ekipler neden sebeplere (CPU/Bellek) değil semptomlara (SLO) alarm kurmalıdır?
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