Partager via

Déplacer vers la droite pour tester en production

Shift right est la pratique de déplacer des tests plus loin dans le processus DevOps pour tester en production. Les tests en production utilisent des déploiements réels pour valider et mesurer le comportement et les performances d’une application dans l’environnement de production.

L’une des façons dont les équipes DevOps peuvent améliorer la vitesse consiste à utiliser une stratégie de test décalée vers la gauche . Shift left pushe la plupart des tests plus tôt dans le pipeline DevOps, afin de réduire le temps nécessaire pour que le nouveau code atteigne la production et fonctionne de manière fiable.

Toutefois, bien que de nombreux types de tests, tels que les tests unitaires, puissent facilement basculer vers la gauche, certaines classes de tests ne peuvent pas s’exécuter sans déployer une partie ou toute une solution. Le déploiement sur un service d’assurance qualité ou intermédiaire peut simuler un environnement comparable, mais il n’existe aucun substitut complet à l’environnement de production. Teams constate que certains types de tests doivent se produire en production.

Les tests en production fournissent les éléments suivants :

  • L’étendue et la diversité complètes de l’environnement de production.
  • Charge de travail réelle du trafic client.
  • Profils et comportements à mesure que la demande de production évolue au fil du temps.

L’environnement de production continue de changer. Même si une application ne change pas, l’infrastructure qu’elle s’appuie sur les modifications constamment. Le test en production valide l’intégrité et la qualité d’un déploiement de production donné et de l’environnement de production en constante évolution.

Le passage de droite au test en production est particulièrement important pour les scénarios suivants :

Déploiements de microservices

Les solutions basées sur des microservices peuvent avoir un grand nombre de microservices développés, déployés et gérés indépendamment. Le changement de droite des tests est particulièrement important pour ces projets, car différentes versions et configurations peuvent atteindre la production de plusieurs façons. Quelle que soit la couverture des tests de préproduction, il est nécessaire de tester la compatibilité en production.

Garantir la qualité après le déploiement

La mise en production n’est que la moitié de la livraison de logiciels. L’autre moitié garantit la qualité à grande échelle avec une charge de travail réelle en production. Étant donné que l’environnement continue de changer, une équipe n’est jamais chargée des tests en production.

Les données de test de production sont littéralement les résultats des tests de la charge de travail réelle du client. Les tests en production incluent la surveillance, le test de basculement et l’injection d’erreurs. Ce test effectue le suivi des échecs, des exceptions, des métriques de performances et des événements de sécurité. La télémétrie de test permet également de détecter les anomalies.

Niveaux de déploiement

Pour protéger l’environnement de production, les équipes peuvent déployer des modifications de manière progressive et contrôlée à l’aide de déploiements etd’indicateurs de fonctionnalités basés sur des niveaux. Par exemple, il est préférable d’intercepter un bogue qui empêche un acheteur d’effectuer son achat lorsque moins de 1% de clients sont sur ce niveau de déploiement, qu’après avoir basculé tous les clients à la fois. La valeur de fonctionnalité avec les défaillances détectées doit dépasser les pertes nettes de ces défaillances, mesurées de manière significative pour l’entreprise donnée.

Le premier niveau doit être la plus petite taille nécessaire pour exécuter la suite d’intégration standard. Les tests peuvent être similaires à ceux déjà exécutés précédemment dans le pipeline sur d’autres environnements, mais les tests valident que le comportement est le même dans l’environnement de production. Ce niveau identifie les erreurs évidentes, telles que les configurations incorrectes, avant qu’elles n’affectent les clients.

Une fois le niveau initial validé, le niveau suivant peut élargir pour inclure un sous-ensemble d’utilisateurs réels pour l’exécution de test. Si tout semble correct, le déploiement peut progresser à travers d’autres niveaux et tests jusqu’à ce que tout le monde l’utilise. Le déploiement complet ne signifie pas que le test est terminé. Le suivi des données de télémétrie est critiquement important pour les tests en production.

Injection d’erreur

Teams utilise souvent l’injection de pannes et l’ingénierie du chaos pour voir comment un système se comporte dans des conditions d’échec. Ces pratiques vous aident à :

  • Vérifiez que les mécanismes de résilience implémentés fonctionnent réellement.
  • Vérifiez qu’une défaillance dans un sous-système est contenue dans ce sous-système et qu’elle n’est pas en cascade pour produire une panne majeure.
  • Prouvez que le travail de réparation d’un incident antérieur a l’effet souhaité, sans avoir à attendre qu’un autre incident se produise.
  • Créez des exercices de formation plus réalistes pour les ingénieurs de site en direct afin qu’ils puissent mieux se préparer à traiter les incidents.

Il est recommandé d’automatiser les expériences d’injection de pannes, car elles sont des tests coûteux qui doivent s’exécuter sur des systèmes en constante évolution.

L’ingénierie du chaos peut être un outil efficace, mais doit être limité aux environnements canary qui ont peu ou pas d’impact sur le client.

Test de basculement

Une forme d’injection de pannes est le test de basculement pour prendre en charge la continuité d’activité et la récupération d’urgence (BCDR). Teams doit avoir des plans de basculement pour tous les services et sous-systèmes. Les plans doivent inclure les éléments suivants :

  • Explication claire de l’impact commercial du service en panne.
  • Carte de toutes les dépendances en termes de plateforme, de technologie et de personnes mettant en place les plans BCDR.
  • Documentation formelle des procédures de récupération d’urgence.
  • Cadence d’exécution régulière des exercices de récupération d’urgence.

Test d’erreur du disjoncteur

Un mécanisme de disjoncteur coupe un composant donné d’un système plus grand, généralement pour empêcher les défaillances de ce composant de se propager en dehors de ses limites. Vous pouvez déclencher intentionnellement des disjoncteurs pour tester les scénarios suivants :

  • Indique si un secours fonctionne lorsque le disjoncteur s’ouvre. La secours peut fonctionner avec des tests unitaires, mais la seule façon de savoir si elle se comporte comme prévu en production consiste à injecter une erreur pour la déclencher.

  • Indique si le disjoncteur a le seuil de sensibilité approprié à ouvrir lorsqu’il a besoin. L’injection d’erreurs peut forcer la latence ou déconnecter les dépendances pour observer la réactivité de l’analyseur. Il est important de vérifier non seulement que le comportement correct se produit, mais qu’il se produit assez rapidement.

Exemple : Test d’un disjoncteur de cache Redis

Le cache Redis améliore les performances du produit en accélérant l’accès aux données couramment utilisées. Envisagez un scénario qui prend une dépendance non critique sur Redis. Si Redis tombe en panne, le système doit continuer à fonctionner, car il peut revenir à l’utilisation de la source de données d’origine pour les demandes. Pour confirmer qu’une défaillance Redis déclenche un disjoncteur et que le secours fonctionne en production, exécutez régulièrement des tests sur ces comportements.

Le diagramme suivant montre les tests du comportement de secours du disjoncteur Redis. L’objectif est de s’assurer que lorsque le disjoncteur s’ouvre, les appels sont finalement passés à SQL.

Diagramme montrant les tests du disjoncteur Redis et du comportement de secours.

Le diagramme précédent montre trois AT, avec les disjoncteurs devant les appels à Redis. Un test force le disjoncteur à s’ouvrir par le biais d’une modification de configuration, puis observe si les appels vont à SQL. Un autre test vérifie ensuite le changement de configuration opposé, en fermant le disjoncteur pour confirmer que les appels reviennent à Redis.

Ce test vérifie que le comportement de secours fonctionne lorsque le disjoncteur s’ouvre, mais il ne valide pas que la configuration du disjoncteur ouvre le disjoncteur quand il doit. Le test de ce comportement nécessite la simulation d’échecs réels.

Un agent d’erreur peut introduire des erreurs dans les appels qui vont à Redis. Le diagramme suivant montre les tests avec l’injection d’erreurs.

Diagramme montrant le test du disjoncteur Redis avec l’injection de pannes.

  1. L’injecteur d’erreur bloque les requêtes Redis.
  2. Le disjoncteur s’ouvre et le test peut observer si la secours fonctionne.
  3. L’erreur est supprimée et le disjoncteur envoie une demande de test à Redis.
  4. Si la demande réussit, les appels reviennent à Redis.

D’autres étapes peuvent tester la sensibilité du disjoncteur, si le seuil est trop élevé ou trop bas, et si d’autres délais d’expiration système interfèrent avec le comportement du disjoncteur.

Dans cet exemple, si le disjoncteur ne s’ouvre pas ou ne se ferme pas comme prévu, il peut provoquer un incident de site en direct (LSI). Sans le test d’injection d’erreurs, le problème peut ne pas être détecté, car il est difficile d’effectuer ce type de test dans un environnement de laboratoire.

Étapes suivantes

  • Last updated on