Primeiro: entender o risco real
Antes de alterar um sistema antigo, mapeamos versão de linguagem e framework, dependências, banco, integrações, deploy, backups, pontos de falha e conhecimento que hoje está apenas na cabeça de alguém.
Essa leitura gera uma fila priorizada: incidentes e riscos de segurança primeiro; depois automação de deploy, testes, observabilidade e modernizações que reduzem custo futuro.
- Aplicações Java/Spring antigas e modernas
- Sistemas PHP e integrações históricas
- Bancos PostgreSQL, Oracle e MySQL
- Pipelines GitHub Actions, GitLab CI e Jenkins
- Docker, Kubernetes, AWS, Azure e Google Cloud
Modernização progressiva em vez de big bang
Reescrever tudo de uma vez costuma trocar um risco conhecido por vários riscos novos. Quando possível, isolamos módulos, extraímos integrações, atualizamos dependências por etapas e adicionamos testes ao redor dos fluxos que mais importam.
Esse modelo permite entregar melhorias enquanto o sistema continua gerando valor.
Operação com sinais, não com adivinhação
Logs estruturados, métricas, alertas e rastreamento de transações reduzem o tempo para descobrir por que algo falhou. O objetivo de observabilidade não é colecionar dashboards: é responder rapidamente o que aconteceu, quem foi afetado e qual mudança corrigirá o problema.
Como assumimos um sistema sem documentação
O primeiro passo nunca é alterar código. É uma leitura do repositório e da infraestrutura que produz um mapa: onde estão os pontos únicos de falha, quais dependências estão sem atualização de segurança, o que não tem backup testado e quais partes ninguém pode tocar sem quebrar outra coisa.
Esse levantamento é entregue como documento, com os riscos ordenados por gravidade e esforço. Ele tem valor por si só, mesmo que a sustentação continue com outra equipe.
- Inventário de sistemas, integrações, credenciais e acessos
- Mapa de risco com dependências vencidas e falhas conhecidas
- Verificação de backup e teste real de restauração
- Plano de estabilização com prioridade e esforço estimados
- Documentação de arquitetura que não existia antes
Modernização gradual, sem parar a operação
Reescrita completa é a decisão mais cara e mais arriscada disponível, e quase nunca é necessária. O caminho que funciona é substituir o legado por partes: isolar um módulo atrás de uma interface, reescrever esse módulo, direcionar o tráfego para a versão nova e repetir.
A operação nunca para, cada etapa pode ser revertida e o valor aparece durante o processo, não só no fim. É também o único formato em que dá para interromper o trabalho no meio sem ficar com um sistema pela metade.
Observabilidade e resposta a incidente
Sistema sem telemetria só avisa que caiu quando o cliente liga. Com métrica, log estruturado e alerta configurado, o problema aparece antes e a investigação leva minutos em vez de um dia inteiro de tentativa e erro.
No plano Crítico há canal de emergência 24/7 para incidentes críticos (P1), com sistemas cobertos e SLA definidos na proposta. O tempo de atuação é descontado da franquia mensal. Nos demais planos, o atendimento acontece em horário comercial, sempre com registro do que foi feito e do tempo consumido.
- Métrica, log estruturado e rastreamento entre serviços
- Alerta com limiar acordado — não alerta que todo mundo ignora
- Registro pós-incidente com causa raiz e ação corretiva
- Relatório mensal de horas consumidas e saúde dos sistemas
- Revisão de custo e dimensionamento em AWS, Azure e Google Cloud
Perguntas frequentes
Vocês trabalham com sistema sem documentação?
Sim. A documentação inicial pode ser reconstruída a partir de código, banco, infraestrutura, logs e conversas com usuários-chave.
Precisa migrar para Kubernetes?
Não. Kubernetes só faz sentido quando o contexto justifica a complexidade. Para muitos sistemas, containers simples ou uma plataforma gerenciada são mais econômicos e confiáveis.
Atendem incidente fora do horário?
O plano Crítico prevê canal de emergência 24/7 para incidentes críticos (P1). Sistemas cobertos, severidades e SLA são definidos na proposta; o atendimento consome a franquia contratada e horas excedentes dependem de aprovação.
Vocês assumem um sistema sem documentação nenhuma?
Sim, é o caso mais comum. O levantamento inicial produz a documentação que não existia: arquitetura, integrações, dependências e riscos.
E se o sistema cair fora do horário comercial?
No plano Crítico há canal direto de emergência 24/7 para incidentes P1, dentro do escopo e SLA acordados. Nos demais, o atendimento é em horário comercial com resposta no mesmo dia útil.