Infrastructure KPI et pharmacie

Pourquoi est-ce nécessaire

Les KPI de l'infrastructure transforment les « sentiments » de stabilité en objectifs mesurables, gèrent le risque et la concentration des travaux. Les bonnes mesures lient les SLI techniques aux résultats de l'entreprise (conversion, Time-to-Wallet, LTV) et permettent de planifier le développement, la charge et la part d'innovation de la fiabilité.

Notions de base : SLI, SLO, SLA et budget des erreurs

SLI (Service Level Indicator) est un indicateur de qualité mesurable : proportion de demandes réussies, p95 latitude, aptyme par intervalle.
SLO (Service Level Objective) - le but selon SLI (par exemple, "le succès ≥ 99. 9 % en 30 jours").
SLA (Accord) est une promesse extérieure avec pénalités/prêts. Toujours dérivé de SLO, mais pas égal à lui.
Budget des erreurs = '1 − SLO'. C'est la proportion maximale admissible de « non-échec » par fenêtre de mesure. Utilisé pour prendre des décisions sur les rejets à risque et les expériences.

• Disponibilité SLO 99. 95 % en 30 jours → budget des erreurs 0. 05% ≈ 21. 6 minutes d'échec dans le mois civil.

Quatre signaux « or » et des signaux supplémentaires

1. Latence (p50/p90/p95/p99, plus important que la moyenne).
2. Erreurs (5xx/timeout/Business Error).
3. Trafic/passe (RPS/QPS, MBps).
4. Saturation (CPU/RAM/IO/FD/connexions/GC/quotas).
En option : démarrage à froid, files d'attente/beclog, temps de dépliage, conformité SLO.

Modèle SLI pour différents types de services

HTTP/API

Disponibilité : '(succès 2xx/3xx − erreurs logiques )/( toutes les requêtes)'

Latence : 'p95' pour les demandes réussies ; objectif sur les itinéraires « chauds ».
Qualité : proportion de requêtes avec 'audience/scope' correctes (pas d'erreurs authZ).

Files d'attente/asynchrones

Temps de traitement du message : p95 end-to-end ≤ N secondes.
Backlog : médiane <X, queue p99 <Y.
Erreur de livraison : ≤ Z ppm.

Base de données/cache

Latence des opérations : p95 get/put/commit.
Saturation : connexion pool utilisation, cache hit-ratio.
Bugs : timeouts, deadlocks, événements storms.

CDN/statique

Hit Ratio : ≥ du niveau cible ; dégradation → augmentation de la charge d'origin.
Disponibilité POP : Mise en page Anycast, les pannes sont compensées par les voisins.

Paiements (SLI d'entreprise)

Time-to-Wallet p95, succès de dépôt/retrait%, taux d'échec PSP.

Calcul de la disponibilité et « aptame »

Disponibilité du service = « demandes réussies/toutes les demandes » (de préférence plutôt que « minutes d'aptame »).
Alternative pour les nœuds d'infrastructure : « temps dans l'état » vert « /temps de fenêtre ».
Fenêtre de calendrier : 28-31 jours, fenêtre glissante : les 30/90 derniers jours.
Heures de travail/fenêtres critiques : pour le backoffice peut être considéré comme un aptyme selon l'horaire (par exemple, 08 : 00-22 : 00 heure locale).

• « Disponibilité (A) ≈ Av (B) × Av (C) × Av (A 'B, C) » - Il est important de placer les SLO aux frontières.

Exemple de jeu SLO (échantillon)

API Gateway : disponibilité ≥ 99. 95 %/30д; p95 latitude ≤ 120 ms ; Erreur ≤ 0. 2%.
Checkout/Paiements : succès du dépôt ≥ 98. 5 %/30д; Time-to-Wallet p95 ≤ 90 с; PSP-timeouts ≤ 0. 3%.
Base de données : p95 lecture ≤ 10 ms ; p95 write ≤ 25 ms ; replica lag p95 ≤ 150 мс.
Cache : hit ratio ≥ 85 %; eviction storms = 0/30д.
Paiements : p95 traitement ≤ 5 min ; les frod falls positifs ≤ 0. 3%.

Budget des erreurs et gestion des changements

Si le budget des erreurs est épuisé de 50 % + avant le milieu de la fenêtre - le « gel » des fiches/versions est introduit, l'accent est mis sur la stabilisation.
Si le budget est dépensé lentement, vous pouvez accélérer les expériences/canaries.
La consommation budgétaire est associée à des versions/incidents spécifiques via 'release _ id'.

Alerting : comment ne pas « appeler la nuit » pour rien

Alert uniquement pour la dégradation SLO et les symptômes vitaux, pas pour chaque métrique.
Multi-window, multi-burn rate : fenêtre courte (5-15 min) + longue (1-6 h).
Exemple : « Burn rate 14 × en 5 min et 6 × en 1 heure » → page on-call.
Horloge silencieuse pour signaux non-P1 ; routage par responsabilité (own....).

Dashboards et pratiques de visualisation

SLO panel : conformité par service, budget restant, cartes de dépendance.
Panneau latin : p50/p90/p95/p99, décomposition par itinéraire/tenants/pays/ASN.
Panneau d'erreur : codes/causes, corrélation avec les versions/fichflags.
Panneau de capacity : CPU/RAM/IO/network/FD/connects, tendances et prévisions.
Tableau de bord : conversion, Time-to-Wallet, dépôts/retraits, impact des protections (WAF/antibot).

Incidents, MTTR et postmortems

• MTTD (détection), MTTA (accept), MTTR/MTTC (récupération/dissuasion), % des incidents sans RCA à temps.
• Playbooks : qui escalade, comment allumer les fichflags/blocs, comment faire tomber la sortie, la communication avec les entreprises.
• Postmortem (blameless) : faits, ligne temporelle, causes profondes (ceux/processus), actions : immédiats/à long terme, tests de régression, effets sur les SLO.

Performance, saturation et dégradation

Headroom : réserve de ressources cible (par exemple CPU <70 % p95, RAM <75 % p95).
Hot paths : profilage des itinéraires critiques ; 'p99' est plus important que la moyenne.
Modes de degradation : cache-only-only, dropping des requêtes sans importance, « limitation des taux « /quota.

Formules et exemples de calculs

1) Disponibilité sur demande

availability = (total_requests - error_requests) / total_requests

où 'error _ requests' = 5xx + timeouts + erreurs commerciales (configurables).

2) Budget des erreurs (minutes)

error_budget_minutes = window_minutes (1 - SLO)

Exemple : 30 jours (43 200 min), SLO 99. 95% → 21. 6 minutes

3) Burn rate

burn_rate = observed_error_ratio / (1 - SLO)

Si SLO 99. 9 % (budget 0. 1%) et erreur 1 % → burn_rate = 10 ×.

4) Disponibilité composite

A_total ≈ A_gw × A_auth × A_db × A_psp

De petites chutes frappent de manière multiplicative le total A.

Politiques de mesure et d'exclusion

Fenêtres non planifiées (incidents) - sont prises en compte.
Fenêtres de service planifiées - ne sont prises en compte que si le SLA est prescrit ainsi ; pour les SLO souvent non déduits (ou marqués séparément comme 'planned _ downtime').
Synthétique vs utilisateurs réels : il est utile d'avoir les deux canaux (RUM + contrôles synthétiques).

Exemples d'artefacts

KQL/BouQL (idées)

promql sum(rate(http_requests_total{status=~"5..    timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (SLI d'entreprise sur les paiements)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

Gestion des dépendances et des cascades

Contrats SLO entre équipes : gateway↔auth↔wallet↔PSP.
Politiques de degradation : lorsque la dépendance tombe, le service passe en « mode simplifié ».
Feature flags : Désactivation des fonctions non critiques, « sortie grise » pour réduire les queues de latitude.

Planification et prévisions de la capacité

Chomez. Prévisions RPS/MBps sur les tendances et les événements (tournois, matchs, promotions).
Test de charge sur les « sentiers d'or », tests séparés pour les PSP/paiements.
Marge au sommet : facteur cible 1. 3×–2. 0 × de la charge attendue.

Chèque d'implémentation SLO/KPI

1. Identifiez les chemins utilisateur critiques et négociez un SLI « du point de vue du client ».
2. Sélectionner les cibles SLO et la fenêtre (30/90 jours) ; calculer le budget des erreurs.
3. Intégrer la collecte de métriques dans les passerelles/services, normaliser les codes/causes.
4. Configurer les alertes burn-rate (fenêtre courte + longue), routage et on-call.
5. Visualisez la conformité SLO, associez-la aux versions/fichflags.
6. Mettre en place une politique budgétaire contre le changement et un processus de gel.
7. Rétrospectives et RCA pour chaque dépassement, tests de régression.
8. Revivez le SLO tous les trimestres sur l'utilisation effective du budget et les objectifs opérationnels.

Erreurs typiques

Ils mesurent « aptyme par ping » en ignorant les erreurs d'application.
SLO est « sur le stock » (99. 999 %), mais sont inaccessibles et ne résolvent rien.
Alerts par des mesures de bas niveau au lieu de symptômes personnalisés.
Il n'y a pas de carte de dépendance → on ne sait pas où il brûle.
Il n'y a pas de lien entre SLO et les versions → on ne sait pas qui a « mangé » le budget.
Ignorer les p99 queues est → bon moyen mais mauvais UX VIP utilisateurs.

Spécificité pour iGaming/fintech

Pics programmés : matchs/événements/promotions - augmenter la capacité à l'avance, réchauffer le cache/CDN, inclure des profils de limites spécifiques.
Business SLI : Time-to-Wallet, succès du dépôt/retrait, « vitesse de paiement » p95 ; à la racine des dashboards.
PSP/partenaires : SLO/dashboards distincts par fournisseur, commutation automatique des itinéraires.
Antibot/antifrod : Ne pas manger le budget des erreurs - séparer les « blocs légitimes » des « erreurs techniques ».
Réglementation : stockage des journaux, reproductibilité des calculs SLO/SLA, rapports d'incident.

FAQ

Dois-je déduire les travaux planifiés de SLO ?
Généralement pas : SLO reflète l'expérience vécue par l'utilisateur. Des exceptions peuvent être prévues pour les SLA.

Pourquoi p95 et pas la moyenne ?
La moyenne masque les queues ; L'UX détermine les résidus (p95/p99).

Puis-je avoir un SLO pour l'ensemble du produit ?
Vous avez besoin d'un arbre SLO : agrégé par produit et enfant par chemins/composants critiques.

Résultat

Un système d'infrastructure KPI robuste est un SLI personnalisé, un SLO réaliste, un budget des erreurs comme levier de gestion du changement, une alerte intelligente et une discipline des incidents et des RCA. Liez les indicateurs techniques aux métriques commerciales, automatisez la collecte et la visualisation - et l'infrastructure deviendra prévisible et l'aptyme sera contrôlé même dans les scénarios de pointe.