Deploy terminou. A pipeline passou, o health check respondeu 200, o release está em produção. A tendência natural é fechar a aba e passar para a próxima tarefa. Mas "respondeu 200" e "está configurado como deveria" são frases diferentes, e a distância entre elas é onde muitos incidentes começam.
Um serviço pode estar disponível e, ao mesmo tempo, com o certificado prestes a expirar, sem headers de segurança essenciais, ou servindo dados públicos desatualizados. Uptime responde "está respondendo?". O checklist pós-deploy responde "está tudo certo do ponto de vista de quem acessa de fora?".
Disponibilidade e latência
O primeiro item é o mais óbvio, mas vale detalhar. Verificar disponibilidade não é só fazer um GET e esperar 200. É conferir:
- O endpoint principal responde com o status esperado?
- A latência está dentro do razoável para a região de quem acessa? Um deploy que mudou dependências pode dobrar o tempo de resposta sem mudar o status code.
- O conteúdo retornado é o esperado? Um 200 com corpo vazio ou com uma página de fallback não é um sucesso.
Para APIs, vale fazer uma requisição que exercite o caminho crítico — não apenas o health check. O health check muitas vezes bypassa a aplicação real e responde direto do balanceador ou do sidecar.
Certificado SSL/TLS
O segundo item é o que costuma ficar de fora. Um deploy pode, direta ou indiretamente, afetar o certificado:
- O certificado entregue na porta 443 é o correto para aquele hostname? Mudanças de infraestrutura (troca de balanceador, ajuste de proxy reverso) podem fazer o servidor voltar a servir um certificado antigo ou errado.
- Quantos dias restam até a expiração? Se o deploy aconteceu em um ambiente que acabou de renovar o certificado, vale confirmar que o novo está sendo servido.
- A cadeia está completa? Intermediários faltando geram erro em clientes rigorosos mesmo que o certificado da folha esteja válido.
Uma checagem rápida com curl -vvI https://seudominio.com mostra o certificado entregue e a cadeia. Em ambientes com múltiplos hostnames ou rotas condicionais, vale testar cada um.
Headers de segurança
Headers de segurança são configuração de servidor ou de proxy reverso, e mudanças de infraestrutura podem alterá-los sem aviso. Os principais para conferir:
- Strict-Transport-Security (HSTS). Diz ao navegador para sempre usar HTTPS naquele domínio. Sem ele, a primeira visita pode cair em HTTP e ficar vulnerável a downgrade.
- X-Content-Type-Options: nosniff. Impede que o navegador tente adivinhar o MIME type de uma resposta, reduzindo risco de interpretação equivocada de conteúdo.
- Content-Security-Policy (CSP). Define de onde a página pode carregar recursos. Um deploy que muda a origem de assets (CDN, bucket S3) pode quebrar a página se a CSP não for atualizada junto.
- X-Frame-Options ou frame-ancestors na CSP. Controla se a página pode ser carregada em iframes. Relevante para prevenir clickjacking.
Nenhum desses headers é obrigatório por padrão. Eles precisam estar explícitos na configuração. Se o deploy mudou a forma como o servidor é servido — por exemplo, trocou de nginx para um balanceador gerenciado — os headers podem ter sido perdidos no caminho.
Domínio e dados públicos relacionados
O último item é o mais negligenciado. Um domínio público carrega mais informação do que o conteúdo da página:
- Os registros DNS estão apontando para os destinos esperados? Uma mudança de IP ou de CNAME pode ter sido parte do deploy, e vale confirmar que propagou.
- Existem registros de segurança de e-mail (SPF, DKIM, DMARC) consistentes? Se o deploy envolveu mudança de provedor de e-mail, esses registros precisam estar alinhados.
- Dados públicos do domínio (como informações expostas em headers de resposta ou em metadados) mudaram?
Esse tipo de verificação raramente faz parte do checklist padrão, mas é exatamente o que um visitante externo — ou uma ferramenta de monitoramento — vê.
Por que fazer isso depois de cada deploy
Um checklist pós-deploy não substitui testes de integração, staging ou canary. Ele cobre um espaço diferente: o momento em que o código já está em produção, mas ninguém ainda olhou para o serviço como um visitante externo. É nesse intervalo que problemas de configuração ficam ativos por horas ou dias, até alguém perceber pelo sintoma visível.
Transformar essas verificações em rotina — ou em automação — reduz o tempo entre o deploy e a detecção de um problema que não apareceu nos testes.
Próximo passo
Pegue os quatro itens — disponibilidade, certificado, headers e dados públicos — e transforme em um script ou em uma etapa da pipeline que rode automaticamente após cada deploy. O que não é automático vira item esquecido. Se automatizar não for viável agora, ao menos deixe o checklist documentado e visível para quem faz a revisão final.
Ferramentas de monitoramento externo como a cymesh podem executar essas verificações de forma contínua, não apenas no momento do deploy, e guardar histórico do que mudou e quando. O princípio, porém, é o mesmo: disponível não é o mesmo que revisado.