Résolution et restauration¶
Diagnostiquer methodiquement, mitiger l'impact et restaurer le service de façon controlee.
Diagnostic methodique¶
Le diagnostic est la phase la plus consommatrice de temps. Une méthode structurée evite de tourner en rond.
Principes du diagnostic¶
- Éliminer avant d'affirmer : posez des hypothèses et invalidez-les, ne partez pas directement en correction
- Commencer par les changements récents : 80 % des incidents P1/P2 sont liés à un déploiement ou une modification de configuration dans les 2 heures précédentes
- Correlater les signaux : rapprochez les métriques, les logs et les traces pour circonscrire la zone d'impact
- Isoler le périmètre : une region ? un pod ? un batch spécifique ?
Arbre de décision diagnostic¶
flowchart TD
A([Symptome confirme]) --> B{Changement recent ?}
B -- Oui --> C[Tester rollback ou revert]
B -- Non --> D{Ressources systeme saturees ?}
C --> E{Probleme resolu ?}
E -- Oui --> F[Mitigation par rollback]
E -- Non --> D
D -- Oui --> G[Scale out / redemarrage]
D -- Non --> H{Dependance externe ?}
H -- Oui --> I[Verifier SLA fournisseur / fallback]
H -- Non --> J[Analyse logs / traces approfondies]Mitigation vs correction definitive¶
Il est essentiel de distinguer les deux actions pour ne pas confondre vitesse et pérennité.
| Action | Objectif | Effet | Exemple |
|---|---|---|---|
| Mitigation | Réduire l'impact immédiatement | Service partiellement ou totalement restaure, cause non éliminée | Rollback de déploiement, redémarrage de service |
| Fix temporaire | Contourner la cause le temps de préparer un correctif | Service stable, dette technique créée | Feature flag désactivé, quota augmente |
| Correction definitive | Éliminer la cause racine | Service stable, cause éliminée | Patch applicatif, refactoring |
Lors d'un incident, la priorité est la mitigation. La correction definitive peut attendre que le service soit stable.
Modalites de restauration¶
| Technique | Quand l'utiliser | Risques |
|---|---|---|
| Rollback applicatif | Régression introduite par un déploiement récent | Perte des migrations DB non réversibles |
| Failover | Composant primaire defaillant avec un secondaire disponible | Desynchronisation possible, cold start |
| Redémarrage | Leak mémoire, état corrompu, connexion bloquee | Perte de sessions en cours |
| Contournement (workaround) | Fonctionnalité secondaire, fix rapide possible | Dette technique, oubli du fix definitif |
| Scaling horizontal | Surchargé ponctuelle de charge | Coût, ne résout pas une régression logique |
Critères de clôture¶
Un incident ne peut être clos que lorsque les critères suivants sont satisfaits :
- Le service est restaure a son état nominal (métriques dans les seuils normaux)
- Les utilisateurs impactes ont été notifies
- La statuspage a été mise à jour
- La cause provisoire est documentee dans le ticket d'incident
- Les actions de suivi (fix definitif, post-mortem) sont planifiees
Ne jamais clôturer un P1 sans monitoring renforce
Après la restauration d'un P1, maintenez un monitoring renforce pendant au minimum 24 heures. Les incidents complexes ont tendance a rechuter : un composant stabilise peut cacher un problème sous-jacent qui se manifeste à la prochaine montee en charge. Gardez la war room ouverte en mode "surveillance" jusqu'à confirmation de la stabilité.
Documentation de clôture¶
À la clôture, le ticket d'incident doit contenir :
- Heure de début et de fin
- Sévérité finale (elle peut avoir change en cours d'incident)
- Périmètre réel (utilisateurs touches, services impactes)
- Actions de mitigation appliquees
- Cause provisoire (sera confirmee par le post-mortem)
- Lien vers la timeline war room