Maintenant sur le thème battage DevOps. Convoyeur d'intégration continue et de livraison de CI / CD est mis en œuvre par tous ceux qui en ont envie. Mais la plupart ne prêtent pas toujours l'attention voulue à la fiabilité des systèmes d'information à divers stades 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 l'implémentation de scénarios possibles pour leur "auto-guérison".

Source

Je travaille en tant qu'ingénieur au sein du département de gestion des services informatiques de LANIT-Integration . Mon domaine principal 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é sur des questions d'actualité concernant le contrôle de la qualité de leurs services informatiques. La tâche principale est de minimiser le temps de cycle de libération et d'augmenter la fréquence de leur libération. Bien sûr, tout cela est bien: plus de versions - plus de nouvelles fonctionnalités - plus d'utilisateurs satisfaits - plus de profits. Mais en réalité, tout ne se passe pas toujours bien. À des taux de déploiement très élevés, la question se pose immédiatement de la qualité de nos versions. Même avec un pipeline entièrement automatisé, l'un des plus gros problèmes est le transfert de services du test à la production, ce qui n'affecte pas la disponibilité et l'interaction de l'utilisateur avec l'application.

Sur la base des résultats de nombreuses conversations avec les clients, je peux dire que le contrôle de la qualité des versions, le problème de la fiabilité des applications et la possibilité de son "auto-guérison" (par exemple, le retour à une version stable) à différentes étapes du pipeline CI / CD sont parmi les sujets les plus passionnants et pertinents.


Récemment, j'ai moi-même travaillé du côté client - dans le service d'assistance aux 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 fait face au rythme élevé de développement, la qualité de certains microservices a souffert, ce qui a donné lieu à des surnoms ridicules pour eux et leurs créateurs. Il y avait des histoires sur les matériaux dont ces produits sont faits.

"Énoncé du problème"

La fréquence élevée des rejets et un grand nombre de microservices rendent difficile la compréhension de l'application dans son ensemble, tant au stade des tests qu'au stade opérationnel. Les changements se produisent constamment et il est très difficile de les contrôler sans de bons outils de surveillance. Souvent, après une sortie nocturne le matin, les développeurs sont assis sur un baril de poudre et attendent que rien ne se brise, bien qu'au stade des tests, tous les contrôles aient réussi.

Il y a encore un point. Au stade des tests, l'opérabilité du logiciel est vérifiée: la mise en œuvre des principales fonctions de l'application et l'absence d'erreurs. Les estimations qualitatives des performances sont soit absentes, 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. Par conséquent, lorsqu'une panne se produit dans un environnement productif, le service d'assistance technique ne découvre que lorsque de vrais utilisateurs commencent à se plaindre. Je souhaite minimiser l'impact des logiciels de faible qualité sur les utilisateurs finaux.

L'une des solutions consiste à mettre en œuvre des processus de contrôle qualité logiciel à différentes étapes du pipeline CI / CD, à ajouter divers scripts pour restaurer le système en cas d'accident. N'oubliez pas non plus que nous avons des 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 capture des assemblages de qualité inférieure);
• 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 d'auto-guérison).

Outil de surveillance et de collecte de métriques

Afin de réaliser les tâches définies, un système de surveillance est nécessaire pour détecter les problèmes et les transférer vers des systèmes d'automatisation à différentes étapes du pipeline CI / CD. De plus, un point positif sera si ce système fournit des métriques utiles pour différentes équipes: développement, test, opération. Et tout à fait merveilleux, si pour les affaires.

Pour collecter des métriques, vous pouvez utiliser une combinaison de différents systèmes (Prometheus, ELK Stack, Zabbix, etc.), mais, à mon avis, les solutions APM ( Application Performance Monitoring ) sont les mieux adaptées à ces tâches, ce qui peut grandement vous simplifier la vie.

Dans le cadre de mon travail dans le service d'escorte, j'ai commencé à faire un projet similaire en utilisant la solution de classe APM de Dynatrace. Maintenant, en tant qu'intégrateur, je connais assez bien le marché des systèmes de surveillance. Mon opinion subjective: Dynatrace est le mieux adapté pour de telles tâches.
La solution Dynatrace fournit un affichage horizontal de chaque opération utilisateur avec un degré de détail approfondi jusqu'au niveau d'exécution du code. Vous pouvez suivre l'intégralité de la chaîne d'interaction entre les différents services d'information: des niveaux frontaux d'applications Web et mobiles, des serveurs d'applications principaux, du bus d'intégration à un appel spécifique à la base de données.

Source Construction automatique de toutes les dépendances entre les composants du système

Source Détection et construction automatiques d'un chemin pour une opération de service

N'oubliez pas non plus que nous devons nous intégrer à divers outils d'automatisation. Ici, la solution dispose d'une API pratique qui vous permet d'envoyer et de recevoir diverses mesures et événements.

Ensuite, nous allons passer à une discussion plus détaillée sur la façon de résoudre les tâches à l'aide du système Dynatrace.

Tâche 1. Automatisation du contrôle qualité des assemblages au stade des tests

La première tâche consiste à détecter les problèmes le plus tôt possible aux étapes du pipeline de livraison des applications. Seules les «bonnes» versions de code devraient atteindre l'environnement de prod. Pour ce faire, des moniteurs supplémentaires doivent être inclus dans votre pipeline au stade des tests pour vérifier la qualité de vos services.



Examinons les étapes pour implémenter cela et automatiser ce processus:

Source

La figure montre le déroulement des étapes automatisées de contrôle de la qualité des logiciels:

1. déploiement d'un système de surveillance (installation d'agents);
2. définition des événements d'évaluation de la qualité de votre logiciel (métriques et valeurs seuils) et leur transfert vers le système de surveillance;
3. génération de charge et tests de performance;
4. collecte de données de performance et de disponibilité dans un système de surveillance;
5. transfert des 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 d'assemblage automatique.

Étape 1. Déployer un 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 l'instance de 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 séparément pour chaque processus. Une situation similaire sera pour les plates-formes cloud et conteneurs. Dans le même temps, vous pouvez également automatiser l'installation d'agents. Dynatrace s'intègre parfaitement dans le concept d '"infrastructure en tant que code" ( Infrastructure en tant que code ou IaC ): il existe des scripts et des instructions prêts à l'emploi pour toutes les plates-formes populaires. Intégrez l'agent dans la configuration de votre service et lorsque vous le déployez, vous obtenez immédiatement un nouveau service avec un agent déjà en cours d'exécution.

Étape 2. Identifiez vos événements d'évaluation de la qualité des logiciels

Vous devez maintenant déterminer 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ème.

Ensuite, vous devez déterminer les mesures que vous souhaitez inclure dans la vérification pour chacun des niveaux. Par exemple, il peut s'agir de runtime (avec séparation par moyenne, médiane, centile, etc.), d'erreurs (logique, 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, l'équipe DevOps introduit le concept de «Monitoring as code». Ce que je veux dire par là, c'est qu'un développeur / testeur peut écrire un simple fichier JSON qui définit les indicateurs de contrôle de qualité logiciel.

Regardons un exemple d'un tel fichier JSON. Les objets de l'API Dynatrace sont utilisés comme paire clé / valeur (voir l' API Dynatrace pour une description de l'API ).

{    "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 temporelles:

• timeseriesId - métrique vérifiée, par exemple, temps de réponse, nombre d'erreurs, mémoire utilisée, etc.
• agrégation - le niveau d'agrégation des métriques, dans notre cas moy, mais vous pouvez utiliser tout ce dont vous avez besoin (moy, min, max, somme, nombre, centile);
• balises - une 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 ajustent les valeurs seuils de nos métriques, si la valeur des tests dépasse le seuil sévère, alors notre assemblage est marqué comme infructueux.

La figure suivante montre un exemple d'utilisation de ces corbeilles.

Source

Étape 3. Génération de charge

Après avoir déterminé les niveaux de qualité de notre service, il est nécessaire de générer une charge de test. Vous pouvez utiliser n'importe lequel des outils de test qui vous conviennent, par exemple Jmeter, Selenium, Neotys, Gatling, etc.

Le système de surveillance Dynatrace vous permet de capturer diverses métadonnées de vos tests et de reconnaître quel test se rapporte à quel cycle de publication et quel service. Il est recommandé d'ajouter des en-têtes supplémentaires aux requêtes HTTP de test.

La figure suivante montre un exemple où, en utilisant l'en-tête X-Dynatrace-Test facultatif, nous marquons que ce test fait référence au test de l'opération d'ajout d'un article au panier.

Source

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. Ainsi, le système peut faire la distinction entre différents tests entre eux.

Source Événement dans le système de surveillance sur le lancement du test de charge

Étape 4-5. Collectez les données de performances et transférez les données vers un système CI / CD

Parallèlement au test généré, un événement est transmis au système de surveillance sur la nécessité de collecter des données sur la vérification des indicateurs de qualité de service. Notre fichier JSON est également indiqué, dans lequel les métriques clés sont définies.

Un événement sur la nécessité de vérifier la qualité des logiciels générés sur le serveur CI / CD pour les envoyer au système de surveillance

Dans notre exemple, l'événement de contrôle qualité est appelé perfSigDynatraceReport (Performance_Signature ) - il s'agit d'un plug - in prêt à l'emploi pour l'intégration avec Jenkins, qui a été développé par les gars de T-Systems Multimedia Solutions. Chaque événement concernant le lancement du 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 lors de l'assemblage, les évalue et compare le résultat avec les assemblages précédents et les exigences non fonctionnelles.

Événement dans le système de surveillance sur le début du contrôle qualité de l'assemblage. Source

Une fois le test terminé, toutes les mesures d'évaluation de la qualité du logiciel sont retransférées au système d'intégration continue, par exemple Jenkins, qui génère un rapport sur les résultats.

Résultat des statistiques d'assemblage sur le serveur CI / CD. Source

Pour chaque assemblage individuel, nous voyons des statistiques pour chaque métrique que nous avons définie pendant tout le test. Nous voyons également s'il y a eu des violations à certaines valeurs de seuil (avertissement et thrasholds sévères). Sur la base des métriques agrégées, l'assemblage entier est marqué comme stable, instable ou a échoué. De plus, pour plus de commodité, vous pouvez ajouter des indicateurs pour comparer l'assemblage actuel avec l'assemblage précédent dans le rapport.

Affichez les statistiques détaillées d'assemblage sur le serveur CI / CD. Source

Comparaison détaillée de deux assemblages

Si nécessaire, vous pouvez accéder à l'interface Dynatrace et y regarder plus en détail les statistiques de chacun de vos assemblages et les comparer les uns aux autres.

Comparaison des statistiques d'assemblage dans Dynatrace. Source

Conclusions

En conséquence, nous obtenons le service «monitoring as a service», automatisé dans le pipeline d'intégration continue. Le développeur ou le testeur n'a besoin que de déterminer la liste des métriques dans le fichier JSON, et tout le reste se produit automatiquement. Nous obtenons un contrôle de qualité transparent des versions: toutes les notifications sur les performances, la consommation des 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. Ainsi, nous minimisons le pourcentage d'assemblages de faible qualité atteignant l'environnement alimentaire.

Mais que faire si un mauvais logiciel arrive toujours au point de vente, ou si quelque chose se casse. Pour l'utopie, nous voulions disposer de mécanismes de détection automatique des problèmes et, si possible, le système lui-même rétablirait sa capacité de travail, au moins la nuit.

Pour ce faire, nous, par analogie avec la section précédente, fournissons des vérifications automatiques de la qualité des logiciels dans l'environnement de production et mettons des scripts pour l'auto-réparation du système sous eux.


Correction automatique en tant que code

La plupart des entreprises ont déjà une base de connaissances accumulées sur divers types de problèmes courants et une liste d'actions pour les résoudre, par exemple, redémarrage des processus, nettoyage des ressources, restauration des versions, restauration des modifications de configuration incorrectes, augmentation ou diminution du nombre de composants dans un cluster, changement de contour bleu ou vert et autre

Malgré le fait que ces cas d'utilisation sont connus depuis de nombreuses années pour de nombreuses équipes avec lesquelles je communique, seuls quelques-uns ont pensé et investi dans leur automatisation.

Si vous y réfléchissez, alors dans l'implémentation de processus d'auto-guérison de la santé de l'application, il n'y a rien de super compliqué, vous devez présenter les scénarios de travail bien connus de vos administrateurs sous la forme de scripts de code (le concept d '«autocorrection en tant que code») que vous avez écrits à l'avance pour chaque cas spécifique. Les scénarios de réparation automatique doivent résoudre la cause première du problème. Vous définissez vous-même les bonnes actions de réponse aux incidents.

Toute métrique de votre système de surveillance peut agir comme un déclencheur pour exécuter un script, l'essentiel est que ces métriques déterminent avec précision que tout est mauvais, car je ne voudrais 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 la solution APM (Dynatrace sera encore un exemple), qui vous aideront également à vous faciliter la vie.

Premièrement, il y a tout ce qui concerne l'opérabilité en termes d'application. La solution fournit des centaines de mesures à 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 (mesures du système d'exploitation hôte, JMX, MQ, serveur Web, etc.);
• niveau plateforme (virtualisation, cloud, conteneur, etc.).

Surveillance des niveaux dans Dynatrace. Source

Deuxièmement, comme je l'ai dit plus tôt, Dynatrace possède une API ouverte, ce qui le rend très pratique pour l'intégrer à 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.

Voici un exemple d'interaction avec Ansible.

Source

Ci-dessous, je donnerai quelques exemples de l'automatisation exacte qui peut être effectuée. Ce n'est qu'une partie des cas; les répertorier dans votre environnement ne peut être limité que par votre imagination et les capacités de vos outils de surveillance.

1. Mauvais déploiement - restauration de version

Même si nous testons tous très bien dans un environnement de test, il y a toujours une chance qu'une nouvelle version puisse tuer votre application dans l'environnement prod. Le même facteur humain n'a pas été annulé.

Dans la figure suivante, nous voyons qu'il y a une forte augmentation du temps d'exécution des opérations sur le service. Le début de ce saut coïncide avec le temps de déploiement de l'application. Nous transférons toutes ces informations sous forme d'événements au système d'automatisation. Si l'aptitude au service du service ne se normalise pas après l'expiration de la durée spécifiée par nous, un script est automatiquement appelé qui ramène la version à l'ancienne.

Dégradation des performances après le déploiement. Source

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 a 100% d'utilisation du processeur.

Utilisation du processeur à 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, oui, un script est exécuté qui ajoute automatiquement le nœud au routage, restaurant ainsi le système dans son ensemble.

Mise à l'échelle des nœuds après un incident

3. Manque d'espace sur le disque dur - Nettoyage de disque

Je pense que beaucoup de ces processus sont déjà automatisés. À l'aide d'APM, vous pouvez également surveiller l'espace libre sur le sous-système de disque. En l'absence d'espace ou de fonctionnement lent du disque, nous appelons le script pour nettoyer ou ajouter de l'espace.


Chargement du disque à 100%

4. Faible activité utilisateur ou faible conversion - basculez entre les branches bleue et verte

Je rencontre souvent des clients utilisant deux circuits (déploiement bleu-vert) pour des applications dans l'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 cardinaux peuvent se produire qui ne sont pas immédiatement perceptibles. Cependant, une dégradation des performances et de la disponibilité peut ne pas être observée. Pour répondre rapidement à de tels changements, il est préférable d'utiliser diverses métriques qui reflètent le comportement de l'utilisateur (nombre de sessions et d'actions utilisateur, conversion, taux de rebond). La figure suivante montre un exemple dans lequel, lorsque la conversion diminue, le basculement entre les branches logicielles a lieu.

Chute de conversion après le basculement entre les branches du logiciel. Source

Mécanismes de détermination automatique des problèmes

À la fin, je donnerai un autre exemple, pour lequel j'aime le plus Dynatrace.

Dans une partie de mon histoire sur l'automatisation du contrôle qualité des assemblages dans un environnement de test, nous avons déterminé toutes les valeurs de seuil en mode manuel. 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 l'environnement de production, il est souhaitable que les problèmes soient détectés automatiquement, en tenant compte des différents mécanismes de base.

Dynatrace possède des outils d'intelligence artificielle intégrés intéressants qui, sur la base des mécanismes pour déterminer les mesures anormales (référence) et construire une carte d'interaction entre tous les composants, comparer et corréler les événements entre eux, déterminer les anomalies dans le travail de votre service et fournir des informations détaillées sur chaque problème et cause racine.

En analysant automatiquement les dépendances entre les composants, Dynatrace détermine non seulement si le service problématique est la cause principale, mais aussi sa dépendance à l'égard d'autres services. Dans l'exemple ci-dessous, Dynatrace surveille et évalue automatiquement la santé de chaque service dans le cadre d'une transaction, identifie le service Golang comme la raison principale.

Un exemple de détermination de la cause première d'une défaillance. Source

La figure suivante montre le processus de surveillance des problèmes avec votre application depuis le début de l'incident.

Visualisation d'un problème émergent avec l'affichage de tous les composants et événements sur ceux-ci

Le système de surveillance a compilé une chronologie complète des événements sur le problème. Dans la fenêtre sous la chronologie, nous voyons tous les événements clés sur chacun des composants. En fonction de ces événements, vous pouvez spécifier des procédures de correction automatique sous forme de scripts de code.

De plus, je vous conseille d'intégrer le système de surveillance avec Service Desk ou un bug tracker. En cas de problème, les développeurs reçoivent rapidement des informations complètes pour leur analyse 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 nous perturbons toujours les performances du système, nous lançons des mécanismes pour le restaurer.


Cela vaut vraiment la peine d’automatiser la surveillance 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 prod, pensez immédiatement aux moniteurs à ajouter pour les vérifications dans l'environnement de test afin d'éviter d'avoir une mauvaise construction dans le prod, et créez également un script pour résoudre automatiquement ces problèmes.

J'espère que mes exemples vous aideront dans vos efforts. Il sera également intéressant pour moi de voir vos exemples de mesures utilisées pour la mise en œuvre de systèmes d'auto-guérison.

Source