Bonjour ! Je m'appelle Pasha Cherniak, je suis développeur principal chez QIWI, et aujourd'hui je veux parler de l'inévitable. À propos de l'héritage.
Commençons par une question : qu'est-ce qu'un service hérité ? Est-ce un service que le développeur n'a pas touché depuis une semaine/mois/an ? Ou est-ce un service qui a été écrit par un programmeur moins expérimenté, par exemple vous-même, mais il y a un an ? Et maintenant, vous êtes meilleur et plus expérimenté. Ou alors, un service hérité est-il un service que vous avez décidé de ne plus jamais engager et que vous préparez lentement à remplacer ? Quoi qu'il en soit, laisser un tel service sans surveillance et sans mise à jour est une bombe à retardement qui peut exploser plus tard.
Avant de parler de la façon dont nous travaillons avec nos services hérités chez QIWI, je vais expliquer comment nous avons mis de l'ordre dans les services de Wallet. Cela fait déjà deux ans que je suis responsable de son bon fonctionnement. S'il y a un problème, c'est toujours à moi qu'on téléphone en premier. Généralement, je n'ai pas le culot d'appeler quelqu'un d'autre à 23 heures, donc je devais m'asseoir et me pencher sur tous les services de notre domaine.
Mais, comme tout le monde, j'aime dormir la nuit, donc j'ai essayé de comprendre l'exploitation : « Les gars, pourquoi m'appelez-vous ? ». La réponse que j'ai reçue était assez succincte : « Et à qui d'autre ? ». Parce que je répare des services, et en plus les gars ne savent tout simplement pas à qui appeler.
C'est pourquoi, lors d'une rétrospective de l'équipe backend de Wallet, nous avons décidé de créer un tableau listant nos services, microservices et monolithes de Wallet, ainsi que les responsables de chacun. Les tableaux sont en général utiles, dans des limites raisonnables.
En plus des informations sur qui est responsable de quoi, il y avait des réponses à des questions : 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 en cas de besoin. Le propriétaire du service a le droit de laisser +2 dans les commits, et les responsables doivent également être présents lors de la revue avant que ce service n'accepte un nouveau commit.
Le temps passait, de nouvelles pratiques ont été mises en place, comme la migration vers Kubernetes, divers checkstyle, spotbugs, ktlint, la présence de logs dans Kibana, l'autodiscovery des services au lieu d'indiquer directement les adresses, et d'autres fonctionnalités utiles. Et partout, notre tableau permettait de suivre l'actualité de nos services. Pour nous, c'est une sorte de liste de contrôle qui indique ce que ce service peut faire et ce qu'il ne peut pas encore. Mais nous allions plus loin, comprenant que nous manquions d'informations sur nos services : où se trouvent les sources du service, où les tâches de build sont lancées dans TeamCity, comment elles sont déployées, où se trouvent les sources des tests end2end, des photos de grazing sur l'architecture, sur les décisions prises. Idéalement, nous souhaitions que toutes ces informations soient disponibles quelque part, à portée de main. C'est pourquoi notre tableau est devenu un point de départ pour rechercher des informations.
Mais QIWI, bien que conservant l'esprit d'une start-up, est une grande entreprise. Nous avons déjà 12 ans, et les équipes évoluent : des gens partent, d'autres arrivent, de nouvelles équipes se forment. Et nous avons découvert sur notre domaine plusieurs services hérités. Certains sont venus avec des développeurs d'autres équipes, d'autres étaient reliés de manière indirecte au Wallet, c'est pourquoi ces services sont maintenant dans notre balance. Pourquoi se donner la peine de comprendre ce qui fonctionne et comment ? Le service fonctionne, et nous avons des fonctionnalités produits qu'il faut impérativement développer.
Comme cela arrive.
Mais à un moment donné, nous réalisons que le service ne remplit plus sa fonction, que quelque chose est tombé en panne — que faire dans une telle situation ? Le service a tout simplement cessé de fonctionner. Complètement. Et nous l'avons appris, d'une part, par accident, et d'autre part, six mois plus tard. Cela arrive. La seule chose que nous savions — sur quelles machines virtuelles le service était déployé, où se trouvaient ses sources, et c'est tout. Nous faisons un git clone et nous plongeons dans les pensées de la personne qui a écrit cela il y a quelques années, mais que voyons-nous ? Aucune trace de Spring Boot que nous connaissons si bien, bien que nous soyons full stack et tout ça. Peut-être y a-t-il Spring Framework ? Eh bien, non.
Le gars qui a écrit tout ça était strict et écrivait tout en Java pur. Il n'y a pas d'outils habituels pour les développeurs, et l'idée émerge — il faudrait tout réécrire. Nous avons des microservices, et de chaque toaster, on entend le traditionnel « Les gars, les microservices, c'est ce dont vous avez besoin ! ». Si jamais quelque chose ne va pas, vous pouvez prendre n'importe quel langage et tout ira bien.
Le problème est qu'actuellement, nous n'avons pas de client qui répond à ce service. Quelles étaient ses exigences commerciales, que doit faire ce service ? Ce service est profondément intégré dans vos processus commerciaux.
Alors, dites-moi combien il est simple de réécrire un service sans connaître ses exigences commerciales ? On ne sait pas comment le service est loggé, s'il y a des métriques — c'est inconnu. Quelles sont-elles, s'il y en a — encore plus inconnu. Et en plus, le service contient une énorme quantité de classes de logique métier non identifiable. Certaines données vont dans une base de données, dont nous ne savons rien pour l'instant.
Par quoi commencer ?
Par la chose la plus logique — avoir des tests. Là, on écrit généralement au moins une certaine logique et on peut tirer des conclusions sur ce qui se passe. Actuellement, TDD est à la mode, mais nous remarquons que même il y a 5 ans, tout était pratiquement le même qu'aujourd'hui : il y a presque pas de tests unitaires, et ils ne nous diront pas grand-chose. À part peut-être une certaine vérification, comme la manière dont un xml est signé avec un certificat personnalisé.
Nous n'avons rien pu comprendre à partir du code, et nous avons dû aller vérifier ce qui se passait sur la machine virtuelle. Nous avons ouvert les journaux du service et trouvé une erreur dans le client http, un certificat auto-signé qui avait été intégré aux ressources de l'application, et qui avait sérieusement expiré. Nous avons contacté nos analystes, ils ont demandé un nouveau certificat, qui nous a été délivré et le service fonctionne à nouveau. Cela semble être la fin. Ou peut-être pas ? Le service fonctionne, il remplit une fonction qui est nécessaire pour notre entreprise. Nous avons des normes de développement d'applications, qui existent probablement aussi chez vous. Par exemple, ne pas stocker les journaux sur le nœud dans un dossier, mais les conserver dans un type de stockage, comme Elastic, et les consulter dans Kibana. On peut se rappeler des métriques dorées. Autrement dit, la charge sur le service, le nombre de requêtes vers le service, s'il est vivant ou non, comment se passe son HealthCheck. Dans tous les cas, ces métriques aideront à savoir quand il peut être retiré de l'exploitation et oublié comme un mauvais rêve.
Que faire
C'est pourquoi nous ajoutons ce vieux service dans le tableau, puis nous allons chercher des développeurs volontaires qui s'occuperont du service et le remettront en ordre : écrire au moins des informations sur le service, ajouter des liens vers les tableaux de bord dans Grafana, vers les tâches de compilation, comprendre comment déployer l'application, il ne s'agit pas de balancer des fichiers par FTP.
La question principale est de savoir combien de temps toute cette activité bénévole prendra. Un sprint pour un développeur plus ou moins expérimenté, par exemple, lors d'un 20 % de dette technique. Et combien de temps il a fallu pour comprendre toute la logique enracinée liée à la communication avec un certain système gouvernemental, pour la mettre à jour avec des technologies plus récentes ? Je ne peux pas le garantir, ça pourrait prendre un mois, ou peut-être deux pour l’équipe. C'est par expérience d'intégration actuelle avec un nouveau service que je le dis.
À ce stade, il n'y a aucune valeur ajoutée pour l'entreprise. Rien du tout. Prendre le service sous support et y consacrer un peu de temps est normal. Mais après nos danses habituelles avec le service, nous l'avons ajouté au tableau, ajouté des informations à son sujet, et peut-être qu'un jour nous le réécrirons. Mais maintenant, il répond à nos normes de fonctionnement des services.
En fin de compte, j'aimerais arriver à un certain plan pour que faire avec les services Legacy.
Réécrire les legacy from scratch est une mauvaise idée.
Sérieusement, il n'est même pas nécessaire d'y penser. Il est clair que cela pourrait être souhaité, et qu'il y a des avantages, mais généralement, cela n'est nécessaire pour personne, y compris vous-même.
Répertoire
Déterrez le code source de vos applications, créez un répertoire indiquant ce qui est où et comment cela fonctionne, et ajoutez une description du projet (un readme.md conditionnel) afin de comprendre rapidement où se trouvent les journaux et les métriques. Le développeur qui s'en occupera après vous ne pourra que vous remercier.
Comprenez le domaine
Si vous avez un domaine, essayez de rester à l'affût. Ça peut sembler banal, mais tout le monde ne surveille pas si les services sont cohérents. En fait, travailler selon un même standard est beaucoup plus simple.
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Que faites-vous avec votre héritage ?
31.5%Je le réécris depuis le début, c'est plus correct.
52.6%À peu près la même chose que vous.
10.5%Nous n'avons pas d'héritage, nous sommes super.
5.2%Je vais écrire dans les commentaires.
38 utilisateurs ont voté. 20 utilisateurs se sont abstenus.
Source : habr.com
