Pratiques de déploiement sécurisé

Parfois, une version ne répond pas aux attentes. Malgré la mise en œuvre de bonnes pratiques et la réussite de tous les contrôles de qualité, il arrive parfois que des problèmes surviennent lors d’un déploiement en production, causant des problèmes inattendus pour les utilisateurs. Pour réduire au minimum l’impact de ces problèmes, il est recommandé que les équipes DevOps adoptent une stratégie d’exposition progressive qui équilibre l’exposition d’une version donnée avec sa performance prouvée. À mesure qu’une version se révèle efficace en production, elle devient disponible pour des publics de plus en plus larges jusqu’à ce que tout le monde l’utilise. Les équipes peuvent utiliser des pratiques de déploiement sécurisé pour maximiser la qualité et la rapidité des mises en production.

Contrôler l’exposition aux clients

Les équipes DevOps peuvent mettre en œuvre diverses pratiques pour contrôler l’exposition des mises à jour aux clients. Historiquement, les tests A/B ont été un choix populaire pour les équipes souhaitant voir comment différentes versions d’un service ou d’une interface utilisateur se comportent par rapport à des objectifs cibles. Les tests A/B sont également relativement faciles à utiliser car les changements sont généralement mineurs et ne comparent souvent que différentes versions à l’interface utilisateur visible par le client.

Déploiement sécurisé via des anneaux

À mesure que les plate-formes se développent, l’échelle de l’infrastructure et les besoins du public ont également tendance à augmenter. Cela crée une demande pour un modèle de déploiement qui équilibre les risques associés à un nouveau déploiement avec les avantages des mises à jour promises. L’idée générale est qu’une version donnée doit d’abord être exposée uniquement à un petit groupe d’utilisateurs ayant une tolérance au risque élevée. Ensuite, si la version fonctionne comme prévu, elle peut être élargie à un groupe plus large d’utilisateurs. S’il n’y a aucun problème, le processus peut se poursuivre avec des groupes encore plus larges d’utilisateurs, ou anneaux, jusqu’à ce que tout le monde utilise la nouvelle version. Avec des plates-formes de livraison continue modernes comme GitHub Actions et Azure Pipelines, la création d’un processus de déploiement en anneaux est accessible aux équipes DevOps de toutes tailles.

Indicateurs de fonctionnalités

Certaines fonctionnalités doivent parfois être déployées dans le cadre d’une version, mais pas initialement exposées aux utilisateurs. Dans ces cas, les indicateurs de fonctionnalités offrent une solution où la fonctionnalité peut être activée via des modifications de configuration basées sur l’environnement, l’anneau ou tout autre déploiement spécifique.

Opt-in de l’utilisateur

Similaire aux indicateurs de fonctionnalités, l’opt-in utilisateur offre un moyen de limiter l’exposition. Dans ce modèle, une fonction donnée est activée dans la version, mais n’est pas activée pour un utilisateur à moins qu’il ne le souhaite spécifiquement. La décision de tolérance au risque est déléguée aux utilisateurs afin qu’ils puissent décider à quelle vitesse ils veulent adopter certaines mises à jour.

En général, plusieurs pratiques sont utilisées simultanément. Par exemple, une équipe peut avoir une fonctionnalité expérimentale destinée à un cas d’utilisation très spécifique. Puisqu’il s’agit d’un risque, elle ne sera déployée que dans le premier anneau pour que les utilisateurs internes puissent l’essayer. Cependant, même si les fonctionnalités sont dans le code, quelqu’un devra définir l’indicateur de fonctionnalité pour un déploiement spécifique dans l’anneau de manière à ce que la fonctionnalité soit exposée via l’interface utilisateur. Et là encore, l’indicateur de fonctionnalité peut seulement exposer l’option pour un utilisateur de choisir d’utiliser la nouvelle fonctionnalité. Toute personne qui n’est pas dans l’anneau sur ce déploiement ou qui n’a pas opté pour l’option ne sera pas exposée à la fonctionnalité. Bien que cet exemple soit un peu tiré par les cheveux, il illustre la flexibilité et la praticité de l’exposition progressive.

Problèmes courants auxquels sont confrontées les équipes au début

À mesure que les équipes adoptent une pratique DevOps Agile, elles peuvent rencontrer des problèmes similaires à ceux d’autres équipes qui ont migré des livraisons monolithiques traditionnelles. Les équipes habituées à déployer une fois tous les quelques mois ont une mentalité qui prévoit une période de stabilisation. Elles s’attendent à ce que chaque déploiement introduise un changement substantiel dans leur service et qu’il y ait des problèmes imprévus.

Les charges utiles sont trop volumineuses

Les services déployés tous les quelques mois sont généralement remplis de nombreuses modifications. Cela augmente la probabilité qu’il y ait des problèmes immédiats et rend également difficile la résolution de ces problèmes, à cause de la quantité de nouvelles choses. En passant à des livraisons plus fréquentes, les différences dans les éléments déployés deviennent plus faibles, ce qui permet des tests plus ciblés et un dépannage plus simple.

Aucune isolation des services

Les systèmes monolithiques sont traditionnellement dimensionnés en mettant à niveau le matériel sur lequel ils sont déployés. Cependant, lorsque quelque chose ne va pas avec l’instance, cela crée des problèmes pour tout le monde. Une solution simple consiste à ajouter plusieurs instances pour équilibrer la charge des utilisateurs. Cependant, cela peut nécessiter de sérieuses considérations architecturales car de nombreux systèmes hérités ne sont pas conçus pour être multi-instances. De plus, d’importants doublons de ressources peuvent être nécessaires pour une fonctionnalité qui pourrait être mieux consolidée ailleurs.

À mesure que de nouvelles fonctionnalités sont ajoutées, découvrez si une architecture de micro-services peut vous aider à exploiter et redimensionner grâce à une meilleure isolation des services.

Les étapes manuelles sont propices aux erreurs

Lorsqu’une équipe ne déploie que quelques fois par an, automatiser les livraisons peut ne pas sembler en valoir la chandelle. Par conséquent, de nombreux processus de déploiement sont gérés manuellement. Cela nécessite beaucoup de temps et d’efforts, et laisse la place aux erreurs humaines. L’automatisation des tâches de génération et de déploiement les plus courantes peut contribuer grandement à réduire le temps perdu et les erreurs internes.

Les équipes peuvent également utiliser l’infrastructure en tant que code (IaC) pour avoir un meilleur contrôle sur les environnements de déploiement. Cela élimine le besoin de demander à l’équipe des opérations d’apporter des modifications manuelles à mesure que de nouvelles fonctionnalités ou dépendances sont introduites dans différents environnements de déploiement.

Seul le personnel opérationnel peut effectuer des déploiements

Certaines organisations ont des politiques exigeant que tous les déploiements soient initiés et gérés par le personnel des opérations. Bien qu’il y ait eu de bonnes raisons pour cela par le passé, un processus Agile DevOps est considérablement bénéfique lorsque l’équipe de développement peut lancer et contrôler les déploiements. Les plates-formes modernes de livraison continue offrent un contrôle granulaire sur les personnes pouvant initier chaque déploiement et qui peuvent accéder aux journaux d’état et à d’autres informations de diagnostic, en veillant à ce que les personnes concernées aient rapidement accès aux informations pertinentes.

Les mauvais déploiements sont lancés et ne peuvent pas être annulés.

Parfois, un déploiement se passe mal et les équipes doivent résoudre le problème. Cependant, lorsque les processus sont manuels et que l’accès à l’information est lent et limité, il peut être difficile de revenir à un déploiement précédent qui fonctionnait correctement. Heureusement, il existe divers outils et pratiques pour réduire les risque de déploiements ratés.

Principes de base

Les équipes souhaitant adopter des pratiques de déploiement sécurisées doivent établir quelques principes fondamentaux pour soutenir leurs efforts.

Soyez cohérent

Les mêmes outils utilisés pour le déploiement en production doivent être utilisés dans les environnements de développement et de test. Si des problèmes surviennent, tels que ceux qui découlent souvent de nouvelles versions de dépendances ou d’outils, ils doivent être détectés bien avant que le code ne soit proche d’être publié en production.

Soyez attentif aux signaux de qualité

Trop d’équipes tombent dans le piège courant de ne pas prendre suffisamment au sérieux les signaux de qualité. Au fil du temps, elles peuvent constater qu’elles écrivent des tests ou entreprennent des tâches de qualité simplement pour faire passer le feu orange d’un avertissement à un feu vert. Les signaux de qualité sont vraiment importants car ils donnent le pouls d’un projet. Les signaux de qualité utilisés pour approuver les déploiements doivent être suivis constamment et quotidiennement.

Les déploiements ne doivent pas nécessiter d’arrêt

Bien qu’il ne soit pas essentiel que chaque service soit disponible en permanence, les équipes doivent aborder leurs étapes de livraison et d’exploitation DevOps en gardant en tête qu’elles peuvent et doivent déployer de nouvelles versions sans avoir à les mettre hors-service, ne serait-ce qu’un instant. Les outils d’infrastructure et de pipeline modernes sont suffisamment avancés aujourd’hui pour permettre à pratiquement n’importe quelle équipe de viser une disponibilité de 100 %.

Les déploiements doivent avoir lieu pendant les heures de travail

Si une équipe considère que les déploiements ne nécessitent aucun arrêt, alors l’heure à laquelle un déploiement est effectué n’a pas vraiment d’importance. De plus, il est avantageux de lancer les déploiements pendant les heures de travail, en particulier tôt dans la journée et en début de semaine. Si quelque chose se passe mal, cela doit être détecté suffisamment tôt pour en contrôler les impacts. De plus, tout le monde sera déjà au travail et concentré sur la résolution des problèmes.

Déploiement en anneaux

Les équipes avec des pratiques de déploiement DevOps matures sont en mesure d’adopter un déploiement en anneaux. Dans ce modèle, les nouvelles fonctionnalités sont d’abord déployées pour les clients disposés à accepter un niveau de risque supérieur. À mesure que le déploiement fait ses preuves, le public peut s’élargir pour inclure davantage d’utilisateurs jusqu’à ce que tout le monde l’utilise.

Exemple de modèle en anneaux

Un modèle de déploiement typique en anneaux est conçu pour trouver des problèmes dès que possible grâce à la segmentation soigneuse des utilisateurs et de l’infrastructure. L’exemple suivant illustre l’utilisation des anneaux par une équipe essentielle chez Microsoft.

Anneau	Objectif	Users	Centre de données
0	Recherche la plupart des bogues impactant l’utilisateur introduits par le déploiement	Interne uniquement, tolérance élevée pour les risques et les bogues	USA Centre-Ouest
1	Domaines que l’équipe ne teste pas de manière approfondie	Clients utilisant une large gamme de fonctionnalité	Un petit centre de données
2	Problèmes liés à l’échelle	Comptes publics, de préférence gratuits, utilisant une gamme diversifiée de fonctionnalités	Un centre de données moyen ou volumineux
3	Problèmes d’échelle dans les comptes internes et problèmes internationaux	Grands comptes internes et clients européens	Centre de données interne et centre de données européen
4	Unités d’échelle restantes	Tout les autres	Toutes les cibles de déploiement

Respectez le « temps de cuisson »

Le terme bake time (temps de cuisson) fait référence à la durée pendant laquelle un déploiement est autorisé à s’exécuter avant de passer à l’anneau suivant. Pour certains problèmes, cela peur prendre des heures, voire plus, avant de avant que les premiers symptômes apparaissent. La version doit donc être utilisée pendant une durée appropriée avant d’être considérée comme prête.

En général, une journée de 24 heures est suffisante pour détecter des bugs latents dans la plupart des scénarios. Cependant, cette période doit inclure une période d’utilisation maximale, ce qui nécessite une journée de travail complète pour les services qui atteignent leur pic pendant les heures de travail.

Accélérez les correctifs urgents

Un incident en direct sur site (LSI) survient lorsqu’un bug a un impact grave en production. Les LSI nécessitent la création d’un correctif urgent, qui est une mise à jour hors bande conçue pour résoudre un problème de haute priorité.

Si un bug est classé Sev 0, le type de bug le plus grave, le correctif urgent peut être déployé directement sur l’unité d’échelle touchée aussi rapidement que possible de manière responsable. Bien que l’essentiel reste que la correction n’aggrave pas les choses, les bogues de cette gravité sont considérés comme si perturbateurs qu’ils doivent être traités immédiatement

Les bogues classés Sev 1 doivent être déployés par l’intermédiaire de l’anneau 0, mais peuvent ensuite être déployés vers les unités d’échelle affectées dès qu’ils sont approuvés.

Les correctifs urgents pour les bugs de gravité moindre doivent être déployés à travers tous les anneaux comme prévu.

Points clés

Toute équipe souhaite livrer rapidement des mises à jour de la plus haute qualité possible. Grâce aux bonnes pratiques, la livraison peut être une partie productive et indolore du cycle DevOps.

• Déployez souvent.
• Restez dans le vert tout au long du sprint.
• Utilisez des outils de déploiement cohérents en développement, en test et en production.
• Utilisez une plate-forme de livraison continue permettant l’automatisation et l’autorisation.
• Suivez des pratiques de déploiement sécurisées.

Étapes suivantes

Découvrez comment les indicateurs de fonctionnalités aident à contrôler l’exposition des nouvelles fonctionnalités aux utilisateurs.