Sommaire de la documentation
Modules
Protection des données
Infrastructure
Gestion des incidents
Comment Solentra gère les incidents de service et les problèmes techniques.
Processus de gestion des incidents
La gestion des incidents suit un processus structuré en phases clairement définies :
- 1. Détection, Identification par la surveillance automatique, signalement utilisateur ou surveillance manuelle
- 2. Qualification, Classification de la sévérité, évaluation de l'impact, désignation d'un responsable
- 3. Diagnostic, Analyse de la cause, identification des composants affectés
- 4. Résolution, Mise en place d'un contournement temporaire puis d'un correctif définitif
- 5. Vérification, Confirmation que le service est restauré et fonctionne normalement
- 6. Post-mortem, Analyse des causes racines, actions préventives, documentation
Classification des incidents
| Sévérité | Critères | Exemples | Réponse |
|---|---|---|---|
| Critique (S1) | Service inaccessible pour tous les utilisateurs | Panne complète, perte de données | Mobilisation immédiate, communication toutes les 30 min |
| Majeur (S2) | Fonctionnalité clé indisponible | Module inaccessible, lenteurs sévères | Traitement prioritaire, communication horaire |
| Mineur (S3) | Dégradation limitée avec contournement | Erreur intermittente, lenteur modérée | Traitement normal, communication au besoin |
| Informatif (S4) | Anomalie sans impact utilisateur | Erreur dans les logs, alerte préventive | Planification dans le prochain sprint |
Communication pendant les incidents
La communication est un élément central de la gestion des incidents :
- Notification initiale dans les 15 minutes suivant la détection pour les incidents S1 et S2
- Mises à jour régulières sur la page de statut et par courriel
- Fréquence de mise à jour : toutes les 30 minutes (S1), toutes les heures (S2), au besoin (S3-S4)
- Notification de résolution avec résumé de l'impact et des actions entreprises
- Communication proactive même en l'absence de nouvelles informations (pour rassurer les utilisateurs)
Rapport post-incident
Un rapport post-incident détaillé est produit pour chaque incident de sévérité S1 ou S2 :
- Chronologie complète de l'incident, détection, diagnostic, résolution
- Analyse de la cause racine (Root Cause Analysis)
- Impact mesuré, durée, nombre d'utilisateurs affectés, données impactées
- Actions correctives mises en place pour éviter la récurrence
- Mesures préventives planifiées pour renforcer la résilience