Neste cliente, meu trabalho tinha duas frentes. Uma era um projeto com começo, meio e fim: desligar uma linha de produto financeiro inteira. A outra era o dia a dia, garantindo que os times de produto não ficassem parados esperando a plataforma.
Desligar sem quebrar
A empresa decidiu descontinuar uma linha de produto. Ficaram para trás mais de uma dezena de microsserviços, cada um com banco de dados, segredos, pipelines e infraestrutura em sandbox e produção, além de dezenas de repositórios. Parte deles já estava arquivada, mas ninguém tinha certeza do que ainda rodava.
Desligar sistema financeiro é delicado. Apagar algo que ainda está em uso derruba a produção, e apagar sem backup pode significar perder dado que precisa ser guardado. Por isso, antes de apagar qualquer coisa, escrevi um roteiro de desligamento e passei a aplicá-lo serviço a serviço, sempre na mesma ordem: tirar o exporter de métricas, remover a infraestrutura do Terraform e os releases do Helm, localizar o banco do serviço pelo Vault, apagar os segredos e as referências no Vault e no Jenkins, excluir os bancos de sandbox e de produção e, por fim, arquivar os repositórios.
Antes de remover cada serviço ou VM, havia backup e snapshot. Cada etapa ficou registrada com evidência no card do serviço, em sandbox e em produção. E documentei como descobrir qual banco cada serviço usava a partir dos segredos no Vault, um conhecimento que não estava escrito em lugar nenhum.
No fim, todos os serviços foram desligados com rastreabilidade: para cada um, é possível provar o que saiu, quando e com qual backup. A empresa passou a manter e pagar menos infraestrutura, com menos segredos expostos, e o roteiro ficou pronto para os próximos desligamentos.
Destravar quem entrega
No dia a dia, os times de produto dependiam da plataforma para quase tudo que não era código. Atendi dezenas de pedidos de times diferentes. Na parte de segredos, eram credenciais de integrações no Vault, credenciais dinâmicas de banco e chaves cifradas com KMS. No CI/CD, falhas de build e deploy no Jenkins, no Helm e no SonarQube, incluindo um bloqueio de quality gate em plena semana de entrega. Em acesso e rede, SSO, VPN, DNS interno, security groups, rotas de API gateway e permissões em S3 e EKS.
Para que os pedidos repetidos deixassem de depender de mim, escrevi um guia de solução para os tipos mais comuns e registrei um débito técnico: configurações de API gateway feitas à mão em homologação, que precisavam ir para a infraestrutura como código.
"O parceiro está lento"
Chamadas para um parceiro externo às vezes passavam de três segundos, e o parceiro garantia que respondia sempre em menos de 500 ms. Em vez de discutir quem tinha razão, medi. Escrevi um script que, de dentro do cluster, repetia a chamada e separava o tempo de DNS, de conexão TCP, de handshake TLS e de resposta.
DNS e TCP eram sempre rápidos. Em 4 de cada 10 chamadas, o atraso de cerca de três segundos acontecia exatamente no handshake TLS. A conversa saiu do "é a rede" e do "é o parceiro" e passou a ter um lugar específico para investigar.
Por que os desenvolvedores não viam os pods
Os engenheiros não conseguiam ver o consumo de CPU e memória dos pods em nenhum ambiente. Fui camada por camada. O mapeamento de usuários no cluster estava certo. A role de leitura do Kubernetes já incluía as métricas. O login pelo SSO assumia a role certa na AWS. O que faltava era a role do SSO cadastrada nos acessos do cluster EKS. Adicionei a entrada, e os engenheiros passaram a ver o consumo sem pedir para a plataforma.
O que eu levo disso
Em sistema legado, o perigo não está no que você sabe que existe, e sim no que ninguém lembra que ainda roda. Um roteiro com evidência transforma uma tarefa arriscada num processo auditável. E, quando duas partes discordam, seja sobre latência ou sobre permissão, quebrar o problema em etapas costuma encerrar a discussão e mostrar onde procurar.