Opérations et gestion de la capacité des systèmes → Alerte

Alert en fonction de la capacité des systèmes

1) Pourquoi est-ce nécessaire

Les alertes capacitives avertissent que nous approchons des limites techniques bien avant l'incident : « Nous sommes à 80 % du plafond - il est temps de nous adapter ». Pour les entreprises alimentaires, c'est directement sur l'argent : paris manqués/dépôts, séances de drops, retards de jeux en direct et refus des fournisseurs = revenus perdus, réputation, amendes et remboursements.

• Il est prévisible de supporter les charges de pointe (ivents, tournois, strim, grandes campagnes).
• Activer le skating automatique à temps et planifier la capacity uplift.
• Réduire le bruit et réveiller « sur l'affaire » quand SLO/argent risque.
• Donner aux ingénieurs des recommandations précises via le runbook.

2) Concepts de base

Capacité (Capacity) : bande passante la plus stable possible (RPS/TPS, connexions, IOPS, throughput).
Headroom : marge entre la charge actuelle et les limites.
SLO/SLA : niveaux cibles de disponibilité/temps de réponse ; les alertes doivent être « SLO-aware ».
Burn-rate : vitesse de « combustion » SLO budget erreurs/latence.
High/Low Watermark : niveaux supérieurs/inférieurs pour le déclenchement et la récupération automatique.

3) Architecture des signaux et sources de données

Téléémétrie : métriques (Prometheus/OTel), logs (ELK/ClickHouse), traces (OTel/Jaeger).
Approche en couches : alertes par couches (Edge → API → services métiers → files d'attente/streams → bases de données/caches → stockage de fichiers/objets → fournisseurs externes).
Contexte : Ficheflags, sorties, campagnes marketing, tournois, géo-alignement.
Pneumatique d'incident : Alertmanager/PagerDuty/Opsgenie/Slack ; le lien vers le runbook et la matrice d'escalade.

4) Métriques clés par couches (que surveiller et pourquoi)

Edge / L7

RPS, 95-/99-percentile latency, error rate (5xx/4xx), open connections.
Rate-limits/quotas, drops на CDN/WAF/Firewall.

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

Saturation par workers/workpool, file de requêtes, timeouts vers les downstreams.
Proportion de dégradation (fallbacks, circuits-breakers).

Files d'attente/streaming (Kafka/Rabbit/Pulsar)

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).
Partition skew, rebalancing churn, ISR (pour Kafka), retrai/grand-père leiter.

Workers asynchrones

Temps d'attente des tâches, longueur de la file d'attente, pourcentage de tâches SLA en retard.
Saturation CPU/Mémoire/FD dans les pools.

Cache (Redis/Memcached)

Hit ratio, latency, evictions, mémoire usée, clients connectés/ops/s.
Clusters : slots/répliques, événements d'échec.

БД (PostgreSQL/MySQL/ClickHouse)

Active connections vs max, lock waits, replication lag, buffer/cache hit.
IOPS, read/write latency, checkpoint/flush, bloat/fragmentation.

Stockage d'objets/fichiers

PUT/GET latency, 4xx/5xx, egress, requêtes/s, limites du fournisseur.

Fournisseurs externes (paiements/CUS/fournisseurs de jeux)

TPS limites, QPS fenêtre, error rate/timeout, file de retraits, "cost per call'.

Infrastructure

CPU/Memory/FD/IOPS/Network saturation sur les nœuds/pods/ASG.
Événements HPA/VPA, pending pods, conteneur OOM/Throttling.

5) Types d'alertes capacitives

1. Seuils statiques

Simple et compréhensible : 'db _ connexions> 80 % max'. C'est comme un signal-balise.

2. Seuils adaptatifs (dynamiques)

Basé sur la saisonnalité et la tendance (rolling windows, STL-décomposition). Ils permettent de pêcher « exceptionnellement haut pour cette heure/jour de la semaine ».

3. SLO (burn-rate)

Ils sont activés lorsque la vitesse de passage de l'error-budget met le SLO à l'impact dans l'horizon X de l'horloge.

4. Pronostic (forecast-alerts)

Dans 20 minutes, avec la tendance actuelle, la file d'attente atteindra 90 %. Ils utilisent une prévision linéaire/Robust/Prophet sur les fenêtres courtes.

5. Composites (multi-signaux)

Déclencher la combinaison : 'queue _ lag ↑' + 'consumer _ cpu 85 %' + 'autoscaling at max' → 'il faut une intervention manuelle ".

6) Politiques de seuil et anti-bruit

• Haut : avertissement 70-75 %, Crète 85-90 %. Vers le bas : hystérésis 5-10 p.p. Pour ne pas « scier au seuil ».

• « for : 5m'pour les crèmes, » for : 10-15m'pour les alertes. Mode nuit : router le non critique dans le chat sans paging.

• Regrouper par service/cluster/géo afin de ne pas produire de cartes d'incident.

• Si le fournisseur KYC est sur l'out et l'erreur API, la conséquence est le pagim du propriétaire de l'intégration, pas tous les consommateurs.

• Pendant la période des actions, augmenter les seuils de bruit pour la « croissance attendue », mais laisser les alertes SLO intactes.

7) Exemples de règles (pseudo-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) Approche SLO et priorité d'affaires

Du signal à l'impact sur l'entreprise : les alertes de capacité doivent se référer à risk to SLO (jeux spécifiques/géo/métriques GGR, conversion de dépôt).
Hiérarchisation : avertissements pour le service en ligne ; Crète - page du propriétaire du domaine ; La chute SLO est un incident majeur et une chaîne de commandement « consolidée ».
Les ficheflags de dégradation : réduction automatique de la charge (lecture partielle, réduction des fiches lourdes, réduction de la fréquence des broadcasts jackpot, arrêt des animations « lourdes » dans les jeux en direct).

9) Auto-Skaling et déclencheurs « corrects »

HPA/VPA : ciblage non seulement par CPU/Mémoire, mais aussi par métriques d'entreprise (RPS, queue lag, p99 latitude).
Timings Warm-up : prendre en compte le démarrage froid et les limites du fournisseur (ASG spin-up, builders conteneurisés, chauffage des caches).
Guardrails : conditions d'arrêt avec une augmentation des erreurs en avalanche ; la protection contre le « problème du skate ».
Capacity-playbooks : où et comment ajouter un shard/lot/réplique, comment redistribuer le trafic par région.

10) Processus : De la conception à l'exploitation

1. Cartographie des limites : collecter les limites « vraies » de bottleneck pour chaque couche (max cons, IOPS, TPS, quotas).
2. Sélection des métriques-prédicteurs : quels signaux avant tout le monde indiquent « s'assoir après N minutes ».
3. Conception des seuils : haut/bas + SLO-burn + composites.
4. Runbook pour chaque crête : étapes de diagnostic (« quoi ouvrir », « quelles commandes », « où escalader »), trois options d'action : contournement rapide, mise à l'échelle, dégradation.
5. Tests : simulations de charges (chaos/game days), « démarrage à sec » des alertes, contrôle anti-bruit.
6. Revue et adoption : propriétaire du signal = propriétaire du service. Pas de page sans propriétaire.
7. Rétrospectives et tuning : analyse hebdomadaire des faux/sautés ; métrique « MTTA (ack), MTD, MTR, Noise/Signal ratio ».

11) Anti-modèles

CPU> 90 % ⇒ panique : sans corrélation avec latency/queues, cela peut être normal.
« Un seuil pour tous » : différentes régions/zones temporelles - différents profils de trafic.
Alert sans runbook : Paige sans action claire épuise on-call.
L'aveuglement des fournisseurs : les quotas/limites externes sont souvent les premiers à « briser » les scénarios (PSP, KYC, antifrod, fournisseurs de jeux).
Pas d'hystérésis : « sciage » à la limite 80 %/79 %.

12) Caractéristiques des iGaming/finplatforms

Pics programmés : prime time, finales de tournois, grands matchs ; augmenter les répliques ciblées et remplir les caches à l'avance.
Strimes et jackpots en direct : surtensions d'actifs de diffusion → limites sur les courtiers/sites Web.
Paiements et KYC : guichets fournisseurs, anti-frottement ; conserver les itinéraires de secours et le « mode grace » des dépôts.
Géo-équilibrage : les échecs locaux du fournisseur sont d'emmener le trafic vers la région voisine où il y a un headroom.
Responsabilité : en cas de risque de perte de paris/jackpots - pagination instantanée à l'équipe de domaine + alerte d'entreprise.

13) Dashboards (recrutement minimum)

Capacity Aperçu : headroom par strates, top 3 des sites à risque, burn-rate SLO.
Stream & Queues: lag, backlog growth, consumer saturation, HPA state.
DB & Cache : Connecteurs, repl-lag, p95/p99 laticy, hit ratio, evictions.
Providers : TPS/fenêtres/quotas, timeouts/errors, coût des appels.
Release/Feature context : releases/ficheflags à côté des courbes.

14) Chèque de mise en œuvre

• Liste des « vraies » limites et propriétaires.
• Carte des métriques prédictives + liens entre les couches.
• Seuils statiques + hystérésis.
• SLO-burn-alerties sur les chemins critiques (dépôt, pari, lancement d'un jeu en direct).
• Alertes prédictives en file d'attente/strimes/connections.
• Suppression/maintenance de la fenêtre ; anti-bruit de la politique.
• Runbook "et avec des commandes, des graphiques, des ficheflags de dégradation.
• Analyse hebdomadaire des faux positifs et tuning.
• Prise en compte des campagnes marketing et du calendrier des événements.

15) Exemple de modèle de runbook (abrégé)

Signal : 'StreamBacklogAtRisk'

Objectif : Empêcher la croissance de lag> 10 millions et retarder les traitements> 5 min.

1. Vérifiez 'hpa _ desired/max', throttle/oom dans les pods.

2. Voir 'rate (lag)', répartition par lot (skew).

3. Vérifier le courtier (ISR, under-replicated, network).

• Augmenter consumer-replicas par + N, augmenter max-in-flight.
• Inclure un pool prioritaire sur les « axes critiques ».
• Abaisser temporairement la fréquence des traitements secondaires/enrichment.
• Si 'ASG at max' - demander un uplift temporaire au nuage ; en parallèle - inclure la dégradation des fonctions lourdes.
• Retour en arrière : retour au profil « trafic normal » après 'lag <1 million' 15 minutes.
• Escalade : propriétaire du cluster Kafka, puis de la plateforme SRE.

16) KPI et qualité de signal

Coverage :% des chemins critiques fermés par des alertes capacitives.
Noise/Signal : pas plus de 1 fausse page par appel/semaine.
MTTD/MTR : Les incidents capacitifs sont détectés ≤5 min avant les coups de SLO.
Saves proactifs : pieu dans les incidents évités (par post mortem).

17) Démarrage rapide (défauts conservateurs)

OBD : avertissement 75 % des connexions/IOPS/lat ; Crète 85 %, hystérésis 8-10 pp

Cache : 'hit <0. 9 'Et' evictions> 0 '> 5 min est un avertissement ;' used _ mem> 85 % 'est une crête.
Files d'attente : 'lag' hauteur> 3 σ de la moyenne pour 30d + 'hpa at max' - Crète.
API: `p99 > SLO1. 3 '10 min - avertissement ;' burn-rate> 4 '15 min - crète.
Fournisseurs : 'throughput> 90 % du quota' est un avertissement ; 'timeouts> 5 %' est une crête.

18) FAQ

Q : Pourquoi ne pas alerter simplement « CPU> 80 % » ?
R : Sans contexte de latitude/files d'attente, c'est du bruit. Le CPU lui-même n'est pas égal au risque.

Q : Faut-il des seuils adaptatifs ?
R : Oui, pour la saisonnalité journalière/hebdomadaire - réduire les faux positifs.

Q : Comment prendre en compte le marketing/events ?
R : Calendrier des campagnes → annotations sur les graphiques + ajustement temporaire de l'anti-bruit, mais pas de SLO-alerte.