Le sujet du DevOps est désormais à la mode. Pipeline d’intégration et de livraison continue tout le monde le met en œuvre. Mais la plupart ne prêtent pas toujours l’attention voulue à la fiabilité des systèmes d’information aux différentes étapes du pipeline CI/CD. Dans cet article, je voudrais parler de mon expérience dans l'automatisation des contrôles de qualité des logiciels et dans la mise en œuvre de scénarios possibles pour son « auto-réparation ».
Je travaille en tant qu'ingénieur dans le département de gestion des services informatiques d'une entreprise . Mon principal domaine d'expertise est la mise en œuvre de divers systèmes de surveillance des performances et de la disponibilité des applications. Je communique souvent avec des clients informatiques de différents segments de marché concernant les problématiques actuelles liées au suivi de la qualité de leurs services informatiques. L’objectif principal est de minimiser la durée du cycle de publication et d’augmenter la fréquence des versions. Bien sûr, tout cela est bien : plus de versions - plus de nouvelles fonctionnalités - des utilisateurs plus satisfaits - plus de profits. Mais en réalité, les choses ne se passent pas toujours bien. Avec des taux de déploiement très élevés, la question se pose immédiatement sur la qualité de nos releases. Même avec un pipeline entièrement automatisé, l’un des plus grands défis consiste à faire passer les services du test à la production sans impact sur la disponibilité des applications et l’expérience utilisateur.
Sur la base des résultats de nombreuses conversations avec les clients, je peux dire que le contrôle qualité des versions, le problème de la fiabilité des applications et la possibilité de son « auto-réparation » (par exemple, revenir à une version stable) à différentes étapes du CI Le pipeline /CD fait partie des sujets les plus passionnants et les plus pertinents.
Récemment, j'ai moi-même travaillé du côté client - dans le service de support pour les logiciels d'applications bancaires en ligne. L'architecture de notre application utilisait un grand nombre de microservices auto-écrits. Le plus triste est que tous les développeurs n'ont pas pu faire face au rythme de développement élevé ; la qualité de certains microservices en a souffert, ce qui a donné lieu à des surnoms amusants pour eux et leurs créateurs. Il y avait des histoires sur les matériaux à partir desquels ces produits étaient fabriqués.
"Formulation du problème"
La fréquence élevée des releases et le grand nombre de microservices rendent difficile la compréhension du fonctionnement de l'application dans son ensemble, tant au stade des tests qu'au stade opérationnel. Des changements se produisent constamment et il est très difficile de les contrôler sans de bons outils de suivi. Souvent, après une sortie nocturne le matin, les développeurs s'assoient comme sur une poudrière et attendent que rien ne se brise, même si tous les contrôles ont réussi au stade des tests.
Il y a encore un point. Au stade des tests, la fonctionnalité du logiciel est vérifiée : la mise en œuvre des principales fonctions de l'application et l'absence d'erreurs. Les évaluations qualitatives des performances sont soit manquantes, soit ne prennent pas en compte tous les aspects de l'application et de la couche d'intégration. Certaines mesures peuvent ne pas être vérifiées du tout. Ainsi, lorsqu'une panne survient dans un environnement de production, le service d'assistance technique n'en est informé que lorsque les utilisateurs réels commencent à se plaindre. Je souhaite minimiser l'impact des logiciels de mauvaise qualité sur les utilisateurs finaux.
L'une des solutions consiste à mettre en œuvre des processus de vérification de la qualité des logiciels à différentes étapes du pipeline CI/CD et à ajouter divers scénarios pour restaurer le système en cas d'urgence. Nous rappelons également que nous avons DevOps. Les entreprises s'attendent à recevoir un nouveau produit le plus rapidement possible. Par conséquent, tous nos contrôles et scripts doivent être automatisés.
La tâche est divisée en deux volets :
- contrôle qualité des assemblages au stade des tests (pour automatiser le processus de détection des assemblages de mauvaise qualité) ;
- contrôle de la qualité des logiciels dans l'environnement de production (mécanismes de détection automatique des problèmes et scénarios possibles pour leur auto-réparation).
Outil de suivi et de collecte de métriques
Afin d'atteindre les objectifs fixés, un système de surveillance est nécessaire, capable de détecter les problèmes et de les transférer aux systèmes d'automatisation à différentes étapes du pipeline CI/CD. Ce sera également une chose positive si ce système fournit des métriques utiles aux différentes équipes : développement, tests, exploitation. Et c’est absolument merveilleux si c’est aussi pour les affaires.
Pour collecter des métriques, vous pouvez utiliser un ensemble de systèmes différents (Prometheus, ELK Stack, Zabbix, etc.), mais, à mon avis, les solutions de classe APM sont les mieux adaptées à ces tâches (), ce qui peut grandement vous simplifier la vie.
Dans le cadre de mon travail au sein du service support, j'ai commencé à réaliser un projet similaire en utilisant une solution de classe APM de Dynatrace. Aujourd'hui travaillant chez un intégrateur, je connais assez bien le marché des systèmes de surveillance. Mon avis subjectif : Dynatrace est le mieux adapté pour résoudre de tels problèmes.
Dynatrace fournit une vue horizontale de chaque opération utilisateur à un niveau granulaire jusqu'au niveau d'exécution du code. Vous pouvez suivre toute la chaîne d'interaction entre les différents services d'information : depuis les niveaux front-end des applications Web et mobiles, les serveurs d'applications back-end, le bus d'intégration jusqu'à un appel spécifique à la base de données.
. Construction automatique de toutes les dépendances entre les composants du système
. Détection et construction automatiques du chemin d'exploitation du service
Nous rappelons également que nous devons intégrer divers outils d'automatisation. Ici, la solution dispose d'une API pratique qui vous permet d'envoyer et de recevoir diverses métriques et événements.
Passons ensuite à un examen plus détaillé de la manière de résoudre ces problèmes à l'aide du système Dynatrace.
Tâche 1. Automatisation du contrôle qualité des assemblages au stade des tests
Le premier défi consiste à détecter les problèmes le plus tôt possible dans le pipeline de livraison des applications. Seules les « bonnes » versions de code devraient atteindre la production. Pour ce faire, votre pipeline au stade des tests doit inclure des moniteurs supplémentaires pour vérifier la qualité de vos services.
Voyons étape par étape comment mettre en œuvre cela et automatiser ce processus :
La figure montre le flux des étapes automatisées de test de qualité des logiciels :
- déploiement d'un système de surveillance (installation d'agents) ;
- identifier les événements pour évaluer la qualité de votre logiciel (métriques et valeurs seuils) et les transférer au système de surveillance ;
- génération de tests de charge et de performances ;
- collecter des données de performances et de disponibilité dans le système de surveillance ;
- transfert de données de test basées sur les événements d'évaluation de la qualité du logiciel du système de surveillance vers le système CI/CD. Analyse automatique des assemblages.
Étape 1. Déploiement du système de surveillance
Vous devez d'abord installer les agents dans votre environnement de test. Dans le même temps, la solution Dynatrace a une fonctionnalité intéressante : elle utilise l'agent universel OneAgent, qui est installé sur une instance du système d'exploitation (Windows, Linux, AIX), détecte automatiquement vos services et commence à collecter des données de surveillance sur eux. Vous n'avez pas besoin de configurer un agent distinct pour chaque processus. La situation sera similaire pour les plateformes cloud et conteneurisées. Dans le même temps, vous pouvez également automatiser le processus d'installation de l'agent. Dynatrace s'inscrit parfaitement dans le concept "infrastructure as code" () : Il existe des scripts et des instructions prêts à l'emploi pour toutes les plateformes populaires. Vous intégrez l'agent dans la configuration de votre service, et lorsque vous le déployez, vous recevez immédiatement un nouveau service avec un agent déjà fonctionnel.
Étape 2 : Définissez vos événements de qualité logicielle
Vous devez maintenant décider de la liste des services et des opérations commerciales. Il est important de prendre en compte exactement les opérations utilisateur qui sont critiques pour votre service. Ici, je recommande de consulter des analystes commerciaux et systèmes.
Ensuite, vous devez déterminer les mesures que vous souhaitez inclure dans l'examen pour chaque niveau. Par exemple, il peut s'agir du temps d'exécution (divisé en moyenne, médiane, centiles, etc.), des erreurs (logiques, service, infrastructure, etc.) et de diverses métriques d'infrastructure (tas de mémoire, garbage collector, nombre de threads, etc.).
Pour l’automatisation et la facilité d’utilisation par l’équipe DevOps, le concept de « Monitoring as Code » apparaît. Ce que je veux dire par là, c'est qu'un développeur/testeur peut écrire un simple fichier JSON qui définit les mesures d'assurance qualité du logiciel.
Regardons un exemple d'un tel fichier JSON. Les objets de l'API Dynatrace sont utilisés sous forme de paires clé/valeur (la description de l'API peut être trouvée ici ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}Le fichier est un tableau de définitions de séries chronologiques :
- timeseriesId – la métrique vérifiée, par exemple, le temps de réponse, le nombre d'erreurs, la mémoire utilisée, etc. ;
- agrégation - niveau d'agrégation des métriques, dans notre cas moy, mais vous pouvez utiliser celui dont vous avez besoin (avg, min, max, sum, count, percentile) ;
- tags – balise d'objet dans le système de surveillance, ou vous pouvez spécifier un identifiant d'objet spécifique ;
- sévère et avertissement – ces indicateurs régulent les valeurs seuils de nos métriques ; si la valeur du test dépasse le seuil sévère, alors notre build est marquée comme échouée.
La figure suivante montre un exemple d’utilisation de tels seuils.
Étape 3 : Génération de charge
Une fois que nous avons déterminé les niveaux de qualité de notre service, nous devons générer une charge de test. Vous pouvez utiliser n'importe lequel des outils de test avec lesquels vous êtes à l'aise, tels que Jmeter, Selenium, Neotys, Gatling, etc.
Le système de surveillance de Dynatrace vous permet de capturer diverses métadonnées de vos tests et de reconnaître quels tests appartiennent à quel cycle de publication et à quel service. Il est recommandé d'ajouter des en-têtes supplémentaires aux requêtes de test HTTP.
La figure suivante montre un exemple où, à l'aide de l'en-tête supplémentaire X-Dynatrace-Test, nous indiquons que ce test concerne le test de l'opération d'ajout d'un article au panier.
Lorsque vous exécutez chaque test de charge, vous envoyez des informations contextuelles supplémentaires à Dynatrace à l'aide de l'API d'événement du serveur CI/CD. De cette façon, le système peut différencier les différents tests.
. Événement dans le système de surveillance concernant le début du test de charge
Étape 4-5. Collecter les données de performances et transférer les données vers le système CI/CD
Avec le test généré, un événement est transmis au système de surveillance concernant la nécessité de collecter des données sur la vérification des indicateurs de qualité de service. Il spécifie également notre fichier JSON, qui définit les métriques clés.
Événement sur la nécessité de vérifier la qualité du logiciel généré sur le serveur CI/CD pour envoi au système de surveillance
Dans notre exemple, l'événement de contrôle qualité s'appelle perfSigDynatraceReport (Performance_Signature) - c'est prêt pour l'intégration avec Jenkins, qui a été développé par les gars de T-Systems Multimedia Solutions. Chaque événement de lancement de test contient des informations sur le service, le numéro de build et la durée du test. Le plugin collecte les valeurs de performances au moment de la construction, les évalue et compare le résultat avec les versions précédentes et les exigences non fonctionnelles.
Événement dans le système de surveillance concernant le début d'un contrôle de qualité de construction.
Une fois le test terminé, toutes les mesures permettant d'évaluer la qualité du logiciel sont retransférées vers un système d'intégration continue, par exemple Jenkins, qui génère un rapport sur les résultats.
Le résultat des statistiques sur les assemblys sur le serveur CI/CD.
Pour chaque build individuel, nous voyons des statistiques pour chaque métrique que nous avons définie tout au long du test. Nous voyons également s'il y a eu des violations de certaines valeurs seuils (avertissement et thrashholds sévères). Sur la base de métriques globales, l’ensemble de la build est marqué comme stable, instable ou en échec. De plus, pour plus de commodité, vous pouvez ajouter des indicateurs au rapport comparant la version actuelle avec la précédente.
Affichez des statistiques détaillées sur les assemblys sur le serveur CI/CD.
Comparaison détaillée de deux assemblages
Si nécessaire, vous pouvez vous rendre sur l'interface Dynatrace et y consulter plus en détail les statistiques de chacun de vos builds et les comparer entre elles.
Comparaison des statistiques de build dans Dynatrace.
résultats
En conséquence, nous obtenons un service de « surveillance en tant que service », automatisé dans le pipeline d'intégration continue. Le développeur ou le testeur n'a qu'à définir une liste de métriques dans un fichier JSON, et tout le reste se fait automatiquement. Nous recevons un contrôle qualité transparent des versions : toutes les notifications concernant les performances, la consommation de ressources ou les régressions architecturales.
Tâche 2. Automatisation du contrôle qualité des logiciels dans un environnement de production
Nous avons donc résolu le problème de l'automatisation du processus de surveillance au stade des tests dans Pipeline. De cette façon, nous minimisons le pourcentage d’assemblages de mauvaise qualité qui atteignent l’environnement de production.
Mais que faire si un mauvais logiciel finit par être vendu ou si quelque chose tombe en panne ? Pour une utopie, nous voulions que des mécanismes détectent automatiquement les problèmes et, si possible, que le système lui-même rétablisse sa fonctionnalité, au moins la nuit.
Pour ce faire, nous devons, par analogie avec la section précédente, prévoir des contrôles automatiques de la qualité des logiciels dans l'environnement de production et les baser sur des scénarios d'auto-réparation du système.
Correction automatique en tant que code
La plupart des entreprises disposent déjà d'une base de connaissances accumulée sur divers types de problèmes courants et d'une liste d'actions pour les résoudre, par exemple, redémarrer des processus, nettoyer des ressources, restaurer des versions, restaurer des modifications de configuration non valides, augmenter ou diminuer le nombre de composants dans le cluster, en changeant le contour bleu ou vert, etc.
Bien que ces cas d'utilisation soient connus depuis des années par de nombreuses équipes avec lesquelles je discute, peu d'entre elles ont réfléchi ou investi dans leur automatisation.
Si vous y réfléchissez, il n'y a rien de trop compliqué dans la mise en œuvre de processus d'auto-réparation des performances des applications ; vous devez présenter les scénarios de travail déjà connus de vos administrateurs sous forme de scripts de code (le concept « auto-fix as code »). , que vous avez rédigé à l'avance pour chaque cas spécifique. Les scripts de réparation automatique doivent viser à éliminer la cause première du problème. Vous déterminez vous-même les actions correctes pour répondre à un incident.
N'importe quelle métrique de votre système de surveillance peut servir de déclencheur pour lancer le script, l'essentiel est que ces métriques déterminent avec précision que tout va mal, car vous ne voudriez pas obtenir de faux positifs dans un environnement productif.
Vous pouvez utiliser n'importe quel système ou ensemble de systèmes : Prometheus, ELK Stack, Zabbix, etc. Mais je vais donner quelques exemples basés sur une solution APM (Dynatrace en sera encore un exemple) qui vous faciliteront également la vie.
Il y a d’abord tout ce qui touche aux performances en termes de fonctionnement des applications. La solution fournit des centaines de métriques à différents niveaux que vous pouvez utiliser comme déclencheurs :
- niveau utilisateur (navigateurs, applications mobiles, appareils IoT, comportement des utilisateurs, conversion, etc.) ;
- niveau de service et d’exploitation (performances, disponibilité, erreurs, etc.) ;
- niveau d'infrastructure d'application (métriques du système d'exploitation hôte, JMX, MQ, serveur Web, etc.) ;
- niveau plateforme (virtualisation, cloud, conteneur, etc.).
Suivi des niveaux dans Dynatrace.
Deuxièmement, comme je l'ai dit plus tôt, Dynatrace dispose d'une API ouverte, ce qui facilite son intégration avec divers systèmes tiers. Par exemple, envoyer une notification au système d'automatisation lorsque les paramètres de contrôle sont dépassés.
Vous trouverez ci-dessous un exemple d'interaction avec Ansible.
Ci-dessous, je vais donner quelques exemples du type d'automatisation qui peut être réalisé. Ceci n'est qu'une partie des cas ; leur liste dans votre environnement ne peut être limitée que par votre imagination et les capacités de vos outils de surveillance.
1. Mauvais déploiement - restauration de la version
Même si nous testons tout très bien dans un environnement de test, il existe toujours un risque qu'une nouvelle version tue votre application dans un environnement de production. Le même facteur humain n'a pas été annulé.
Dans la figure suivante, nous constatons une forte augmentation du temps d’exécution des opérations sur le service. Le début de ce saut coïncide avec le moment du déploiement sur l'application. Nous transmettons toutes ces informations sous forme d'événements au système d'automatisation. Si les performances du service ne reviennent pas à la normale après le délai que nous avons défini, un script est automatiquement appelé pour restaurer la version à l'ancienne.
Dégradation des performances des opérations après le déploiement.
2. Chargement des ressources à 100 % - ajoutez un nœud au routage
Dans l'exemple suivant, le système de surveillance détermine que l'un des composants subit une charge CPU de 100 %.
Charge CPU 100 %
Plusieurs scénarios différents sont possibles pour cet événement. Par exemple, le système de surveillance vérifie en outre si le manque de ressources est associé à une augmentation de la charge sur le service. Si tel est le cas, un script est exécuté qui ajoute automatiquement un nœud au routage, rétablissant ainsi la fonctionnalité du système dans son ensemble.
Mise à l'échelle après un incident
3. Manque d'espace sur le disque dur - nettoyage du disque
Je pense que de nombreuses personnes ont déjà automatisé ces processus. À l'aide d'APM, vous pouvez également surveiller l'espace libre sur le sous-système de disque. S'il n'y a pas d'espace ou si le disque fonctionne lentement, nous appelons un script pour le nettoyer ou ajouter de l'espace.
Chargement du disque 100 %
4. Faible activité des utilisateurs ou faible conversion – commutation entre les branches bleues et vertes
Je vois souvent des clients utiliser deux boucles (déploiement bleu-vert) pour des applications dans un environnement de production. Cela vous permet de basculer rapidement entre les branches lors de la livraison de nouvelles versions. Souvent, après le déploiement, des changements spectaculaires peuvent survenir sans être immédiatement perceptibles. Dans ce cas, aucune dégradation des performances et de la disponibilité ne peut être observée. Pour réagir rapidement à de tels changements, il est préférable d'utiliser diverses métriques qui reflètent le comportement des utilisateurs (nombre de sessions et d'actions des utilisateurs, conversion, taux de rebond). La figure suivante montre un exemple dans lequel, lorsque les taux de conversion chutent, un basculement entre les branches logicielles se produit.
Le taux de conversion chute après le basculement entre les branches logicielles.
Mécanismes de détection automatique des problèmes
Enfin, je vais vous donner un autre exemple de la raison pour laquelle j'aime le plus Dynatrace.
Dans la partie de mon histoire sur l'automatisation des contrôles qualité des assemblages dans un environnement de test, nous avons déterminé manuellement toutes les valeurs seuils. Ceci est normal pour un environnement de test, le testeur détermine lui-même les indicateurs avant chaque test en fonction de la charge. Dans un environnement de production, il est souhaitable que les problèmes soient détectés automatiquement, en tenant compte de divers mécanismes de base.
Dynatrace dispose d'outils d'intelligence artificielle intégrés intéressants qui, basés sur des mécanismes permettant de déterminer des métriques anormales (baselining) et de construire une carte d'interaction entre tous les composants, en comparant et en corrélant les événements entre eux, déterminent les anomalies dans le fonctionnement de votre service et fournissent des informations détaillées. des informations sur chaque problème et sa cause profonde.
En analysant automatiquement les dépendances entre les composants, Dynatrace détermine non seulement si le service problématique est la cause première, mais également sa dépendance vis-à-vis d'autres services. Dans l'exemple ci-dessous, Dynatrace surveille et évalue automatiquement la santé de chaque service au sein de l'exécution de la transaction, identifiant le service Golang comme cause première.
Un exemple de détermination de la cause première d’un échec.
La figure suivante montre le processus de surveillance des problèmes avec votre application depuis le début d'un incident.
Visualisation d'un problème émergent avec affichage de tous les composants et événements sur ceux-ci
Le système de surveillance a collecté une chronologie complète des événements liés au problème survenu. Dans la fenêtre située sous la chronologie, nous voyons tous les événements clés sur chacun des composants. Sur la base de ces événements, vous pouvez définir des procédures de correction automatique sous forme de scripts de code.
De plus, je vous conseille d'intégrer un système de surveillance avec Service Desk ou un bug tracker. Lorsqu'un problème survient, les développeurs reçoivent rapidement des informations complètes pour l'analyser au niveau du code dans l'environnement de production.
Conclusion
En conséquence, nous nous sommes retrouvés avec un pipeline CI/CD avec des contrôles de qualité logiciels automatisés intégrés dans Pipeline. Nous minimisons le nombre d'assemblages de mauvaise qualité, augmentons la fiabilité du système dans son ensemble et si notre système tombe toujours en panne, nous lançons des mécanismes pour le restaurer.
Cela vaut vraiment la peine d’investir des efforts dans l’automatisation du contrôle de la qualité des logiciels ; ce n’est pas toujours un processus rapide, mais avec le temps, cela portera ses fruits. Je recommande qu'après avoir résolu un nouvel incident dans l'environnement de production, vous réfléchissiez immédiatement aux moniteurs à ajouter pour les vérifications dans l'environnement de test afin d'éviter qu'une mauvaise version n'entre en production, et également de créer un script pour corriger automatiquement ces problèmes.
J'espère que mes exemples vous aideront dans vos efforts. Je serai également intéressé de voir vos exemples de métriques utilisées pour mettre en œuvre des systèmes d'auto-guérison.
Source: habr.com