Saat 03:14. Telefon nöbetçi uygulamasının o tanıdık sesiyle çalıyor: "node-14 CPU utilization > 85%". Yataktan kalkıp laptop'ı açıyorum. HPA zaten iki pod eklemiş, gecikme grafikleri dümdüz, hata oranı sıfırın dibinde, tek bir kullanıcı bile bir şey hissetmemiş. Alarmı kapatıp yatağa dönüyorum ama uyku gitti. Ertesi sabah merak edip saydım: son otuz günde 1.240 alarm üretmişiz, bunların 41'i gece nöbetçiyi uyandırmış ve uyandıranların yalnızca üçü gerçekten insan müdahalesi gerektirmiş. Yüzde yedi. Nöbetçilerimizin uykusunu %93 ihtimalle boşuna bölüyorduk ve bunun faturası sadece uyku değildi.
Gürültünün İçinde Kaybolan Gerçek Yangın
Faturayı acı biçimde bir cuma gecesi ödedik. Ödeme hata oranımız 40 dakika boyunca %2,1'de seyretti; normali binde üçtür. Alarm vardı ama eşiği %5'e kurulmuştu, çünkü daha düşük eşikler "çok öterdi". Nöbetçi arkadaş aynı gece dört ayrı disk ve CPU alarmıyla boğuşurken, asıl kanamayı sabah iş sürekliliği raporunda gördük: o 40 dakikada tamamlanamayan ödemelerin GMV karşılığı yedi haneliydi. Alert fatigue soyut bir kavram değil; kurt işaretleriyle dolu bir köyde gerçek kurdun rahatça gezmesi demek. O hafta izleme felsefemizi kökten değiştirmeye karar verdik: makinelerin ateşini değil, kullanıcının acısını ölçeceğiz.
Kaç Dakika Kötü Olmaya Hakkımız Var?
İlk adım, her kritik kullanıcı yolculuğu için bir SLI tanımlamaktı. Checkout için "başarıyla tamamlanan ödeme isteği / tüm ödeme istekleri", arama için "300 milisaniyenin altında dönen sorgu oranı", sipariş takibi için sayfanın hatasız açılma oranı. Sonra her SLI'a bir hedef koyduk: checkout başarısı için %99,9. Bu hedefin matematiksel gölgesi error budget: ayda yaklaşık 43 dakika "kötü olma hakkı". Bu çerçevenin en güçlü yanı mühendislikle ürün arasındaki pazarlığı sayısallaştırması. Bütçe doluyken kimse feature dondurma tartışması açmıyor; bütçe eridiğinde ise "bu sprint güvenilirlik sprint'i" kararı duyguyla değil rakamla veriliyor.
SLI tanımlamanın kağıt üstünde beş dakikalık göründüğünü, pratikte haftalar süren tartışmalar doğurduğunu da söyleyeyim. "Başarılı ödeme isteği" ne demek? Kullanıcının kartı limit yetersizliğinden reddedilirse bu bizim hatamız değil; onu paydadan mı çıkaracağız, payda tutup "beklenen hata" mı sayacağız? Ölçümü nereden alacağız: uygulama kendi başarısını raporlarsa, uygulamanın hiç cevap veremediği en kötü senaryoları göremez; biz bu yüzden kritik SLI'ları load balancer loglarından, yani kullanıcıya en yakın noktadan hesaplıyoruz. Bir de sahiplik meselesi var: her SLO'nun tek bir sahibi ekip olmak zorunda, yoksa bütçe eridiğinde herkes komşusuna bakıyor. Bu tartışmaların hepsi yorucuydu ve hepsi alarmların kendisinden daha değerli çıktı; çünkü ekipler ilk kez "bizim servisimizin iyi olması ne demek" sorusuna yazılı cevap verdi.
Yanma Hızı: İki Pencereli Nöbetçi
Alarm tarafında sihirli kavram burn rate, yani bütçeyi tüketme hızı. Hata oranınız tam SLO sınırındaysa burn rate 1'dir ve bütçe ayın sonunda biter; burn rate 14,4 ise 43 dakikalık bütçe iki saatte kül olur. Biz Google SRE workbook'taki multi-window multi-burn-rate düzenini Prometheus recording rule'ları ve Grafana alerting ile kurduk: son 1 saatin VE son 5 dakikanın burn rate'i 14,4'ü aşarsa page, son 6 saat ile 30 dakika 6'yı aşarsa yine page, son 3 gün ile 6 saat 1'i aşarsa sadece iş günü içinde bakılacak bir ticket. Kısa pencere alarmın hızlı kapanmasını, uzun pencere tek bir istek dalgasının nöbetçiyi kaldırmamasını sağlıyor. Recording rule'lar kritik; burn rate hesabını sorgu anında yapmaya kalkarsanız hem Prometheus'u yorarsınız hem de alarm değerlendirmesi yavaşlar. Biz her SLI için beş hazır seri tutuyoruz ve alarm kuralları bu serilerin üstünde milisaniyede değerleniyor.
CPU Alarmları Nereye Gitti?
En çok direnç gören karar şuydu: sebep tabanlı alarmların (CPU, bellek, disk, pod restart, Kafka lag) neredeyse tamamını page olmaktan çıkardık. Yok etmedik; hepsi dashboard'larda ve olay anında teşhis için bir tık uzakta duruyor. Ama telefon yalnızca semptom çaldırıyor: kullanıcı bir acı hissediyor mu, hissedecek mi? Ekipten haklı bir itiraz geldi: "Disk dolarsa kullanıcı acıyı hissettiğinde çok geç olur." Doğru; bu yüzden tükenme tipi metriklere tahminli alarm kurduk: "disk 4 saat içinde dolacak eğilimde" page'dir, "disk %80" değildir. Aradaki fark, alarmın bir eylem cümlesi taşıması: gecenin üçünde uyanan insan ne yapacağını alarmın adından okuyabilmeli.
Bu cümleyi ciddiye alıp her page'e bir runbook bağladık: alarm bildiriminin içinde ilgili dashboard'un, muhtemel sebepler listesinin ve ilk üç teşhis komutunun linki geliyor. Bir de haftalık bir ritüel başlattık: her pazartesi 30 dakikalık alarm review'ında geçen haftanın bütün page'leri tek tek masaya yatırılıyor. Aksiyon üretmeyen her page için üç seçenek var: eşiği düzelt, ticket seviyesine indir ya da tamamen sil. "Belki lazım olur" diye yaşatılan alarm, bizde artık teknik borç sayılıyor. İlk aylarda bu toplantıdan her hafta beş-altı silme kararı çıkıyordu; şimdilerde çoğu hafta gündem boş geçiyor ve boş gündem, sistemin sağlıklı olduğunun en sessiz kanıtı.
Altı Ay Sonra Nöbet Defteri
Rakamlar şöyle değişti: aylık toplam alarm 1.240'tan 214'e, gece page'leri 41'den 5'e indi; buna karşılık page başına gerçek aksiyon oranı %7'den %74'e çıktı. Cuma gecesi kaçırdığımız türden bir olay bir daha yaşandı ve bu kez 1 saat + 5 dakika penceresi olayı dördüncü dakikada yakaladı; müdahale 40 dakika değil 11 dakika sürdü. Nöbet anketindeki "nöbet dönemim uykumu ciddi etkiliyor" cevabı %61'den %18'e düştü; bunu vanity metric sanmayın, nöbetçi kalitesi doğrudan MTTR'dır. Beklemediğimiz bir yan etki de yöneticiler tarafında oldu: error budget panoları, teknik olmayan paydaşların da okuyabildiği ilk güvenilirlik dili haline geldi. "Checkout bu ay bütçesinin %60'ını yedi" cümlesi, bir yöneticiye "p99 latency yükseldi" cümlesinin asla anlatamadığını anlatıyor; kapasite ve öncelik tartışmaları artık bu panoların önünde yapılıyor. İtiraf edeyim, hâlâ mükemmel değiliz: SLO'su tanımlanmamış iç servislerde eski usul eşik alarmları yaşıyor ve her çeyrek bir SLI daha ekliyoruz. Burn rate eşiklerinin de ilk hallerinde yanlışlarımız oldu: düşük trafikli gece saatlerinde birkaç yüz isteklik bir örneklemde iki-üç hata, 5 dakikalık penceredeki burn rate'i tavana yapıştırıp bir kez nöbetçiyi boşuna kaldırdı. Çözüm, kısa pencere koşuluna minimum istek hacmi şartı eklemek oldu; istatistik, örneklem küçükken bağırmayı sever, alarm sistemi sevmemeli.
Bu dönüşümün özü teknik değil kültürel: alarm, "bir metrik eşiği aştı" demek değil, "bir insanın şu anda uyanması gereken bir şey oluyor" demek. Bu ikisini ayıramayan her izleme sistemi, er geç en pahalı olayında sessiz kalır. Kendi alarm envanterinizi çıkarıp "geçen ay kaç page geldi, kaçı aksiyon aldı" sorusunu cevaplarsanız muhtemelen bizimkine benzer bir tabloyla karşılaşırsınız; o tabloyu nasıl toparlayacağınızı konuşmak isterseniz iletişim sayfasından yazın. Gecenin üçünde çalmayan bir telefonun değerini, ancak bir zamanlar çalanlar bilir.