Skip to main content

> hassas_uyarı_mimarisi:_çok_pencereli_çoklu_tüketim_hızlı_(multi-window_multi-burn-rate)_slo_alarmları

Hassas Uyarı Mimarisi: Çok Pencereli Çoklu Tüketim Hızlı (Multi-Window Multi-Burn-Rate) SLO Alarmları

Tek pencereli eşik alarmları neden ya aşırı alarm yorgunluğu yaratır ya da hata bütçesi tamamen yandıktan 4 saat sonra uyanmanıza sebep olur; Google'ın Çok Pencereli Çoklu Tüketim Hızı algoritması her iki sorunu nasıl çözer?

Principal/Architect (L7+)

⚡ÖZET VE TEKNİK CEVAP

Geleneksel izleme sistemleri ilkel ve tek pencereli kurallara dayanır (ör. 'Hata oranı 5 dakika boyunca %1'i geçerse alarm çal'). Bu durum çözümsüz bir matematiksel ikilem yaratır:

1

Kısa Pencereler (5 dk): Geçici 2 saniyelik zararsız ağ dalgalanmalarında bile gece yarısı telefon çaldırarak alarm yorgunluğu yaratır.

2

Uzun Pencereler (1 saat): Gerçek büyük krizlerde çok geç alarm verir ve mühendisler uyandığında aylık hata bütçesinin %100'ü çoktan tükenmiş olur. Google SRE mühendisleri bu sorunu Çok Pencereli Çoklu Tüketim Hızlı (Multi-Window Multi-Burn-Rate) Uyarı Algoritması ile çözdü:

1

Tüketim Hızı Çarpanı (Burn Rate): 1 x tüketim hızı 30 günlük bütçeyi 30 günde bitirir; 14.4 ext{x} tüketim hızı ise 30 günlük bütçeyi 2 günde (1 saatte bütçenin %2'sini) tüketir.

2

Çift Pencere Doğrulaması: Alarm SADECE HEM Uzun Pencere (1 saatlik 14.4 ext{x}) HEM DE Kısa Pencere (5 dakikalık 14.4 ext{x}) aynı anda bütçeyi yakıyorsa çalar. Bu algoritma geçici gürültüyü %99 oranında elerken gerçek felaketlerde mühendisleri 2 dakikanın altında ayağa kaldırır.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

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

Mekanizma

Çok pencereli çoklu tüketim alarmları Prometheus üzerinde 4 matematiksel kademeyle çalışır:

1

Kritik Acil Alarm (14.4 ext{x} Hız): Bütçenin %2'sini 1 saatte yakar ightarrow Uzun Pencere: 1 saat, Kısa Pencere: 5 dakika ightarrow Telefonu anında çaldırır.

2

Orta Seviye Alarm (6 x Hız): Bütçenin %5'ini 6 saatte yakar ightarrow Uzun Pencere: 6 saat, Kısa Pencere: 30 dakika ightarrow Telefon çaldırır.

3

Yavaş Erime Bileti (1 x Hız): Bütçenin %10'unu 3 günde yakar ightarrow Uzun Pencere: 3 gün, Kısa Pencere: 6 saat ightarrow Gece kimseyi uyandırmaz, Jira bileti açar.

4

PromQL Çoklu Pencere Sorgusu: Hem 1 saatlik hem 5 dakikalık pencerelerin aynı anda 14.4 ext{x} eşiğini aştığını doğrulayan mantıksal and sorgusu çalıştırılır.

🎯2. Doğru Kullanım Senaryosu

Kapsam
  1. ▸Seviye mikroservis SLO alarmları, kurumsal SaaS erişilebilirlik yönetişimi, SRE alarm gürültüsünü azaltma ve kritik API ağ geçidi izleme sistemleri.

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

Kritik Risk

Kısa pencereyi (5 dk) eklemeyip sadece 1 saatlik uzun pencereye göre alarm kurmak ve arıza canlıda tamamen çözüldükten sonra bile sistemin 55 dakika boyunca boş yere telefon çaldırmaya devam etmesi.

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler
  • ✓

    15 saniyelik geçici dalgalanmalar için nöbetçinin gecede 10 kez uyanması

  • ✓

    müşteriler şikayet ettikten 90 dakika sonra ilk alarmın çalması

  • ✓

    hata bütçesinin tamamı tükenmesine rağmen hiçbir alarmın çalmamış olması

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler
  • ✓

    Sloth veya Pyrra gibi araçlarla Google SRE standart çok pencereli PromQL şablonlarını kullanın

  • ✓

    yavaş tüketimleri (1 ext{x}-2 ext{x}) telefon çaldırmak yerine Jira biletine yönlendirin

  • ✓

    tüm SLO alarmlarında çift pencere doğrulamasını zorunlu kılın

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

Ödünleşim

Çok pencereli çoklu tüketim alarmları sahte alarmları tamamen sıfırlar ve gerçek krizlerde anında uyarır; ancak ileri seviye matematiksel PromQL ve SLO modelleme bilgisi gerektirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir ödeme ağ geçidinin %99,9 erişilebilirlik SLO hedefi vardı. Kullandıkları basit kural (10 dakika boyunca Hata > %0,1) bankaların geçici zaman aşımları yüzünden haftada 40 sahte alarm üretiyor ve mühendisleri çıldırtıyordu. Büyük bir veritabanı bozulması sırasında hata oranı %0,08'de (statik eşiğin hemen altında) kaldı ve hiçbir alarm çalmadan 12 saat içinde tüm aylık hata bütçesi yandı. SRE ekibi Google Çok Pencereli Çoklu Tüketim Hızı modelini kurdu:

1

Kritik krizler için 14.4 ext{x} (1 saat / 5 dk pencere) alarmı kurdu,

2

Orta seviye için 6 x (6 saat / 30 dk pencere) alarmı kurdu, ve

3

Yavaş erimeleri Jira'ya bağladı. Gece çalan sahte alarm sayısı 40'tan 0'a indi ve gerçek krizler 110 saniyenin altında yakalandı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Hizmet Seviyesi Hedefi (SLO) alarmlarında 'Tüketim Hızı' (Burn Rate) nedir?

Bir servisin kabul edilebilir hata bütçesini ne kadar hızlı tükettiğini ölçen birimsiz bir çarpandır; $1 ext{x}$ tüketim hızı 30 günlük bütçeyi tam 30 günde bitirirken, $14.4 ext{x}$ tüketim hızı tüm bütçeyi sadece 2 günde (1 saatte bütçenin %2'sini) tüketir.
Q2

Çoklu tüketim alarmlarında Çift Pencere Doğrulaması (Uzun Pencere + Kısa Pencere) neden zorunludur?

Uzun pencere sahte alarmları önlemek için yeterli istatistiksel veriyi garanti eder; kısa pencere ise arıza canlıda çözüldüğü anda alarmın gereksiz yere çalmaya devam etmesini engelleyerek anında susmasını sağlar.

Hassas Uyarı Mimarisi: Çok Pencereli Çoklu Tüketim Hızlı (Multi-Window Multi-Burn-Rate) SLO Alarmları — Sıkça Sorulan Sorular

Çok Pencereli Çoklu Tüketim Hızlı Prometheus kurallarını otomatik oluşturan açık kaynaklı araçlar hangileridir?

Sloth (basit YAML tanımlarından standart Prometheus/PromQL SLO kuralları üretir) ve Pyrra.

Yavaş eriyen $1 ext{x}-2 ext{x}$ hata bütçesi tüketim hızları nasıl yönetilmelidir?

Asla gece insanları uyandırmamalı; mesai saatlerinde incelenmek üzere otomatik bir orta öncelikli Jira bileti veya Slack bildirimi oluşturulmalıdır.

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

Temel Gerçekler & İlkeler

  • ▸

    Çok Pencereli Çoklu Tüketim Alarmları hassas izleme için Google SRE dünya standardıdır.

  • ▸

    Tüketim Hızı bütçe erime hızını ölçer (14.4 ext{x} = 1 saatte bütçenin %2'sinin yanması).

  • ▸

    Çift Pencere doğrulaması (Uzun + Kısa) geçici gürültüyü %99 oranında yok eder.

  • ▸

    Hızlı erimeleri (14.4 ext{x}) telefon alarmına, yavaş erimeleri (1 x) Jira biletine yönlendirin.

Yaygın Yanılgılar

  • ✗

    Yanılgı: 5 dakikalık statik eşik alarmları mikroservisler için yeterlidir (Gerçek: Statik eşikler ya aşırı sahte alarm üretir ya da sinsi bütçe tüketen arızaları kaçırır).

  • ✗

    Yanılgı: Hata bütçesindeki her erime için nöbetçi mühendis uyandırılmalıdır (Gerçek: Sadece felaket seviyesindeki >14.4 ext{x} erimeler telefon çaldırmalıdır).

Karar Kılavuzu & Önceliklendirme

Sahte alarmları tamamen bitirmek ve gerçek sistem kesintilerini 2 dakikanın altında tespit etmek için Sloth/Pyrra ile üretilen Google Çok Pencereli Çoklu Tüketim Hızı SLO alarmlarını kurun.

Doğrulanmış Kaynaklar & Referanslar