

- Description
- Poste d'aiguillage ferroviaire à côté d'un passage à niveau : un point de supervision du trafic.
- Source
- Hassocks5489 · page d’origine
- Licence
- CC0 Domaine public
Exploitation, supervision et capacité
Ce thème évalue la capacité à faire tourner le produit BI : planification et suivi des rafraîchissements, alertes d'échec, supervision de la capacité (application Capacity Metrics de…
En bref
Ce thème évalue la capacité à faire tourner le produit BI : planification et suivi des rafraîchissements, alertes d'échec, supervision de la capacité (application Capacity Metrics de Microsoft Fabric/Power BI, journaux d'activité, journaux de requêtes), runbooks, gestion des incidents, objectifs de niveau de service (SLO), planification de capacité. Il complète IND (livrer) et précède CST (payer juste).
Niveau : 🟢→🔴 · Code thème : OPS
1. Pourquoi ce thème#
Un rafraîchissement qui échoue la nuit produit, le matin, des chiffres de la veille présentés comme du jour. Une capacité saturée ralentit ou bloque tous les rapports qui la partagent, y compris ceux qui n'y sont pour rien (« voisin bruyant »). Sur capacité Fabric/Premium, la consommation est lissée dans le temps ; un pic non maîtrisé finit par déclencher une limitation (throttling) progressive : d'abord des délais de 20 secondes sur les nouvelles opérations interactives, puis leur rejet, enfin le rejet de toutes les requêtes (politique Microsoft susceptible d'évoluer). Sans supervision, on découvre les incidents par les utilisateurs.
2. Ce que mesure le thème#
- Axe : de la découverte des pannes par les utilisateurs à une exploitation proactive avec SLO.
- Indicateurs clés : taux de réussite des rafraîchissements ; délai de détection d'un échec (MTTD) ; délai de remise en service (MTTR) ; utilisation moyenne et pic de la capacité ; fraîcheur observée vs promise.
- Unités : %, minutes, % d'unités de capacité (CU).
3. Les 5 niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Aveugle | On apprend les pannes par les utilisateurs. | MTTD en heures ; aucune alerte |
| 2 | Alertes d'échec | L'équipe est prévenue d'un échec de rafraîchissement dans l'heure. | Notifications d'échec ; MTTD < 1 h |
| 3 | Tableau de bord | On voit en un coup d'œil la santé des rafraîchissements, de la capacité et des usages. | Tableau de bord d'exploitation ; réussite > 98 % |
| 4 | SLO et runbooks | La fraîcheur et la disponibilité sont engagées, mesurées, et les incidents suivent une procédure. | SLO publiés ; MTTR < 1 h sur incidents connus |
| 5 | Anticipé | Les incidents sont prévenus par l'analyse de tendance, la capacité s'ajuste avant saturation. | Alertes prédictives ; 0 throttling non anticipé |
4. Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| BI-OPS-1.1 | Les rafraîchissements sont planifiés dans le service | Planification visible |
| BI-OPS-1.2 | Un responsable d'exploitation est nommé | Fiche |
| BI-OPS-1.3 | Le contact support est connu des utilisateurs | Canal communiqué |
| BI-OPS-2.1 | Notification d'échec envoyée à un groupe (pas à une personne) | Destinataires configurés |
| BI-OPS-2.2 | Historique de rafraîchissement consulté et conservé | Journal |
| BI-OPS-2.3 | Heure et fenêtre de rafraîchissement choisies pour éviter les pics | Planning de charge |
| BI-OPS-2.4 | La date de dernière actualisation est visible dans le rapport | Indicateur de fraîcheur |
| BI-OPS-3.1 | Application Capacity Metrics (ou équivalent) installée et consultée | Rapport d'usage de la capacité |
| BI-OPS-3.2 | Journaux d'activité exportés et conservés au-delà de la rétention native | Magasin de journaux |
| BI-OPS-3.3 | Tableau de bord d'exploitation : réussite, durée, volumétrie, usages | Rapport d'exploitation |
| BI-OPS-3.4 | Identification des opérations les plus consommatrices (CU) | Top 10 mensuel |
| BI-OPS-3.5 | Suivi des tailles de modèles et de leur croissance | Tableau de suivi |
| BI-OPS-4.1 | SLO définis par rapport (fraîcheur, disponibilité) | Document |
| BI-OPS-4.2 | Runbooks pour les incidents types (échec de passerelle, jeton expiré, schéma modifié) | Runbooks testés |
| BI-OPS-4.3 | Revue d'incident (cause racine, action corrective) | Comptes rendus |
| BI-OPS-4.4 | Astreinte ou plage de support claire | Planning |
| BI-OPS-4.5 | Procédure de dépassement de capacité (priorisation, report, montée de capacité) | Procédure |
| BI-OPS-5.1 | Alertes sur tendance (croissance d'usage, dégradation lente) | Alertes tracées |
| BI-OPS-5.2 | Dimensionnement planifié et revu chaque trimestre | Compte rendu |
| BI-OPS-5.3 | Capacité adaptée automatiquement ou par script (pause/reprise, redimensionnement planifié) | Automatisation |
| BI-OPS-5.4 | Exercices de panne (restauration, bascule) | Rapport d'exercice |
5. Lecture détaillée par niveau#
🟢 Niveau 1 — Aveugle#
- Signes : « ça n'a pas rafraîchi ce matin », le mail arrive de la direction commerciale.
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Alertes d'échec#
- Signes : notifications envoyées à un groupe ; l'historique est lu quand il y a un doute. Les rafraîchissements sont planifiés hors heures de pointe.
- Gain : MTTD réduit de plusieurs heures à moins d'une heure.
- Limite : un rafraîchissement réussi peut quand même charger des données incomplètes (la source n'a pas fini) : l'alerte d'échec ne détecte pas le faux succès (TST).
- Difficulté : 2/5 · Effort : 2/5.
Symptôme : succès du rafraîchissement mais chiffres de la veille. Cause : traitement amont (datamart) non terminé ou rejoué ; le rafraîchissement du modèle a lu un état partiel. Remède : conditionner le déclenchement à la fin du traitement amont (rafraîchissement déclenché par API en fin de chaîne), et afficher la date de dernière donnée.
🟡 Niveau 3 — Tableau de bord#
- Signes : un rapport d'exploitation (modèle sur les journaux d'activité, l'historique de rafraîchissement, Capacity Metrics) répond aux questions : combien de rafraîchissements ont échoué cette semaine ? Quels modèles consomment le plus ? Quelles heures saturent ?
// Exemple (Log Analytics, si les journaux du service y sont envoyés — à vérifier selon configuration)
PowerBIDatasetsWorkspace
| where OperationName == "QueryEnd"
| summarize P95_ms = percentile(DurationMs, 95), Nb = count() by ArtifactName, bin(TimeGenerated, 1h)
| order by P95_ms desc
- Gain : décisions fondées sur des chiffres.
- Limite : réactif plus que proactif.
- Difficulté : 3/5 · Effort : 3/5.
Dans Capacity Metrics, distingue les opérations interactives (requêtes de visuels, lissées sur 5 minutes au minimum, jusqu'à 64 minutes selon la consommation) des opérations d'arrière-plan (rafraîchissements, lissées sur 24 h) : un rafraîchissement lourd la nuit pèse sur la capacité du jour suivant (lissage).
🟡 Niveau 4 — SLO et runbooks#
- Signes : « le rapport des ventes est frais à 7 h 00 en semaine, 99 % des jours ouvrés » ; le runbook dit quoi faire si la passerelle ne répond plus ou si le jeton d'une source expire. Après incident, on rédige une revue sans blâme.
- Gain : engagement clair, résolution plus rapide.
- Limite : SLO trop ambitieux sans moyens = SLO ignoré.
- Difficulté : 4/5 · Effort : 4/5.
Fil rouge SFA : la fraîcheur dépend d'une chaîne en quatre maillons (application terrain → synchronisation → datamart → modèle). Le SLO « 7 h 00 » est la somme des délais de chaque maillon ; on affiche l'horodatage de la dernière synchronisation terrain, pas seulement celui du modèle.
🔴 Niveau 5 — Anticipé#
- Signes : alertes de tendance (croissance d'usage de +30 % en trois mois), dimensionnement revu à chaque trimestre, pause/reprise ou redimensionnement planifié de la capacité (capacités Fabric F ; ex. réduction de nuit/week-end quand le modèle économique le permet), exercices de panne.
- Gain : pas de surprise de capacité, coût mieux ajusté (CST).
- Limite : l'automatisation de capacité demande une compréhension fine du lissage et de la facturation ; une pause de capacité rend les contenus indisponibles.
- Difficulté : 5/5 · Effort : 5/5.
Sépare, si le budget le permet, les charges interactives critiques (rapports de direction) des charges lourdes de traitement (rafraîchissements massifs) sur des capacités différentes ou des fenêtres distinctes.
L'IA aide à lire des journaux, à résumer un incident et à proposer un runbook ; elle ne décide pas d'un redimensionnement coûteux et ne voit pas votre contrat de service.
6. Atteinte partielle et notation#
Règle commune. « Un 5 partiel » : alertes de tendance posées sur la capacité mais pas sur la performance par rapport (BI-OPS-5.1 = 0,5), revue trimestrielle effective (5.2 = 1), capacité manuelle (5.3 = 0), exercice de panne fait une fois (5.4 = 0,5).
7. Passer au niveau suivant#
Moyens possibles (facultatifs) :
| Passage | Leviers possibles |
|---|---|
| 1 → 2 | Alertes d'échec vers un groupe ; plan de charge |
| 2 → 3 | Capacity Metrics ; export des journaux d'activité ; rapport d'exploitation |
| 3 → 4 | SLO ; runbooks ; revues d'incident ; astreinte |
| 4 → 5 | Alertes de tendance ; scripts de capacité ; exercices de panne |
Pièges :
- Faux positif : 100 % de réussite des rafraîchissements avec des données vides.
- Goodhart : « MTTR court » obtenu en fermant les tickets sans cause racine.
- Alerte fatigue : trop de notifications → plus personne ne lit. Sélectionner, router, supprimer le bruit.
- Se fier à une seule mesure ponctuelle de capacité : les pics sont courts ; regarder la distribution.
8. Voir aussi#
- Thèmes voisins : PRF · ETL · IND · CST · GOV
- Autres matrices : DL — observabilité et fiabilité · DL — déploiement et exploitation · PD — exploitation et support
- Contenus : OneLake — architecture · OneLake — difficultés et pièges · SQL Server SaaS — architecture · Checklist de projet reporting
✻ Rédigé par Claude Sonnet 5.5