🥇Servizos legados na túa infraestrutura

Ola! Chámome Pasha Chernyak, son un desenvolvedor líder en QIWI e hoxe quero falar do inevitable. Sobre Legacy.

Comecemos coa pregunta: que é o servizo Legacy? Un servizo heredado é un servizo que o programador non tocou durante unha semana/mes/ano? Ou é un servizo que foi escrito por un programador menos experimentado, por exemplo, por vostede en concreto, pero hai un ano? E agora estás máis xenial e con máis experiencia. Ou é o servizo Legacy un servizo que decidiu non comprometerse nunca máis e que pouco a pouco está preparando un substituto para el? En calquera caso, deixar un servizo deste tipo desatendido e sen actualizar é unha bomba de reloxería que pode explotar máis tarde.

Antes de pasar a coñecer como traballamos en QIWI cos nosos servizos legados, contarei como fixemos orde nos servizos de Wallet. Dende hai dous anos son o responsable da súa actuación. Se hai algún problema, sempre me chaman primeiro. Normalmente non teño o valor de chamar a outra persoa ás 11 horas, así que tiven que sentarme e descubrir todos os servizos do noso dominio.

Pero a min, como a calquera persoa, gústame durmir pola noite, así que tratei de lidar coa explotación: "Rapaces, por que me chamas?" Ao que recibín unha resposta bastante lacónica como "Quen máis?" Porque arranxo os servizos e os mozos simplemente non saben a quen chamar.

Por iso, nunha das retrospectivas do equipo de backend de Wallet, decidimos que necesitabamos facer un cartel cunha lista dos nosos servizos, microservizos e monólitos de carteira, e os responsables dos mesmos. Os sinais son xeralmente útiles, dentro de límites razoables.

Ademais da información sobre quen é o responsable de que, houbo respostas ás preguntas: quen é o propietario do servizo, quen é o responsable do seu desenvolvemento, arquitectura e ciclo de vida. Os responsables deste servizo son os que poden solucionalo se ocorre algo. O propietario do servizo ten dereito a deixar +2 en commits, os responsables tamén deben estar presentes na revisión antes de que este servizo acepte un novo commit.

Co paso do tempo, comezaron a aplicarse novas prácticas, por exemplo, a migración a Kubernetes, todo tipo de estilos de verificación, erros puntuales, ktlint, a presenza de rexistros en Kibana, servizos de descubrimento automático en lugar de especificar directamente enderezos e outras cousas útiles. E en todas partes a nosa mesa permitiunos manter a relevancia dos nosos servizos. Para nós, esta é unha especie de lista de verificación que di que este servizo pode facelo, pero aínda non o fai. onde se lanzan tarefas de montaxe en TeamCity, como se despregan, onde se almacenan as fontes das probas end2end, fotos de sesións de preparación sobre a arquitectura, sobre as decisións tomadas. O ideal sería que toda esta información estivese nalgún lugar e estivese a man cando sexa necesaria. Polo tanto, o noso sinal converteuse no punto de partida para a busca de información.

Pero QIWI, aínda que conserva o espírito dunha startup, é unha gran empresa. Xa temos 12 anos, e os equipos están cambiando: marcha a xente, vén xente, fórmanse novos equipos. E descubrimos varios servizos no noso dominio que herdamos. Algúns proviñan de desenvolvedores doutros equipos, outros simplemente están relacionados dalgunha forma indirectamente co Wallet, polo que agora temos o servizo no noso balance. Comprender o que e como funciona - por que? O servizo funciona e temos características do produto que definitivamente hai que mellorar.

Como ocorre

Pero nalgún momento descubrimos que o servizo deixa de cumprir a súa función, algo está roto, que facer ante tal situación? O servizo simplemente deixou de funcionar. En todo. E disto decatámonos, en primeiro lugar, por accidente, e en segundo lugar, seis meses despois. Ocorre. O único que sabiamos era en que máquinas virtuais se implantaría o servizo, onde se atopaban as súas fontes e iso é todo. Facemos un clon de git e mergullámonos na mente da persoa que escribiu isto hai uns anos, pero que vemos? Ningunha das Spring Boot que nos son familiares, aínda que estamos afeitos a todo, temos unha pila chea e todo iso. Quizais hai un marco de primavera alí? Pero non.

O tipo que escribiu todo isto era duro e escribiu todo en Java puro. Non hai ferramentas habituais para un desenvolvedor, e xorde unha idea: hai que reescribir todo isto. Temos microservizos e de cada torradeira sae o habitual "Rapaces, os microservizos son o que necesitas!" Se de súpeto algo sae mal, podes tomar calquera idioma con calma e todo estará ben.

O caso é que agora non temos un cliente que se encargue deste servizo. Que requisitos comerciais tiña, que debería facer este servizo? E o servizo está estreitamente integrado nos seus procesos de negocio.

Agora dime, que tan fácil é reescribir un servizo sen coñecer os seus requisitos comerciais? Non está claro como se rexistra o servizo; descoñécese se hai métricas. Cales son, se é o caso, é aínda máis descoñecido. E ao mesmo tempo, o servizo contén un gran número de clases de lóxica empresarial incomprensible. Algo está incluído nalgunha base de datos, do que tampouco sabemos nada aínda.

Por onde comezar?

Desde o punto máis lóxico - a dispoñibilidade de probas. Normalmente hai, polo menos, algunha lóxica escrita alí e podes sacar conclusións sobre o que está a suceder. Agora o TDD está de moda, pero vemos que hai 5 anos todo era case igual que agora: case non hai probas unitarias, e non nos dirán nada. Ben, agás quizais algún tipo de verificación, como algúns xml están asinados con algún certificado personalizado.

Non puidemos entender nada do código, así que fomos ver que había na máquina virtual. Abrimos os rexistros do servizo e atopamos un erro do cliente http neles. Puxémonos en contacto cos nosos analistas, solicitaron un novo certificado, expedíronnolo e o servizo volve a funcionar. Parece que iso é todo. Ou non? Despois de todo, o servizo funciona, realiza algunha función que o noso negocio necesita. Temos certos estándares para o desenvolvemento de aplicacións, que probablemente ti tamén. Por exemplo, non almacene os rexistros no nodo nun cartafol, senón gárdaos nalgún tipo de almacenamento, como o elástico, e míreos en Kibana. Tamén podes lembrar as métricas douradas. É dicir, a carga do servizo, o número de solicitudes do servizo, se está vivo ou non, como vai o seu HealthCheck. Polo menos, estas métricas axudaranche a saber cando se pode sacar do servizo coa conciencia tranquila e esquecer como un mal soño.

¿Que facer

Por iso, engadimos á mesa un servizo tan antigo, e despois imos a buscar voluntarios entre os desenvolvedores que se fagan cargo do servizo e poñelo en orde: escribirán polo menos algunha información sobre o servizo, engadirán ligazóns a paneis de control en grafana, para realizar tarefas de montaxe e comprender como Implementar a aplicación, non cargue ficheiros manualmente mediante ftp.

O principal é canto tempo levará toda esta útil actividade de voluntariado? Un sprint para un desenvolvedor máis ou menos experimentado, por exemplo, durante unha débeda técnica do 20%. Canto tempo levou comprender toda a lóxica arraigada de comunicarse cun determinado sistema estatal e achegalo ás novas tecnoloxías? Non podo garantir isto, quizais un mes ou quizais dous do traballo do equipo. Dígoo por experiencia de integración actual con algún servizo novo.

Ao mesmo tempo, non hai liberación de valor comercial. En todo. É normal contratar un servizo de apoio e dedicarlle un pouco de tempo. Pero despois dos nosos bailes estándar co servizo, engadímolo á mesa, engadimos información sobre el e, quizais, algún día o reescribimos. Pero agora cumpre cos nosos estándares de servizo.

Como resultado, gustaríame elaborar un plan sobre o que facer cos servizos Legacy.

Reescribir o legado dende cero é unha mala idea
En serio, nin sequera tes que pensar niso. Está claro que me gustaría, e hai algunhas vantaxes, pero normalmente ninguén o necesita, incluído ti mesmo.

Directorio
Saca os códigos fonte das túas aplicacións, fai un libro de referencia que indique cal é onde e como funciona, introduce unha descrición do proxecto alí (reame.md condicional) para comprender rapidamente onde se atopan os rexistros e as métricas. O programador que se ocupará disto despois de ti só agradecerá.

Comprender o dominio
Se tes un dominio, intenta manter o dedo no pulso. Parece trivial, si, pero non todos se aseguran de que os servizos estean nunha soa clave. Pero traballar nun estándar é moito máis sinxelo.

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.