Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
OPS06-BP01 Planifier les modifications infructueuses
Prévoyez de revenir à un état correct connu ou de remédier à la situation dans l’environnement de production si le déploiement entraîne un résultat indésirable. L’existence d’une politique visant à établir un tel plan aide toutes les équipes à développer des stratégies de récupération en cas d’échec des modifications. Parmi les exemples de stratégies, citons les étapes de déploiement et de restauration, les stratégies de changement, les indicateurs de fonctionnalité, l’isolation du trafic et le déplacement du trafic. Une seule version peut inclure plusieurs modifications de composants connexes. La stratégie doit permettre de résister ou de se remettre d’une défaillance de tout changement de composant.
Résultat escompté : vous avez préparé un plan de reprise détaillé pour votre modification en cas d’échec. En outre, vous avez réduit la taille de votre version afin de minimiser l’impact potentiel sur d’autres composants de la charge de travail. Vous avez ainsi réduit l’impact sur l’entreprise en diminuant le temps d’arrêt potentiel causé par une modification ratée et en augmentant la flexibilité et l’efficacité des temps de récupération.
Anti-modèles courants :
-
Vous avez effectué un déploiement et votre application est devenue instable, mais il semble qu’il y ait des utilisateurs actifs sur le système. Vous devez décider entre annuler la modification et avoir un impact sur les utilisateurs actifs et attendre pour annuler la modification en sachant que les utilisateurs peuvent être impactés de toute façon.
-
Après avoir modifié la routine, vos nouveaux environnements sont accessibles, mais l’un de vos sous-réseaux est devenu inaccessible. Vous devez décider de tout annuler ou d’essayer de réparer le sous-réseau inaccessible. Pendant cette période de détermination, le sous-réseau reste inaccessible.
-
Vos systèmes ne sont pas conçus de manière à pouvoir être mis à jour avec de plus petites versions. Par conséquent, il est difficile d’annuler ces modifications en bloc en cas d’échec du déploiement.
-
Vous n’utilisez pas l’infrastructure en tant que code (IaC) et vous avez effectué des mises à jour manuelles de votre infrastructure, ce qui a entraîné une configuration indésirable. Vous n’êtes pas en mesure de suivre et d’annuler efficacement les modifications manuelles.
-
Parce que vous n’avez pas mesuré l’augmentation de la fréquence de vos déploiements, votre équipe n’est pas incitée à réduire la taille de ses changements et à améliorer ses plans de restauration pour chaque modification, ce qui entraîne une augmentation des risques et des taux d’échec.
-
Vous ne mesurez pas la durée totale d’une panne causée par des modifications infructueuses. Votre équipe n’est pas en mesure d’établir des priorités et d’améliorer l’efficacité de son processus de déploiement et de son plan de reprise.
Avantages de la mise en place de cette meilleure pratique : le fait de disposer d'un plan de reprise après des modifications infructueuses permet de minimiser le temps moyen de restauration (MTTR) et de réduire l'impact sur votre entreprise.
Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé
Directives d’implémentation
Une stratégie et une pratique cohérentes et documentées, adoptées par les équipes de publication des versions, permettent à une organisation de planifier ce qui doit se passer en cas d’échec des modifications. La politique devrait permettre la correction à l’avance dans des circonstances spécifiques. Dans les deux cas, un plan de correction à l’avance ou de restauration doit être bien documenté et testé avant d’être déployé dans la production réelle, afin de réduire au minimum la durée nécessaire pour restaurer une modification.
Étapes d’implémentation
-
Documentez les stratégies qui exigent des équipes qu’elles disposent de plans efficaces pour restaurer les modifications dans un délai donné.
-
Les stratégies doivent préciser les cas où une situation de correction à l’avance est autorisée.
-
Exigez qu’un plan de restauration documenté soit accessible à toutes les personnes concernées.
-
Précisez les conditions de restauration (par exemple, lorsqu’il s’avère que des modifications non autorisées ont été déployées).
-
-
Analysez le niveau d’impact de toutes les modifications liées à chaque composante d’une charge de travail.
-
Autorisez les modifications répétitives à être normalisées, modélisées et préautorisées si elles suivent un flux de travail cohérent qui applique les politiques de modification.
-
Réduisez l’impact potentiel de toute modification en en réduisant la taille, de sorte que la reprise prenne moins de temps et ait moins d’impact sur l’entreprise.
-
Veillez à ce que les procédures de restauration ramènent le code à l’état correct connu afin d’éviter les incidents dans la mesure du possible.
-
-
Intégrez des outils et des flux de travail pour appliquer vos politiques de manière programmée.
-
Faites en sorte que les données relatives aux modifications soient visibles pour les autres propriétaires de charges de travail afin d’améliorer la rapidité du diagnostic en cas de modification défaillante impossible à annuler.
-
Mesurez le degré de réussite de cette pratique à l’aide de données sur les modifications visibles et identifiez les améliorations itératives.
-
-
Utilisez des outils de surveillance pour vérifier le succès ou l’échec d’un déploiement afin d’accélérer la prise de décision concernant la restauration.
-
Mesurez la durée de l’interruption lors d’un changement infructueux afin d’améliorer continuellement vos plans de reprise.
Niveau d’effort du plan d’implémentation : moyen
Ressources
Bonnes pratiques associées :
Documents connexes :
Vidéos connexes :
