{"id":53442,"date":"2019-12-02T00:00:00","date_gmt":"2019-12-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/legacy-servisy-v-vashej-infrastrukture"},"modified":"2020-02-18T14:01:20","modified_gmt":"2020-02-18T11:01:20","slug":"legacy-servisy-v-vashej-infrastrukture","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/legacy-servisy-v-vashej-infrastrukture","title":{"rendered":"Services Legacy dans votre infrastructure","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour ! Je m'appelle Pasha Cherniak, je suis d\u00e9veloppeur principal chez QIWI, et aujourd'hui je veux parler de l'in\u00e9vitable. \u00c0 propos de l'h\u00e9ritage.<\/p>\n

Commen\u00e7ons par une question : qu'est-ce qu'un service h\u00e9rit\u00e9 ? Est-ce un service que le d\u00e9veloppeur n'a pas touch\u00e9 depuis une semaine\/mois\/an ? Ou est-ce un service qui a \u00e9t\u00e9 \u00e9crit par un programmeur moins exp\u00e9riment\u00e9, par exemple vous-m\u00eame, mais il y a un an ? Et maintenant, vous \u00eates meilleur et plus exp\u00e9riment\u00e9. Ou alors, un service h\u00e9rit\u00e9 est-il un service que vous avez d\u00e9cid\u00e9 de ne plus jamais engager et que vous pr\u00e9parez lentement \u00e0 remplacer ? Quoi qu'il en soit, laisser un tel service sans surveillance et sans mise \u00e0 jour est une bombe \u00e0 retardement qui peut exploser plus tard.<\/p>\n

\"Services<\/a><\/noindex><\/p>\n

Avant de parler de la fa\u00e7on dont nous travaillons avec nos services h\u00e9rit\u00e9s chez QIWI, je vais expliquer comment nous avons mis de l'ordre dans les services de Wallet. Cela fait d\u00e9j\u00e0 deux ans que je suis responsable de son bon fonctionnement. S'il y a un probl\u00e8me, c'est toujours \u00e0 moi qu'on t\u00e9l\u00e9phone en premier. G\u00e9n\u00e9ralement, je n'ai pas le culot d'appeler quelqu'un d'autre \u00e0 23 heures, donc je devais m'asseoir et me pencher sur tous les services de notre domaine. <\/p>\n

Mais, comme tout le monde, j'aime dormir la nuit, donc j'ai essay\u00e9 de comprendre l'exploitation : \u00ab Les gars, pourquoi m'appelez-vous ? \u00bb. La r\u00e9ponse que j'ai re\u00e7ue \u00e9tait assez succincte : \u00ab Et \u00e0 qui d'autre ? \u00bb. Parce que je r\u00e9pare des services, et en plus les gars ne savent tout simplement pas \u00e0 qui appeler.<\/p>\n

C'est pourquoi, lors d'une r\u00e9trospective de l'\u00e9quipe backend de Wallet, nous avons d\u00e9cid\u00e9 de cr\u00e9er un tableau listant nos services, microservices et monolithes de Wallet, ainsi que les responsables de chacun. Les tableaux sont en g\u00e9n\u00e9ral utiles, dans des limites raisonnables.
\n<\/a><\/noindex>
\nEn plus des informations sur qui est responsable de quoi, il y avait des r\u00e9ponses \u00e0 des questions : qui est le propri\u00e9taire du service, qui est responsable de son d\u00e9veloppement, de son architecture et de son cycle de vie. Les personnes responsables de ce service sont celles qui peuvent le r\u00e9parer en cas de besoin. Le propri\u00e9taire du service a le droit de laisser +2 dans les commits, et les responsables doivent \u00e9galement \u00eatre pr\u00e9sents lors de la revue avant que ce service n'accepte un nouveau commit.<\/p>\n

Le temps passait, de nouvelles pratiques ont \u00e9t\u00e9 mises en place, comme la migration vers Kubernetes, divers checkstyle, spotbugs, ktlint, la pr\u00e9sence de logs dans Kibana, l'autodiscovery des services au lieu d'indiquer directement les adresses, et d'autres fonctionnalit\u00e9s utiles. Et partout, notre tableau permettait de suivre l'actualit\u00e9 de nos services. Pour nous, c'est une sorte de liste de contr\u00f4le 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\u00f9 se trouvent les sources du service, o\u00f9 les t\u00e2ches de build sont lanc\u00e9es dans TeamCity, comment elles sont d\u00e9ploy\u00e9es, o\u00f9 se trouvent les sources des tests end2end, des photos de grazing sur l'architecture, sur les d\u00e9cisions prises. Id\u00e9alement, nous souhaitions que toutes ces informations soient disponibles quelque part, \u00e0 port\u00e9e de main. C'est pourquoi notre tableau est devenu un point de d\u00e9part pour rechercher des informations.<\/p>\n

Mais QIWI, bien que conservant l'esprit d'une start-up, est une grande entreprise. Nous avons d\u00e9j\u00e0 12 ans, et les \u00e9quipes \u00e9voluent : des gens partent, d'autres arrivent, de nouvelles \u00e9quipes se forment. Et nous avons d\u00e9couvert sur notre domaine plusieurs services h\u00e9rit\u00e9s. Certains sont venus avec des d\u00e9veloppeurs d'autres \u00e9quipes, d'autres \u00e9taient reli\u00e9s de mani\u00e8re 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\u00e9s produits qu'il faut imp\u00e9rativement d\u00e9velopper.<\/p>\n

Comme cela arrive.<\/h2>\n

\nMais \u00e0 un moment donn\u00e9, nous r\u00e9alisons que le service ne remplit plus sa fonction, que quelque chose est tomb\u00e9 en panne \u2014 que faire dans une telle situation ? Le service a tout simplement cess\u00e9 de fonctionner. Compl\u00e8tement. 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 \u2014 sur quelles machines virtuelles le service \u00e9tait d\u00e9ploy\u00e9, o\u00f9 se trouvaient ses sources, et c'est tout. Nous faisons un git clone et nous plongeons dans les pens\u00e9es de la personne qui a \u00e9crit cela il y a quelques ann\u00e9es, mais que voyons-nous ? Aucune trace de Spring Boot que nous connaissons si bien, bien que nous soyons full stack et tout \u00e7a. Peut-\u00eatre y a-t-il Spring Framework ? Eh bien, non.<\/p>\n

Le gars qui a \u00e9crit tout \u00e7a \u00e9tait strict et \u00e9crivait tout en Java pur. Il n'y a pas d'outils habituels pour les d\u00e9veloppeurs, et l'id\u00e9e \u00e9merge \u2014 il faudrait tout r\u00e9\u00e9crire. Nous avons des microservices, et de chaque toaster, on entend le traditionnel \u00ab Les gars, les microservices, c'est ce dont vous avez besoin ! \u00bb. Si jamais quelque chose ne va pas, vous pouvez prendre n'importe quel langage et tout ira bien.<\/p>\n

Le probl\u00e8me est qu'actuellement, nous n'avons pas de client qui r\u00e9pond \u00e0 ce service. Quelles \u00e9taient ses exigences commerciales, que doit faire ce service ? Ce service est profond\u00e9ment int\u00e9gr\u00e9 dans vos processus commerciaux. <\/p>\n

Alors, dites-moi combien il est simple de r\u00e9\u00e9crire un service sans conna\u00eetre ses exigences commerciales ? On ne sait pas comment le service est logg\u00e9, s'il y a des m\u00e9triques \u2014 c'est inconnu. Quelles sont-elles, s'il y en a \u2014 encore plus inconnu. Et en plus, le service contient une \u00e9norme quantit\u00e9 de classes de logique m\u00e9tier non identifiable. Certaines donn\u00e9es vont dans une base de donn\u00e9es, dont nous ne savons rien pour l'instant. <\/p>\n

Par quoi commencer ?<\/h2>\n

\nPar la chose la plus logique \u2014 avoir des tests. L\u00e0, on \u00e9crit g\u00e9n\u00e9ralement au moins une certaine logique et on peut tirer des conclusions sur ce qui se passe. Actuellement, TDD est \u00e0 la mode, mais nous remarquons que m\u00eame il y a 5 ans, tout \u00e9tait pratiquement le m\u00eame qu'aujourd'hui : il y a presque pas de tests unitaires, et ils ne nous diront pas grand-chose. \u00c0 part peut-\u00eatre une certaine v\u00e9rification, comme la mani\u00e8re dont un xml est sign\u00e9 avec un certificat personnalis\u00e9.<\/p>\n

Nous n'avons rien pu comprendre \u00e0 partir du code, et nous avons d\u00fb aller v\u00e9rifier ce qui se passait sur la machine virtuelle. Nous avons ouvert les journaux du service et trouv\u00e9 une erreur dans le client http, un certificat auto-sign\u00e9 qui avait \u00e9t\u00e9 int\u00e9gr\u00e9 aux ressources de l'application, et qui avait s\u00e9rieusement expir\u00e9. Nous avons contact\u00e9 nos analystes, ils ont demand\u00e9 un nouveau certificat, qui nous a \u00e9t\u00e9 d\u00e9livr\u00e9 et le service fonctionne \u00e0 nouveau. Cela semble \u00eatre la fin. Ou peut-\u00eatre pas ? Le service fonctionne, il remplit une fonction qui est n\u00e9cessaire pour notre entreprise. Nous avons des normes de d\u00e9veloppement d'applications, qui existent probablement aussi chez vous. Par exemple, ne pas stocker les journaux sur le n\u0153ud dans un dossier, mais les conserver dans un type de stockage, comme Elastic, et les consulter dans Kibana. On peut se rappeler des m\u00e9triques dor\u00e9es. Autrement dit, la charge sur le service, le nombre de requ\u00eates vers le service, s'il est vivant ou non, comment se passe son HealthCheck. Dans tous les cas, ces m\u00e9triques aideront \u00e0 savoir quand il peut \u00eatre retir\u00e9 de l'exploitation et oubli\u00e9 comme un mauvais r\u00eave.<\/p>\n

Que faire<\/h2>\n

\nC'est pourquoi nous ajoutons ce vieux service dans le tableau, puis nous allons chercher des d\u00e9veloppeurs volontaires qui s'occuperont du service et le remettront en ordre : \u00e9crire au moins des informations sur le service, ajouter des liens vers les tableaux de bord dans Grafana, vers les t\u00e2ches de compilation, comprendre comment d\u00e9ployer l'application, il ne s'agit pas de balancer des fichiers par FTP. <\/p>\n

La question principale est de savoir combien de temps toute cette activit\u00e9 b\u00e9n\u00e9vole prendra. Un sprint pour un d\u00e9veloppeur plus ou moins exp\u00e9riment\u00e9, par exemple, lors d'un 20 % de dette technique. Et combien de temps il a fallu pour comprendre toute la logique enracin\u00e9e li\u00e9e \u00e0 la communication avec un certain syst\u00e8me gouvernemental, pour la mettre \u00e0 jour avec des technologies plus r\u00e9centes ? Je ne peux pas le garantir, \u00e7a pourrait prendre un mois, ou peut-\u00eatre deux pour l\u2019\u00e9quipe. C'est par exp\u00e9rience d'int\u00e9gration actuelle avec un nouveau service que je le dis.<\/p>\n

\u00c0 ce stade, il n'y a aucune valeur ajout\u00e9e pour l'entreprise. Rien du tout. Prendre le service sous support et y consacrer un peu de temps est normal. Mais apr\u00e8s nos danses habituelles avec le service, nous l'avons ajout\u00e9 au tableau, ajout\u00e9 des informations \u00e0 son sujet, et peut-\u00eatre qu'un jour nous le r\u00e9\u00e9crirons. Mais maintenant, il r\u00e9pond \u00e0 nos normes de fonctionnement des services.<\/p>\n

En fin de compte, j'aimerais arriver \u00e0 un certain plan pour que faire avec les services Legacy. <\/p>\n

R\u00e9\u00e9crire les legacy from scratch est une mauvaise id\u00e9e.<\/b>
\nS\u00e9rieusement, il n'est m\u00eame pas n\u00e9cessaire d'y penser. Il est clair que cela pourrait \u00eatre souhait\u00e9, et qu'il y a des avantages, mais g\u00e9n\u00e9ralement, cela n'est n\u00e9cessaire pour personne, y compris vous-m\u00eame.<\/p>\n

R\u00e9pertoire<\/b>
\nD\u00e9terrez le code source de vos applications, cr\u00e9ez un r\u00e9pertoire indiquant ce qui est o\u00f9 et comment cela fonctionne, et ajoutez une description du projet (un readme.md conditionnel) afin de comprendre rapidement o\u00f9 se trouvent les journaux et les m\u00e9triques. Le d\u00e9veloppeur qui s'en occupera apr\u00e8s vous ne pourra que vous remercier.<\/p>\n

Comprenez le domaine<\/b>
\nSi vous avez un domaine, essayez de rester \u00e0 l'aff\u00fbt. \u00c7a peut sembler banal, mais tout le monde ne surveille pas si les services sont coh\u00e9rents. En fait, travailler selon un m\u00eame standard est beaucoup plus simple.<\/p>\n

Seuls les utilisateurs enregistr\u00e9s peuvent participer au sondage. Connectez-vous<\/a><\/noindex>, s'il vous pla\u00eet.<\/p>\n

Que faites-vous avec votre h\u00e9ritage ?<\/h2>\n