Salut Je m'appelle Pasha Chernyak, je suis l'un des principaux développeurs de QIWI et aujourd'hui, je veux parler de l'inévitable. À propos de Legacy.
Commençons par la question: qu'est-ce qu'un service hérité? Un service hérité est-il un service auquel le développeur n'a pas touché depuis une semaine / mois / année? Ou est-ce un service qui a été écrit par un programmeur moins expérimenté, par exemple, spécifiquement par vous, mais il y a un an? Et maintenant, vous êtes plus cool et plus expérimenté. Ou, après tout, un service hérité est-il un service que vous décidez de ne plus jamais valider et que vous préparez lentement un remplacement? Dans tous les cas, laisser ce service sans surveillance et sans mise à jour est une bombe à retardement qui peut exploser plus tard.
Avant de passer à la façon dont nous travaillons avec nos services hérités dans QIWI, je vais vous dire comment nous mettons les choses en ordre avec les services dans le portefeuille. Depuis deux ans maintenant, je suis responsable de ses performances. S'il y a un problème, ils m'appellent toujours en premier. Je n'ai généralement pas l'audace d'appeler quelqu'un d'autre à 23 heures, j'ai donc dû m'asseoir et comprendre tous les services de notre domaine.
Mais moi, comme toute personne, j'aime dormir la nuit, alors j'ai essayé de faire face à l'opération: "Les gars, pourquoi m'appelez-vous?" À quoi il a reçu une réponse assez concise du formulaire "Qui d'autre?" Parce que je répare des services, et les gars ne savent tout simplement pas qui appeler.
Par conséquent, dans l'une des rétrospectives de l'équipe de backend de Wallet, nous avons décidé que nous devons compiler une plaque sur laquelle est écrite une liste de nos services, microservices et monolithes du portefeuille, et leurs responsables. Les comprimés sont généralement utiles, dans une mesure raisonnable.
En plus des informations sur qui est responsable de quoi, il y avait des réponses aux questions: qui est le propriétaire du service, qui est responsable de son développement, de l'architecture et du cycle de vie. Les personnes responsables de ce service sont des personnes qui peuvent le réparer en cas de problème. Le propriétaire du service a le droit de laisser +2 dans les commits, les responsables doivent également être présents à la revue avant que ce service ne prenne en charge le nouveau commit.
Au fil du temps, de nouvelles pratiques ont commencé à être appliquées, par exemple, la migration vers Kubernetes, toutes sortes de styles de contrôle, les bogues ponctuels, ktlint, la présence de journaux dans kiban, les services de découverte automatique au lieu de spécifier directement les adresses et d'autres choses utiles. Et partout notre table nous a permis de maintenir la pertinence de nos services. Pour nous, il s'agit d'une liste de contrôle qui indique que ce service sait comment le faire, mais ce n'est pas encore le cas. Mais nous sommes allés plus loin, réalisant que nous manquons d'informations sur nos services, pour lesquels nous gardons une trace de l'endroit où se trouvent les codes source du service. , où les tâches d'assemblage sont lancées dans TeamCity, comment elles sont déployées, où sont stockés les codes source des tests end2end, des photos de toilettages sur l'architecture, sur les décisions prises. Idéalement, je voulais que toutes ces informations se trouvent quelque part et soient à portée de main en cas de besoin. Par conséquent, notre plaque est devenue un point de départ pour trouver des informations.
Mais QIWI, tout en conservant l'esprit d'une startup, est une grande entreprise. Nous avons déjà 12 ans et les équipes changent: des gens partent, des gens arrivent, de nouvelles équipes se forment. Et nous avons trouvé sur notre domaine plusieurs services dont nous avons hérité. Quelque chose est venu avec des développeurs d'autres équipes, quelque chose de juste indirectement lié au portefeuille, donc le service est maintenant dans notre bilan. Traitez de quoi et comment cela fonctionne - pourquoi? Le service fonctionne et nous avons des caractéristiques de produit qui doivent être nettoyées.
Comme cela arrive
Mais à un moment donné, nous constatons que le service cesse de remplir sa fonction, quelque chose a cassé - que faire dans cette situation? Le service a juste cessé de fonctionner. Absolument. Et nous l'avons appris, d'une part, par hasard, et d'autre part, six mois plus tard. Ça arrive. La seule chose que nous savions était sur quelles machines virtuelles le service était déployé, où se trouvaient ses sources, et c'est tout. Nous faisons cloner git et plonger dans les pensées de la personne qui a écrit cela il y a plusieurs années, mais que voyons-nous? Il n'y a pas de Spring Boot familier, bien que nous soyons habitués à tout, nous avons une pile complète et tout ça. Peut-être existe-t-il un cadre Spring? 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 familiers pour le développeur, et l'idée surgit - il faudrait tout réécrire. Nous avons également des microservices, et de chaque grille-pain, nous entendons le familier "Les gars, les microservices sont ce dont vous avez besoin!". Si tout à coup quelque chose ne va pas, vous prendrez calmement n'importe quelle langue et tout ira bien.
Le fait est que maintenant nous n'avons pas de client responsable de ce service. Quelles étaient ses exigences commerciales, que devrait faire ce service en général? 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 commerciales? Le service ne sait pas comment il est consigné; il n'existe pas de métriques. Ce qu'ils sont, le cas échéant, est d'autant plus inconnu. Et pendant le service, un grand nombre de classes de logique métier obscure. Quelque chose est inclus dans une sorte de base de données, sur laquelle nous ne savons rien encore.
Par où commencer?
Du plus logique - avec la disponibilité des tests. Au moins une sorte de logique y est généralement écrite et des conclusions peuvent être tirées sur ce qui se passe. Maintenant, le TDD est à la mode, mais nous voyons qu'il y a 5 ans, tout était presque le même que maintenant: il n'y a presque pas de tests unitaires, et ils ne nous diront absolument rien. Eh bien, sauf peut-être une sorte de vérification de la façon dont certains fichiers XML sont signés avec une sorte de certificat personnalisé.
Nous ne pouvions rien comprendre par le code, et nous avons envoyé un coup d'œil pour voir ce qu'était la machine virtuelle. Nous avons ouvert les journaux de service, y avons trouvé une erreur de client http, un certificat auto-signé qui a été cousu dans les ressources de l'application, sans scrupule. Nous avons contacté nos analystes, ils ont demandé un nouveau certificat, ils nous l'ont délivré et le service fonctionne à nouveau. Cela semblerait être tout. Ou pas? Pourtant, le service fonctionne, il remplit certaines fonctions dont notre entreprise a besoin. Nous avons certaines normes de développement d'applications que vous avez très probablement. Par exemple, ne stockez pas les journaux sur le nœud dans le dossier, mais stockez-les dans une sorte de stockage, comme un élastique, regardez-les dans le kiban. Vous pouvez rappeler les métriques d'or. Autrement dit, la charge sur le service, le nombre de demandes pour le service, qu'il soit vivant ou non, comment se déroule son bilan de santé. À tout le moins, ces paramètres vous aideront à savoir quand il peut être mis hors service et oublié comme un mauvais rêve avec une conscience claire.
Que faire
Par conséquent, nous ajoutons un ancien service à la tablette, puis nous recherchons des volontaires parmi les développeurs qui prendront soin du service et le mettront en ordre: ils écriront au moins quelques informations sur le service, ajouteront des liens vers des tableaux de bord dans graphan, aux tâches d'assemblage, et comprendront comment Déployez l'application, ne téléchargez pas de fichiers en utilisant ftp avec vos mains.
L'essentiel est de savoir combien prendra tout ce bénévolat utile? Un sprint pour un développeur plus ou moins expérimenté, par exemple lors d'une dette technique de 20%. Et combien de temps a-t-il fallu pour comprendre toute la logique profondément enracinée de la communication avec un certain système d'État et l'amener aux nouvelles technologies? Je ne peux pas garantir cela, peut-être un mois, ou peut-être deux travaux d'équipe. C'est ce que je dis de l'expérience d'intégration à l'heure actuelle avec un nouveau service.
Dans le même temps, il n'y a pas d'épuisement de la valeur commerciale. Absolument. Prendre le service d'assistance et y consacrer un peu de temps est normal. Mais après nos danses standard avec le service, nous l'avons ajouté à la table, ajouté des informations à ce sujet et, peut-être, un jour nous le réécrirons. Mais maintenant, il répond à nos normes de service.
En conséquence, je voudrais apporter à un plan quoi faire avec les services hérités.
Réécrire l'héritage à partir de zéro est une mauvaise idéeSérieusement, vous n’avez même pas à y penser. Il est clair que nous le souhaiterions, et certains avantages sont visibles, mais généralement cela n'est nécessaire pour personne, y compris vous-même.
Ouvrage de référenceDéterrez les codes sources de vos applications, créez un répertoire qui indiquera quoi et où il se trouve et comment cela fonctionne, entrez-y la description du projet (conditionnel readme.md) pour comprendre rapidement où se trouvent les journaux et les mesures. Un développeur qui s'en occupera après vous dira seulement merci.
Comprendre le domaineSi vous possédez un domaine, essayez de garder le doigt sur le pouls. Cela semble ringard, oui, mais tout le monde ne s'assure pas que les services sont dans une seule clé. Mais travailler dans une seule norme est en fait beaucoup plus facile.