Operations Incidents¶
La gestion des incidents regroupe l'ensemble des procédures permettant de détecter, qualifier, analyser, résoudre et documenter les événements susceptibles d'affecter le fonctionnement de CMonChoix Platform.
Un incident ne correspond pas nécessairement à une erreur logicielle.
Il peut également résulter :
- d'une dégradation des performances ;
- d'une incohérence des données ;
- d'une interruption de traitement ;
- d'une indisponibilité d'un composant ;
- d'une évolution inattendue du comportement de la Platform.
La gestion des incidents vise à restaurer un fonctionnement normal tout en préservant la traçabilité complète des événements.
Objectifs¶
La gestion des incidents poursuit plusieurs objectifs.
- rétablir rapidement un fonctionnement normal ;
- limiter l'impact sur les utilisateurs ;
- identifier la cause réelle ;
- éviter les corrections temporaires inutiles ;
- capitaliser sur chaque incident afin d'améliorer durablement la Platform.
Principes¶
La gestion des incidents repose sur plusieurs principes.
Corriger la cause¶
L'objectif n'est jamais de masquer un symptôme.
Une correction durable agit toujours sur l'origine du problème.
Préserver les données¶
Une intervention ne doit jamais compromettre :
- la cohérence des données ;
- la traçabilité des traitements ;
- la reproductibilité des analyses.
Procéder méthodiquement¶
Chaque incident suit le même processus d'analyse.
Cette méthode garantit des interventions reproductibles.
Documenter systématiquement¶
Chaque incident important enrichit la connaissance opérationnelle de la Platform.
La documentation permet d'éviter la répétition des mêmes erreurs.
Cycle de gestion¶
Le traitement d'un incident suit toujours les mêmes étapes.
Détection
│
▼
Qualification
│
▼
Analyse
│
▼
Correction
│
▼
Validation
│
▼
Documentation
Chaque étape possède une responsabilité clairement définie.
Détection¶
Un incident peut être détecté de plusieurs manières.
Par exemple :
- une alerte de monitoring ;
- une anomalie observée par un opérateur ;
- une régression fonctionnelle ;
- un échec de traitement ;
- une incohérence détectée lors d'un audit.
La détection ne constitue pas encore une analyse.
Elle identifie simplement une situation inhabituelle.
Qualification¶
L'incident est ensuite qualifié.
L'objectif consiste à déterminer :
- le composant concerné ;
- le périmètre impacté ;
- le niveau de criticité ;
- les conséquences possibles.
Cette étape permet de prioriser les interventions.
Analyse¶
L'analyse vise à identifier la cause réelle.
Plusieurs éléments peuvent être examinés.
Pipeline¶
Le traitement s'est-il déroulé normalement ?
Database¶
Les données sont-elles cohérentes ?
Runtime¶
Les traitements d'exécution présentent-ils une anomalie ?
Frontend¶
Le problème concerne-t-il uniquement la présentation ?
Historique¶
Une évolution récente peut-elle expliquer le comportement observé ?
Correction¶
Une fois la cause identifiée, la correction est appliquée.
La correction privilégie toujours :
- les traitements officiels ;
- les mécanismes de reconstruction ;
- les procédures documentées.
Une modification directe des données finales doit rester exceptionnelle.
Validation¶
Après la correction, plusieurs contrôles sont réalisés.
Ils permettent notamment de confirmer :
- la disparition du problème ;
- la stabilité des traitements ;
- la cohérence des projections ;
- l'absence de régression.
Une correction n'est considérée comme terminée qu'après validation.
Documentation¶
Chaque incident significatif doit être documenté.
La documentation précise notamment :
- la date ;
- le contexte ;
- les symptômes ;
- la cause identifiée ;
- les actions réalisées ;
- les validations effectuées ;
- les enseignements retenus.
Cette documentation contribue à l'amélioration continue de la Platform.
Classification¶
Les incidents peuvent être classés selon leur impact.
Incident mineur¶
Le fonctionnement général de la Platform reste assuré.
L'impact est limité.
Incident majeur¶
Une fonctionnalité importante est affectée.
Une intervention rapide est nécessaire.
Incident critique¶
Le fonctionnement global de la Platform est compromis.
La priorité devient le rétablissement du service dans les meilleurs délais.
Dépendances¶
La gestion des incidents peut mobiliser plusieurs composants.
- Monitoring
- Pipeline
- Database
- Runtime
- Read Services
- Write Services
- outils d'exploitation
Chaque composant apporte les informations nécessaires à l'analyse.
Invariants¶
La gestion des incidents respecte plusieurs propriétés.
Comprendre avant de corriger¶
Une intervention ne doit jamais être réalisée sans analyse préalable.
Corriger à la source¶
Les traitements responsables sont corrigés.
Les données dérivées sont ensuite reconstruites.
Préserver la traçabilité¶
Toutes les actions réalisées restent documentées.
Éviter les contournements permanents¶
Une solution temporaire ne doit pas devenir une solution définitive.
Garde-fous¶
Afin de préserver la stabilité de la Platform, plusieurs règles doivent toujours être respectées.
Ne jamais :
- corriger directement une projection sans identifier la cause ;
- modifier le Frontend pour masquer une incohérence métier ;
- ignorer une anomalie détectée par le monitoring ;
- supprimer des données utiles à l'analyse ;
- considérer un incident comme résolu sans validation complète.
Amélioration continue¶
Chaque incident constitue une opportunité d'améliorer la Platform.
L'analyse des incidents permet notamment :
- d'améliorer les procédures ;
- d'enrichir les outils de monitoring ;
- de renforcer les mécanismes de validation ;
- d'identifier les évolutions prioritaires.
L'objectif n'est pas uniquement de résoudre les incidents, mais également de réduire leur probabilité de réapparition.