🥇 Serviços legados na sua infraestrutura

Olá! Meu nome é Pasha Chernyak, sou desenvolvedor principal na QIWI e hoje quero falar sobre o inevitável. Sobre o Legacy.

Vamos começar com a pergunta: o que é um serviço Legacy? Um serviço Legacy é um serviço que nenhum desenvolvedor tocou por uma semana/mês/ano? Ou é um serviço que foi escrito por um programador menos experiente, como você, há um ano? Agora você é mais habilidoso e experiente. Ou um serviço Legacy é aquele que você decidiu nunca mais atualizar e está aos poucos preparando uma substituição? De qualquer forma, deixar esse serviço à deriva e não atualizá-lo é uma bomba-relógio que pode explodir mais tarde.

Antes de falarmos sobre como trabalhamos com nossos serviços Legacy na QIWI, vou contar como organizamos os serviços em nossa carteira. Há dois anos, sou responsável pelo seu funcionamento. Se há algum problema, sou sempre o primeiro a ser acionado. Normalmente não tenho a ousadia de ligar para alguém às 11 horas da noite, então acabo tendo que me sentar e entender todos os serviços do nosso domínio.

Mas eu, como qualquer pessoa, gosto de dormir à noite, por isso tentei resolver a questão: "Pessoal, por que vocês estão me ligando?". E recebi uma resposta bem direta: "Quem mais?". Porque eu conserto os serviços e, além disso, a equipe simplesmente não sabe a quem ligar.

Portanto, em uma das retrospectivas da equipe de back-end da carteira, decidimos que era necessário criar uma tabela listando nossos serviços, microsserviços e monólitos, assim como os responsáveis por eles. Tabelas são realmente úteis, dentro de limites razoáveis.

Além das informações sobre quem é responsável pelo quê, havia respostas para perguntas como: quem é o proprietário do serviço, quem é responsável por seu desenvolvimento, pela arquitetura e pelo ciclo de vida. As pessoas responsáveis por esse serviço são aquelas que podem consertá-lo em caso de necessidade. O proprietário do serviço tem o direito de adicionar +2 nos commits, e os responsáveis também devem estar presentes na revisão antes que esse serviço receba um novo commit.

O tempo passou e novas práticas começaram a ser aplicadas, como a migração para Kubernetes, diversos checkstyle, spotbugs, ktlint, a presença de logs no Kibana, autodiscovery de serviços em vez de indicar endereços diretamente, e outras utilidades. E em todos os lugares nossa tabela permitia manter a atualidade de nossos serviços. Para nós, isso é uma espécie de checklist que indica que este serviço é capaz de fazer isso, mas ainda não faz isso. Mas nós avançamos, percebendo que faltava informação sobre nossos serviços que monitoramos, onde estão os códigos-fonte do serviço, onde são iniciadas as tarefas de compilação no TeamCity, como são implementados, onde estão armazenados os códigos-fonte dos testes end2end, fotos sobre a arquitetura, decisões tomadas. Idealmente, gostaríamos que todas essas informações estivessem armazenadas em algum lugar e acessíveis quando necessário. Assim, nossa tabela se tornou o ponto de partida na busca por informações.

Mas a QIWI, embora mantenha o espírito de startup, é uma grande empresa. Estamos com 12 anos e as equipes mudam: pessoas vão, pessoas vêm, novas equipes são formadas. E encontramos em nosso domínio vários serviços que herdamos. Algo veio com desenvolvedores de outras equipes, algo estava indiretamente relacionado à Carteira, por isso o serviço agora está sob nossa responsabilidade. Para que se preocupar com o que e como funciona — por quê? O serviço está funcionando e temos recursos que precisamos desenvolver.

Como costuma acontecer

Mas em algum momento descobrimos que o serviço parou de executar sua função, algo quebrou — o que fazer em uma situação assim? O serviço simplesmente parou de funcionar. Completamente. E descobrimos isso, primeiro, por acaso, e, segundo, seis meses depois. Isso acontece. A única coisa que sabíamos era em quais máquinas virtuais o serviço estava rodando, onde estavam seus códigos-fonte, e só. Fazemos git clone e mergulhamos nos pensamentos da pessoa que escreveu isso há alguns anos, mas o que vemos? Nenhum Spring Boot familiar para nós, embora estejamos acostumados com tudo, já que temos um full stack e tudo mais. Pode ser que exista um Spring Framework? Mas não existe.

O rapaz que escreveu tudo isso era rigoroso e programava tudo em Java puro. Não há ferramentas familiares para os desenvolvedores e surge a ideia — seria bom reescrever tudo isso. Temos microserviços, e de cada torradeira vem o familiar "Pessoal, microserviços são o que vocês precisam!". Se algo não der certo, você pode pegar qualquer linguagem que tudo funcionará bem.

A questão é que atualmente não temos um cliente responsável por este serviço. Quais eram suas necessidades de negócio? O que esse serviço deve realmente fazer? E o serviço está fortemente integrado aos seus processos de negócios.

E agora me diga, quão fácil é reescrever o serviço sem conhecer suas necessidades de negócio? Não está claro como o serviço faz logs, se há métricas — isso é desconhecido. Quais são elas, se existirem — isso também é desconhecido. E, além disso, o serviço tem uma enorme quantidade de classes com lógica de negócio confusa. Algo entra em um banco de dados do qual também não sabemos nada por enquanto.

Por onde começar?

Pelo mais lógico — pela existência de testes. Geralmente, lá está escrita alguma lógica e é possível tirar conclusões sobre o que está acontecendo. Atualmente, o TDD está na moda, mas vemos que há 5 anos era praticamente a mesma coisa que agora: quase não existem testes unitários, e eles não nos dizem nada. Bem, exceto talvez alguma verificação de como um xml é assinado com algum certificado personalizado.

Não conseguimos entender nada pelo código, então decidimos verificar o que estava acontecendo na virtualização. Abrimos os logs do serviço e encontramos um erro do cliente HTTP: o certificado autoassinado, que estava embutido nos recursos do aplicativo, estava completamente expirado. Contatamos nossos analistas, que pediram um novo certificado; conseguimos um e o serviço voltou a funcionar. Pareceria que era isso. Ou não? Afinal, o serviço está funcionando; ele realiza uma função que é necessária para o nosso negócio. Temos certos padrões de desenvolvimento de aplicativos, que provavelmente vocês também têm. Por exemplo, não armazenar logs no nó dentro de uma pasta, mas sim em algum tipo de repositório, como o Elasticsearch, e visualizá-los no Kibana. Podemos lembrar também das métricas vitais. Ou seja, a carga no serviço, o número de solicitações para o serviço, se ele está vivo ou não, como está o HealthCheck. Pelo menos, essas métricas ajudarão a saber quando ele pode ser retirado de operação e esquecido como um pesadelo.

O que fazer

Por isso, adicionamos esse serviço antigo à tabela, e depois vamos procurar entre os desenvolvedores voluntários que queiram cuidar do serviço e colocá-lo em ordem: escrever alguma informação sobre o serviço, adicionar links para os dashboards no Grafana, para as tarefas de compilação, entender como implantar o aplicativo, não dá para simplesmente jogar arquivos via FTP.

O principal é — quanto tempo toda essa atividade voluntária vai levar? Um sprint para um desenvolvedor mais ou menos experiente, por exemplo, durante 20% da dívida técnica. E quanto tempo levou para entender toda a lógica enraizada para se comunicar com algum sistema governamental e trazê-la para tecnologias mais modernas? Não posso garantir, pode levar um mês ou, talvez, dois meses de trabalho da equipe. Falo isso com base na experiência de integração atual com algum novo serviço.

Ao mesmo tempo, não há valor comercial algum. Nenhum. Assumir o suporte do serviço e gastar um pouco de tempo nisso é normal. Mas após nossas danças padrão com o serviço, o adicionamos à tabela, incluímos informações sobre ele e, talvez, um dia o reescreveremos. Mas, por enquanto, ele atende aos nossos padrões de operação dos serviços.

Como conclusão, gostaria de apresentar um plano sobre o que fazer com os serviços legados.

Reescrever o legado do zero é uma má ideia.
Sério, você nem deve pensar nisso. É claro que seria bom e existem alguns benefícios, mas geralmente isso não é necessário para ninguém, incluindo você mesmo.

Guia
Desenterram os códigos-fonte das suas aplicações e criam um guia que indique o que e onde está, e como funciona. Inclua também uma descrição do projeto (um readme.md), para entender rapidamente onde estão os logs e as métricas. O desenvolvedor que trabalhar nisso depois de você só vai agradecer.

Entenda o domínio
Se você possui algum domínio, tente ficar atento. Parece banal, sim, mas nem todos monitoram para que os serviços estejam em uma mesma linha. E, na verdade, é muito mais fácil operar com um único padrão.

Apenas usuários registrados podem participar da pesquisa. Entre, por favor.