clement13.net
Photo d’origine : Bouée de sauvetage suspendue à un portique de corde dans un musée de sauvetage en mer : le secours prêt à servir
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
Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

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…

Guide≈ 8 min de lectureVérifiéContrôle effectuéLes faits, chiffres et références ont été contrôlés au regard des sources citées dans la fiche.Rédaction assistée par IA ; sources citées en bas de page. Une erreur ? Signalez-la via le site clement13.net.Lecture

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
🧪 Exemple

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).

⚠️ Piège

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.

⚠️ Piège

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é.

🤖 IA

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#

✻ Rédigé par Claude Sonnet 5.5