Uyarı ve Arıza Yanıtı
(Bölüm: Teknoloji ve Altyapı)
Kısa Özet
Güçlü uyarı, yalnızca "kırmızı metrik'değil, kullanıcı değerinin ihlal edildiğinin bir işaretidir. "IGaming için SLO kapıları (gecikme, kullanılabilirlik, ödeme dönüşümü, Time-to-Wallet), çoklu yakma kuralları, açık çağrı, yükseltme, ChatOps ve runbooks rolleri önemlidir. Amaç, sapmayı hızlı bir şekilde görmek, düzeltebilenleri bilgilendirmek ve bir dahaki sefere daha hızlı ve daha ucuz tepki vermek için bilgiyi düzeltmektir.
1) Temel Bilgiler: Metriklerden Eyleme
SLI - SLO - Uyarı - ölçülen kalite - hedef seviye - "bütçe açık" koşulu.
Şiddet (SEV): SEV1 - kritik (risk altındaki gelir/GGR), SEV2 - ciddi, SEV3 - orta, SEV4 - küçük.
Etki/Aciliyet: Kim acı çekiyor (tüm/bölge/kiracı/kanal) ve ne kadar acil (TTW↑, p99↑, hata- rate↑).
İşlem yapılabilirlik: her alarm için - belirli bir eylem (runbook + sahibi).
2) Sinyal taksonomisi
ТехSLO: p95/p99 gecikme API'si, hata oranı, doygunluk (CPU/IO/GPU), kuyruk gecikmesi.
BusinessSLO: Ödeme dönüşümü (girişim - başarı), Time-to-Wallet (TTW), bahis başarısı, oyun lansmanı.
Ödeme yolları: PSP'ye özgü metrikler (zaman aşımı/düşüş artışları).
Ön/mobil: RUM metrikleri (LCP/INP), çökme oranı, senaryo sentetikleri (giriş/depozito/oran/çıkış).
3) Uyarı politikası: SLO ve yakma oranı
SLI/SLO Örnekleri
Payments-api kullanılabilirliği ≥ 99. %9/30d p95'/depozito '≤ 250 ms/30d
'Payments _ attempt> success ≥ temel − dönüşümü 0. %3/24 saat
TTW p95 ≤ 3 dakika/24 saat
Çoklu pencere/Çoklu yanma (идея PromQL)
Hızlı yanma: SLO ihlali normalden 5-10 × daha hızlı (5-15 dakika içinde uyarı sayfası).
Yavaş yanma: Yavaş bütçe tükenmişliği (1-3 saat içinde bilet + analiz).
yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2.. 3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }
4) Gürültü azaltma ve sinyal kalitesi
Gerçeğin doğru kaynağı: Ağır "ham" ifadelerle değil, kümelerle (kayıt kuralları) değiştirmek.
Veri tekilleştirme - 'Hizmet/bölge/önem derecesine'göre alertmanager grupları.
Hiyerarşi: İş/SLI için ilk uyarı, aşağıda - teşhis olarak teknik metrikler.
Bastırma: planlı bakım/serbest bırakma (ek açıklama) sırasında, yukarı akış olayları sırasında.
Kardinalite: Uyarı etiketlerinde 'user _ id/session _ id' kullanmayın.
Test uyarıları: Düzenli "eğitim" tetikleyicileri (kanalları, rolleri, runabook bağlantılarını kontrol etme).
5) Alertmanager Yönlendirme ve Eskalasyon
yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack
receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"
inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]
Fikir: SEV = sayfa> PagerDuty/SMS; Gerisi Slack/ticket. İnhibisyon, yukarıdaki aktif SEV ile daha düşük seviyelerin "yutturmacasını" bastırır.
6) Grafana Uyarı (ek katman olarak)
Panolarda Merkezi Uyarı kuralları (Prometheus/Loki/Cloud).
İletişim noktaları: PagerDuty/Slack/Email, Klasör başına bildirim politikaları.
Sessizlikler: planlı işler, göçler, salıvermeler.
Biletteki panelin otomatik ekran görüntüsüne sahip anlık görüntüler.
7) Çağrı ve canlı süreçler
Rotasyon: 1. hat (SRE/platform), 2. hat (servis sahibi), 3. hat (DB/Payments/Sec).
SLA reaksiyonları: 5 dakika (SEV1) ≤ tanıma, 15 dakika ≤ tanı, her 15-30 dakikada bir iletişim.
Görev kanalları: '# incident-warroom', '# status-updates' (sadece gerçekler).
Çalışma kitapları: Her uyarıdaki bağlantı + ChatOps hızlı komutları ('/rollback ','/freeze','/scale ').
Eğitim alarmları: aylık (insanları, kanalları, runabook alaka düzeyini kontrol etme).
8) Olaylar: Yaşam Döngüsü
1. Algılama (uyarı/rapor/sentetikler) - Çağrı üzerine onaylayın.
2. Triyaj: SEV/etkilenen/hipotez, açık savaş odası belirlemek.
3. Stabilizasyon: rolls/rollback/scaling/phicheflags.
4. İletişim: durum şablonu (aşağıya bakınız), ETA/sonraki adımlar.
5. Kapanış: SLO kurtarma onayı.
6. Olay Sonrası İnceleme (RCA): 24-72 saat sonra, hiçbir ücret, eylem öğeleri.
- Ne kırıldı/etkilendi (bölge/kiracı/kanal)
- Başladığında/SEV
- Geçici önlemler (hafifletme)
- N dakika içinde sonraki durum güncellemesi
- İletişim (Olay Yöneticisi)
9) iGaming'in özellikleri: "ağrı" bölgeleri ve uyarıları
Ödemeler/TTW: PSP zaman aşımlarının payı, kod hatalarında artış, TTW p95> 3m.
Turnuva zirveleri: P99 API/oyun başlangıç zamanı/kuyruk gecikmesi; limitlerin/otomatik ölçeğin teşviki.
Fonların sonuçları: Kazıcı/manuel kontrollerin SLA'sı, ülkeye göre limitler.
Oyun sağlayıcıları: stüdyoya göre kullanılabilirlik, oturum başlatma süresi, başlatma düşüşü.
RG/Uyumluluk: uzun oturumlar/" dogon" patlamaları, eşikleri aşan - bir sayfa değil, RG ekibine bir bilet + bildirim.
10) Kural örnekleri (isteğe bağlı)
Yüksek gecikme süresi p95 (API)
promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"
Kurşun kuyruğu "açık"
promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"
Ödeme Dönüşümü Daldırıldı
promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"
11) ChatOps ve Otomasyon
Eylem düğmeleri ile uyarıları otomatik gönderme: Kanaryayı durdur, Rollback, Scale + N
Komut kısaltmaları: '/incident start ','/status update','/call
Botlar bağlamı sıkılaştırır: en son deploi, bağımlılık grafiği, örnekler, ilgili biletler.
12) Olay Sonrası Çalışma (RCA)
Factbox: Zaman çizelgesi, ne gördüm/denedim, ne işe yaradı.
Temel neden: teknik ve organizasyonel nedenler.
Algılamalar ve Savunmalar: Hangi sinyallerin yardımcı olduğu/başarısız olduğu.
Eylem öğeleri: belirli görevler (SLO/uyarılar/kodlar/sınırlar/testler/runabook).
Vade tarihleri ve sahipleri: şartlar ve sorumluluklar; 2-4 hafta sonra takip seansı.
13) Uygulama kontrol listesi
1. Anahtar akışları için SLI/SLO tanımlayın (API/Payments/Games/TTW).
2. Kayıt kurallarını ve çoklu yanma uyarılarını + Alertmanager yönlendirmesini ayarlayın.
3. Rotasyon, reaksiyon SLO ve yükselmeler ile çağrı üzerine girin.
4. Uyarıları runbook'lara ve ChatOps komutlarına bağlayın.
5. Bastırma/sessiz pencereleri, serbest bırakma/çalışma ek açıklamalarını yapılandırın.
6. Öğrenme alarmları ve oyun günü senaryoları yapın (PSP düşüşü, p99 yükselişi, kuyruk gecikmesi yükselişi).
7. Uyarı Kalitesini Ölçün: MTTA/MTTR, % gürültülü/yanlış, SLO tarafından kapsama.
8. Düzenli RCA'lar ve eşiklerin/süreçlerin revizyonu.
9. İş/destek iletişim durumunu (şablonlar) girin.
10. Her şeyi kod olarak belgeleyin: kurallar, rotalar, runabook bağlantıları.
14) Anti-desenler
"Her metrik" uyarı fetig ile uyarı, görmezden.
SLO yok - neyin "normal" olduğu ve neyin "yandığı" açık değildir.
Bastırma/engelleme yok - çığ kopyaları.
Küçük olaylar için gece sayfası (SEV, Impact ile karşılaştırılamaz).
Runbook/owner olmadan uyarılar.
ChatOps/denetim olmadan "manuel" eylemler.
RCA/Eylem öğeleri yok - olayları tekrarlayın.
Özet
Uyarı ve yanıt vermek bir kurallar dizisi değil, bir süreçtir. Çoklu yakma uyarılarıyla SLO'yu bağlayın, açık bir çağrı üzerine yükseltme oluşturun, ChatOps ve canlı runabook ekleyin, düzenli olarak RCA'lar ve eğitim oturumları gerçekleştirin. Daha sonra olaylar daha az sıklıkta, daha kısa ve daha ucuz olacak ve sürümler iGaming'in sıcak saatlerinde bile daha öngörülebilir olacaktır.