OPS06-BP01 Planifier les modifications infructueuses - AWS Well-Architected Framework

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 des résultats indésirables. 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 politiques, citons les étapes de déploiement et de restauration, les politiques de changement, les indicateurs de fonction, 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 souhaité : 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 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 liés au respect de cette bonne pratique : Disposer d'un plan de reprise en cas de modifications infructueuses permet de minimiser le temps moyen de récupération (MTTR) et de réduire l'impact sur votre entreprise.

Niveau de risque exposé si cette bonne pratique n'est pas respectée : Élevé

Directives d'implémentation

Une politique 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

  1. Documentez les politiques qui exigent des équipes qu'elles disposent de plans efficaces pour restaurer les modifications dans un délai donné.

    1. Les politiques doivent préciser les cas où une situation de correction à l'avance est autorisée.

    2. Exigez qu'un plan de restauration documenté soit accessible à toutes les personnes concernées.

    3. Précisez les conditions de restauration (par exemple, lorsqu'il s'avère que des modifications non autorisées ont été déployées).

  2. Analysez le niveau d'impact de toutes les modifications liées à chaque composante d'une charge de travail.

    1. 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.

    2. 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.

    3. 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.

  3. Intégrez des outils et des flux de travail pour appliquer vos politiques de manière programmée.

  4. 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.

    1. 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.

  5. 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.

  6. 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 :