Opérations et gestion → Audit des métriques et des SLA

Audit des métriques et SLA

1) Pourquoi est-ce nécessaire

Si les métriques sont erronées - les solutions seront erronées, les SLA seront violées « sur papier » ou au contraire cacher les problèmes. L'audit métrique et le SLA garantissent la comparabilité, la crédibilité et la sécurité juridique des promesses faites aux utilisateurs et aux partenaires.

• Fournir une seule « source de vérité » (SSOT) et des calculs reproductibles.
• Réduire les écarts entre les dashboards/rapports/facturation.
• Rendre les SLA réalisables et vérifiables (evidence-based).
• Détecter les dégradations dans les mesures aussi tôt que dans les services.

2) Notions de base et limites de la responsabilité

Métrique (métrique) : Valeur mesurée (RPS, p95, CR, GGR, Taux de réussite).
KPI/OKR : cibles auxquelles les métriques sont liées.
SLO : qualité de service cible (p. ex. "p99 ≤ 400 ms 99. 9 % du temps").
SLA : une promesse extérieure ; juridiquement significatif, basé sur SLO.
L'OLA : accord interne entre les équipes/fournisseurs, soutient l'ALS.
SSOT : système/entrepôt dont les données sont considérées comme des données de référence pour les rapports.

3) Taxonomie des métriques (couches)

1. Infrastructure : CPU/Mémoire/IO/Net, pods/nœuds, HPA/VPA.
2. Plate-forme : files d'attente/strim (lag, throughput), OBD/cache (connects, hit), API (p95/p99, 5xx).
3. Flux d'affaires : dépôts/retraits, paris, lancement de jeux, autorisation, KYC.
4. Produit/marketing : conversions, ARPPU/LTV, campagnes.
5. Qualité des processus : MTTA/MTR, taux d'échec de changement, couverture des feuilles de contrôle.

Règle : chaque métrique doit avoir un calque, un propriétaire et une formule.

4) Sources de données et « vérité »

Téléémétrie en ligne : Prometheus/OTel, logs (ELK/ClickHouse), tracés.
Événements et comptabilité : Kafka/Outbox, DWH/date-marts (BigQuery/ClickHouse).
Artefacts manuels : postmortems, tiquets, registres d'incidents.
Registres externes : rapports des fournisseurs (PSP/KYC/studios), facturation.

Résoudre le conflit : en cas de divergence « en ligne vs DWH », il existe un règlement de priorité (par exemple, pour les SLA, des agrégats de DWH avec une traçabilité de source).

5) Processus d'audit des métriques (contour de gestion)

1. Inventaire : catalogue métrique/SLO/SLA (nom, propriétaire, couche, formule, source, fréquence de calcul).
2. Vérification des formules : rapprochement des requêtes SQL/pro avec la définition (tests de calcul unitaire).
3. Sample et revérification : échantillons de lignes d'événements/logs et rapprochement manuel.
4. Mise en correspondance des contours : comparaison des rapports Dashboards en ligne et DWH.
5. Contrôle des changements : je revois les formules lors des sorties de schémas/logique.
6. Audit SLA : vérification de l'exactitude des assemblages et des exceptions (maintenance planifiée, force majeure).
7. Rapport et améliorations : liste des anomalies et des fiches détectées avec les deadlines.

6) Définitions et formules (échantillons)

• `success = requests - (5xx + timeouts + circuit_open)`
• `success_rate = success / requests`

• le SSOT fixe une seule définition de fenêtre (rolling 5m/1h) et d'agrégation (HDR/TDigest).

• 'SLO _ availability _ month = (temps _ de fonctionnement - exceptions _ valides )/temps _ total '

• `SLA_month = 99. 90 % de l'aptyme par la fenêtre UTC, à l'exclusion des fenêtres planifiées (notification T-48) prouvées par les accidents chez les opérateurs de transit (documents) "

7) Qualité des données : contrôles et alertes

• Полнота (completeness): `received_events / expected_events ≥ 0. 99`.
• Actualité (timel....) : Charge lag ≤ N minutes.
• Unicité (uniqueness) : pas de prises par clés (idempotency-key).
• Cohérence (consistency) : montants/devises/signes.
• Linéarité (monotonicité) : les compteurs ne sont pas « rétractés ».

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) Audit SLA/OLA : méthodologie

1. Rassemblez le calendrier des exceptions : fenêtres de planification, dégradations convenues, actes des vendeurs.
2. Calcul de l'aptame : par zone temporelle unique, avec un support SSOT.
3. Rapprochement avec les incidents : timing, tickets, postmortems.
4. Attribution : défaillances propres, fournisseur, transit, DDoS, travaux programmés.
5. Périmètre SLA : expérience utilisateur (E2E) vs une API spécifique.
6. Rapports : rapport mensuel/trimestriel : faits, écarts, indemnités (le cas échéant), mesures correctives.

9) Vérification de la reproductibilité des calculs

Versionage de formules : Git-référentiel avec les spécifications SQL/BouQL/Dock.
Tests unitaires de métriques : sur les données synthétiques (cas edge : sauts, prises, limites de dates).
Data lineage : du dashboard aux tables et événements originaux.
Snapshots : geler les données pour les couper afin que les calculs de plumes soient comparables.

10) Échantillons de contrôle (sampling)

Chaque jour : 10-20 événements selon les flux clés (le dépôt/taux/kous) - la vérification de main трассировки ↔ DWH.
Chaque semaine : 1 % sample pour comparer « en ligne vs DWH » par agrégats.
Mensuelle : ensemble d'incidents avec effet SLA - reconstruction détaillée.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) Audit des dashboards et alertes

Un seul dictionnaire de métriques : un glossaire directement sur le dashboard.
Annotations de release/events : pour voir la cause des anomalies.
Comparaison « avant/après la sortie » : panneaux de régression automatiques.
Doublures/divergences : identification de « deux p99 différents » - modification des formules/fenêtres.
Disponibilité des panneaux : droits, réserve, contrôle des références/versions.

12) Gestion des changements dans les métriques

Processus RFC : changement de formule/fenêtre/source - via RFC avec évaluation de l'impact sur les SLA/rapports.
Migration « expand → migrate → contract » : nous menons temporairement les deux versions, nous comparons, puis nous éteignons l'ancienne.
Communications : notifiez à l'avance le produit/l'entreprise des changements de valeur « selon la nouvelle technique ».

13) Spécificités iGaming/fintech

Pics de demande : les métriques doivent résister aux charges explosives (les agrégations ne « bouillent » pas).
Fournisseurs : SLA dépend de OLA vendeurs → stocker leurs rapports, les états des incidents et les quotas.
Coût : 'cost _ per _ 1k _ calls'et' coût de succès 'sont des panneaux obligatoires.
Antifrod/risque : sensibilité aux retards et aux « faux positifs » métriques.

14) Dashboards d'audit (recrutement minimum)

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.
SLO/SLA Evidence : SLO calculé, SLA réel, exceptions, références aux incidents/actes.
Compare en ligne vs DWH : Taux p95/p99/Success, écarts et tendances.
Vendor SLA : aptyme/quotas/time out/coût en coupe des fournisseurs.
Release Impact : régression des métriques après mise en place/activation de la fiche.

15) Chèque d'audit (opérationnel)

• Le catalogue métrique/SLO/SLA avec les propriétaires et les formules est à jour.
• Le SSOT est défini pour chaque rapport/panneau.
• Les tests unitaires de formules sont verts, les pipes de calcul sont documentées.
• Les alertes sur la qualité des données sont actives (completeness/timel..../duplicates).
• « Online vs DWH » des écarts ≤ le seuil autorisé (par exemple, ≤2 %).
• Les exceptions convenues aux SLA sont documentées et jointes au rapport.
• Des échantillons de contrôle ont été effectués et des actes ont été rédigés.
• Tous les changements de formule sont passés par le RFC et la migration.

16) Exemples (fragments)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17) Anti-modèles

Deux formules différentes « une » métrique sur des panneaux différents.
Modifier la métrique sans migration et la notification - « sauts » dans OKR/SLA.
Rapports dans Excel local en tant que « vérité » (non reproductible).
Mélange des fuseaux horaires et des calendriers dans les calculs SLA.
Les exceptions aux SLA ne sont pas documentées.
Pas d'alertes sur la qualité des mesures.

18) KPI de maturité des mesures

Drift Rate Online↔DWH (objectif de ≤2 %).
Metrics Health Uptime (temps sans dégradation ingest/ETL).
Time-to-Fix Formula (temps d'élimination de l'erreur dans la formule).
Taux de dispersion SLA (fréquence des cas controversés avec des partenaires).
Coverage SLO/SLA (proportion de voies critiques avec SLO/SLA formellement décrites).

19) Rôles et responsabilités

Propriétaire métrique/service : formule, source, dashboard, alertes.
Observability/SRE : SSOT/plateforme, tests de formule, alertes de qualité des données.
Data/BI : DWH, reproductibilité des rapports, lineage.
Avocats/associés gestionnaires : Accords SLA et exceptions.
Responsable de l'incident : attribution et combinaison des incidents avec l'ALS.

20) Démarrage rapide (30 jours)

Semaine 1 : inventaire des métriques/SLO/SLA et des propriétaires ; désigner le SSOT.
Semaine 2 : inclure les alertes de qualité des données et le panneau « Online vs DWH ».
Semaine 3 : effectuer des échantillons de contrôle, aligner la fenêtre p95/p99.
Semaine 4 : formaliser le processus RFC pour les formules, préparer un rapport mensuel SLA avec des annexes.

21) FAQ

Q : Qu'est-ce que le SSOT pour l'ALS ?
A : Stockage avec calculs reproductibles (DWH) et lineage complet ; panneaux en ligne - pour le contrôle opérationnel, pas pour les actes juridiques.

Q : Comment faire face aux « deux p99 » ?
R : Fixer la fenêtre/méthode d'agrégation dans le répertoire métrique, migrer les panneaux, ajouter un alert à la dérive.

Q : Comment tenir compte des travaux planifiés ?
R : Tenir un calendrier des exceptions et les déduire automatiquement de l'ALS selon les règles du contrat ; conserver les artefacts de confirmation.