{"id":53442,"date":"2019-12-02T00:00:00","date_gmt":"2019-12-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/legacy-servisy-v-vashej-infrastrukture"},"modified":"2020-02-18T14:01:20","modified_gmt":"2020-02-18T11:01:20","slug":"legacy-servisy-v-vashej-infrastrukture","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/legacy-servisy-v-vashej-infrastrukture","title":{"rendered":"Servi\u00e7os legados em sua infraestrutura","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1! Meu nome \u00e9 Pasha Chernyak, sou desenvolvedor principal na QIWI e hoje quero falar sobre o inevit\u00e1vel. Sobre o Legacy.<\/p>\n

Vamos come\u00e7ar com a pergunta: o que \u00e9 um servi\u00e7o Legacy? Um servi\u00e7o Legacy \u00e9 um servi\u00e7o que nenhum desenvolvedor tocou por uma semana\/m\u00eas\/ano? Ou \u00e9 um servi\u00e7o que foi escrito por um programador menos experiente, como voc\u00ea, h\u00e1 um ano? Agora voc\u00ea \u00e9 mais habilidoso e experiente. Ou um servi\u00e7o Legacy \u00e9 aquele que voc\u00ea decidiu nunca mais atualizar e est\u00e1 aos poucos preparando uma substitui\u00e7\u00e3o? De qualquer forma, deixar esse servi\u00e7o \u00e0 deriva e n\u00e3o atualiz\u00e1-lo \u00e9 uma bomba-rel\u00f3gio que pode explodir mais tarde.<\/p>\n

\"Servi\u00e7os<\/a><\/noindex><\/p>\n

Antes de falarmos sobre como trabalhamos com nossos servi\u00e7os Legacy na QIWI, vou contar como organizamos os servi\u00e7os em nossa carteira. H\u00e1 dois anos, sou respons\u00e1vel pelo seu funcionamento. Se h\u00e1 algum problema, sou sempre o primeiro a ser acionado. Normalmente n\u00e3o tenho a ousadia de ligar para algu\u00e9m \u00e0s 11 horas da noite, ent\u00e3o acabo tendo que me sentar e entender todos os servi\u00e7os do nosso dom\u00ednio. <\/p>\n

Mas eu, como qualquer pessoa, gosto de dormir \u00e0 noite, por isso tentei resolver a quest\u00e3o: \"Pessoal, por que voc\u00eas est\u00e3o me ligando?\". E recebi uma resposta bem direta: \"Quem mais?\". Porque eu conserto os servi\u00e7os e, al\u00e9m disso, a equipe simplesmente n\u00e3o sabe a quem ligar.<\/p>\n

Portanto, em uma das retrospectivas da equipe de back-end da carteira, decidimos que era necess\u00e1rio criar uma tabela listando nossos servi\u00e7os, microsservi\u00e7os e mon\u00f3litos, assim como os respons\u00e1veis por eles. Tabelas s\u00e3o realmente \u00fateis, dentro de limites razo\u00e1veis.
\n<\/a><\/noindex>
\nAl\u00e9m das informa\u00e7\u00f5es sobre quem \u00e9 respons\u00e1vel pelo qu\u00ea, havia respostas para perguntas como: quem \u00e9 o propriet\u00e1rio do servi\u00e7o, quem \u00e9 respons\u00e1vel por seu desenvolvimento, pela arquitetura e pelo ciclo de vida. As pessoas respons\u00e1veis por esse servi\u00e7o s\u00e3o aquelas que podem consert\u00e1-lo em caso de necessidade. O propriet\u00e1rio do servi\u00e7o tem o direito de adicionar +2 nos commits, e os respons\u00e1veis tamb\u00e9m devem estar presentes na revis\u00e3o antes que esse servi\u00e7o receba um novo commit.<\/p>\n

O tempo passou e novas pr\u00e1ticas come\u00e7aram a ser aplicadas, como a migra\u00e7\u00e3o para Kubernetes, diversos checkstyle, spotbugs, ktlint, a presen\u00e7a de logs no Kibana, autodiscovery de servi\u00e7os em vez de indicar endere\u00e7os diretamente, e outras utilidades. E em todos os lugares nossa tabela permitia manter a atualidade de nossos servi\u00e7os. Para n\u00f3s, isso \u00e9 uma esp\u00e9cie de checklist que indica que este servi\u00e7o \u00e9 capaz de fazer isso, mas ainda n\u00e3o faz isso. Mas n\u00f3s avan\u00e7amos, percebendo que faltava informa\u00e7\u00e3o sobre nossos servi\u00e7os que monitoramos, onde est\u00e3o os c\u00f3digos-fonte do servi\u00e7o, onde s\u00e3o iniciadas as tarefas de compila\u00e7\u00e3o no TeamCity, como s\u00e3o implementados, onde est\u00e3o armazenados os c\u00f3digos-fonte dos testes end2end, fotos sobre a arquitetura, decis\u00f5es tomadas. Idealmente, gostar\u00edamos que todas essas informa\u00e7\u00f5es estivessem armazenadas em algum lugar e acess\u00edveis quando necess\u00e1rio. Assim, nossa tabela se tornou o ponto de partida na busca por informa\u00e7\u00f5es.<\/p>\n

Mas a QIWI, embora mantenha o esp\u00edrito de startup, \u00e9 uma grande empresa. Estamos com 12 anos e as equipes mudam: pessoas v\u00e3o, pessoas v\u00eam, novas equipes s\u00e3o formadas. E encontramos em nosso dom\u00ednio v\u00e1rios servi\u00e7os que herdamos. Algo veio com desenvolvedores de outras equipes, algo estava indiretamente relacionado \u00e0 Carteira, por isso o servi\u00e7o agora est\u00e1 sob nossa responsabilidade. Para que se preocupar com o que e como funciona \u2014 por qu\u00ea? O servi\u00e7o est\u00e1 funcionando e temos recursos que precisamos desenvolver.<\/p>\n

Como costuma acontecer<\/h2>\n

\nMas em algum momento descobrimos que o servi\u00e7o parou de executar sua fun\u00e7\u00e3o, algo quebrou \u2014 o que fazer em uma situa\u00e7\u00e3o assim? O servi\u00e7o simplesmente parou de funcionar. Completamente. E descobrimos isso, primeiro, por acaso, e, segundo, seis meses depois. Isso acontece. A \u00fanica coisa que sab\u00edamos era em quais m\u00e1quinas virtuais o servi\u00e7o estava rodando, onde estavam seus c\u00f3digos-fonte, e s\u00f3. Fazemos git clone e mergulhamos nos pensamentos da pessoa que escreveu isso h\u00e1 alguns anos, mas o que vemos? Nenhum Spring Boot familiar para n\u00f3s, embora estejamos acostumados com tudo, j\u00e1 que temos um full stack e tudo mais. Pode ser que exista um Spring Framework? Mas n\u00e3o existe.<\/p>\n

O rapaz que escreveu tudo isso era rigoroso e programava tudo em Java puro. N\u00e3o h\u00e1 ferramentas familiares para os desenvolvedores e surge a ideia \u2014 seria bom reescrever tudo isso. Temos microservi\u00e7os, e de cada torradeira vem o familiar \"Pessoal, microservi\u00e7os s\u00e3o o que voc\u00eas precisam!\". Se algo n\u00e3o der certo, voc\u00ea pode pegar qualquer linguagem que tudo funcionar\u00e1 bem.<\/p>\n

A quest\u00e3o \u00e9 que atualmente n\u00e3o temos um cliente respons\u00e1vel por este servi\u00e7o. Quais eram suas necessidades de neg\u00f3cio? O que esse servi\u00e7o deve realmente fazer? E o servi\u00e7o est\u00e1 fortemente integrado aos seus processos de neg\u00f3cios. <\/p>\n

E agora me diga, qu\u00e3o f\u00e1cil \u00e9 reescrever o servi\u00e7o sem conhecer suas necessidades de neg\u00f3cio? N\u00e3o est\u00e1 claro como o servi\u00e7o faz logs, se h\u00e1 m\u00e9tricas \u2014 isso \u00e9 desconhecido. Quais s\u00e3o elas, se existirem \u2014 isso tamb\u00e9m \u00e9 desconhecido. E, al\u00e9m disso, o servi\u00e7o tem uma enorme quantidade de classes com l\u00f3gica de neg\u00f3cio confusa. Algo entra em um banco de dados do qual tamb\u00e9m n\u00e3o sabemos nada por enquanto. <\/p>\n

Por onde come\u00e7ar?<\/h2>\n

\nPelo mais l\u00f3gico \u2014 pela exist\u00eancia de testes. Geralmente, l\u00e1 est\u00e1 escrita alguma l\u00f3gica e \u00e9 poss\u00edvel tirar conclus\u00f5es sobre o que est\u00e1 acontecendo. Atualmente, o TDD est\u00e1 na moda, mas vemos que h\u00e1 5 anos era praticamente a mesma coisa que agora: quase n\u00e3o existem testes unit\u00e1rios, e eles n\u00e3o nos dizem nada. Bem, exceto talvez alguma verifica\u00e7\u00e3o de como um xml \u00e9 assinado com algum certificado personalizado.<\/p>\n

N\u00e3o conseguimos entender nada pelo c\u00f3digo, ent\u00e3o decidimos verificar o que estava acontecendo na virtualiza\u00e7\u00e3o. Abrimos os logs do servi\u00e7o 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\u00e7o voltou a funcionar. Pareceria que era isso. Ou n\u00e3o? Afinal, o servi\u00e7o est\u00e1 funcionando; ele realiza uma fun\u00e7\u00e3o que \u00e9 necess\u00e1ria para o nosso neg\u00f3cio. Temos certos padr\u00f5es de desenvolvimento de aplicativos, que provavelmente voc\u00eas tamb\u00e9m t\u00eam. Por exemplo, n\u00e3o armazenar logs no n\u00f3 dentro de uma pasta, mas sim em algum tipo de reposit\u00f3rio, como o Elasticsearch, e visualiz\u00e1-los no Kibana. Podemos lembrar tamb\u00e9m das m\u00e9tricas vitais. Ou seja, a carga no servi\u00e7o, o n\u00famero de solicita\u00e7\u00f5es para o servi\u00e7o, se ele est\u00e1 vivo ou n\u00e3o, como est\u00e1 o HealthCheck. Pelo menos, essas m\u00e9tricas ajudar\u00e3o a saber quando ele pode ser retirado de opera\u00e7\u00e3o e esquecido como um pesadelo.<\/p>\n

O que fazer<\/h2>\n

\nPor isso, adicionamos esse servi\u00e7o antigo \u00e0 tabela, e depois vamos procurar entre os desenvolvedores volunt\u00e1rios que queiram cuidar do servi\u00e7o e coloc\u00e1-lo em ordem: escrever alguma informa\u00e7\u00e3o sobre o servi\u00e7o, adicionar links para os dashboards no Grafana, para as tarefas de compila\u00e7\u00e3o, entender como implantar o aplicativo, n\u00e3o d\u00e1 para simplesmente jogar arquivos via FTP. <\/p>\n

O principal \u00e9 \u2014 quanto tempo toda essa atividade volunt\u00e1ria vai levar? Um sprint para um desenvolvedor mais ou menos experiente, por exemplo, durante 20% da d\u00edvida t\u00e9cnica. E quanto tempo levou para entender toda a l\u00f3gica enraizada para se comunicar com algum sistema governamental e traz\u00ea-la para tecnologias mais modernas? N\u00e3o posso garantir, pode levar um m\u00eas ou, talvez, dois meses de trabalho da equipe. Falo isso com base na experi\u00eancia de integra\u00e7\u00e3o atual com algum novo servi\u00e7o.<\/p>\n

Ao mesmo tempo, n\u00e3o h\u00e1 valor comercial algum. Nenhum. Assumir o suporte do servi\u00e7o e gastar um pouco de tempo nisso \u00e9 normal. Mas ap\u00f3s nossas dan\u00e7as padr\u00e3o com o servi\u00e7o, o adicionamos \u00e0 tabela, inclu\u00edmos informa\u00e7\u00f5es sobre ele e, talvez, um dia o reescreveremos. Mas, por enquanto, ele atende aos nossos padr\u00f5es de opera\u00e7\u00e3o dos servi\u00e7os.<\/p>\n

Como conclus\u00e3o, gostaria de apresentar um plano sobre o que fazer com os servi\u00e7os legados. <\/p>\n

Reescrever o legado do zero \u00e9 uma m\u00e1 ideia.<\/b>
\nS\u00e9rio, voc\u00ea nem deve pensar nisso. \u00c9 claro que seria bom e existem alguns benef\u00edcios, mas geralmente isso n\u00e3o \u00e9 necess\u00e1rio para ningu\u00e9m, incluindo voc\u00ea mesmo.<\/p>\n

Guia<\/b>
\nDesenterram os c\u00f3digos-fonte das suas aplica\u00e7\u00f5es e criam um guia que indique o que e onde est\u00e1, e como funciona. Inclua tamb\u00e9m uma descri\u00e7\u00e3o do projeto (um readme.md), para entender rapidamente onde est\u00e3o os logs e as m\u00e9tricas. O desenvolvedor que trabalhar nisso depois de voc\u00ea s\u00f3 vai agradecer.<\/p>\n

Entenda o dom\u00ednio<\/b>
\nSe voc\u00ea possui algum dom\u00ednio, tente ficar atento. Parece banal, sim, mas nem todos monitoram para que os servi\u00e7os estejam em uma mesma linha. E, na verdade, \u00e9 muito mais f\u00e1cil operar com um \u00fanico padr\u00e3o.<\/p>\n

Apenas usu\u00e1rios registrados podem participar da pesquisa. Entre<\/a><\/noindex>, por favor.<\/p>\n

O que voc\u00ea faz com seu legado?<\/h2>\n