Pendant un incident, choisissez l’action la plus susceptible de rétablir le service avec un risque contrôlé.
Pendant un incident, choisissez l’action la plus susceptible de rétablir le service avec un risque contrôlé. Le retour arrière réintroduit une version, mais ne restaure pas forcément les données. Le correctif urgent modifie la version actuelle et demande une cause suffisamment établie.
Vérifier les frontières de changement
Comparez l’apparition du problème aux publications, configurations, migrations et prestataires. La version précédente peut-elle lire et écrire les données actuelles ? Une migration destructive ou une opération externe irréversible peut empêcher un retour simple. Préservez les preuves tout en limitant le dommage en cours.
Comparer les moyens de reprise
Envisagez désactivation d’une fonction, routage ou réduction de charge en plus du code. Comparez temps d’exécution et de vérification, étendue, réversibilité et coût d’une erreur. Un correctif doit cibler une cause étroite et vérifiable. Les corrections de données et migrations sont des actions contrôlées distinctes, pas des effets cachés d’un déploiement.
Agir de façon coordonnée
Nommez un exécutant et annoncez résultat attendu et critères de succès. Évitez les modifications simultanées dont les effets deviennent indissociables. Utilisez le circuit de livraison établi et gardez une trace. Vérifiez ensuite parcours clients, files et intégrité des données. Un processus vert ne prouve pas la reprise du travail perdu ; clôturez après stabilité convenue et attribution des actions restantes.
Un exemple à vérifier
Une nouvelle version peut écrire des données obligatoires inconnues de l’ancienne. Même avec l’image précédente disponible, revenir peut aggraver la panne. Vérifiez la compatibilité sur les données actuelles et l’éventuelle limitation du parcours par un interrupteur de fonctionnalité. Un correctif étroit peut alors être préférable. Avant exécution, consignez action, signal attendu et condition d’arrêt pour préserver une décision coordonnée malgré l’urgence.
- Service associé
- Reprise après sinistre : tester RTO et RPO
- Un runbook de production utilisable par une petite équipe
Questions fréquentes
Le retour arrière est-il toujours plus rapide ?
Non. Compatibilité et données peuvent le rendre lent ou dangereux.
Peut-on annuler une migration ?
Seulement avec un chemin inverse valide et testé sur les données présentes.
Quand choisir un correctif urgent ?
Quand sa cause est étroite, prouvée et moins risquée que les alternatives.
Plusieurs équipes peuvent-elles agir ensemble ?
Oui avec coordination explicite évitant les changements contradictoires.
Quand clôturer l’incident ?
Après vérifications de service et de données et prise en charge des suites.
Transformons votre besoin en périmètre réalisable
Partagez le parcours utilisateur, les intégrations et les contraintes de lancement. Nous pouvons préparer une estimation avec hypothèses et exclusions.
Pour aller plus loin
Reprise après sinistre : tester RTO et RPO
Un plan de reprise devient crédible lorsqu’un service utilisable peut être restauré.
Un runbook de production utilisable par une petite équipe
Un runbook aide à passer d’un symptôme précis à une décision sûre.
Niveaux de gravité des incidents : une matrice d’escalade
La gravité décrit l’impact métier actuel ou crédible, pas le ton d’un message de journal.