Navegue neste artigo
Infraestrutura de produção não é apenas o lugar onde a aplicação roda. Ela reúne os controles que permitem publicar, observar, atualizar e recuperar o sistema com um nível de risco compatível com o negócio.
A arquitetura deve ser proporcional ao produto
Nem todo produto precisa de Kubernetes, múltiplas regiões ou dezenas de serviços. Muitas aplicações operam melhor com uma VPS bem configurada, containers, banco protegido, proxy reverso e uma rotina clara de atualização e recuperação.
A decisão considera criticidade, volume, equipe, orçamento, requisitos de disponibilidade e tempo aceitável de recuperação. Complexidade também é um risco operacional.
A infraestrutura certa é a menor arquitetura capaz de atender os requisitos atuais com um caminho compreensível de evolução.
Começo pelo risco e pelos ativos que precisam ser protegidos
Antes de configurar servidores, identifico dados sensíveis, credenciais, integrações, fluxos de receita e pontos cuja indisponibilidade interromperia a operação. Esse mapa orienta onde colocar controles mais fortes.
Também defino responsabilidades: quem pode publicar, acessar produção, restaurar um backup, alterar DNS ou rotacionar uma credencial. Segurança sem responsáveis claros tende a existir apenas no documento.
- Dados pessoais, financeiros ou estratégicos.
- Credenciais e chaves de integração.
- Domínios, DNS e certificados.
- Banco de dados, arquivos e filas.
- Pipelines e registros de artefatos.
- Acessos administrativos e trilhas de auditoria.
Acesso, rede e segredos formam a primeira camada
Reduzo a superfície exposta, separo serviços internos dos públicos e aplico o princípio do menor privilégio. Segredos ficam fora do código, com escopo limitado e possibilidade de rotação.
Firewall, TLS e autenticação forte ajudam, mas não substituem atualizações, inventário de dependências e revisão periódica de acessos.
- Acesso administrativo restrito, individual e autenticado.
- Portas públicas apenas quando necessárias.
- Segredos fora do repositório e com rotação possível.
- Criptografia em trânsito e certificados renováveis.
- Permissões separadas por serviço e ambiente.
- Registro de alterações e acessos sensíveis.
Deploy precisa ser reproduzível e reversível
Uma entrega segura produz o mesmo artefato a partir da mesma versão, aplica migrações de forma controlada e verifica saúde antes de expor a nova versão. O pipeline não deve depender de passos lembrados por uma única pessoa.
Rollback não é apenas voltar o código. Mudanças em banco e contratos de API precisam ser compatíveis ou ter um plano próprio de retorno.
- Versão identificável e build reproduzível.
- Configuração separada do código.
- Migrações revisadas e compatíveis.
- Health checks e validação após deploy.
- Estratégia de rollback ou correção segura.
- Registro de quem publicou e o que mudou.
Observabilidade mostra o que o usuário está sentindo
Logs registram eventos, métricas mostram tendências e traces ajudam a seguir uma operação entre componentes. O importante é conectar esses sinais a perguntas reais: o serviço está respondendo, o fluxo principal conclui e os erros estão aumentando?
Alertas precisam apontar para situações que exigem ação. Uma grande quantidade de notificações sem prioridade apenas ensina a equipe a ignorá-las.
- Logs estruturados sem dados sensíveis desnecessários.
- Métricas de disponibilidade, latência, erros e capacidade.
- Traces para fluxos distribuídos e integrações.
- Alertas acionáveis com responsável e procedimento.
- Dashboards ligados a jornadas e objetivos do serviço.
Backup só existe quando a restauração foi testada
Banco, cache e arquivos possuem ciclos de vida diferentes. Defino o que precisa persistir, por quanto tempo, em qual local e quem pode restaurar. Cópias importantes não devem depender do mesmo servidor que estão protegendo.
O plano de continuidade registra tempo e perda aceitáveis, ordem de recuperação e comunicação durante o incidente. Ele precisa ser exercitado antes de ser necessário.
- Política de retenção e cópias fora do ambiente principal.
- Restauração testada com evidência.
- RPO e RTO compatíveis com o negócio.
- Runbook de incidente e responsáveis.
- Revisão de capacidade e custo ao longo do tempo.
Agentes exigem limites adicionais de execução
Agentes podem consultar dados e executar ferramentas, por isso o ambiente precisa controlar permissões, custo, tempo, volume e efeitos possíveis. Entradas externas são tratadas como não confiáveis, e ações sensíveis pedem aprovação.
Tracing, avaliações e logs ajudam a entender como uma decisão foi construída. O objetivo do harness é limitar o impacto de uma resposta errada e tornar o comportamento auditável.
- Ferramentas expostas por função e com escopo mínimo.
- Limites de custo, tempo e quantidade de tentativas.
- Validação de entradas e saídas.
- Aprovação humana para ações irreversíveis.
- Auditoria de chamadas, resultados e falhas.
- Mecanismo de interrupção e recuperação segura.
Fontes e leituras relacionadas
Este material apresenta minha forma de trabalhar e tem caráter educativo. A solução adequada depende do contexto, dos riscos e das responsabilidades de cada projeto.
Compartilhar