

- Description
- Bouée de sauvetage suspendue à un portique de corde dans un musée de sauvetage en mer : le secours prêt à servir
- Source
- Alf van Beem · page d’origine
- Licence
- CC0 Domaine public
Exploitation et support
Une fois livré, un produit de données entre dans sa vie la plus longue : chaque nuit, un chargement doit réussir ; chaque matin, des utilisateurs attendent des chiffres frais. Les pannes de…
Niveau : 🟢→🔴 · Code thème : EXP
Pourquoi ce thème#
Une fois livré, un produit de données entre dans sa vie la plus longue : chaque nuit, un chargement doit réussir ; chaque matin, des utilisateurs attendent des chiffres frais. Les pannes de données ont une propriété désagréable : elles sont souvent silencieuses (le traitement réussit, mais avec des données partielles ou périmées). Une exploitation immature se voit à l'heure du premier appel : si c'est l'utilisateur qui prévient l'équipe, c'est que la supervision a échoué. Ce thème traite de la supervision des données (pas de la disponibilité du serveur seulement), de la gestion des incidents, du support et de la continuité. Il complète la matrice DL — observabilité et fiabilité et la matrice BI — exploitation, supervision et capacité, côté rapport. Ici, l'angle est le service de données tenu.
Ce que mesure le thème#
- Axe : de l'intervention à la demande à l'amélioration continue pilotée par les problèmes récurrents.
- Indicateur clé : part des incidents de données détectés avant l'utilisateur et respect des SLA de données (fraîcheur, disponibilité, délai de résolution).
- Unité : % d'incidents détectés en interne ; % de jours où la fraîcheur est tenue ; délai moyen de détection, de résolution ; nombre d'incidents récurrents.
Les cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Pompier | Quand une panne est signalée, quelqu'un la traite ; le délai dépend des personnes. | Détection par les utilisateurs ; résolution en jours |
| 2 | Supervisé | L'échec d'un chargement est visible le matin par l'équipe, qui prévient les utilisateurs. | Statut des traitements consulté chaque jour |
| 3 | Organisé | Les incidents sont catégorisés, priorisés et traités selon des délais cibles ; les procédures d'exploitation sont écrites. | Délai de résolution cible par priorité ; support avec file |
| 4 | Engagé | Les SLA de données sont mesurés et tenus ; les alertes précèdent la plainte ; chaque incident majeur a un bilan et des actions. | ≥ 90 % d'incidents détectés en interne ; fraîcheur tenue ≥ 95 % des jours |
| 5 | Auto-réparant | Les pannes courantes se réparent seules ; les problèmes récurrents sont éliminés ; la capacité est anticipée. | Récurrences proches de 0 ; interventions manuelles rares |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| PD-EXP-1.1 | Les traitements planifiés sont listés avec leur horaire et leur propriétaire. | Calendrier d'exploitation. |
| PD-EXP-1.2 | Un journal de traitement consigne début, fin, statut et erreurs. | Table ou fichier journal consultable. |
| PD-EXP-1.3 | Un point d'entrée unique reçoit les demandes de support. | Boîte ou outil de tickets. |
| PD-EXP-1.4 | Une sauvegarde régulière est en place. | Historique de sauvegardes. |
| PD-EXP-2.1 | L'échec d'un traitement déclenche une notification à l'équipe. | Test : un échec simulé génère un message. |
| PD-EXP-2.2 | Chaque matin, l'état des chargements est vérifié (par une personne ou un tableau). | Trace de vérification quotidienne. |
| PD-EXP-2.3 | Les utilisateurs sont prévenus quand les données sont en retard. | Message ou bandeau de fraîcheur dans le rapport. |
| PD-EXP-2.4 | La date de dernière actualisation est visible dans chaque rapport. | Indicateur de fraîcheur présent. |
| PD-EXP-3.1 | Les incidents sont catégorisés (échec de chargement, donnée incorrecte, accès, performance) et priorisés. | Grille de priorités et tickets classés. |
| PD-EXP-3.2 | Des délais cibles de traitement existent par priorité. | Document de SLA de support et statistiques de respect. |
| PD-EXP-3.3 | Des procédures d'exploitation écrites (relance, reprise, rejeu) sont utilisables par un tiers. | Procédure exécutée par un non-auteur sans aide. |
| PD-EXP-3.4 | Un astreinte ou une permanence est définie pour les traitements critiques. | Planning d'astreinte, ou règle de reprise écrite. |
| PD-EXP-4.1 | Les SLA de données (fraîcheur, complétude) sont mesurés automatiquement et publiés (QUA). | Tableau de conformité aux SLA sur ≥ 3 mois. |
| PD-EXP-4.2 | Les alertes proactives (volume anormal, retard, dérive) précèdent la plainte. | Cas où l'alerte est partie avant l'utilisateur. |
| PD-EXP-4.3 | Chaque incident majeur donne lieu à un bilan sans blâme avec actions suivies. | Comptes rendus et statut des actions. |
| PD-EXP-4.4 | La reprise après sinistre (restauration complète) a été jouée. | Exercice de restauration avec durée mesurée. |
| PD-EXP-5.1 | Les pannes courantes déclenchent une reprise automatique sûre (relance, rejeu). | Reprises automatiques tracées sans intervention. |
| PD-EXP-5.2 | Les problèmes récurrents sont supprimés à la cause, pas seulement traités. | Tendance du nombre d'incidents par cause. |
| PD-EXP-5.3 | La capacité (volumes, fenêtre de chargement) est anticipée et planifiée. | Prévision de la fenêtre de chargement à 12 mois. |
| PD-EXP-5.4 | Le temps d'intervention manuelle par produit est mesuré et diminue. | Mesure suivie sur ≥ 3 trimestres. |
Lecture détaillée par niveau#
🟢 Niveau 1 — Pompier#
- Signes : « les chiffres ne sont pas à jour » arrive à 9 h ; on cherche l'erreur dans des journaux illisibles ; les reprises sont improvisées.
- Gain : réactivité héroïque.
- Ne garantit pas : la durée de la prochaine panne ni la dépendance à une personne.
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Supervisé#
- Signes : une alerte à l'échec ; un bandeau « données à jour au… » ; les utilisateurs sont prévenus par l'équipe avant leur journée.
- Gain : les pannes visibles cessent d'être des surprises.
- Ne garantit pas : la détection des pannes silencieuses (traitement réussi, données partielles).
- Difficulté : 2/5 · Effort : 2/5.
🟡 Niveau 3 — Organisé#
- Signes : tickets catégorisés ; procédures utilisables par un tiers ; délais cibles par priorité ; permanence définie.
- Gain : le service survit aux absences ; les utilisateurs savent quoi attendre.
- Ne garantit pas : que les délais soient respectés ni que l'on prévienne les pannes.
- Difficulté : 3/5 · Effort : 3/5.
🟡 Niveau 4 — Engagé#
- Signes : SLA de fraîcheur mesurés ; alertes de volume ; bilans sans blâme ; restauration jouée.
- Gain : une exploitation qui se prouve et progresse.
- Ne garantit pas : l'élimination des causes (on gère bien les pannes, mais elles reviennent).
- Difficulté : 4/5 · Effort : 4/5.
-- Contrôle de fraîcheur et de volume après chargement (T-SQL) : détecte la panne « silencieuse »
SELECT 'Releve' AS Objet,
MAX([date]) AS DerniereDate,
COUNT(*) AS NbLignesJour,
CASE WHEN MAX([date]) < CAST(GETDATE() AS date) THEN 'RETARD'
WHEN COUNT(*) < 0.5 * (SELECT AVG(N) FROM [exp].[VolumeJ7]) THEN 'VOLUME_ANORMAL'
ELSE 'OK' END AS Statut
FROM [fact].[Releve] WITH (NOLOCK)
WHERE [date] = CAST(GETDATE() AS date); -- sur un chargement de nuit, ajustez la date de référence
Une nuit, le chargement des relevés « réussit » mais l'application source était en maintenance : 6 % du volume habituel, donc des totaux faux le matin. Niveau 2 : aucune alerte (le traitement est vert). Niveau 4 : la règle « volume < 50 % de la moyenne des 7 derniers jours » bloque la publication et notifie l'équipe à 6 h 10, qui prévient les utilisateurs avant 8 h. Le coût du niveau 4 : une requête et une table de volumes de référence.
🔴 Niveau 5 — Auto-réparant#
- Signes : les reprises sûres se font seules ; chaque cause récurrente est supprimée ; la fenêtre de chargement est planifiée à 12 mois.
- Gain : une charge d'astreinte réduite ; une équipe qui construit plutôt que de réparer.
- Ne garantit pas : l'absence d'incident rare et complexe ; l'automatisation peut aussi masquer un problème sous-jacent (relancer sans comprendre).
- Difficulté : 5/5 · Effort : 5/5.
Atteinte partielle et notation#
Évaluez sur les trois derniers mois d'incidents : un jalon vaut 1 si la pratique s'est appliquée à tous, 0,5 à la majorité, 0 sinon. Pour PD-EXP-4.2, comptez les incidents réels où l'alerte a précédé la plainte, sur un registre (QUA PD-QUA-1.1).
Un « 5 partiel » : trois reprises automatiques fonctionnent (5.1 à 0,5), les incidents récurrents ont été réduits de moitié (5.2 à 0,5), la capacité est suivie sans prévision (5.3 à 0,5), le temps manuel n'est pas mesuré (5.4 à 0).
La supervision de l'infrastructure sans la donnée : le serveur est vert, le traitement est vert, les chiffres sont faux. Remède : superviser la fraîcheur, le volume et la distribution, c'est-à-dire des propriétés de la donnée.
La relance qui masque : relancer jusqu'à ce que ça passe sans chercher la cause. Symptôme : un incident « résolu » trois fois par semaine. Remède : compter les relances comme des incidents et exiger une cause.
Passer au niveau suivant#
Moyens possibles (facultatifs)
| Passage | Leviers possibles |
|---|---|
| 1 → 2 | Un journal de traitement unique ; une notification à l'échec ; un indicateur de fraîcheur dans les rapports. |
| 2 → 3 | Une grille de priorités ; des procédures testées par un tiers ; un planning de permanence. |
| 3 → 4 | Contrôles de volume et de fraîcheur ; bilans sans blâme ; exercice de restauration (voir DOP). |
| 4 → 5 | Reprises idempotentes automatiques ; revue mensuelle des causes récurrentes ; prévision de capacité. |
Pièges transverses : (1) Faux positif — SLA tenu sur un périmètre trop étroit (un seul traitement) ; vérifiez la couverture. (2) Goodhart — viser « zéro incident » conduit à ne plus les déclarer ; mesurez la détection, pas le nombre. (3) Héros — une exploitation reposant sur une personne n'a pas dépassé le niveau 1, quelle que soit sa qualité.
Utile pour résumer un journal d'erreurs, proposer un diagnostic, rédiger un bilan d'incident, détecter des anomalies de volume. Garde-fous : l'IA ne modifie pas la production sans validation ; ses diagnostics sont des hypothèses ; ne lui transmettez pas de données personnelles issues des journaux (SEC).
Voir aussi#
- Même matrice : 03 Qualité · 06 DataOps · 11 Coût et valeur · 12 Métadonnées · README
- Autres matrices : DL — déploiement et exploitation · DL — observabilité et fiabilité · BI — exploitation, supervision et capacité · PI — livraison et mise en production
- Pratique : CI/CD pour la data · SQL Server SaaS — difficultés · OneLake — difficultés · métriques et reporting de projet
- Glossaire · Notation
✻ Rédigé par Claude Sonnet 5.5