Grande parte dos sistemas que eu vejo quebrar dá sinal antes. O problema é que quase ninguém presta atenção nesses sinais até que seja tarde demais. Depois de anos assumindo sistemas de outras pessoas e cuidando dos meus próprios, aprendi a reconhecer o que costuma aparecer antes de uma queda séria. É isso que eu quero contar aqui.
Os sinais técnicos aparecem bem antes da queda
Só que quase ninguém está olhando pra eles. Dependências que ficaram anos sem atualizar. Versões de linguagem ou framework que o fabricante já não suporta mais. Backup que existe, mas nunca foi testado numa restauração de verdade. Certificado e domínio que sempre são renovados em cima da hora. Alertas que chegam e que ninguém lê. Lentidão que aumenta um pouquinho a cada mês, sem que ninguém pergunte por quê. Tudo isso é fumaça.
Os sinais comportamentais são ainda mais reveladores
Quando alguém diz "não mexe nisso que está funcionando", eu já fico atento. Quando só uma pessoa sabe reiniciar o servidor, ou quando quem criou o sistema saiu da empresa e não deixou nada escrito, o alerta já está ligado. Quando o time tem medo de publicar uma mudança numa sexta-feira, o sistema já está doente. Pra mim o melhor termômetro é justamente esse medo. Se a equipe tem receio de tocar em alguma parte do código, aquela parte é o próximo problema.
O erro mais comum de quem gere o negócio
É achar que um sistema pronto está terminado. Muita gente trata software como um prédio, que você constrói e depois só usa. Na prática ele se parece muito mais com um carro, que precisa de revisão mesmo quando está andando bem.
O que costuma ficar de fora é justamente o que parece invisível. Atualização de segurança, teste de backup, monitoramento, documentação, acesso e senha guardados em nome de uma pessoa e não da empresa, renovação de domínio e de certificado. Nada disso dá retorno visível enquanto está funcionando, então vira o primeiro corte quando o orçamento aperta. O problema é que a conta chega depois, e chega bem maior.
Um padrão que se repete
O começo é quase sempre inocente. Uma dependência fica sem atualizar porque alguém teve receio de que a atualização quebrasse algo. Passa um ano, depois dois, e a distância entre a versão que o sistema usa e a versão atual cresce tanto que atualizar deixa de ser uma tarefa e vira um projeto inteiro.
Aí acontece o gatilho. Aparece uma falha de segurança, ou o provedor descontinua a versão antiga, ou uma integração com terceiros para de funcionar do nada. De repente virou urgente, e urgência sai caro. Tudo é feito às pressas, muitas vezes no pior momento possível, como um período de pico de vendas. O que custaria algumas horas por mês vira semanas de trabalho sob pressão, com risco real de perder dado ou ficar fora do ar.
Outro padrão que já vi se repetir é o do backup fantasma. Todo mundo acredita que ele existe, ninguém nunca tentou restaurar, e no dia em que precisa descobre que estava incompleto, ou vazio.
Um checklist pra avaliar o seu sistema
Antes de assumir um sistema de terceiros, eu tento responder a estas perguntas. Você pode aplicar no seu próprio sistema mesmo sem ser técnico, é só levar essas perguntas pro seu time ou pro seu fornecedor.
- Alguém consegue colocar o sistema pra rodar do zero em outra máquina, seguindo só o que está documentado?
- O código está num repositório versionado, e a empresa tem acesso de administrador a ele?
- Quais dependências e versões estão desatualizadas, e alguma delas já saiu de suporte?
- Existem testes automatizados, mesmo que sejam poucos?
- Existe backup, e alguém já restaurou um pra provar que funciona?
- Quem tem acesso a servidor, banco de dados, domínio e serviços externos, e essas contas pertencem à empresa?
- Existe monitoramento e registro de erros, e alguém realmente olha isso?
- Há cuidados básicos de segurança, como senha fora do código, painel administrativo protegido e servidor atualizado?
- Como uma mudança chega até a produção, e quantos passos manuais existem nesse caminho?
- O histórico de alterações mostra atividade recente, e quantas pessoas diferentes já mexeram nele?
- Se a pessoa mais importante do projeto sumisse amanhã, o sistema continuaria de pé?
- Quais são as datas de vencimento de domínio, certificado, licenças e cobranças dos serviços usados?
Uma dica de leitura. Conte quantas respostas foram "não sei". Esse número diz mais sobre o risco do que qualquer resposta isolada.
O custo real de ignorar isso
O dinheiro é a parte mais visível, mas não é a maior. Existe o tempo, porque a equipe passa a viver apagando incêndio e para de construir o que traria crescimento de verdade. Existe o estresse, das noites e fins de semana de emergência, do medo constante de que algo caia. E existe a reputação, que demora anos pra construir e uma tarde fora do ar pra arranhar. Cliente que perde dado ou não consegue comprar raramente reclama. Ele simplesmente vai embora.
Quando a pessoa decide agir de forma preventiva, muda o tipo de conversa inteira. O custo fica pequeno, previsível e constante. As decisões passam a ser tomadas com calma, comparando opções, e não no desespero. O time ganha confiança pra evoluir o sistema em vez de só sustentá-lo. E o dono do negócio dorme melhor, o que não é um detalhe pequeno.
Não é gasto, é o preço de funcionar
Manutenção não é gasto, é o preço de ter um sistema funcionando de verdade. Não precisa começar grande. Um dia por mês dedicado a atualizar, testar o backup e revisar acessos já muda o jogo. E descobrir o que você não sabe sobre o seu próprio sistema já é uma vitória, porque é impossível cuidar do que a gente nem enxerga.