Analyse opérationnelle

1) Qu'est-ce que l'analyse opérationnelle et pourquoi il est nécessaire

L'analyse opérationnelle (Ops Analytics) est un assemblage système de signaux de l'observation (métriques/logs/trajets), ITSM (incidents/problèmes/modifications), CI/CD (versions/configi), fournisseurs (PSP/KYC/CDN/Cloud), FinOps (coûts)) et le SLI (succès des paiements, enregistrement), transformé en vitrines et dashboards uniques pour la prise de décision.

• réduire le MTTD/MTTR par une détection précoce et une attribution correcte des causes ;
• garder le contrôle du SLO et du budget des erreurs ;
• lier les changements → l'impact (communiqués/configis → SLI/SLO/plaintes/coûts) ;
• donner l'analyse self-service aux équipes et à la gestion.

2) Sources et couche de données canoniques

Télémétrie : métriques (SLI/ressources), logs (sampling/édition PII), tracks (trace_id/span_id, tags de sortie).
Modules ITSM/Incident : SEV, Timestamps T0/Detected/Ack/Declared/Mitigated/Recovered, RCA/CAPA.
CI/CD & Bou : versions, commits, canaris/bleu-vert, flag-state, configs ciblés.
Fournisseurs : statuts/SLA, retards, codes d'erreur, poids des itinéraires.
FinOps : coût par tags/comptes/tenants, $/unité (1k opéras.) .
DataOps : fraîcheur des vitrines, erreurs DQ, lineage.

Le principe clé est une corrélation unique à travers les identifiants : 'service', 'région', 'tenant', 'release _ id', 'change _ id', 'incident _ id', 'provider', 'trace _ id'.

3) Modèle de données unique (cadre simplifié)

dim_service(service_id, owner, tier, slo_targets…)
dim_time(ts, date, hour, tz)
dim_region(region_id, country, cloud)
dim_provider(provider_id, type, sla)
fact_sli(ts, service_id, region_id, tenant, metric, value, target, window)
fact_incident(incident_id, service_id, sev, t0, t_detected, t_ack, t_declared, t_mitigated, t_recovered, root_cause, trigger_id, burn_minutes)
fact_change(change_id, type(code    config    infra), service_id, region_id, started_at, finished_at, canary_pct, outcome(ok    rollback), annotations)
fact_cost(ts, service_id, region_id, tenant, cost_total, cost_per_1k)
fact_provider(ts, provider_id, region_id, metric(latency    error    status), value)
fact_dq(ts, dataset, freshness_min, dq_errors)

4) SLI/SLO et métriques d'entreprise

Бизнес-SLI: `payment_success_ratio`, `signup_completion`, `deposit_latency`.
Тех-SLI: `availability`, `http_p95`, `error_rate`, `queue_depth`.
SLO calque : cibles + burn-rate (fenêtre courte/longue), annotations automatiques des violations.
Normalisation : indicateurs sur 1k opérations réussies/utilisateurs/trafic.

5) Corrélations et attribution des causes

Versions/configis ↔ SLI/SLO : annotations sur les graphiques ; rapports de cause à effet (proportion d'incidents liés au changement ; MTTR changes-incidents).
Les fournisseurs ↔ des SLI d'entreprise : poids des itinéraires vs latency/error, contribution de chaque fournisseur dans les défauts de SLO.
Capacité/ressources ↔ retards : surchauffe des pools → croissance p95 → impact sur la conversion.

6) Anomalies et prévisions

Anomalie-détect : saisonnalité + seuils percentiles + fiches de changement-recherche (avant/après la sortie).
Prévisions : modèles de charge hebdomadaires/saisonniers, prévisions d'erreurs budgétaires de burn-out, prédiction des coûts ($/ed.) .
Gardreilles : alertes uniquement au quorum des sources (synthétique + RUM + Business SLI).

7) Vitrines et dashboards (référence)

1. Executive 28d : SEV-mix, MTTR/MTTD médian, SLO adherence, $/unité, raisons principales.
2. SRE Ops: SLI/SLO + burn-rate, Page Storm, Actionable %, Change Failure Rate.
3. Change Impact : Communiqués/configis ↔ SLI/SLO/plaintes, retours et leurs effets.
4. Providers : lignes de statut PSP/KYC/CDN, effets sur les ISS d'entreprise, temps de réponse.
5. FinOps : cost per 1k txn, logs/egress, anomalies de coût, recommandations (échantillonnage, stockage).
6. DataOps : fraîcheur des vitrines, erreurs DQ, piplines SLA, succès backfill.

8) Qualité des données et gouvernance

Contrats d'événements : schémas clairs pour les incidents/sorties/SLI (champs obligatoires, fuseaux horaires uniques).
DQ-checker : exhaustivité, unicité des clés, cohérence du temps (t0≤detected≤ack...).
Linéaire : du dashboard à la source (traceable).
PII/secrets : édition/masquage par politique ; WORM pour evidence.
SLA de fraîcheur : vitrines Ops ≤ 5 min de retard.

9) Mesures de la maturité de l'analyse opérationnelle

Coverage :% des services critiques dans les vitrines et les bordes SLO (objectif ≥ 95 %).
Freshness : proportion de widgets frais ≤ 5 min (objectif ≥ 95 %).
Actionability : du % des passages de дашборда vers l'action (plejbouk/SOP/tiket) ≥ 90 %.
Détection Coverage : ≥ 85 % des incidents détectent l'automatisation.
Taux d'attribution : proportion d'incidents avec cause confirmée et déclencheur ≥ 90 %.
Changer Impact Partager : proportion d'incidents liés au changement (contrôler la tendance).
Qualité des données : bogues DQ/semaine → ↓ QoQ.

10) Processus : des données aux actions

1. Collecte → nettoyage → normalisation des vitrines → (ETL/ELT, feature-couche pour ML).
2. Détection/prévision → escalade matricielle (IC/P1/P2/Comms).
3. Action : playbook/SOP, gate de sortie, drapeau ficha, changement de fournisseur.
4. Evidence et AAR/RCA : temps, graphiques, liens vers les versions/logs/trajets.
5. CAPA et solutions de produits : priorité par burn-minute et $-impact.

11) Exemples de demandes (idée)

11. 1 Impact des sorties sur SLO (24h)

sql
SELECT r. change_id,
COUNT(i. incident_id) AS incidents,
SUM(i. burn_minutes) AS burn_total_min,
AVG(CASE WHEN i.root_cause='code' THEN 1 ELSE 0 END) AS code_ratio
FROM fact_change r
LEFT JOIN fact_incident i
ON i.trigger_id = r. change_id
WHERE r. started_at >= NOW() - INTERVAL '24 hours'
GROUP BY 1
ORDER BY burn_total_min DESC;

11. 2 Proportion de problèmes des fournisseurs par région

sql
SELECT region_id, provider_id,
SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END) AS prov_inc,
COUNT() AS all_inc,
100. 0SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END)/COUNT() AS pct
FROM fact_incident
WHERE t0 >= DATE_TRUNC('month', NOW())
GROUP BY 1,2
ORDER BY pct DESC;

11. 3 Cost per 1k paiements réussis

sql
SELECT date(ts) d,
SUM(cost_total)/NULLIF(SUM(success_payments)/1000. 0,0) AS cost_per_1k
FROM fact_cost c
JOIN biz_payments b USING (ts, service_id, region_id, tenant)
GROUP BY d ORDER BY d DESC;

12) Modèles d'artefacts

12. 1 Schéma de l'événement d'incident (JSON, fragment)

json
{
"incident_id": "2025-11-01-042",
"service": "payments-api",
"region": "eu",
"sev": "SEV-1",
"t0": "2025-11-01T12:04:00Z",
"detected": "2025-11-01T12:07:00Z",
"ack": "2025-11-01T12:09:00Z",
"declared": "2025-11-01T12:11:00Z",
"mitigated": "2025-11-01T12:24:00Z",
"recovered": "2025-11-01T12:48:00Z",
"root_cause": "provider",
"trigger_id": "chg-7842",
"burn_minutes": 18
}

12. 2 Catalogue de métriques (YAML, fragment)

yaml metric: biz. payment_success_ratio owner: team-payments type: sli target: 99. 5 windows: ["5m","1h","6h","28d"]
tags: [tier0, region:eu]
pii: false

12. 3 Fiche de rapport Executive (sections)

1) SEV mix and MTTR/MTTD trends
2) SLO adherence and burn-out risks
3) Change Impact (CFR)
4) Providers: Degradation and switchover
5) FinOps: $/unit, log anomalies/egress
6) CAPAs: Status and Deadlines

13) Outils et modèles architecturaux

Data Lake + DWH : couche « brute » pour la télémétrie, vitrines pour les solutions.
Stream-processing : near-real-time SLI/burn-rate, fiches en ligne pour les anomalies.
Feature Store : réutilisation des fiches (canaries, saisonnalité, signaux fournisseurs).
Semantic Layer/Metric Store : définitions de métriques uniques (SLO, MTTR...).
Contrôle d'accès : RBAC/ABAC, row-level security for tenants/regions.
Catalogue/Lineage : recherche, descriptions, dépendances, propriétaires.

14) Chèques-feuilles

14. 1 Lancement de l'analyse opérationnelle

• Les dictionnaires SLI/SLO, SEV, causes, types de changement ont été approuvés.
• Schémas d'événements et temporisations uniques.
• Connecteurs de télémétrie, ITSM, CI/CD, fournisseurs, facturation.
• Vitrines : SLI/SLO, Incidents, Changements, Providers, FinOps.
• Executive/SRE/Change/Providers dashboards sont disponibles.
• Configurés quorum-alerts et suppression sur les fenêtres de service.

14. 2 Revue hebdomadaire Ops

• Tendances SEV, MTTR/MTTD, échecs SLO, burn-minutes.
• Change Impact et CFR, état des retours en arrière.
• Incidents providentiels et temps de réaction.
• FinOps : $/ed., anomalies de logs/egress.
• Statut, arriérés, priorités de l'ACPA.

15) Anti-modèles

« Mur des graphiques » sans passer à l'action.
Différentes définitions des métriques des commandes (pas de couche sémantique).
L'absence d'annotations des versions/fenêtres est une attribution faible des causes.
Orientation vers la moyenne au lieu de p95/p99.
Il n'y a pas de normalisation du volume - les grands services « semblent pires ».
PII dans les loges/vitrines, perturbation des rétentions.
Les données sont « stagnantes » (> 5-10 min pour les widgets temps réel).

16) Feuille de route pour la mise en œuvre (4-8 semaines)

1. Ned. 1 : arrangements sur le dictionnaire des métriques, les schémas d'événements, la corrélation id ; connexion SLI/SLO et ITSM.
2. Ned. 2 : vitrines Incidents/Changements/Providers, annotations de sortie ; Executive & SRE dashboards.
3. Ned. 3 : Couche FinOps ($/ed.) , un lien avec le SLI ; anomalie-detect avec quorum.
4. Ned. 4 : self-service (semantic layer/metric store), catalogue et lineage.
5. Ned. 5-6 : prévisions de charge/coût, rapports aux fournisseurs, vitrine CAPA.
6. Ned. 7-8 : couverture de ≥95 % de Tier-0/1, SLA fraîcheur ≤5 min, examens réguliers Ops.

17) Résultat

L'analyse opérationnelle est une machine décisionnelle : définitions unifiées des métriques, vitrines fraîches, attribution correcte des causes et transitions directes vers les playbacks et les SOP. Dans un tel système, l'équipe détecte et explique rapidement les écarts, évalue avec précision l'impact des sorties et des fournisseurs, gère les coûts et réduit le risque systémique - et les utilisateurs reçoivent un service stable.