Dashboard central de commande

1) Désignation et principes

Le dashboard central de contrôle (ci-après le CDU) est un guichet unique pour la prise de décisions dans les opérations. Il agrège les signaux de télémétrie, ITSM, CI/CD, catalogue de services, calendrier de travail et fournisseurs, les transformant en widgets valides (activables).

• SLO-first : haut - SLO cibles et burn-rate par Tier-0/1.
• One-click to action : du widget - au pleybuk/runbook ou au tiquet.
• Dictionnaire unique : SEV, statuts, couleurs et seuils identiques.
• Annotations d'événements : versions/configi/fenêtres sur tous les graphiques.
• Rôles et résolutions : représentations personnelles (on-call, IC, management).
• Faible bruit : quorum des sources, déduplication et suppression par les fenêtres.

2) Rôles et scénarios clés

On-call (P1/P2) : Comprendre rapidement « ce qui brûle » et ouvrir le playbook (≤1 clic).
IC : déclarer SEV, démarrer le mode war-room, contrôler la cadence des comms-updates.
Release Manager : voir les gates, la progression des canaries, la volonté de retour en arrière.
Service Owner/Product : SLI d'entreprise (succès des paiements/enregistrements), impact fich.
SRE/Platform : Capacité, Auto-Skale, Anomalies, DR-Prevention.
FinOps : $/unité, dépassements, alertes budgétaires.
Sécurité/Juridique : posture, certificats clés, fenêtres de rotation, audit WORM par des liens.

3) Architecture d'information du CDU

• SLO по Tier-0/1 (availability/latency/success) с burn-rate 2-окна.
• Statut SEV : incidents actifs et leur temporisation.
• Statut des versions : canari/blue-green, gates actives.
• Les « feux de trafic » des fournisseurs (PSP/KYC/CDN).

• Fenêtres de service (maintenant/24h), carte de suppression.
• Capacité : CPU/RAM/IO/queue-depth/p95 latitude avec prédiction.
• FinOps : $/1k txn, budget de spend de jour vs, anomalies de volume de log.
• DataOps : fraîcheur des vitrines, SLA des pipelines, erreurs DQ.
• Sécurité : durée des certificats, rotation des secrets, vulnérabilités critiques (age/SLA).

• Corrélations « sortie ↔ SLO », « fournisseur ↔ refus/latence ».
• Liens rapides : logs, tracks, tiquets, playbooks, SOP, matrice d'escalade.

4) Widgets (jeu de référence)

1. SLO & Burn-rate

Affiche le SLI actuel, l'objectif et la consommation du budget des erreurs (1h/6h).
Action : ouvrir le playbook de dégradation du service.

2. Incidents (panneau SEV)

Actif/dernier, Declare/Comms minuteries, les rôles IC/Comms.
Action : ouvrir la salle de guerre, modèle d'update, chèque IC.

3. Sorties/Configi

Canaris 1→5→25 %, drapeaux, retour en arrière (bouton/lien vers SOP).
Annotations : version, commits, auteur.

4. Fenêtres de maintenance

Services actuels/à venir, impactés/régions ; masque de suppression.
Action : négocier les notifications, inclure les gardes SLO.

5. Capacité/Auto Skale

Prévisions de consommation (Naive/AR), carte hotspot, warm-pool.
Action : demande de quotas/règles de skale (PR dans repo-policy).

6. FinOps

$/unité, haut « cher » demandes/logs, daily burn vs budget.
Action : ouvrir le rapport et la recommandation (sample des logs, archives).

7. Fournisseurs

SLA/statut PSP/KYC/CDN, poids des itinéraires, préparation folback.
Action : changer de poids, modèle de communication aux partenaires.

8. Security

Certificats (≤30d), rotations tardives, vulnérabilités (age), événements suspects.
Action : ouvrir l'IR-playbook/ticket.

9. DataOps

Fraîcheur des vitrines, pourcentage de passes, refus de pipline, DLQ.
Action : backfill/quarantaine/rollback transformation.

5) États/couleurs/seuils (référence)

Vert : SLI à l'intérieur de la cible, burn-rate <1 ×.
Amber : SLI se dégrade, burn-rate 1-2 ×, croissance p95, mais workaround est là.
Red : breach ou burn-out prédictif <1h ; Ouvrir le SEV-1/0.
Grey : suppression (fenêtre), pas de télémétrie (erreur source).

6) Annotations et corrélations

Les états de sortie/config/fenêtre/fournisseur sont affichés sur les graphiques SLO.
Clic sur le marqueur → diff, auteur, gates, bouton « Retour/Folback/SOP ».
Dans un incident, la ligne temporelle est construite à partir d'annotations et d'actions ChatOps.

7) Sources de données et vérification

Télémétrie : métriques/trajets/logs avec trace_id.
ITSM : incidents/problèmes/modifications (statuts/SLA).
CI/CD : versions, signatures, artefacts, tests.
Annuaire de services/CMDB : propriétaires, SLO, dépendances.
Calendrier : fenêtres de service.
Fournisseurs : Status-API + confirmations manuelles (atterrissage dans une vitrine distincte).
FinOps : tags de facturation/ressources, volumes logiques, egress.

Contrôle qualité : quorum, sondes en double, SLA de fraîcheur, alertes sur les sources « muettes ».

8) Modes d'affichage

War-room : une disposition fixe SLO/Incidents/Releases/Comms-timer.
Executive (28 jours) : tendances MTTR/MTTD/SEV mix, $/ed., SLO-adgerence.
On-call : panneau compact « nuit » (mode sombre, gros chiffres).
Multi-tenant/région : filtres service/région/tenant ; presets.

9) Navigation et actions (one-click)

Boutons : '/declare sev1 ', '/freeze', '/rollback ', '/status update', « ouvrir le playbook ».
Drill- ดาวn : SLO → graphique → logs/trajets avec filtres pré-remplis (trace_id, release_id).
Sharing : snapshot de panneaux en ticket/status page.

10) Sécurité, accès, audit

SSO/OIDC + RBAC/ABAC : rôles et scoops (voir/action).
JIT/JEA : l'action « dangereuse » n'est disponible qu'avec une augmentation temporaire.
L'audit est immuable : qui a cliqué sur quoi, quelles demandes/équipes sont parties.
Secrets : ne sont pas affichés, seulement les liens vers le gestionnaire de secrets.

11) Métriques de maturité des CDU

Actionability ≥ 90 %: les clics conduisent à des actions et pas seulement à des graphiques.
Time-to-First-Action ≤ 2 min du CDU à la SEV-1/0.
Proportion d'incidents où le CDU était une « source de vérité » ≥ 95 %.
Widgets freshness :% avec les données « frais 5 min ».
Coverage :% des services critiques ayant des cartes SLO et des annotations de version.
Zero-blind-spots : sources « muettes » pour la semaine = 0.

12) Chèques-feuilles

Conception

• Les rôles et les scénarios sont décrits (P1/P2/IC/Exec/FinOps/Security/DataOps).
• Dictionnaire de couleurs/SEV/seuils convenu.
• Sources de données avec quorum et SLA de fraîcheur.
• Maquettes War-room/On-call/Executive.
• Plan d'intégration ChatOps/ITSM/CI/CD/CMDB.

Exploitation

• Les widgets passent par le linter (champs obligatoires, owner, seuils).
• Une fois par semaine - Enquête sur l'escalade/alerte avec les améliorations des CDU.
• Des snapshots d'incidents sont appliqués à l'AAR/RCA.
• Mode obscur/mobile pour les gardes.
• Tests de « noirceur » des sources et d'exactitude des annotations.

13) Modèles (idées)

13. 1 Définition de widget (YAML)

yaml id: slo-payments title: "SLO: Success of payments (EU)"
owner: team-payments type: slo_burnrate sli:
metric: "biz. payment_success_ratio"
target_pct: 99. 5 burn_rate:
short_window: "1h"
long_window: "6h"
thresholds:
amber: { burn_rate: 1. 2 }
red:  { burn_rate: 2. 0 }
actions:
- label: "Open playbook"
link: "rb://payments/slo-degrade"
- label: "Release rollback"
link: "sop://REL-ROLLBACK-01"
annotations:
release: true change: true filters:
region: "eu"
tier: "0"

13. 2 Carte d'incident (JSON)

json
{
"id": "incidents-active",
"type": "incident_board",
"sev": ["SEV-0", "SEV-1", "SEV-2"],
"fields": ["id","sev","service","since","ic","next_comms_at"],
"actions": [{"label":"War-room","cmd":"/declare sev1"}]
}

13. 3 Lien avec la sortie

yaml id: release-canary type: release_progress source: cicd://checkout gates: ["tests","signatures","slo_guardrails"]
canary_steps: [1,5,25]
rollback: "sop://REL-ROLLBACK-01"
annotations: { on_charts: ["slo-latency","slo-success"] }

13. 4 Widget FinOps

yaml id: finops-burn type: cost_unit metrics:
- id: "cost_per_1k_txn"
- id: "logs_daily_gib"
alerts:
- when: "cost_per_1k_txn > target1. 2"
action: "open://finops/reco-logs-sampling"

14) Anti-modèles

Le mur des graphiques sans action et sans pleybuck.
Différentes couleurs/seuils par commande → confusion dans le SEV.
Aucune annotation de version/fenêtre - une corrélation complexe des causes.
Les sources en double sans quorum sont de faux pages/bruit.
Secrets/clés sur le panneau - risque de fuite.
Un rendu lent (pas de requêtes/agrégations) - les panneaux ne s'ouvrent pas au combat.

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

1. Ned. 1 : collecte des exigences par rôle, dictionnaire des statuts/couleurs, disposition des trois modes.
2. Ned. 2 : connexion SLO/Incidents/Releases/Windows, annotations, actions ChatOps.
3. Ned. 3 : ajout de FinOps/Capacity/Providers/DataOps/Security, quorum des sources.
4. Ned. 4 : War-room mode, snapshots en ITSM, pilote en Tier-0.
5. Ned. 5-6 : optimisation des performances, preset mobile/on-call, linter widget.
6. Ned. 7-8 : métriques de maturité, examen hebdomadaire, recommandations automatiques (échantillonnage des loges, quotas, folback).

16) Résultat

Les CDU ne sont pas des « beaux graphiques », mais un panel de solutions : SLO et burn-rate en haut, incidents/sorties/fenêtres dans le même contexte, actions instantanées via ChatOps et SOP, sources confirmées et annotations. Un tel dashboard réduit MTTA/MTR, simplifie les communications, soutient FinOps et rend l'exploitation transparente et prévisible.