Resiliência e Segurança de Deploy
Visão Geral
Coisas vão quebrar. A postura não é "prevenir toda falha", mas falhe pequeno, recupere rápido e aprenda sempre. Confiabilidade não é ausência de falha; é o raio de explosão limitado e o tempo de recuperação curto quando a falha chega.
Segurança de Deploy — Todo Deploy Reversível e Exposto Progressivamente
- O artefato é imutável e promovido, não reconstruído. Uma imagem, construída uma vez no CI e identificada por seu digest de conteúdo, move-se preview → staging → produção inalterada. Reconstruir por ambiente significa implantar algo que você nunca testou.
- Tags são ponteiros mutáveis; o digest é a identidade. Uma tag pode ser sobrescrita e apontar silenciosamente para outro lugar. Um digest de conteúdo não pode. Cada ambiente registra o digest que validou, e a produção executa apenas um digest que um ambiente inferior validou — então "exatamente o que testamos" é uma propriedade que o pipeline impõe, não uma disciplina que alguém precisa lembrar.
- Uma decisão humana precede a produção. Para um mantenedor solo, isso é uma pausa deliberada e um registro de auditoria, não uma separação de funções. Diga qual é o caso; não exagere.
- A versão em execução é injetada no momento do deploy, nunca embutida na imagem. Uma versão embutida como argumento de build força uma reconstrução para carimbar uma release, e a reconstrução é exatamente o que a promoção existe para evitar.
- Quando a infraestrutura fica em seu próprio repositório, coordene por expandir/contrair. A infraestrutura expande primeiro (aditiva, compatível com versões anteriores), a aplicação consome a nova capacidade em um deploy posterior, e a infraestrutura contrai apenas quando nenhum artefato vivo depende da forma antiga — a mesma disciplina de uma mudança de esquema (veja
migracoes-com-zero-tempo-de-inatividade). O invariante: nunca envie um artefato de aplicação que exija uma mudança de infraestrutura ainda não ativa. Mantido isso, cada repositório é independentemente reversível, o que torna o rollback tratável quando os dois estão dessincronizados. - Avance apenas quando puder reverter. Um caminho de rollback existe e é testado antes de uma mudança arriscada ser enviada. "Como desfazemos isso?" é respondido no plano, não durante o incidente.
- Rollback é reimplantar o digest anteriormente bom. Esse digest ainda está no registro e ainda é imutável, então reverter é promoção reversa — nunca uma reconstrução, e nunca uma reconstrução "como era".
- Exposição progressiva. Novas versões alcançam os usuários gradualmente (rollout verificado por saúde, canário onde suportado), então uma release ruim prejudica uma fração, não todos.
- Mudanças de esquema são desacopladas dos deploys de código e seguem expandir/contrair (veja
migracoes-com-zero-tempo-de-inatividade). Um deploy nunca deve exigir uma migração destrutiva simultânea. - Uma lista de verificação de prontidão para deploy bloqueia a produção: observabilidade em vigor, rollback verificado, migrações seguras para expansão, SLOs intactos.
Resposta a Incidentes — Falha é um Insumo para Aprendizado
- Classifique por severidade e responda proporcionalmente; tenha um caminho conhecido para engajar as pessoas certas.
- Postmortems sem culpa para todo incidente visível ao usuário. Linha do tempo escrita, causas contribuintes (sistêmicas, não pessoais), itens de ação concretos. A pergunta é "o que no sistema permitiu que isso acontecesse", nunca "quem errou".
- Itens de ação são rastreados, não esquecidos — eles fluem para o documento de Considerações Futuras (veja
registrando-decisoes) e se tornam trabalho real. - O orçamento de erros governa. Quando a confiabilidade é gasta, o trabalho de confiabilidade tem prioridade sobre funcionalidades até que o orçamento se recupere.
Referência Rápida
| Antes de um deploy arriscado | Confirme |
|---|---|
| Artefato | Construído uma vez no CI; promovido por digest; o mesmo que o staging validou |
| Portão | Uma decisão humana registrada antes da produção |
| Rollback | Caminho existe e é testado |
| Exposição | Gradual/canário, não tudo de uma vez |
| Esquema | Seguro para expansão, desacoplado do deploy de código |
| Observabilidade | Você consegue ver se está dando errado? |
Quando escalar isso
Projetos locais/pré-lançamento escrevem estas regras agora, ativam nos primeiros usuários reais. As propriedades são portáveis — construa uma vez, promova o que testou, decida antes da produção, seja capaz de reverter — mas os mecanismos não são: uma promoção por digest é significativa em um host de contêineres e praticamente irrelevante para um site estático, e uma plataforma gerenciada pode fornecer ambientes de preview e rollback instantâneo gratuitamente. Nomeie o mecanismo na skill de entrega do projeto; mantenha a propriedade aqui. Empilhe mecanismos (k8s probes, canário, ambientes por PR): entrega-na-nuvem-aks.
Raciocínio completo: Artigo XII da constituição, incluído em engenharia-constituicao/referencias/engenharia-constituicao.md.