Opérations et gestion des → Indicateurs de performance

Métriques de performance

1) Pourquoi les métriques de performance sont nécessaires

• détecter les dégradations avant les incidents,
• prévoir la capacité et le budget,
• comparer les solutions alternatives (cache DB vs, gRPC vs REST),
• gérer les régressions après les libérations.

Principes : dictionnaire unique des métriques, agrégation par percentiles (p50/p90/p95/p99), comptabilité séparée des voies « chaudes » et « froides », contexte (version, région, fournisseur, appareil).

2) Taxonomie des métriques

2. 1 Cadre SRE de base

Quatre signaux dorés : Latitude, Trafic, Erreurs, Saturation.
RED (pour les microservices) : Rate, Errors, Durée.
USE (pour le fer) : Utilisation, Saturation, Errors.

2. 2 niveaux

Infrastructure : CPU, RAM, disque, réseau, conteneurs, nœuds.
Plate-forme/Services : API-endpoint, file d'attente, cache, OBD, bus d'événements.
Expérience client : Web Vitals, SDK mobile, streaming, CDN.
Plate-forme de données : ETL/ELT, strimes, vitrines, retards BI.
Flow critique d'affaires : autorisation, KYC, dépôts/paiements, tours de jeu.

3) Catalogue des mesures et formules clés

3. 1 API et microservices

RPS (Requests per second).
Latency p50/p95/p99 (ms) - de préférence « end-to-end » et « backend-only ».
Taux d'erreur (%) = 5xx + 4xx validable/toutes les requêtes.
Saturation : longueur moyenne de la file d'attente des workers, requêtes « in-flight ».
Cold Start Rate (pour FaaS).
Throttling/Dropped Requests.

Exemple de SLO : p95 latitude ≤ 250 ms à RPS jusqu'à 2k dans la région UE-Est ; Erreurs ≤ 0. 5%.

3. 2 Bases de données

QPS/Transactions/s, avg/median query time, p95 query time.
Lock Waits / Deadlocks, Row/Index Hit Ratio, Buffer Cache Miss%.
RepLag (réplication), Checkpoint/Flush time, Autovacuum lag.
Hot Keys/Skew sont les meilleures N clés de charge.

Formule « Requêtes de noyau » : QPS/ vCPU_core_count → signal pour le chardage.

3. 3 Cache et CDN

Hit Ratio (%), Evictions/s, Latency p95, Item Size percentiles.
Origin Offload (%) для CDN, TTFB, Stale-while-revalidate hit%.

3. 4 Files d'attente/strim

Ingress/egress msg/s, Consumer Lag (messages/heure), taux de rebalance.
Processing Time p95, DLQ Rate.

3. 5 Infrastructures/conteneurs

CPU Utilization %, CPU Throttle %, Run Queue length.
Memory RSS/Working Set, OOM kills, Page Faults.
Disk IOPS/Latency/Throughput, Network RTT/ retransmits.
Node Saturation: pods pending, pressure (CPU/Memory/IO).

3. 6 Client Web (UX)

Core Web Vitals: LCP, INP, CLS.
TTFB, FCP, TTI, Resource Timing (DNS, TLS, TTFB, download).
Error Rate (JS), Long Tasks, SPA route change time.
CDN Geo-Latency (percentile).

3. 7 Client mobile

App Start time (cold/warm), ANR rate, Crash-free sessions %.
Network round-trips/session, Payload size, Battery drain/session.
Taux de réussite hors ligne (opérations de cache).

3. 8 Plateforme de données et rapports

Freshness Lag (T-now → витрина), Throughput rows/s, Job Success %.
Cost per TB traité, Skew par lot, Late events %.
BI Time-to-Render p95 pour les principaux dashboards.

3. 9 Flow critique de domaine (iGaming comme exemple)

Auth p95, KYC TTV (Time-to-Verify), Deposit/Withdrawal p95.
Game Round Duration p95, RNG call latency, Provider RTT p95.
Payment PSP success rate, Chargeback investigation SLA.

4) Normalisation, percentiles et attribution

Percents par rapport aux moyennes : nous fixons p50/p90/p95/p99 - les moyennes lissent les douleurs de pointe.
Coupes : version de l'application, région, fournisseur, canal réseau (4G/Wi-Fi), appareil.
Corrélation : nous associons les métriques « backend-only » et « real-user » pour les chaînes causales.
Exemplars/Traces : nous associons les percents extrêmes aux tracés.

5) Seuils et alertes (grille approximative)

Latitude p95 (API de base) : warning> 250 ms, critical> 400 ms 5 minutes consécutives.
Error rate: warning > 0. 5 %, critical> 2 % (par endpoint, pas global).
DB RepLag: warning > 2 s, critical > 10 s.
Kafka consumer lag (time): warning > 30 s, critical > 2 min.
Web LCP (p75): warning > 2. 5 s, critical > 4 s.
Mobile ANR: warning > 0. 5%, critical > 1%.
ETL Freshness: warning > +15 min, critical > +60 min от SLA.

Utilisez des seuils statiques + adaptatifs (saisonnalité, modèles de jour), la déduplication et le regroupement des alertes par service/version.

6) Test de performance

Types : baseline, stress, longue durée (soak), chaos (liens degrade/PSP).
Profils de charge : selon les remorques réelles (distribution-based), « burst », pics régionaux.
Objectifs : Atteindre SLO avec des opérations RPS et mix cibles, valider backpressure.
Métriques de course : Throughput, Error %, p95 latency, GC pause, CPU throttle, queue lag, cost/run.

Règle de régression : la sortie est considérée comme réussie si la p95 n'est pas dégradée> 10 % à profil égal et que le coût de la requête (CPU-ms/requête) n'a pas augmenté> 15 %.

7) Planification de la capacité et prix/performance

Modèle de demande : RPS par montre × travail/requête moyen (CPU-ms, IO-ops).
Headroom : 30-50 % de marge pour les chemins critiques, auto-scaling par P95.
Cost KPIs: Cost per 1k requests, Cost per GB served, $ per 1 p. p. Amélioration de LCP.
Mise en cache/dénormalisation : compter « cache ROI » = (économies de CPU-ms − coût du cache).
Régions chaudes et froides : offload dans CDN/edge, réplication en lecture seule.

8) Pratiques d'observation et de profilage

Traces : trace-ID distribuée à travers tous les hop's ; l'échantillonnage est intelligent (tail-based).
Métriques : Prometheus/OpenTelemetry, notation unique des noms et des labels.
Logs : avec corrélation par trace/span, budget par bruit de journal, édition PII.
Profileurs : Profil CPU/Heap/Alloc/Lock, profilage continu (eBPF).
Instances-exemples : nous associons les éclats p99 à un collage span/SQL/PSP spécifique.

9) Métriques des sorties et des commandes (pour être complet)

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
ESPACE : satisfaction, performance, activité, communication, efficacité.
Ces mesures ne sont pas sur le fer, mais elles affectent directement la durabilité de la productivité.

10) Anti-modèles

Chasser les moyennes : ignorer p95/p99.
« Global » error rate : cache des endpoints douloureux.
Sans attribution par version : impossible de capter les régressions du client.
Alert-spam : seuils sans hystérésis et correction de la saisonnalité.
Optimisation « à l'aveugle » : absence de profilage et de traçage.
Mélange UX et backend latency : conclusions erronées sur l'expérience client.

11) Chèques-feuilles

Norme de mesure unique

• Dictionnaire de métriques avec formules, unités, propriétaires
• Percentiles obligatoires p50/p90/p95/p99
• Corrélation de trace et corrélation de journal
• Tags : région, version, fournisseur, appareil, canal réseau
• Seuils avec hystérésis et déduplication

Avant la sortie

• Basline p95/p99 sur le steadge et la vente
• Trafic canarien + comparaison des métriques A/B
• Drapeau de ficha avec un retour rapide
• Plan de surveillance (observability runbook)

Régulièrement

• Revoyez les requêtes les plus lentes du top N/SQL
• Audit des stratégies de cache et TTL
• Vérification des réplications Freshness et OBD
• Tests de dégradation des fournisseurs externes (PSP, KYC)

12) Mini-playbooks (exemple)

Dégradation p95/api/payments

1. Vérifier l'erreur % et les délais PSP externes.
2. Vérifiez le client lag de la file d'attente collbec.
3. Voir trace exemples p99 : goulot d'étranglement SQL/HTTP ?
4. Activer le cache d'annuaire/limites, abaisser N + 1.
5. Budget : augmenter temporairement les ressources de worker de 20 %, inclure autoscale.
6. Post-fix : index par (psp_id, status, created_at), rétro-jitter.

Croissance de RepLag dans les EDR

1. Vérifiez les demandes « lourdes » et les transactions longues.
2. Augmentez le parallélisme de réplication et tondez checkpoint.
3. Offload lecture en cache/réplica lecture seule.
4. Dans les fenêtres de pointe - denorm partiel + batchi.

13) Exemples de formules/SQL (simplifié)

Taux d'erreur par endpoint

sql
SELECT endpoint,
100. 0 SUM(CASE WHEN status >= 500 THEN 1 ELSE 0 END) / COUNT() AS error_pct
FROM http_logs
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING COUNT() > 500;

Latency p95 (TDigest/Approx)

sql
SELECT endpoint, approx_percentile(latency_ms, 0. 95) AS p95_ms
FROM http_metrics
WHERE ts >= date_trunc('hour', now())
GROUP BY 1;

Consumer Lag (heure)

sql
SELECT topic, consumer_group,
max(produced_ts) - max(consumed_ts) AS lag_interval
FROM stream_offsets
GROUP BY 1,2;

Web LCP p75

sql
SELECT approx_percentile(lcp_ms, 0. 75) AS lcp_p75
FROM web_vitals
WHERE country = 'UA' AND device IN ('mobile','tablet')
AND ts >= current_date;

14) Incorporation dans les dashboards et rapports

Cartes KPI : p95 latency, error %, RPS, saturation avec les tendances WoW/DoD.
Top N des « pires » endpoints/SQL/ressources, cliquable drill-down → trace.
Corrélation des versions client : graphique « version → p95 LCP/INP → conversion ».
Carte du monde : géo-latitude (CDN), PSP latitude par région.
SLO panel : part du temps dans SLO, départs de SLO, « budget des erreurs ».

15) Résultats

Les métriques de performance sont une discipline systémique : dictionnaire unique, percentiles, attribution, bonne observabilité et SLO rigoureux. En combinant les signaux techniques (latence, lagune, cache-succès) et les signaux de produits (heure KYC, dépôt p95, LCP), vous gérez la qualité de l'expérience et le coût de sa livraison - de manière prévisible et évolutive.