Operacje i Alert → Zarządzanie według zdolności systemowej

Alerty przepustowości systemu

1) Dlaczego go potrzebujesz

Alerty pojemnościowe ostrzegają przed zbliżaniem się do ograniczeń technicznych na długo przed incydentem: "Jesteśmy 80% sufitu - nadszedł czas, aby skalować. "W przypadku firm spożywczych chodzi bezpośrednio o pieniądze: pominięte zakłady/depozyty, spadki sesji, opóźnienia w grze na żywo i awarie dostawcy = utracone przychody, reputacja, grzywny i kickbacks.

• Przewidywalnie wytrzymać szczytowe obciążenia (wydarzenia, turnieje, strumienie, duże kampanie).
• Włącz automatyczne skalowanie na czas i zwiększyć pojemność planu.
• Zmniejsz hałas i obudź się „w biznesie”, gdy SLO/pieniądze są zagrożone.
• Daj inżynierom dokładne zalecenia za pośrednictwem książki startowej.

2) Podstawowe pojęcia

Pojemność: maksymalna stabilna przepustowość (RPS/TPS, połączenia, IOPS, przepustowość).
Zagłówek: margines między obciążeniem bieżącym a limitami.
SLO/SLA: docelowe poziomy dostępności/czasu reakcji; wpisy muszą być „SLO-aware”.
Szybkość spalania: szybkość „spalania” budżetu SLO błędów/opóźnień.
Wysoki/Niski znak wodny: górny/dolny poziom do uruchamiania i automatycznego odzyskiwania.

3) Architektura sygnału i źródła danych

Telemetria: mierniki (Prometheus/OTel), kłody (ELK/ClickHouse), ślady (OTel/Jaeger).
Podejście warstwowe: wpisy według warstw (krawędź → API → usługi biznesowe → kolejki/strumienie → bazy danych/bufory → sklepy plików/obiektów → dostawcy zewnętrzni).
Kontekst: flagi, wydania, kampanie marketingowe, turnieje, geo-wyrównanie.
Opona awaryjna: Alertmanager/PagerDuty/Opsgenie/Slack; wiązanie do matrycy runbooka i eskalacji.

4) Kluczowe mierniki według warstwy (co monitorować i dlaczego)

Krawędź/L7

RPS, 95-/99-percentile latency, błąd (5xx/4xx), otwarte połączenia.
Limity/kwoty stawek, krople на CDN/WAF/Firewall.

API-мли,/Backend-for-Frontend

Nasycenie przez pracownika/pulę roboczą, kolejka żądań, terminy do niższego szczebla.
Frakcja degradacyjna (awaryjne, wyłączniki).

Kolejki/Streaming (Kafka/Królik/Pulsar)

Opóźnienie/opóźnienie konsumenckie, wskaźnik wzrostu zaległości, przepustowość (msg/s, MB/s).
Partition skew, rebalancing churn, ISR (dla Kafka), retray/dziadek-later.

Pracownicy asynchroniczni

Czas realizacji zadania, długość kolejki, odsetek wygasłych zadań SLA.
Procesor nasycenia/pamięć/płyta FD przy basenach.

Bufory (Redis/Memcached)

Współczynnik trafienia, opóźnienia, eksmisje, używana pamięć, podłączone klienci/ops/s.
Klastry: sloty/repliki, zdarzenia awaryjne.

МOG (PostgreSQL/MySQL/ClickHouse)

Aktywne połączenia vs max, oczekiwania na blokadę, opóźnienie replikacji, hit bufora/pamięci podręcznej.
IOPS, odczyt/zapis opóźnienia, punkt kontrolny/spłukiwanie, wzdęcia/fragmentacja.

Przechowywanie obiektów/plików

Latency PUT/GET, 4xx/5xx, egress, requests/sec, limit dostawcy.

Dostawcy zewnętrzni (Płatności/LCC/Dostawcy gier)

Limity TPS, okna QPS, wskaźnik błędów/timeout, kolejka retray, „koszt za połączenie”.

Infrastruktura

Procesor/pamięć/FD/IOPS/nasycenie sieciowe węzłów/podstron/ASG.
Zdarzenia HPA/VPA, oczekujące strąki, pojemnik OOM/Throttling.

5) Rodzaje alertów pojemnościowych

1. Progi statyczne

Proste i proste: 'db _ connections> 80% max'. Dobry jako sygnał nadawczy.

2. Progi adaptacyjne (dynamiczne)

W oparciu o sezonowość i trend (rolling windows, rozkład STL). Pozwól łapać „wyjątkowo wysoko na tę godzinę/dzień tygodnia”.

3. Zorientowane na SLO (szybkość spalania)

Są one uruchamiane, gdy wskaźnik jedzenia błędów w budżecie zagrozi SLO w horyzoncie X godziny.

4. Prognostyczne (prognozy-wpisy)

„Po 20 minutach w obecnym trendzie kolejka osiągnie 90%”. Linear/Robust/Prorok-like prediction na krótkich oknach jest używany.

5. Wielopunktowy

Wyzwalacz z kombinacją: 'queue _ lag α' + 'consumer _ cpu 85%' + 'autoscaling at max' → „potrzebna jest ręczna interwencja”.

6) Polityka progowa i przeciwdziałanie hałasowi

• W górę: ostrzeżenie 70-75%, Kreta 85-90%. W dół: histereza 5-10 pp Aby nie „widzieć na progu”.

• "dla kryteriów 5m' dla ostrzeżeń: 10-15m' dla ostrzeżeń. Tryb nocny: trasa nieistotna dla czatu bez przywoływania.

• Grupa według usług/klastra/geo, aby nie produkować kart incydentalnych.

• Jeśli dostawca KYC nie ma, a błędy API wynikają ze strony właściciela integracji, nie wszystkich konsumentów.

• W okresie zapasów podnieść progi hałasu dla „spodziewanego wzrostu”, ale pozostawić wpisy SLO nienaruszone.

7) Przykłady reguł (pseudo-prometeusz)

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) podejście SLO i priorytet biznesowy

Od sygnału do wpływu biznesu: Alerty zdolności powinny odnosić się do ryzyka SLO (specyficzne gry/geo/GGR, konwersja depozytów).
Wielopoziomowe: ostrzeżenia dla dyżurów; Kreta - strona właściciela domeny; SLO-drop - główny incydent i zespół „podsumowanie” kanał.
Funkcje degradacji: automatyczna redukcja obciążenia (tylko częściowy odczyt, odcięcie ciężkich funkcji, zmniejszenie częstotliwości transmisji jackpota, wyłączenie „ciężkich” animacji w grach na żywo).

9) Automatyczne skalowanie i „poprawne” wyzwalacze

HPA/VPA: cel nie tylko przez procesor/pamięć, ale również przez metryki biznesowe (RPS, kolejka opóźnienia, opóźnienie p99).
Terminy rozgrzewania: uwzględniają limity zimnego rozruchu i dostawcy (spin-up ASG, konstruktorzy kontenerów, bufory rozgrzewające).
Poręcze: warunki zatrzymania w lawinopodobnym wzroście błędów; ochrona przed „problemem skaliska”.
Playbooks pojemności: gdzie i jak dodać odłamek/party/replikę, jak redystrybuować ruch według regionu.

10) Proces: od projektu do działania

1. Mapowanie limitów: zebrać „prawdziwe” limity wąskich gardeł dla każdej warstwy (maks. conns, IOPS, TPS, dostawcy kwot).
2. Wybór mierników prognostycznych: które sygnały wskazują najpierw „odpoczynek w minutach N”.
3. Projekt progowy: wysoka/niska + spalanie SLO + związek.
4. Runbook dla każdego kreta: kroki diagnostyczne („co otworzyć”, „jakie polecenia”, „gdzie eskalować”), trzy opcje działania: szybki przesuwanie, skalowanie, degradacja.
5. Testowanie: symulacje obciążenia (chaos/dni gry), suche początki wpisów, sprawdzanie antyhałasu.
6. Przegląd i przyjęcie: właściciel sygnału = właściciel usługi. Brak właściciela - brak strony.
7. Retrospektywy i dostrajanie: cotygodniowa analiza fałszywych/pominiętych; metryczne „MTTA (ack), MTTD, MTTR, współczynnik szumu/sygnału”.

11) Anty-wzory

Procesor> 90% • panika: bez korelacji z opóźnieniem/kolejkami, może to być normalne.
„Jeden próg dla wszystkich”: różne regiony/strefy czasowe - różne profile ruchu.
Alert bez runbooka: strona bez wyczyszczenia drenażu akcji dyżuru.
Ślepota dla dostawców: kwoty zewnętrzne/limity są często pierwszym, który „łamie” skrypty (PSP, KYC, anty-oszustwa, dostawcy gier).
Brak histerezy: „piła” na granicy 80 %/79%.

12) Cechy iGaming/platform finansowych

Szczyty harmonogramu: czas premierowy, finały turniejów, najważniejsze mecze; Promować repliki docelowe i napełnić bufory z wyprzedzeniem.
Transmisje na żywo i jackpoty: bursts of broadcast events → limity na brokerach/stronach internetowych.
Płatności i KYC: okna dostawców, punkty antykonkurencyjne; przechowywać zapasowe trasy i depozyty w trybie „grace-mode”.
Geo-równowaga: awarie lokalnego dostawcy - skierowanie ruchu do sąsiedniego regionu, w którym znajduje się zagłówek.
Odpowiedzialność: ryzyko utraty zakładów/jackpotów - strona natychmiastowa do zespołu domeny + alert biznesowy.

13) Deski rozdzielcze (minimalny zestaw)

Przegląd pojemności: zagłówek według warstwy, top 3 ryzykowne obszary, spalanie szybkości SLO.
Stream & Kolejki: opóźnienie, wzrost zaległości, nasycenie konsumentów, stan HPA.
DB & Cache: połączenia, repl-lag, opóźnienie p95/p99, współczynnik trafienia, eksmisje.
Dostawcy: TPS/windows/quotas, timeouts/errors, cost call.
Uwolnienie/Kontekst funkcji: wydania/ficheflagi obok krzywych.

14) Lista kontrolna wdrażania

• Wykaz „prawdziwych” limitów i właścicieli.
• Mapa map prognostycznych + powiązania międzywarstwowe.
• Progi statyczne + histereza.
• SLO-burn-alerty na ścieżkach krytycznych (depozyt, zakład, uruchomienie gry na żywo).
• Przewidywane wpisy dotyczące kolejki/strumieni/połączeń.
• Tłumienie/konserwacja okna; polityka antyhałasowa.
• Runbook'i z poleceniami, wykresy, filtry degradacji.
• Cotygodniowa analiza fałszywych pozytywów i dostrajania.
• Konto kampanii marketingowych i kalendarza wydarzeń.

15) Przykładowy wzór książki startowej (skrócony)

Sygnał: „StreamBacklogAtRisk”

Cel: Zapobieganie opóźnieniu wzrostu> 10 mln i opóźnieniu leczenia> 5 min.

1. Sprawdź 'hpa _ desired/max', przepustnicę/oom w dołach.

2. Widok 'rate (lag)', podział (skew).

3. Sprawdź broker (ISR, niedostatecznie replikowana, sieć).

• Zwiększyć repliki konsumentów o + N, podnieść max w locie.
• Włącz pulę priorytetów na „tematy krytyczne”.
• Czasowo zmniejszyć częstotliwość wtórnych zabiegów/wzbogacania.
• Jeśli 'ASG at max' - zażądaj tymczasowego podniesienia z chmury; równolegle - umożliwiają degradację ciężkich funkcji.
• Rollback: Powrót do normalnego profilu ruchu po 'lag <1 million' 15 minut.
• Eskalacja: właściciel klastra Kafka, następnie platforma SRE.

16) KPI i jakość sygnału

Zasięg:% ścieżek krytycznych zamkniętych przez alerty pojemnościowe.
Hałas/sygnał: nie więcej niż 1 fałszywa strona na dyżur/tydzień.
MTTD/MTTR: zdarzenia pojemnościowe wykrywane są ≤ 5 min przed uderzeniem SLO.
Aktywne zapisy: liczba zapobieganych incydentów (po śmierci).

17) Szybki start (niewykonanie zobowiązań konserwatywnych)

DB: ostrzeżenie 75% połączeń/IOPS/lat; kreta 85%, histereza 8-10 pp

Caches: 'trafienie <0. 9 „i” eksmisje> 0 „> 5 min - ostrzeżenie;” used _ mem> 85% '- Kreta.
Kolejki: wysokość "lag"> 3 "średniej dla 30d +" hpa at max "- Kreta.
API: 'p99> SLO1. 3 '10 min - ostrzeżenie; " szybkość spalania> 4 '15 min - Kreta.
Dostawcy: „przepustowość> 90% kwoty” - ostrzeżenie; „timeouts> 5%” - Kreta.

18) FAQ

P: Dlaczego nie tylko „CPU> 80%”?
Odp.: Bez opóźnienia/kontekstu kolejkowania, to hałas. Sam procesor nie jest równy ryzyku.

P: Czy potrzebujemy progów adaptacyjnych?
Odp.: Tak, dla codziennej/tygodniowej sezonowości - zmniejszyć fałszywe pozytywy.

P: Jak rozważyć marketing/wydarzenia?
Odp.: Kalendarz kampanii → adnotacje na wykresach + tymczasowa regulacja antyhałasu, ale nie dotykaj wpisów SLO.