Uyarıların fazlalığını önleme

1) Sorun ve amaç

Uyarı yorgunluğu, sistem çok fazla alakasız veya işlem yapılamaz bildirim gönderdiğinde oluşur. Sonuç olarak, sayfaları görmezden gelmek, MTTA/MTTR'yi büyütmek ve gerçek olayları atlamak.
Amaç: Sinyalleri SLO'lara ve oyun kitaplarına bağlayarak nadir, anlamlı ve yürütülebilir hale getirmek.

2) Sinyal taksonomisi (kanal = sonuçlar)

Sayfa (P0/P1) - bir kişiyi uyandırır; Sadece şimdi manuel işlem gerektiğinde ve bir runbook olduğunda.
Bilet (P2) - saatler/gün içinde asenkron çalışma; uyanmaz, ancak SLA tarafından izlenir.
Dash-only (P3) - aktif eylemler olmadan gözlem/trend; gürültü yaratmaz.
Sessiz Nöbetçi - arka planda metrikler/denetim (RCA/post-mortemler için).

3) "Doğru" uyarının tasarlanması

• Amaç/hipotez (koruduğumuz şey: SLO, güvenlik, para, uyum).
• Tetikleme koşulları (eşik, pencere, kaynak çekirdek).
• Runbook/Playbook (kısa adım ID + bağlantısı).
• Sahip (takım/rol grubu).
• Tamamlama kriterleri (ne zaman kapatılacağı, otomatik çözünürlük).
• Güvenlik açığı sınıfı (kullanıcı etkisi/platform/güvenlik/maliyet).

4) SLO odaklı izleme

SLI/SLO - birincil sinyaller: kullanılabilirlik, gecikme, iş operasyonlarının başarısı.

• Kısa: 1 saat içinde bütçenin %5'i - Sayfa.
• Uzun: 6 saat içinde bütçenin %2'si - Bilet.
• Kohort: Bölge/Sağlayıcı/VIP Segmentine Göre Uyarılar - Daha Az Yanlış Küresel Alarm.

5) Gürültü azaltma teknikleri

1. Quorum probları: Yalnızca ≥2 bağımsız kaynaklar (farklı bölgeler/sağlayıcılar) sorunu doğrularsa tetiklenir.
2. Veri tekilleştirme - toplama anahtarları: hizmet + bölge + kod.
3. Histerezis/süre: Sivri uçları filtrelemek için "kırmızı bölgede ≥ N dakika".
4. Hız sınırı: X'den fazla uyarı/saat/hizmet; aşılırsa, bir sayfa + özet.
5. Otomatik erteleme/akıllı bastırma: T penceresinde tekrarlanan bir uyarı - kök ortadan kalkana kadar Ticket'a çeviri.
6. Olay korelasyonu: düzinelerce semptom yerine bir'ana uyarı "(örn. "DB kullanılamaz", mikro hizmetlerden 5xx'i sıkıştırıyor).
7. Bakım pencereleri: zamanlanmış çalışma, beklenen sinyalleri otomatik olarak bastırır.
8. Anomali + korkuluklar: anomaliler - sadece Bilet olarak, SLO sinyali tarafından onay yoksa.

6) Yönlendirme ve öncelikler

Öncelikler: P0 (Sayfa, 15 dakika güncelleme), P1 (Sayfa, 30 dakika), P2 (Bilet, 4-8 saat), P3 (gözlem).
Etiketlerle yönlendirme: hizmet/env/bölge/kiracı - çağrıya karşılık gelir.
Zaman artışı: 5 dakika içinde hiçbir ack P2 Görev Yöneticisi/IC.
Sessiz Saatler: Kritik Olmayanlar için Gece Saatleri; Sayfa P2/P3 için izin verilmez.
Yorulma politikası: Mühendis> N sayfa/vardiya varsa - P2'ye yeniden dağıtın, sinyal kirlenmesini artırın.

7) Uyarıların kalitesi: düzenlemeler

İşlem yapılabilirlik ≥ %80: Sayfaların büyük çoğunluğu runbook eylemine yol açar.
Yanlış Pozitif ≤ Sayfa sinyalleri için %5.
Düzeltme Süresi Uyarısı ≤ 7 gün - arızalı uyarı düzeltilmeli/kaldırılmalıdır.
Sahiplik %100 - her uyarının bir sahibi ve tanımı ile bir deposu vardır.

8) Kod yaşam döngüsü olarak uyarı

1. PR oluşturun (amaç tanımı, koşullar, runbook, sahip, test planı).
2. Sandbox/Shadow: Gölge uyarısı sohbete/günlüğe yazar, ancak sayfa yapmaz.
3. Kanarya: çağrı üzerine sınırlı seyirci, FP/TP ölçmek.
4. Prod: oran limiti + gözlem 2-4 hafta ile dahil.
5. Haftalık inceleme: kalite metrikleri, düzenlemeler/para çekme.
6. Amortisman: sinyal daha yüksek bir sinyal kopyalarsa veya işlem yapılamaz ise.

9) Vade metrikleri (gösterge tablosunda göster)

Çağrı saati başına uyarılar (medyan/95-persentil).
% actionable (tamamlanan adımlar var) ve false-positive oranı.
MTTA/MTTR sayfa ve sayfa etrafında - bilet fiyatı (yüksek olmamalıdır).
En çok konuşanlar (% ≥20 gürültü yaratan hizmetler/kurallar).
Uyarıyı düzeltmek için ortalama zaman.
Yakma oranı kapsamı: Iki pencerede SLO uyarılarıyla hizmetlerin payı.

10) Kontrol listesi "Uyarıların hijyeni"

• Uyarı SLO/SLI veya iş/güvenlik bağlıdır.
• Bir runbook ve sahibi var; Temas ve savaş odası kanalı belirtilmiştir.
• İki pencere (kısa/uzun) ve kaynakların bir çoğunluğu yapılandırılmıştır.
• Dedup, hız sınırı, otomatik çözümleme ve otomatik erteleme dahildir.
• Windows bakım ve bastırma sürümleri/geçişler için belirtilmiştir.
• Gölge/Kanarya geçti; Ölçülen FP/TP.
• Uyarı kalitesi metrikleri raporu dahil.

11) Mini şablonlar

Uyarı belirtimi (YAML fikri)

yaml id: payments-slo-burn severity: P1 owner: team-payments@sre purpose: "Защитить SLO успеха платежей"
signal:
type: burn_rate sli: payment_success_ratio windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
confirmations:
quorum:
- synthetic_probe: eu,us
- rum: conversion_funnel routing:
page: oncall-payments escalate_after: 5m controls:
dedup_key: "service=payments,region={{region}}"
rate_limit: "1/10m"
auto_snooze_after: "3 pages/1h"
runbook: "rb://payments/slo-burn"
maintenance:
suppress_when: [ "release:payments", "db_migration" ]

Standart güncelleme metni (gürültüyü azaltmak için)

Импакт: падение success_ratio платежей в EU (-3.2% к SLO, 20 мин).
Диагностика: подтвержден кворумом (EU+US синтетика), RUM — рост отказов на 2 шаге.
Действия: переключили 30% трафика на PSP-B, включили degrade-UX, след. апдейт 20:30.

12) Süreçler: Haftalık "Alert Review"

1. Top-talkers - düzenle/sil.

2. Sayfa sinyallerinde FP/TP - eşikleri/pencereleri/nisabı ayarlayın.

3. Düşürme için başvuranlar (Sayfa> Bilet) ve tersi.

4. Time-to-Fix-Alert durumu - gecikmeler servis sahiplerine iletilir.

5. SLO uyarıları ve runbook'ların varlığı ile kapsama alanı kontrol ediliyor.

13) Yayınlara ve işlemlere bağlantı

Serbest bırakma açıklamaları otomatik olarak geçici baskılamalar ekler.
Pencereleri değiştirin: Serbest bırakıldıktan sonraki ilk 30 dakika içinde - sadece SLO sinyalleri.
Playbook'lar kök üzerinde yoğunlaşmak için'daha düşük/bastırma anahtar olmayan uyarı "adımı içerir.

14) Güvenlik ve uyumluluk

Güvenlik sinyalleri (hack/sızıntı/anormal erişimler) - sessiz saatler olmadan ayrı kanallar.
Tüm baskılamaların/sessiz pencerelerin denetim günlüğü: kim, ne zaman, neden, son tarih.
Kritik uyarılar için değişmezlik gereksinimi (olay imzası).

15) Anti-desenler

"Every graph = alert" - çığ.
Satışlarda eşik "! = 0 hata".
Gerçeğin kaynağı olarak bir sonda/bir bölge.
Runbook/sahibi olmayan sayfa.
Terimsiz sürekli "geçici baskılar".
"Daha sonra düzelt" arızalı uyarılar - yıllarca birikir.
Serbest bırakma gürültüsünü üretim olaylarıyla karıştırmak.

16) Uygulama Yol Haritası (4-6 hafta)

1. Envanter: tüm uyarıları boşaltın, sahipleri ve kanalları kapatın.
2. SLO çekirdeği: Kritik hizmetler için çift pencereli yanma oranı kurallarını tanıtır.
3. Gürültü kontrolü: quorum, deadup ve rate-limit'i etkinleştirin, haftalık bir inceleme başlatın.
4. Runbook kapsamı: Playbook'larla Sayfa sinyallerinin %100'ünü kapatın.
5. Fatig politikası: sayfa sınırları/vardiya, Sessiz Saatler, yük yeniden dağıtımı.
6. Otomasyon: Alert-as-Code, Gölge/Kanarya, kalite metrikleri hakkında raporlama.

17) Alt satır

Sessizlik, izleme eksikliği değil, SLO ve süreçlerle ilişkili iyi tasarlanmış sinyallerdir. Quorum, çift pencere, dedup ve katı yönlendirme, uyarıları nadir, doğru ve yürütülebilir hale getirir. Ekip uyuyor, kullanıcılar mutlu, olaylar kontrol altında.