Arıza haberini müşteriden alıyorsanız: izlenebilirlik, SLO ve hata bütçesi

Sistemin bozulduğunu müşteri telefonuyla öğreniyorsanız eksik olan pano sayısı değil, ölçtüğünüz şeyin kendisi. İşleyen kurulumun üç parçası var. Birincisi kullanıcının deneyimini temsil eden bir gösterge, yani SLI: başarılı olay sayısının geçerli olay sayısına oranı. İkincisi bu göstergeye konmuş, yüzde 100 olmayan bir hedef (SLO) ve hedeften doğan hata bütçesi. Üçüncüsü uyarıların sunucu sıcaklığına değil bu bütçenin tükenme hızına bağlanması. Google'ın SRE ekibinin yüzde 99,9 hedefi için verdiği başlangıç eşiği net: bütçenin yüzde 2'si bir saat içinde gidiyorsa nöbetçi aranır. Hangi aracı alacağınız bundan sonraki konu.

Panolar yeşil, ödeme akışı bozuk

Klasik izleme önceden bildiğiniz soruları cevaplar: CPU yüzde kaçta, disk doldu mu, servis ayakta mı. Bu sorular altyapı çökerken işe yarar. Bugünün arızalarının çoğu ise ayakta duran ama yanlış cevap veren sistemlerden geliyor. Ödeme sağlayıcısı yalnızca belirli bir kart tipinde zaman aşımına düşer. Kataloğu büyüyen tek bir kurumsal müşteri yüzünden sepet sorgusu yavaşlar, kuyruk birikir, hiçbir sunucu ölmez. Sağlık kontrolü uç noktası 200 dönmeye devam eder.

İzlenebilirlik tam bu boşluğu doldurur: sistemin dışarıya verdiği veriden, kurulum sırasında aklınıza gelmemiş soruları sorabilmek. Ayrımı test etmenin pratik yolu şu soru. "Şu anda yavaşlık yaşayan kullanıcılar hangi ülkede, hangi API sürümünü çağırıyor ve hangi sorguda bekliyor?" Cevabı yeni kod yazıp yayına çıkarmadan verebiliyorsanız izlenebilirliğiniz var, yoksa elinizde sadece izleme var.

Göstergeyi kullanıcının durduğu yerden seçin

SLI'yı sistemin iç organlarından değil dış yüzeyinden ölçün. İyi bir formül şu kalıba oturur: geçerli isteklerin yüzde kaçı beklenen sürede ve hata dönmeden tamamlandı. Örnek: "Sepete ekleme isteklerinin yüzde kaçı 500 milisaniyenin altında ve 5xx dönmeden bitti." Ortalama kullanmayın, ortalama saklar. Yüz isteğin doksan beşi 100 milisaniyede, beşi on saniyede dönerse ortalama gayet makul görünür, o beş kullanıcı ise sitenizi terk etmiştir. p95 ve p99 dilimlerine bakın.

İki tuzağa dikkat. Birincisi, servisin kendi içinden ölçülen süreler ağdaki ve istemci tarafındaki gecikmeyi görmez; kullanıcı deneyimini tarayıcı tarafından ölçmek gerekir, bunu Core Web Vitals ve site hızı yazısında ayrıntılandırdık. İkincisi, sağlık kontrolü uç noktasını SLI sanmak. O uç nokta genelde bir veritabanına dokunmaz ve uygulamanız iş yapamaz hâldeyken bile neşeyle 200 döner.

Yüzde 100 hedef değil, hata bütçesi buradan çıkar

SRE kitabının cümlesi doğrudan: yüzde 100 muhtemelen hiçbir zaman doğru güvenilirlik hedefi değildir, hem ulaşılamaz hem de kullanıcıların istediğinden veya fark ettiğinden fazladır. Hedefi yüzde 100'ün altına çektiğiniz anda elinizde harcanabilir bir pay oluşur, adı hata bütçesi.

Aritmetiği yapmak kararı somutlaştırır. Otuz günlük pencere 43.200 dakika. Yüzde 99,9 hedefi ayda yaklaşık 43 dakika kesinti hakkı demek. Yüzde 99,95 yaklaşık 22 dakika, yüzde 99,99 ise 4,3 dakika. Toplantıda yüzde 99,99 isteyen ekibe sorulacak soru şu: bir ay boyunca tüm dağıtımlar, veritabanı bakımları ve sağlayıcı arızaları toplamı 4 dakikayı aşmayacak mı? Aşacaksa hedef yanlış yazılmış, sistem değil.

Uyarıyı sebebe değil yakma hızına bağlayın

Sabit eşikli uyarı iki yönden birden bozar. "Son beş dakikada hata oranı yüzde 1'i geçti" kuralı bir yandan gece boyunca gereksiz çalar, bir yandan da aylık bütçeyi sessizce eriten yüzde 0,5'lik sürekli sızıntıyı hiç görmez. SRE Workbook uyarıları dört ölçütle değerlendiriyor: isabet (precision), yakalama (recall), tespit süresi ve alarmın kapanma süresi. Bu dördünü birlikte iyileştiren kurulum, bütçenin yanma hızını iki pencerede birlikte okuyor.

Yüzde 99,9 hedefi için önerilen başlangıç tablosu şöyle: bir saatlik pencerede 14,4 kat yanma (bütçenin yüzde 2'si) nöbetçiyi arar; altı saatlik pencerede 6 kat yanma (yüzde 5) yine arar; üç günlük pencerede 1 kat yanma (yüzde 10) çağrı değil kayıt açar. Her kuralın yanına kısa bir doğrulama penceresi konur (sırasıyla 5 dakika, 30 dakika, 6 saat) ve bu kısa pencere alarmın arıza bittikten sonra saatlerce çalmasını engeller. Üç kural, gecelik gürültünün büyük kısmını da beraberinde götürür.

Üç sinyalin işbölümü

Metrik ucuz, toplu ve sürekli: bir şeyin bozulduğunu söyler. İz (trace) tek bir isteğin servisler arasındaki yolunu gösterir: nerede bozulduğunu söyler. Log pahalıdır ama tek olayın ayrıntısını taşır: neden bozulduğunu söyler. Sıralama önemli, çünkü çoğu ekip yalnızca üçüncüsüne yatırım yapıp ilk iki soruyu grep ile cevaplamaya çalışıyor. Dağıtık bir sistemde bu, yanlış aramada saatler kaybetmek anlamına geliyor.

Güvenlik logları bu üçlüden ayrı bir amaca hizmet eder; kim ne yaptı sorusunun izini ve saklama sürelerini log yönetimi, SIEM ve MDR yazısında ele aldık. İki taraf aynı boruyu paylaşabilir, aynı saklama politikasını paylaşamaz.

Faturayı büyüten iki şey: kardinalite ve örnekleme

Telemetri maliyeti tipik olarak yanlış etiketlerden patlar. OpenTelemetry'de bir metrik akışı için varsayılan kardinalite sınırı 2.000 nitelik kombinasyonu. Sınır aşıldığında fazlalık atılmaz, otel.metric.overflow=true işaretli tek bir veri noktasına katlanır ve özgün nitelikler düşer. Toplamlar doğru kalır, ama artık "hangi müşteride" diye filtreleyemezsiniz. Çözüm sınırı yükseltmek değil, sınırsız nitelikleri baştan etiket yapmamak: kullanıcı kimliği, oturum anahtarı ve ham URL yerine /user/{id} gibi şablonlanmış değerler kullanın.

İzlerde ise kuyruk tabanlı örnekleme (tail sampling) işi çözer. Karar izin tamamlanmasından sonra verildiği için politikayı içeriğe göre yazabilirsiniz: hatalı izlerin tamamını tut, belirli süreyi aşan yavaş izleri tut, geri kalan normal trafikten karşılaştırma için olasılıklı bir taban örnek al. Collector bu kararı verirken izleri bellekte tuttuğu için bellek sınırlayıcı işlemcisini birlikte kurmayı atlamayın. Aynı katman maskeleme için de doğru yer: kişisel veri içeren alanlar, yetkilendirme başlıkları ve anahtarlar telemetriye sızmamalı. Sırların kaçış yollarını koda gömülü sır yönetimi yazısında sıralamıştık, log satırları o listenin sessiz maddesi.

Standart tarafı: OpenTelemetry artık güvenli bahis

OpenTelemetry 21 Mayıs 2026'da CNCF'in en üst olgunluk seviyesine, mezun (graduated) statüsüne geçti. İz, metrik ve log sinyalleri genel kullanıma açık; dördüncü sinyal olan profil ise alfa aşamasında. Projenin 2.800'den fazla şirketten 12.000'i aşkın katkıcısı var ve 240'ı geçen CNCF projesi içinde geliştirme hızı bakımından yalnızca Kubernetes'in gerisinde. Pratikteki karşılığı taşınabilirlik: enstrümantasyonu bir kez yapıp arka ucu satıcı değiştirdiğinizde yeniden yazmamak.

Sahadaki dağılım da bu yönü destekliyor. Grafana'nın 76 ülkeden 1.363 katılımcıyla 1 Ekim 2025 ile 6 Ocak 2026 arasında yürüttüğü ankette Prometheus'a yatırım yapanlar yüzde 77, OpenTelemetry'ye yatırım yapanlar yüzde 76, ikisine birlikte yatırım yapanlar yüzde 65. Yeni bir kurulum yapıyorsanız enstrümantasyonu satıcıya özel kütüphaneyle başlatmanın bugün savunulacak bir tarafı kalmadı.

SLO'yu karara bağlamazsanız süs kalır

Hata bütçesinin işe yaraması için bir politikaya bağlanması gerekir. Politika üç satırla yazılır: bütçe rahatsa normal hızda yayına çıkılır, bütçe eşiğin altına inerse yeni özellik işi durup ekip güvenilirlik işine döner, bütçe bittiğinde dağıtım dondurulur. Bu kural yazılı olmadığında SLO bir pano süsüne dönüşür ve kimse hedefi tutmamanın sonucunu üstlenmez.

Aynı Grafana anketi bu disiplinin neden acil olduğunu da gösteriyor. Ekiplerin en büyük tek engeli yüzde 30 ile uyarı yorgunluğu; onu karmaşıklık ve ek yük (yüzde 38), sinyal-gürültü sorunu (yüzde 34) ve maliyet (yüzde 31) izliyor. Bütçe yanmasına bağlı üç kural, bu listenin ilk üç maddesini birden küçültür çünkü çalan şeylerin sayısını düşürür.

Yapay zekâ hattı hızlandırıyor, kararlılığı bozuyor

DORA'nın 2024 raporunda yapay zekâ kullanımındaki yüzde 25'lik artış, teslimat kararlılığında yüzde 7,2'lik düşüşle ilişkilendirildi. 2025 raporunda geliştiricilerin yüzde 90'ı yapay zekâ araçlarını kullanıyordu, verim tarafındaki ilişki artıya döndü, ama kararsızlık artmaya devam etti. Daha hızlı ve daha kırılgan bir hatta geçiyorsanız kırılmayı ölçen tarafı da güçlendirmeniz gerekir. Hattın kendisini nasıl kuracağınızı küçük ekipler için CI/CD yazısında anlattık; SLO bu hattın çıkışına konan fren.

İlk iki hafta

Birinci hafta: iki veya üç kritik kullanıcı yolu seçin, tipik olarak giriş, sepete ekleme ve ödeme. Her biri için ölçümü mümkün olduğunca dışarıdan alın, gateway veya yük dengeleyici seviyesi iyi bir yer. Her yola bir SLI ve gerçekçi bir SLO yazın; çoğu iş için yüzde 99,9 makul bir başlangıç. İkinci hafta: iki uyarı bırakın, biri hızlı yanma için nöbetçi çağrısı, biri yavaş sızıntı için kayıt. Eski eşik uyarılarının büyük kısmını kapatın. Kritik yollara dağıtık iz ekleyin ve hatalı izleri tam saklayın.

Sonrası için tek soru yeterli: her olaydan sonra "bunu müşteriden önce bize hangi sinyal söylerdi?" diye sorun ve eksik sinyali o hafta ekleyin. Olay anında izlenecek adımları olay müdahale planı yazısında sıralamıştık. Bu alışkanlık telemetrinizi satıcı özellik listesine göre değil kendi arıza geçmişinize göre büyütür, faturayı da öyle tutar.