Oi Meu nome é Pasha Chernyak, sou um dos principais desenvolvedores da QIWI e hoje quero falar sobre o inevitável. Sobre o legado.
Vamos começar com a pergunta: o que é um serviço Legado? Um serviço Legacy é um serviço que o desenvolvedor não tocou por uma semana / mês / ano? Ou é um serviço que foi escrito por um programador menos experiente, por exemplo, especificamente por você, mas um ano atrás? E agora você é mais legal e mais experiente. Ou, afinal, um serviço Legado é um serviço que você decide nunca cometer novamente e está lentamente preparando um substituto para ele? De qualquer forma, deixar este serviço sem vigilância e não atualizar é uma bomba-relógio que pode explodir mais tarde.
Antes de prosseguirmos com a forma como trabalhamos com nossos serviços herdados no QIWI, mostrarei como colocamos as coisas em ordem com os serviços da Carteira virtual. Há dois anos, sou responsável por seu desempenho. Se houver algum problema, eles sempre me ligam primeiro. Normalmente, não tenho a audácia de ligar para outra pessoa às 23:00, então tive que me sentar e entender todos os serviços do nosso domínio.
Mas eu, como qualquer pessoa, gosto de dormir à noite, então tentei lidar com a operação: "Gente, por que você está me ligando?" À qual ele recebeu uma resposta bastante concisa do formulário "Quem mais?" Porque estou reparando serviços e os caras não sabem para quem ligar.
Portanto, em uma das retrospectivas da equipe de back-end da Carteira virtual, decidimos que precisamos compilar uma placa na qual está escrita uma lista de nossos serviços, microsserviços e monólitos da carteira e os responsáveis por eles. Os comprimidos são geralmente úteis, em uma extensão razoável.
Além de informações sobre quem é responsável pelo quê, houve respostas para perguntas: quem é o proprietário do serviço, quem é responsável pelo seu desenvolvimento, pela arquitetura e pelo ciclo de vida. As pessoas responsáveis por este serviço são pessoas que podem consertá-lo se algo acontecer. 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 assuma o novo commit.
Com o passar do tempo, novas práticas começaram a ser aplicadas, por exemplo, migração para o Kubernetes, todos os tipos de estilos de verificação, spotbugs, ktlint, presença de logs no kiban, serviços de descoberta automática em vez de especificar endereços diretamente e outras coisas úteis. E em todos os lugares nossa mesa nos permitiu manter a relevância de nossos serviços. Para nós, esta é uma lista de verificação que diz que esse serviço sabe como fazer isso, mas ainda não o fez, mas fomos além, percebendo que não temos informações sobre nossos serviços, para os quais monitoramos onde estão os códigos-fonte do serviço. , onde as tarefas de montagem são iniciadas no TeamCity, como são implantadas, onde os códigos-fonte dos testes de end2end são armazenados, fotos de groomings sobre arquitetura, sobre decisões tomadas. Idealmente, queria que toda essa informação estivesse em algum lugar e estivesse à mão quando necessário. Portanto, nosso prato se tornou um ponto de partida para encontrar informações.
Mas a QIWI, embora mantenha o espírito de uma startup, é uma grande empresa. Já temos 12 anos e as equipes estão mudando: as pessoas estão saindo, as pessoas estão chegando, novas equipes estão sendo formadas. E encontramos em nosso domínio vários serviços que herdamos. Algo aconteceu com os desenvolvedores de outras equipes, algo de alguma forma relacionado indiretamente à Carteira virtual, então o serviço está agora em nosso balanço. Lide com o que e como funciona - por quê? O serviço funciona e temos recursos do produto que devem ser lavados.
Como acontece
Mas, em algum momento, descobrimos que o serviço deixa de cumprir sua função, algo quebrou - o que deve ser feito nessa situação? O serviço parou de funcionar. Absolutamente. E nós aprendemos sobre 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 foi implantado, onde estão suas fontes e isso é tudo. Fazemos clone do git e mergulhamos nos pensamentos da pessoa que escreveu isso há vários anos, mas o que vemos? Não há Spring Boot familiar para nós, embora estejamos acostumados a tudo, temos uma pilha cheia e tudo isso. Talvez haja um Spring Framework? Mas não.
O cara que escreveu tudo isso foi duro e escreveu tudo em Java puro. Não há ferramentas familiares para o desenvolvedor, e a idéia surge - seria necessário reescrever tudo. Também temos microsserviços, e de cada torradeira ouvimos o familiar "Pessoal, microsserviços são o que você precisa!". Se de repente algo estiver errado, você adotará calmamente qualquer idioma e tudo ficará bem.
O fato é que agora não temos um cliente responsável por esse serviço. Quais eram os requisitos de negócios dele, o que esse serviço deveria fazer em geral? E o serviço está totalmente integrado aos seus processos de negócios.
Agora me diga, como é fácil reescrever um serviço sem conhecer seus requisitos de negócios? O serviço não está claro como é registrado; se há métricas é desconhecido. O que eles são, se houver, é ainda mais desconhecido. E enquanto estiver no serviço, um grande número de classes de lógica comercial obscura. Algo está incluído em algum tipo de banco de dados, sobre o qual também não sabemos nada ainda.
Por onde começar?
Do mais lógico - com a disponibilidade de testes. Pelo menos algum tipo de lógica é geralmente escrito lá e conclusões podem ser tiradas sobre o que está acontecendo. Agora o TDD está na moda, mas vemos que nos mesmos 5 anos atrás tudo era quase o mesmo de agora: quase não há testes de unidade e eles não nos dizem absolutamente nada. Bem, exceto, talvez, algum tipo de verificação de como algum xml é assinado com algum tipo de certificado personalizado.
Não conseguimos entender nada pelo código e enviamos uma olhada para ver o que a máquina virtual estava lá. Abrimos os logs de serviço, encontramos um erro de cliente http neles, um certificado autoassinado que foi costurado nos recursos do aplicativo, sem escrúpulos. Entramos em contato com nossos analistas, eles pediram um novo certificado, eles o emitiram para nós e o serviço funciona novamente. Isso parece ser tudo. Ou não? Ainda assim, o serviço funciona, ele desempenha algumas funções que nossos negócios precisam. Temos alguns padrões de desenvolvimento de aplicativos que você provavelmente possui. Por exemplo, não armazene os logs no nó na pasta, mas armazene em algum tipo de armazenamento, como um elástico, observe-os no kiban. Você pode se lembrar das métricas de ouro. 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 vai o seu HealthCheck. No mínimo, essas métricas ajudarão você a descobrir quando pode ser desativado e esquecido como um pesadelo com a consciência limpa.
O que fazer
Portanto, adicionamos um serviço tão antigo ao tablet e depois procuramos voluntários dentre os desenvolvedores que cuidarão do serviço e o colocarão em ordem: eles escreverão pelo menos algumas informações sobre o serviço, adicionarão links a painéis em graphan, tarefas de montagem e entenderão como Implante o aplicativo, não faça upload de arquivos usando ftp com as mãos.
A principal coisa é quanto vai levar todo esse voluntariado útil? Um sprint para um desenvolvedor mais ou menos experiente, por exemplo, durante uma dívida técnica de 20%. E quanto tempo levou para entender toda a lógica profundamente enraizada da comunicação com um determinado sistema de estado e trazê-lo para as tecnologias mais recentes? Não posso garantir isso, talvez um mês ou talvez dois trabalhos em equipe. É o que digo a partir da experiência de integração no momento atual com algum novo serviço.
Ao mesmo tempo, não há exaustão do valor comercial. Absolutamente. Tomar o serviço de suporte e gastar um pouco de tempo é normal. Mas depois de nossas danças padrão com o serviço, adicionamos à mesa, adicionamos informações sobre ela e, talvez, algum dia a reescrevamos. Mas agora ele atende aos nossos padrões de serviço.
Como resultado, gostaria de trazer para um plano o que fazer com os serviços herdados.
Reescrever o legado do zero é uma má ideiaSério, você nem precisa pensar nisso. É claro que gostaríamos, e algumas vantagens são vistas, mas geralmente isso não é necessário para ninguém, inclusive para você.
Livro de referênciaDesenterre os códigos-fonte dos seus aplicativos, crie um diretório que indique o que, onde e como ele funciona, digite a descrição do projeto (readme.md condicional) para entender rapidamente onde estão os logs e as métricas. Um desenvolvedor que lida com isso depois que você só agradece.
Compreender o domínioSe você possui um domínio, tente manter o dedo no pulso. Parece brega, sim, mas nem todos garantem que os serviços estejam em uma única chave. Mas trabalhar em um padrão é realmente significativamente mais fácil.