Nous avons pensé à créer un système de suivi au stade de la constitution des équipes produit. Il est devenu clair que notre métier - l'exploitation - ne relève pas de ces équipes. Pourquoi donc?
Le fait est que toutes nos équipes sont construites autour de systèmes d'information, de microservices et de fronts individuels, de sorte que les équipes ne voient pas la santé globale de l'ensemble du système dans son ensemble. Par exemple, ils ne savent peut-être pas comment une petite partie du backend profond affecte le front-end. Leur champ d’intérêt est limité aux systèmes avec lesquels leur système est intégré. Si une équipe et son service A n’ont quasiment aucun lien avec le service B, alors un tel service est presque invisible pour l’équipe.
Notre équipe, quant à elle, travaille avec des systèmes très fortement intégrés les uns aux autres : il existe de nombreuses connexions entre eux, c'est une très grande infrastructure. Et le fonctionnement de la boutique en ligne dépend de tous ces systèmes (dont nous en avons d'ailleurs un très grand nombre).
Il s'avère donc que notre département n'appartient à aucune équipe, mais se situe un peu à l'écart. Dans toute cette histoire, notre tâche est de comprendre de manière globale le fonctionnement des systèmes d'information, leurs fonctionnalités, leurs intégrations, leurs logiciels, leur réseau, leur matériel et comment tout cela est connecté les uns aux autres.
La plateforme sur laquelle opèrent nos boutiques en ligne ressemble à ceci :
- avant
- middle-office
- back-office
Peu importe à quel point nous le souhaiterions, il n’arrive pas que tous les systèmes fonctionnent correctement et parfaitement. Le problème, encore une fois, c'est le nombre de systèmes et d'intégrations - avec quelque chose comme le nôtre, certains incidents sont inévitables, malgré la qualité des tests. De plus, tant au sein d'un système distinct qu'en termes de leur intégration. Et vous devez surveiller l’état de l’ensemble de la plateforme, et pas n’importe quelle partie individuelle de celle-ci.
Idéalement, la surveillance de l’état de santé à l’échelle de la plateforme devrait être automatisée. Et nous en sommes venus à considérer le suivi comme une partie inévitable de ce processus. Initialement, il a été construit uniquement pour la partie de première ligne, tandis que les spécialistes des réseaux, les administrateurs de logiciels et de matériel possédaient et ont toujours leurs propres systèmes de surveillance couche par couche. Tous ces gens n'ont suivi le suivi qu'à leur niveau, personne non plus n'en avait une compréhension globale.
Par exemple, si une machine virtuelle tombe en panne, dans la plupart des cas, seul l'administrateur responsable du matériel et de la machine virtuelle en est informé. Dans de tels cas, l'équipe de première ligne a constaté le crash même de l'application, mais elle ne disposait pas de données sur le crash de la machine virtuelle. Et l'administrateur peut savoir qui est le client et avoir une idée approximative de ce qui s'exécute actuellement sur cette machine virtuelle, à condition qu'il s'agisse d'un projet de grande envergure. Il ne connaît probablement pas les plus petits. Dans tous les cas, l'administrateur doit s'adresser au propriétaire et lui demander ce qu'il y avait sur cette machine, ce qui doit être restauré et ce qui doit être modifié. Et si quelque chose de vraiment grave tombait en panne, ils se mettaient à tourner en rond - parce que personne ne voyait le système dans son ensemble.
En fin de compte, ces histoires disparates affectent l’ensemble du frontend, les utilisateurs et notre fonction principale : la vente en ligne. Étant donné que nous ne faisons pas partie d'une équipe, mais que nous sommes engagés dans l'exploitation de toutes les applications de commerce électronique dans le cadre d'une boutique en ligne, nous nous sommes chargés de créer un système de surveillance complet pour la plateforme de commerce électronique.
Structure et pile du système
Nous avons commencé par identifier plusieurs couches de surveillance pour nos systèmes, au sein desquelles nous devions collecter des métriques. Et il fallait combiner tout cela, ce que nous avons fait dans un premier temps. À ce stade, nous finalisons une collection de métriques de la plus haute qualité sur toutes nos couches afin d’établir une corrélation et de comprendre comment les systèmes s’influencent mutuellement.
Le manque de surveillance complète dès les premières étapes du lancement de l'application (puisque nous avons commencé à la construire alors que la plupart des systèmes étaient en production) a conduit au fait que nous avions une dette technique importante pour mettre en place une surveillance de l'ensemble de la plateforme. Nous ne pouvions pas nous permettre de nous concentrer sur la mise en place d'une surveillance pour un SI et sur l'élaboration d'une surveillance détaillée de celui-ci, car le reste des systèmes resterait sans surveillance pendant un certain temps. Pour résoudre ce problème, nous avons identifié une liste des métriques les plus nécessaires pour évaluer l'état du système d'information par couche et avons commencé à la mettre en œuvre.
Par conséquent, ils ont décidé de manger l’éléphant en morceaux.
Notre système se compose de :
- Matériel;
- système opérateur;
- logiciels;
- Parties de l'interface utilisateur dans l'application de surveillance ;
- mesures commerciales ;
- applications d'intégration ;
- sécurité de l'information;
- réseaux;
- équilibreur de trafic.
Au centre de ce système se trouve le contrôle lui-même. Pour comprendre de manière générale l'état de l'ensemble du système, vous devez savoir ce qui se passe avec les applications sur toutes ces couches et dans l'ensemble des applications.
Donc, à propos de la pile.
Nous utilisons des logiciels open source. Au centre, nous avons Zabbix, que nous utilisons principalement comme système d'alerte. Tout le monde sait qu’il est idéal pour la surveillance des infrastructures. Qu'est-ce que cela signifie? Exactement ces métriques de bas niveau dont dispose chaque entreprise qui gère son propre centre de données (et Sportmaster possède ses propres centres de données) : température du serveur, état de la mémoire, raid, métriques des périphériques réseau.
Nous avons intégré Zabbix à Telegram Messenger et Microsoft Teams, qui sont activement utilisés en équipe. Zabbix couvre la couche du réseau lui-même, du matériel et de certains logiciels, mais ce n'est pas une panacée. Nous enrichissons ces données à partir de certains autres services. Par exemple, au niveau matériel, nous nous connectons directement via API à notre système de virtualisation et collectons des données.
Quoi d'autre. En plus de Zabbix, nous utilisons Prometheus, qui nous permet de surveiller les métriques dans une application à environnement dynamique. Autrement dit, nous pouvons recevoir des métriques d'application via un point de terminaison HTTP sans nous soucier des métriques à y charger et de celles non. Sur la base de ces données, des requêtes analytiques peuvent être développées.
Les sources de données pour d'autres couches, par exemple les mesures commerciales, sont divisées en trois composants.
Premièrement, il s'agit de systèmes commerciaux externes, Google Analytics, nous collectons des métriques à partir des journaux. D'eux, nous obtenons des données sur les utilisateurs actifs, les conversions et tout ce qui concerne l'entreprise. Deuxièmement, il s’agit d’un système de surveillance de l’interface utilisateur. Il convient de le décrire plus en détail.
Autrefois, nous commencions par des tests manuels et cela s'est transformé en tests automatiques de fonctionnalités et d'intégrations. À partir de là, nous avons réalisé un suivi, en ne laissant que la fonctionnalité principale, et en nous appuyant sur des marqueurs aussi stables que possible et qui ne changent pas souvent dans le temps.
La nouvelle structure d'équipe signifie que toutes les activités d'application sont confinées aux équipes produit, nous avons donc arrêté de faire des tests purs. Au lieu de cela, nous avons effectué une surveillance de l'interface utilisateur à partir des tests écrits en Java, Selenium et Jenkins (utilisés comme système de lancement et de génération de rapports).
Nous avons fait beaucoup de tests, mais finalement nous avons décidé d'aller sur la route principale, la métrique de haut niveau. Et si nous avons beaucoup de tests spécifiques, il sera difficile de maintenir les données à jour. Chaque version ultérieure brisera considérablement l'ensemble du système, et tout ce que nous ferons est de le réparer. C’est pourquoi nous nous sommes concentrés sur des choses très fondamentales qui changent rarement et nous nous contentons de les surveiller.
Enfin, troisièmement, la source de données est un système de journalisation centralisé. Nous utilisons Elastic Stack pour les journaux, puis nous pouvons extraire ces données dans notre système de surveillance pour les métriques commerciales. En plus de tout cela, nous disposons de notre propre service API de surveillance, écrit en Python, qui interroge tous les services via l'API et collecte leurs données dans Zabbix.
Un autre attribut indispensable de la surveillance est la visualisation. Le nôtre est basé sur Grafana. Il se distingue des autres systèmes de visualisation en ce qu'il vous permet de visualiser les métriques de différentes sources de données sur le tableau de bord. Nous pouvons collecter des métriques de niveau supérieur pour une boutique en ligne, par exemple le nombre de commandes passées au cours de la dernière heure à partir du SGBD, des métriques de performances pour le système d'exploitation sur lequel cette boutique en ligne s'exécute à partir de Zabbix et des métriques pour les instances de cette application. de Prométhée. Et tout cela sera sur un seul tableau de bord. Clair et accessible.
Permettez-moi de noter concernant la sécurité : nous finalisons actuellement le système, que nous intégrerons plus tard au système de surveillance mondial. À mon avis, les principaux problèmes auxquels le commerce électronique est confronté dans le domaine de la sécurité de l'information sont liés aux robots, aux analyseurs et à la force brute. Nous devons garder cela à l’œil, car tout cela peut avoir un impact critique à la fois sur le fonctionnement de nos applications et sur notre réputation d’un point de vue commercial. Et avec la pile choisie, nous accomplissons avec succès ces tâches.
Un autre point important est que la couche application est assemblée par Prometheus. Lui-même est également intégré à Zabbix. Et nous avons aussi sitespeed, un service qui nous permet de visualiser des paramètres tels que la vitesse de chargement de notre page, les goulots d'étranglement, le rendu des pages, le chargement des scripts, etc., il est également intégré à l'API. Nos métriques sont donc collectées dans Zabbix et, par conséquent, nous alertons également à partir de là. Toutes les alertes sont actuellement envoyées vers les principaux modes d'envoi (pour l'instant c'est l'email et le télégramme, MS Teams s'est également connecté récemment). Il est prévu de mettre à niveau les alertes jusqu'à ce que les robots intelligents fonctionnent comme un service et fournissent des informations de surveillance à toutes les équipes produit intéressées.
Pour nous, les métriques sont importantes non seulement pour les systèmes d'information individuels, mais aussi pour l'ensemble de l'infrastructure utilisée par les applications : clusters de serveurs physiques sur lesquels s'exécutent les machines virtuelles, équilibreurs de trafic, Network Load Balancers, le réseau lui-même, utilisation des canaux de communication. . Plus des métriques pour nos propres centres de données (nous en avons plusieurs et l'infrastructure est assez grande).
Les avantages de notre système de surveillance sont qu'avec son aide, nous voyons l'état de santé de tous les systèmes et pouvons évaluer leur impact les uns sur les autres et sur les ressources partagées. Et finalement, cela nous permet de nous engager dans la planification des ressources, qui relève également de notre responsabilité. Nous gérons les ressources du serveur - un pool au sein du commerce électronique, mettons en service et mettons hors service de nouveaux équipements, achetons de nouveaux équipements supplémentaires, effectuons un audit de l'utilisation des ressources, etc. Chaque année, les équipes planifient de nouveaux projets, font évoluer leurs systèmes, et il est important pour nous de leur apporter des ressources.
Et à l’aide de métriques, nous voyons l’évolution de la consommation de ressources par nos systèmes d’information. Et sur cette base, nous pouvons planifier quelque chose. Au niveau de la virtualisation, nous collectons des données et observons des informations sur la quantité de ressources disponibles par centre de données. Et déjà à l’intérieur du centre de données, vous pouvez voir le recyclage, la distribution réelle et la consommation des ressources. De plus, tant avec des serveurs autonomes et des machines virtuelles qu'avec des clusters de serveurs physiques sur lesquels toutes ces machines virtuelles tournent vigoureusement.
Perspectives
Nous avons désormais le cœur du système dans son ensemble prêt, mais il reste encore beaucoup de choses sur lesquelles il faut travailler. Il s'agit au minimum d'une couche de sécurité de l'information, mais il est également important d'atteindre le réseau, de développer les alertes et de résoudre le problème de corrélation. Nous avons de nombreuses couches et systèmes, et sur chaque couche il y a beaucoup plus de mesures. Il s'avère qu'il s'agit d'une matriochka au degré de matriochka.
Notre tâche est finalement de lancer les bonnes alertes. Par exemple, s'il y avait un problème avec le matériel, encore une fois, avec une machine virtuelle, et qu'il y avait une application importante, et que le service n'était en aucun cas sauvegardé. Nous découvrons que la machine virtuelle est morte. Ensuite, les métriques commerciales vous alerteront : des utilisateurs ont disparu quelque part, il n'y a pas de conversion, l'interface utilisateur de l'interface est indisponible, les logiciels et services sont également morts.
Dans cette situation, nous recevrons du spam provenant d’alertes, ce qui ne rentre plus dans le format d’un véritable système de surveillance. La question de la corrélation se pose. Par conséquent, idéalement, notre système de surveillance devrait dire : « Les gars, votre machine physique est morte, et avec elle cette application et ces métriques », à l'aide d'une seule alerte, au lieu de nous bombarder furieusement d'une centaine d'alertes. Il doit signaler l'essentiel - la cause, ce qui permet d'éliminer rapidement le problème dû à sa localisation.
Notre système de notification et de traitement des alertes s'articule autour d'un service d'assistance téléphonique XNUMXh/XNUMX. Toutes les alertes considérées comme indispensables et incluses dans la liste de contrôle y sont envoyées. Chaque alerte doit avoir une description : ce qui s'est passé, ce qu'elle signifie réellement, ce qu'elle affecte. Et aussi un lien vers le tableau de bord et des instructions sur la marche à suivre dans ce cas.
Tout dépend des conditions requises pour créer une alerte. La situation peut alors évoluer dans deux directions : soit il y a un problème qui doit être résolu, soit il y a une défaillance du système de surveillance. Mais dans tous les cas, il faut aller le découvrir.
En moyenne, nous recevons désormais une centaine d'alertes par jour, compte tenu du fait que la corrélation des alertes n'est pas encore correctement configurée. Et si nous devons effectuer des travaux techniques et que nous éteignons de force quelque chose, leur nombre augmente considérablement.
En plus de surveiller les systèmes que nous exploitons et de collecter des métriques considérées comme importantes de notre côté, le système de surveillance nous permet de collecter des données pour les équipes produit. Ils peuvent influencer la composition des métriques au sein des systèmes d’information que nous surveillons.
Notre collègue peut venir demander d'ajouter une métrique qui sera utile à la fois pour nous et pour l'équipe. Ou, par exemple, l'équipe peut ne pas disposer de suffisamment de mesures de base dont nous disposons ; elle doit en suivre certaines spécifiques. Chez Grafana, nous créons un espace pour chaque équipe et accordons des droits d'administrateur. De plus, si une équipe a besoin de tableaux de bord, mais qu’elle-même ne peut/ne sait pas comment le faire, nous l’aidons.
Puisque nous sommes en dehors du flux de création de valeur de l’équipe, de leurs versions et de leur planification, nous arrivons progressivement à la conclusion que les versions de tous les systèmes sont transparentes et peuvent être déployées quotidiennement sans coordination avec nous. Et il est important pour nous de surveiller ces versions, car elles pourraient potentiellement affecter le fonctionnement de l’application et casser quelque chose, ce qui est essentiel. Pour gérer les versions, nous utilisons Bamboo, d'où nous recevons des données via API et pouvons voir quelles versions ont été publiées dans quels systèmes d'information et leur statut. Et le plus important est de savoir à quelle heure. Nous superposons des marqueurs de version sur les principales métriques critiques, ce qui est visuellement très indicatif en cas de problème.
De cette façon, nous pouvons voir la corrélation entre les nouvelles versions et les problèmes émergents. L'idée principale est de comprendre comment le système fonctionne à tous les niveaux, de localiser rapidement le problème et de le résoudre tout aussi rapidement. Après tout, il arrive souvent que ce qui prend le plus de temps n’est pas de résoudre le problème, mais d’en rechercher la cause.
Et dans ce domaine, nous souhaitons à l’avenir miser sur la proactivité. Idéalement, j’aimerais être informé d’un problème imminent à l’avance, et non après coup, afin de pouvoir le prévenir plutôt que de le résoudre. Parfois, de fausses alarmes du système de surveillance se produisent, à la fois en raison d'une erreur humaine et de modifications de l'application. Et nous travaillons là-dessus, le débogueons et essayons d'en avertir les utilisateurs qui l'utilisent avec nous avant toute manipulation du système de surveillance. , ou réalisez ces activités dans la fenêtre technique.
Le système est donc lancé et fonctionne avec succès depuis le début du printemps... et affiche des bénéfices bien réels. Bien entendu, il ne s’agit pas de la version finale ; nous y introduisons de nombreuses autres fonctionnalités utiles. Mais à l’heure actuelle, avec autant d’intégrations et d’applications, l’automatisation de la surveillance est vraiment inévitable.
Si vous surveillez également de grands projets avec un nombre important d'intégrations, écrivez dans les commentaires quelle solution miracle vous avez trouvée pour cela.
Source: habr.com