İşlemler ve Uyarı - Sistem Kapasitesine Göre Yönetim

Sistem kapasitesi uyarıları

1) Neden ihtiyacınız var

Kapasitif uyarılar, olaydan çok önce teknik sınırlara yaklaşma konusunda uyarıyor: "Tavanın %80'iyiz - ölçeklendirme zamanı. Market işletmeleri için bu doğrudan parayla ilgilidir: cevapsız bahisler/depozitolar, oturum düşüşleri, canlı oyun gecikmeleri ve sağlayıcı başarısızlıkları = kayıp gelir, itibar, para cezaları ve geri tepmeler.

• Tahmin edilebileceği gibi, en yüksek yüklere (etkinlikler, turnuvalar, akışlar, büyük kampanyalar) dayanır.
• Zamanında otomatik ölçeklemeyi açın ve kapasite artışını planlayın.
• SLO/para risk altındayken gürültüyü azaltın ve "işte" uyanın.
• Mühendislere runbook aracılığıyla doğru öneriler verin.

2) Temel kavramlar

Kapasite: maksimum kararlı iş hacmi (RPS/TPS, bağlantılar, IOPS, iş hacmi).
Headroom: mevcut yük ve limitler arasındaki marj.
SLO/SLA: hedef kullanılabilirlik/yanıt süresi seviyeleri; Uyarılar "SLO-farkında" olmalıdır.
Burn-rate: Hata/gecikme SLO bütçesini "yakma" hızı.
Yüksek/Düşük Filigran: Harekete geçirmeler ve otomatik kurtarma için üst/alt seviyeler.

3) Sinyal mimarisi ve veri kaynakları

Telemetri: metrikler (Prometheus/OTel), günlükler (ELK/ClickHouse), izler (OTel/Jaeger).
Katman yaklaşımı: katmanlara göre uyarılar (Edge, API, iş hizmetleri, kuyruklar, akışlar, veritabanları, önbellekler, dosya, nesne depoları, harici sağlayıcılar).
Bağlam: özellik bayrakları, sürümler, pazarlama kampanyaları, turnuvalar, coğrafi hizalama.
Olay lastiği: Alertmanager/PagerDuty/Opsgenie/Slack; Runbook ve eskalasyon matrisine bağlanma.

4) Katmanlara göre temel metrikler (neyin izlenmesi ve neden)

Kenar/L7

RPS, 95/99 yüzdelik gecikme, hata oranı (5xx/4xx), açık bağlantılar.
Hız limitleri/kotalar, düşüşler на CDN/WAF/Güvenlik Duvarı.

API- шлюз/Backend-for-Frontend

İşçi/iş havuzu tarafından doygunluk, istek kuyruğu, downstreams için zaman aşımları.
Bozunma fraksiyonu (geri dönüşler, devre kesiciler).

Kuyruklar/Akış (Kafka/Tavşan/Pulsar)

Gecikme/tüketici gecikmesi, iş yükü artış hızı, iş hacmi (msg/s, MB/s).
Bölme eğrilmesi, yeniden dengeleme churn, ISR (Kafka için), retray/büyükbaba-sonra.

Asenkron işçiler

Görev zaman aşımı, kuyruk uzunluğu, süresi dolan SLA görevlerinin yüzdesi.
Havuzlarda doygunluk CPU/Bellek/FD.

Önbellekler (Redis/Memcached)

Vuruş oranı, gecikme, tahliye, kullanılmış bellek, bağlı istemciler/ops/s.
Kümeler: yuvalar/kopyalar, yük devretme olayları.

БД (PostgreSQL/MySQL/ClickHouse)

Aktif bağlantılar vs max, kilit beklemeleri, çoğaltma gecikmesi, tampon/önbellek vuruşu.
IOPS, okuma/yazma gecikmesi, kontrol noktası/sifon, şişkinlik/parçalanma.

Nesne/Dosya Depolama

PUT/GET gecikme, 4xx/5xx, çıkış, istekler/sn, sağlayıcı sınırları.

Dış Sağlayıcılar (Ödemeler/LCC/Oyun Sağlayıcıları)

TPS sınırları, QPS pencereleri, hata oranı/zaman aşımı, geri ödeme kuyruğu, "çağrı başına maliyet".

Altyapı

CPU/Bellek/FD/IOPS/Düğümlerde/bölmelerde/ASG'de ağ doygunluğu.
HPA/VPA olayları, bekleyen bölmeler, konteyner OOM/Kısma.

5) Kapasitif uyarı türleri

1. Statik eşikler

Basit ve anlaşılır: 'db _ connections> 80 % max'. İşaret sinyali kadar iyi.

2. Uyarlanabilir (dinamik) eşikler

Mevsimsellik ve eğilime göre (yuvarlanan pencereler, STL ayrışması). "Haftanın bu saati/günü için alışılmadık derecede yüksek" yakalamaya izin verin.

3. SLO odaklı (yanma oranı)

Hata bütçesi yeme oranı X saat ufkunda SLO'yu tehlikeye attığında tetiklenirler.

4. Prognostik (tahmin uyarıları)

"Mevcut trendde 20 dakika sonra kuyruk %90'a ulaşacak". Kısa pencerelerde Doğrusal/Sağlam/Peygamber benzeri tahmin kullanılır.

5. Çoklu sinyal

'Queue _ lag ↑' + 'consumer _ cpu %85' + 'autoscaling at max' - "manüel müdahale gereklidir" kombinasyonuyla tetikleyin.

6) Eşik politikaları ve gürültü önleme

• Yukarı: uyarı %70-75, Girit %85-90. Aşağı: histerezis 5-10 pp "Eşikte testere" olmamak için.

• 'for: 5m' for criteria ', for: 10-15m' for warnings. Gece modu: çağrı yapmadan sohbet etmek için kritik olmayan rota.

• Olay kartları üretmemek için servis/küme/coğrafi olarak gruplayın.

• KYC sağlayıcısı dışarıdaysa ve API hataları entegrasyon sahibine çağrı yapmaktan kaynaklanıyorsa, tüm tüketiciler değil.

• Stok süresi boyunca, "beklenen büyüme" için gürültü eşiklerini yükseltin, ancak SLO uyarılarını sağlam bırakın.

7) Kural örnekleri (sözde-Prometheus)

ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8) SLO yaklaşımı ve iş önceliği

Sinyalden iş etkisine: Kapasite uyarıları, riski SLO'ya (belirli oyunlar/coğrafi/GGR metrikleri, depozito dönüşümü) yönlendirmelidir.
Çok seviyeli: çağrı üzerine hizmet için uyarılar; Girit - alan adı sahibi sayfası; SLO-drop - büyük olay ve takım "özet" kanalı.
Bozulma özellikleri: otomatik yük azaltma (kısmi salt okunur, ağır özelliklerin kesilmesi, jackpot yayınlarının sıklığının azaltılması, canlı oyunlarda'ağır "animasyonların kapatılması).

9) Otomatik ölçeklendirme ve "doğru" tetikleyiciler

HPA/VPA: sadece CPU/Bellek ile değil, aynı zamanda iş metrikleri (RPS, kuyruk gecikmesi, p99 gecikme) ile de hedefleyin.
Isınma zamanlamaları: Soğuk başlatma ve sağlayıcı sınırlarını (ASG spin-up, konteyner üreticileri, ısınma önbellekleri) dikkate alın.
Korkuluklar: çığ benzeri hataların büyümesinde koşulları durdurun; "Skalim problemine" karşı koruma.
Capacity-playbook'lar: nerede ve nasıl bir parça/parti/kopya ekleneceği, bölgeye göre trafiğin nasıl yeniden dağıtılacağı.

10) Süreç: tasarımdan operasyona

1. Limit haritalama: Her katman için "gerçek" darboğaz sınırlarını toplayın (maks conns, IOPS, TPS, kota sağlayıcıları).
2. Öngörücü metriklerin seçimi: Hangi sinyaller önce "N dakika içinde dinlenme" gösterir.
3. Eşik tasarımı: yüksek/düşük + SLO-burn + bileşik.
4. Her girit için Runbook: tanılama adımları ('ne açılacak ",'ne komutları", "nerede yükselecek"), eylem için üç seçenek: hızlı geçiş, ölçeklendirme, bozulma.
5. Test: yük simülasyonları (kaos/oyun günleri), uyarıların kuru başlangıcı, anti-gürültü kontrolü.
6. Gözden geçirme ve benimseme: sinyal sahibi = servis sahibi. Sahibi yok - sayfası yok.
7. Retrospektifler ve ayar: yanlış/cevapsız haftalık analizi; metrik "MTTA (ack), MTTD, MTTR, Gürültü/Sinyal oranı".

11) Anti-desenler

CPU> %90 ⇒ paniği: Gecikme/kuyruklarla korelasyon olmadan, bu normal olabilir.
"Herkes için bir eşik": farklı bölgeler/saat dilimleri - farklı trafik profilleri.
Runbook olmadan uyarı: açık eylem olmadan sayfa çağrı üzerine drains.
Sağlayıcılara körlük: Dış kotalar/limitler genellikle komut dosyalarını "kıran'ilk kişilerdir (PSP, KYC, sahtekarlık karşıtı, oyun sağlayıcıları).
Histerezis yok: %80/% 79 sınırında "testere".

12) iGaming/finansal platformların özellikleri

Program zirveleri: prime time, turnuva finalleri, büyük maçlar; Hedef kopyaları tanıtın ve önbellekleri önceden doldurun.
Canlı akışlar ve ikramiyeler: yayın olaylarının patlamaları - brokerlar/web siteleri üzerindeki sınırlar.
Ödemeler ve KYC: sağlayıcı pencereleri, dolandırıcılık karşıtı puanlama; Yedek yollar ve "grace-mode" depozitoları saklayın.
Geo-balance: yerel sağlayıcı arızaları - trafiği bir boşluk bulunan komşu bir bölgeye yönlendirmek.
Sorumluluk: Bahisleri/ikramiyeleri kaybetme riski altında - etki alanı ekibine anında sayfa + iş uyarısı.

13) Gösterge Panoları (minimum set)

Kapasiteye Genel Bakış: Katman başı boşluk, ilk 3 riskli alan, yanma oranı SLO.
Akış ve Kuyruklar: gecikme, birikmiş büyüme, tüketici doygunluğu, HPA durumu.
DB & Cache: bağlantılar, repl-lag, p95/p99 gecikme, isabet oranı, tahliyeler.
Sağlayıcılar: TPS/pencereler/kotalar, zaman aşımları/hatalar, çağrı maliyeti.
Yayın/Özellik bağlamı: eğrilerin yanındaki sürümler/phicheflags.

14) Uygulama kontrol listesi

• "Gerçek" limitlerin ve sahiplerin listesi.
• Predictor metrics map + katmanlar arası ilişkiler.
• Statik eşikler + histerezis.
• Kritik yollarda SLO-burn-uyarıları (para yatırma, bahis, canlı oyun başlatma).
• Kuyruk/akışlar/bağlantılar üzerinde tahmini uyarılar.
• Pencerenin bastırılması/bakımı; Gürültü karşıtı siyaset.
• Runbook've komutlar, grafikler, bozulma filtreleri ile.
• Yanlış pozitiflerin haftalık analizi ve ayarlama.
• Pazarlama kampanyaları ve etkinlik takvimi için hesap.

15) Örnek runbook deseni (kısaltılmış)

Sinyal: 'StreamBacklogAtRisk'

Amaç: Gecikme büyümesini> 10 milyon ve tedavi gecikmesini> 5 dakika önlemek.

1. Çukurlarda 'hpa _ described/max', gaz/oom işaretleyin.

2. 'Oranı (gecikme)', bölümlemeyi (eğriltme) görüntüleyin.

3. Denetim aracısı (ISR, az çoğaltılmış, ağ).

• Tüketici kopyalarını + N artırın, uçuşta maksimumu artırın.
• "Kritik konularda" öncelikli havuzu etkinleştirin.
• İkincil tedavilerin/zenginleştirmenin sıklığını geçici olarak azaltın.
• 'ASG maksimumda' - buluttan geçici bir yükseltme isteyin; Paralel olarak - ağır fonksiyonların bozulmasını sağlar.
• Geri alma: 'Lag <1 milyon' 15 dakika sonra normal trafik profiline dönün.
• Eskalasyon: Kafka küme sahibi, sonra SRE platformu.

16) KPI ve sinyal kalitesi

Kapsama: Kapasitif uyarılarla kapatılan kritik yolların %'si.
Gürültü/Sinyal: Çağrı/hafta başına en fazla 1 yanlış sayfa.
MTTD/MTTR: SLO grevlerinden ≤5 dakika önce kapasitif olaylar tespit edilir.
Proaktif tasarruflar: Önlenen olay sayısı (ölüm sonrası).

17) Hızlı başlangıç (muhafazakar varsayılanlar)

DB: uyarı bağlantıların %75/IOPS/lat; Girit %85, histerezis 8-10 pp

Önbellekler: 'hit <0. 9 'Ve' tahliyeler> 0 '> 5 dk - uyarı;' _ mem> %85 'kullandı - Girit.
Kuyruklar: 'Gecikme' yüksekliği> 30d + 'hpa için ortalamanın σ 3'ü maksimum' - Girit.
API: 'p99> SLO1. 3 '10 dk - uyarı;' burn-rate> 4 '15 dk - Girit.
Sağlayıcılar: 'verim> %90 kota' - uyarı; 'zaman aşımları> %5' - Girit.

18) SSS

S: Neden sadece "CPU> %80'değil?
C: Gecikme/kuyruklama bağlamı olmadan, bu gürültüdür. CPU'nun kendisi riske eşit değildir.

S: Uyarlanabilir eşiklere ihtiyacımız var mı?
C: Evet, günlük/haftalık mevsimsellik için - yanlış pozitifleri azaltın.

S: Pazarlama/etkinlikler nasıl değerlendirilir?
C: Kampanya takvimi - grafiklerdeki ek açıklamalar + geçici gürültü önleme ayarı, ancak SLO uyarılarına dokunmayın.