Services hérités dans votre infrastructure

Bonjour! Je m'appelle Pasha Chernyak, je suis l'un des principaux développeurs chez QIWI et aujourd'hui je veux parler de l'inévitable. À propos de l'héritage.

Commençons par la question : qu'est-ce que le service Legacy ? Un service existant est-il un service auquel le développeur n’a pas touché depuis une semaine/mois/année ? Ou s'agit-il d'un service qui a été écrit par un programmeur moins expérimenté, par exemple par vous en particulier, mais il y a un an ? Et maintenant, vous êtes plus cool et plus expérimenté. Ou le service Legacy est-il un service que vous avez décidé de ne plus jamais engager et que vous préparez lentement un remplacement ? Dans tous les cas, laisser un tel service sans surveillance et sans mise à jour est une bombe à retardement qui pourrait exploser plus tard.

Avant de passer à la façon dont nous travaillons chez QIWI avec nos services Legacy, je vais vous expliquer comment nous avons mis de l'ordre dans les services du Wallet. Depuis maintenant deux ans, je suis responsable de sa réalisation. S'il y a un problème, ils m'appellent toujours en premier. Je n'ai généralement pas le courage d'appeler quelqu'un d'autre à 11 heures, j'ai donc dû m'asseoir et découvrir tous les services de notre domaine.

Mais comme toute personne, j'aime dormir la nuit, alors j'ai essayé de faire face à l'exploitation : « Les gars, pourquoi m'appelez-vous ? À quoi j’ai reçu une réponse assez laconique du type « Qui d’autre ? Parce que je répare les services et que les gars ne savent tout simplement pas qui appeler.

Par conséquent, lors de l'une des rétrospectives de l'équipe backend de Wallet, nous avons décidé que nous devions faire une pancarte avec une liste de nos services, microservices et monolithes de portefeuille, ainsi que de leurs responsables. La signalisation est généralement utile, dans des limites raisonnables.

En plus des informations sur qui est responsable de quoi, des réponses aux questions ont été trouvées : qui est le propriétaire du service, qui est responsable de son développement, de son architecture et de son cycle de vie. Les personnes responsables de ce service sont celles qui peuvent le réparer si quelque chose arrive. Le propriétaire du service a le droit de laisser +2 dans les commits, les responsables doivent également être présents à la révision avant que ce service n'accepte un nouveau commit.

Au fil du temps, de nouvelles pratiques ont commencé à être appliquées, par exemple la migration vers Kubernetes, toutes sortes de checkstyle, les spotbugs, ktlint, la présence de journaux dans Kibana, les services de découverte automatique au lieu de spécifier directement des adresses et d'autres choses utiles. Et partout notre table nous a permis de maintenir la pertinence de nos prestations. Pour nous, c'est une sorte de liste de contrôle qui dit que ce service peut le faire, mais ce n'est pas encore le cas. Mais nous sommes passés à autre chose, réalisant que nous manquions d'informations sur nos services, que nous surveillons, où se trouvent les sources de services, où les tâches d'assemblage sont lancées dans TeamCity, comment elles sont déployées, où sont stockées les sources des tests end2end, des photos des sessions de toilettage sur l'architecture, sur les décisions prises. Idéalement, j’aimerais que toutes ces informations se trouvent quelque part et soient à portée de main en cas de besoin. Notre signe est donc devenu le point de départ de la recherche d’informations.

Mais QIWI, même si elle conserve l’esprit d’une startup, est une grande entreprise. Nous avons déjà 12 ans, et les équipes changent : les gens partent, les gens viennent, de nouvelles équipes se forment. Et nous avons découvert plusieurs services sur notre domaine dont nous avons hérité. Certains provenaient de développeurs d'autres équipes, d'autres étaient simplement indirectement liés au portefeuille, nous avons donc maintenant le service dans notre bilan. Comprendre quoi et comment ça marche - pourquoi ? Le service fonctionne et nous avons des fonctionnalités de produit qui doivent absolument être améliorées.

Comment ça se passe

Mais à un moment donné, nous découvrons que le service cesse de remplir sa fonction, quelque chose est cassé - que faire dans une telle situation ? Le service a tout simplement cessé de fonctionner. Du tout. Et nous l’avons découvert, d’une part par hasard, et d’autre part, six mois plus tard. Ça arrive. La seule chose que nous savions, c’était sur quelles machines virtuelles le service serait déployé, où se trouvaient ses sources, et c’est tout. Nous faisons un clone de Git et plongeons dans l'esprit de la personne qui a écrit ceci il y a quelques années, mais que voyons-nous ? Aucun des Spring Boot qui nous sont familiers, même si nous sommes habitués à tout, nous avons une pile complète et tout ça. Peut-être qu'il y a un Spring Framework là-bas ? Mais non.

Le gars qui a écrit tout cela était dur et a tout écrit en Java pur. Il n’y a pas d’outils habituels pour un développeur, et une idée surgit : il faut réécrire tout cela. Nous avons des microservices, et de chaque grille-pain vient l'habituel « Les gars, les microservices sont ce dont vous avez besoin ! Si soudainement quelque chose ne va pas, vous pouvez calmement prendre n'importe quelle langue et tout ira bien.

Le fait est que nous n’avons plus de client responsable de ce service. Quelles exigences commerciales avait-il, que devait faire ce service ? Et le service est étroitement intégré à vos processus métier.

Maintenant, dites-moi, est-il facile de réécrire un service sans connaître ses exigences métier ? On ne sait pas clairement comment le service est enregistré ; on ne sait pas s'il existe des métriques. Ce qu’ils sont, le cas échéant, est d’autant plus inconnu. Et en même temps, le service contient un grand nombre de classes de logique métier incompréhensible. Quelque chose est inclus dans une sorte de base de données, dont nous ne savons encore rien non plus.

Avec quoi commencer?

Du point le plus logique – la disponibilité des tests. Il y a généralement au moins une certaine logique écrite ici et vous pouvez tirer des conclusions sur ce qui se passe. Maintenant, le TDD est à la mode, mais on voit qu'il y a 5 ans, tout était presque pareil qu'aujourd'hui : il n'y a presque pas de tests unitaires, et ils ne nous diront rien du tout. Eh bien, sauf peut-être une sorte de vérification, comment certains XML sont signés avec un certificat personnalisé.

Nous ne comprenions rien au code, alors nous sommes allés voir ce qu’il y avait dans la machine virtuelle. Nous avons ouvert les journaux de service et y avons trouvé une erreur du client http ; le certificat auto-signé qui était intégré dans les ressources de l'application était sans vergogne pourri. Nous avons contacté nos analystes, ils ont demandé un nouveau certificat, ils nous l'ont délivré et le service fonctionne à nouveau. Il semblerait que ce soit tout. Ou non? Après tout, le service fonctionne, il remplit certaines fonctions dont notre entreprise a besoin. Nous avons certaines normes pour le développement d’applications, que vous possédez probablement aussi. Par exemple, ne stockez pas les journaux sur le nœud dans un dossier, mais stockez-les dans un type de stockage, tel qu'un élastique, et consultez-les dans Kibana. Vous pouvez également vous souvenir des métriques dorées. C'est-à-dire la charge du service, le nombre de demandes de service, s'il est vivant ou non, comment se déroule son HealthCheck. À tout le moins, ces mesures vous aideront à savoir quand il peut être mis hors service en toute conscience et oublié comme un mauvais rêve.

Que faire

Par conséquent, nous ajoutons un service si ancien à la table, puis nous recherchons des volontaires parmi les développeurs qui s'occuperont du service et le mettront en ordre : ils écriront au moins quelques informations sur le service, ajouteront des liens vers tableaux de bord dans grafana, pour les tâches d'assemblage et comprendre comment déployer l'application, ne téléchargez pas manuellement de fichiers à l'aide de FTP.

L'essentiel est de savoir combien de temps durera toute cette activité bénévole utile ? Un sprint pour un développeur plus ou moins expérimenté, par exemple lors d'une dette technique de 20%. Combien de temps a-t-il fallu pour comprendre toute la logique enracinée de la communication avec un certain système étatique et l’adapter aux technologies les plus récentes ? Je ne peux pas garantir cela, peut-être un mois ou peut-être deux du travail de l’équipe. Je dis cela à partir de l'expérience de l'intégration actuelle avec un nouveau service.

Dans le même temps, il n’y a aucune libération de valeur commerciale. Du tout. Il est normal de faire appel à un service d’assistance et d’y consacrer un peu de temps. Mais après nos danses standards avec le service, nous l'avons ajouté au tableau, ajouté des informations à ce sujet et, peut-être, le réécrirons un jour. Mais maintenant, il répond à nos normes de service.

En conséquence, j'aimerais élaborer un plan sur ce qu'il faut faire avec les services hérités.

Réécrire l'héritage à partir de zéro est une mauvaise idée
Sérieusement, vous n'avez même pas besoin d'y penser. Il est clair que j’aimerais cela, et il y a certains avantages, mais généralement personne n’en a besoin, y compris vous-même.

Annuaire
Déterrez les codes sources de vos applications, réalisez un ouvrage de référence qui indiquera ce qui se trouve, où et comment cela fonctionne, saisissez-y une description du projet (readme.md conditionnel) pour comprendre rapidement où se trouvent les logs et les métriques. Le développeur qui s'en chargera après vous vous dira seulement merci.

Comprendre le domaine
Si vous possédez un domaine, essayez de rester à l’écoute. Cela semble trivial, certes, mais tout le monde ne s'assure pas que les services sont dans une seule clé. Mais travailler selon une seule norme est en réalité beaucoup plus facile.

Seuls les utilisateurs enregistrés peuvent participer à l'enquête. se connecters'il te plait.

Que faites-vous de votre héritage ?

• 31.5%Je réécris à partir de zéro, c'est plus correct 12

• 52.6%Presque pareil que toi20

• 10.5%Nous n'avons pas d'héritage, nous sommes géniaux4

• 5.2%j'écrirai dans les commentaires2

38 utilisateurs ont voté. 20 utilisateurs se sont abstenus.

Source: habr.com