Navegue neste artigo
Uma aplicação não está pronta só porque o container iniciou. Ela precisa responder corretamente, proteger seus acessos e ter um caminho de recuperação. Use este roteiro em um ambiente de teste antes da primeira publicação.
Desenhe o caminho de uma requisição
Liste entrada pública, proxy, aplicação, banco, filas e integrações. Marque onde ficam credenciais e dados persistentes. O mapa pode ser simples, mas precisa mostrar o que deixa de funcionar quando uma dependência falha.
Separe configuração de segredos. Valide as variáveis exigidas na inicialização e evite credenciais dentro da imagem ou do repositório. Exponha publicamente só os serviços necessários e mantenha permissões proporcionais à função de cada componente.
Publique uma versão que você consegue identificar
Use um artefato versionado e registre qual revisão está em execução. A pipeline deve construir, testar e publicar esse artefato, não depender de alterações manuais no servidor. Verifique a saúde da aplicação e uma jornada real depois da publicação.
Uma migração incompatível pode impedir o retorno da versão anterior. Quando possível, separe mudanças de estrutura e remoções em etapas compatíveis. Escreva o plano de reversão antes de precisar dele.
artefato -> testes -> migração compatível -> deploy
-> saúde + jornada
-> observar
-> continuar ou reverterRegistre sinais que levem a uma ação
Logs explicam eventos; métricas mostram comportamento agregado; traces ajudam a acompanhar uma requisição entre componentes. Comece pelas perguntas da operação: qual jornada falhou, desde quando e qual dependência estava envolvida?
- Identificador de requisição para conectar eventos.
- Taxa de erros e tempo de resposta dos fluxos importantes.
- Fila acumulada e tarefas que não concluem.
- Alertas com responsável e instrução inicial de investigação.
Não grave tokens, senhas ou payloads completos por conveniência. Defina acesso e retenção dos registros.
Restaure um backup antes de confiar nele
Criar um arquivo de backup não prova que ele pode ser restaurado. Em um ambiente separado, recupere banco e arquivos necessários, suba a aplicação e valide uma jornada. Registre quanto tempo demorou e qual ponto dos dados foi recuperado.
RPO representa a perda de dados tolerável em tempo; RTO, o tempo desejado de recuperação. Defina ambos com quem responde pela operação. Eles orientam frequência de backup, retenção e investimento, em vez de surgir de uma configuração padrão.
- Exercício: restaurar dados fictícios e concluir uma consulta na aplicação recuperada.
- Entrega: instruções de deploy, teste de restauração e responsáveis por incidentes.
- Critério de aceite: outra pessoa consegue seguir o procedimento e obter o mesmo resultado.
Fontes e leituras relacionadas
Material educativo. Valide os exemplos em um ambiente de teste e adapte as decisões ao contexto, aos riscos e às responsabilidades do seu projeto.
Compartilhar