Serviços legados em sua infraestrutura

Olá! Meu nome é Pasha Chernyak, sou um desenvolvedor líder da QIWI e hoje quero falar sobre o inevitável. Sobre o legado.

Vamos começar com a pergunta: o que é serviço Legacy? Um serviço legado é um serviço que o desenvolvedor não utiliza há uma semana/mês/ano? Ou é um serviço que foi escrito por um programador menos experiente, por exemplo, especificamente por você, mas há um ano? E agora você está mais legal e experiente. Ou o serviço Legacy é um serviço que você decidiu nunca mais comprometer e está lentamente preparando um substituto para ele? Em qualquer caso, deixar tal serviço sem vigilância e sem atualização é uma bomba-relógio que pode explodir mais tarde.

Antes de falar sobre como nós da QIWI trabalhamos com nossos serviços Legacy, contarei como colocamos ordem nos serviços da Carteira. Há dois anos sou responsável pelo seu desempenho. Se houver algum problema, eles sempre me ligam primeiro. Normalmente não tenho coragem de ligar para outra pessoa às 11h, então tive que sentar e descobrir todos os serviços em nosso domínio.

Mas eu, como qualquer pessoa, gosto de dormir à noite, então tentei lidar com a exploração: “Gente, por que vocês estão me ligando?” Ao que recebi uma resposta bastante lacônica como “Quem mais?” Porque eu conserto serviços e a galera simplesmente não sabe para quem ligar.

Por isso, em uma das retrospectivas da equipe de backend da Wallet, decidimos que precisávamos fazer uma placa com uma lista de nossos serviços, microsserviços e monólitos de carteira, e os responsáveis ​​por eles. Os sinais são geralmente úteis, dentro de limites razoáveis.

Além de informações sobre quem é responsável por quê, houve respostas às questões: quem é o dono do serviço, quem é o responsável pelo seu desenvolvimento, arquitetura e ciclo de vida. Os responsáveis ​​por este serviço são as pessoas que podem consertar caso algo aconteça. O proprietário do serviço tem o direito de deixar +2 nos commits, os responsáveis ​​também devem estar presentes na revisão antes que este serviço aceite um novo commit.

Com o passar do tempo, novas práticas começaram a ser aplicadas, por exemplo, migração para Kubernetes, todos os tipos de checkstyle, spotbugs, ktlint, presença de logs no Kibana, serviços de autodescoberta em vez de especificação direta de endereços e outras coisas úteis. E em todos os lugares a nossa mesa permitiu-nos manter a relevância dos nossos serviços. Para nós, isso é uma espécie de checklist que diz que esse serviço pode fazer isso, mas ainda não, mas seguimos em frente, percebendo que faltam informações sobre nossos serviços, que monitoramos, onde estão localizadas as fontes de serviço, onde as tarefas de montagem são lançadas no TeamCity, como são implantadas, onde são armazenadas as fontes dos testes end2end, fotos das sessões de preparação sobre a arquitetura, sobre as decisões tomadas. Idealmente, gostaria que todas essas informações estivessem em algum lugar e estivessem à mão quando necessário. Portanto, nossa placa tornou-se o ponto de partida para a busca de informações.

Mas a QIWI, embora mantenha o espírito de startup, é uma grande empresa. Já temos 12 anos e as equipes estão mudando: as pessoas vão embora, as pessoas vêm, novas equipes se formam. E descobrimos vários serviços em nosso domínio que herdamos. Alguns vieram de desenvolvedores de outras equipes, alguns simplesmente de alguma forma indiretamente relacionados à Carteira, então agora temos o serviço em nosso balanço. Entender o que e como funciona – por quê? O serviço funciona e temos características do produto que definitivamente precisam ser melhoradas.

Como isso acontece

Mas em algum momento descobrimos que o serviço deixa de cumprir sua função, algo está quebrado - o que fazer em tal situação? O serviço simplesmente parou de funcionar. De forma alguma. E descobrimos isso, em primeiro lugar, por acidente e, em segundo lugar, seis meses depois. Acontece. A única coisa que sabíamos era em quais máquinas virtuais o serviço seria implantado, onde estavam localizadas suas fontes e pronto. Fazemos um clone do git e mergulhamos na mente da pessoa que escreveu isso há alguns anos, mas o que vemos? Nada do Spring Boot que nos é familiar, embora estejamos acostumados com tudo, temos full stack e tudo mais. Talvez haja um Spring Framework aí? Mas não.

O cara que escreveu tudo isso foi durão e escreveu tudo em Java puro. Não existem ferramentas usuais para um desenvolvedor, e surge uma ideia: precisamos reescrever tudo isso. Temos microsserviços, e de cada torradeira vem o habitual “Gente, microsserviços são o que vocês precisam!” Se de repente algo der errado, você pode pegar qualquer idioma com calma e tudo ficará bem.

Acontece que agora não temos um cliente responsável por esse serviço. Quais requisitos de negócios ele tinha, o que esse serviço deveria fazer? E o serviço está totalmente integrado aos seus processos de negócios.

Agora me diga, quão fácil é reescrever um serviço sem conhecer seus requisitos de negócios? Não está claro como o serviço é registrado; não se sabe se existem métricas. O que eles são, se é que existem, é ainda mais desconhecido. E, ao mesmo tempo, o serviço contém um grande número de classes de lógica de negócios incompreensível. Algo está incluído em algum tipo de banco de dados, sobre o qual ainda não sabemos nada.

Com o que começar?

Do ponto mais lógico – a disponibilidade de testes. Geralmente há pelo menos alguma lógica escrita ali e você pode tirar conclusões sobre o que está acontecendo. Agora o TDD está na moda, mas vemos que há 5 anos tudo era quase igual ao que é agora: quase não há testes unitários e eles não nos dizem nada. Bem, exceto talvez algum tipo de verificação, como algum xml é assinado com algum certificado personalizado.

Não conseguíamos entender nada do código, então fomos ver o que havia na máquina virtual. Abrimos os logs de serviço e encontramos neles um erro de cliente HTTP; o certificado autoassinado incorporado aos recursos do aplicativo estava descaradamente podre. Entramos em contato com nossos analistas, eles solicitaram um novo certificado, nos emitiram e o serviço voltou a funcionar. Parece que isso é tudo. Ou não? Afinal, o serviço funciona, ele desempenha alguma função que o nosso negócio precisa. Temos certos padrões para desenvolvimento de aplicativos, que provavelmente você também possui. Por exemplo, não armazene logs no nó em uma pasta, mas armazene-os em algum tipo de armazenamento, como elástico, e observe-os no Kibana. Você também pode se lembrar das métricas de ouro. Ou seja, a carga do serviço, a quantidade de solicitações do serviço, se ele está vivo ou não, como está o seu HealthCheck. No mínimo, essas métricas ajudarão você a saber quando ele pode ser retirado de serviço com a consciência tranquila e esquecido como um pesadelo.

O que fazer

Portanto, adicionamos um serviço tão antigo à mesa, e depois vamos procurar voluntários entre os desenvolvedores que vão cuidar do serviço e colocá-lo em ordem: eles vão escrever pelo menos algumas informações sobre o serviço, adicionar links para dashboards em grafana, para tarefas de montagem, e entender como Deploy a aplicação, não faça upload de arquivos manualmente usando ftp.

O principal é quanto tempo levará toda essa atividade voluntária útil? Um sprint para um desenvolvedor mais ou menos experiente, por exemplo, durante uma dívida técnica de 20%. Quanto tempo demorou para entender toda a lógica arraigada de comunicação com um determinado sistema estatal e trazê-la para tecnologias mais recentes? Não posso garantir isso, talvez um mês ou talvez dois de trabalho da equipe. Digo isso pela experiência da integração atual com algum novo serviço.

Ao mesmo tempo, não há liberação de valor comercial. De forma alguma. É normal contratar um serviço de suporte e dedicar um tempinho a isso. Mas depois de nossas danças padrão com o serviço, nós o adicionamos à mesa, adicionamos informações sobre ele e, quem sabe, algum dia iremos reescrevê-lo. Mas agora atende aos nossos padrões de serviço.

Como resultado, gostaria de elaborar um plano sobre o que fazer com os serviços legados.

Reescrever o legado do zero é uma má ideia
Sério, você nem precisa pensar nisso. É claro que eu gostaria e há algumas vantagens, mas geralmente ninguém precisa disso, inclusive você.

Diretório
Descubra os códigos-fonte de seus aplicativos, faça um livro de referência que indicará onde e como funciona, insira uma descrição do projeto lá (readme.md condicional) para entender rapidamente onde os logs e métricas estão localizados. O desenvolvedor que cuidará disso depois de você apenas agradecerá.

Entenda o domínio
Se você possui um domínio, tente manter o controle. Parece trivial, sim, mas nem todo mundo garante que os serviços estejam em uma única chave. Mas trabalhar em um padrão é, na verdade, significativamente mais fácil.

Apenas usuários registrados podem participar da pesquisa. Entrarpor favor

O que você faz com o seu legado?

• 31.5%Estou reescrevendo do zero, é mais correto 12

• 52.6%Quase igual a você20

• 10.5%Não temos legado, somos ótimos4

• 5.2%Vou escrever nos comentários2

38 usuários votaram. 20 usuários se abstiveram.

Fonte: habr.com