Checklist de Segurança para Deploy

Passo 1 — Classificar o risco do deploy

Aplicar a matriz de risco Gzero antes de qualquer outra coisa. O nível de risco determina o rigor do checklist:

| Risco | Critério | Rigor |

|---|---|---| | Critical | Toca cobrança, autenticação, dados de cliente; migração de schema; deploy coordenado de >3 serviços. | Checklist completo + dois aprovadores + janela restrita. | | High | Mudança em serviço P0/P1 sem flag; dependência externa nova. | Checklist completo + um aprovador. | | Medium | Mudança em serviço P0/P1 atrás de flag; alteração em job batch crítico. | Checklist obrigatório + DRI assina. | | Low | Mudança isolada, sem efeito em outros serviços, com flag. | Checklist reduzido (passos 2, 5, 8). |

Registrar o risco escolhido e a justificativa no documento de deploy.

Passo 2 — Validar cobertura de testes

Não basta CI estar verde. Verificar especificamente:

- [ ] Teste unitário cobre o caminho alterado.

- [ ] Teste de integração cobre fronteira com serviços/vendors afetados. - [ ] Teste manual em ambiente staging foi executado (se mudança de UI/UX crítica). - [ ] Migração de schema foi testada em ambiente espelho da prod (volume similar). - [ ] Casos de borda críticos documentados no PR (ou notas do release).

Se algum item não se aplica (ex: deploy de config), justificar por escrito.

Passo 3 — Confirmar feature flag, canary ou blue/green

Mudança crítica não vai para 100% de tráfego de uma vez. Confirmar qual estratégia será usada:

- Feature flag: mudança envelopada em flag default-off. Rollout gradual por % ou cohort. Plano de ramp documentado (ex: 1% → 10% → 50% → 100% com 24h entre etapas).

- Canary: subconjunto de instâncias recebe a nova versão antes do resto. Critério de promoção documentado (ex: erro <0.1% por 30min). - Blue/green: versão nova roda em paralelo; tráfego é cortado quando saudável. Critério de switch documentado. - Sem flag/canary: apenas para risco low ou mudança puramente reversível em segundos.

Para risco critical/high, flag ou canary é obrigatório, sem exceção.

Passo 4 — Validar observability ready

O time precisa ver o que está acontecendo durante e depois do deploy. Confirmar:

- [ ] Dashboard do serviço está aberto e funcional.

- [ ] Métricas de SLO (latência p95, error rate, throughput) sendo coletadas. - [ ] Logs centralizados acessíveis com filtro pronto para o serviço. - [ ] Alertas críticos do serviço estão ativos (não silenciados de algum incident anterior). - [ ] Se mudança nova introduz métrica/log novo, este já está sendo coletado em staging.

Se uma métrica crítica falta, o deploy não vai. Sem métrica, é impossível detectar regressão.

Passo 5 — Validar dependências

Confirmar que tudo que o serviço depende está saudável e foi notificado:

- [ ] Serviços downstream cientes (se mudança no contrato).

- [ ] Vendors externos notificados se for janela de risco compartilhada. - [ ] Banco de dados sem maintenance window concorrente. - [ ] Janela não conflita com outro deploy de serviço acoplado. - [ ] Feature flag service e config service estão saudáveis.

Passo 6 — Validar comunicação

Quem precisa saber, sabe. Para risco medium+:

- [ ] Anúncio no canal de deploy/ops (#deploys ou equivalente) com janela.

- [ ] Time de suporte notificado para acompanhar tickets. - [ ] Time de produto notificado se há impacto visível ao usuário. - [ ] Status page interna atualizada (se aplicável). - [ ] Se risco critical: aprovação por escrito de líder técnico + manager.

Template mínimo do anúncio:

`` [DEPLOY] — Risco: DRI: <@pessoa> Janela: → Flag/Canary: Rollback: Acompanhe em: <#canal> `

Passo 7 — Validar plano de rollback testável

Plano de rollback que não foi testado é fantasia. Verificar:

- [ ] Plano de rollback existe por escrito, com comandos exatos.

- [ ] Rollback foi simulado em staging recentemente (<30 dias) OU é um caminho conhecido (revert de PR, toggle de flag). - [ ] Tempo estimado de rollback documentado. - [ ] Plano cobre: rollback de código, rollback de schema (se houver), rollback de config, rollback de flag. - [ ] Existe critério de decisão claro: "se métrica X passar de Y por Z minutos, executar rollback".

Para mudança de schema irreversível (drop de coluna, migração destrutiva), o "rollback" verdadeiro é forward fix, e isso precisa estar explícito no plano.

Passo 8 — Validar janela de deploy

Algumas janelas são proibidas por padrão. Bloquear deploy se:

- Sexta-feira após 16h (a não ser hotfix urgente aprovado).

- Véspera de feriado prolongado. - Última semana do mês (financeiro) se serviço toca cobrança. - Quando o DRI ou o secundário do on-call vai estar offline nas próximas 4h. - Durante outro incidente ativo no mesmo domínio.

Exceções precisam de aprovação documentada.

Passo 9 — Emitir GO/NO-GO

Com todos os passos respondidos, o DRI emite a decisão:

- GO: todos os itens aplicáveis marcados, registro assinado, deploy autorizado.

- NO-GO: ao menos um item crítico falhou. Listar quais e o que precisa ser resolvido antes da próxima tentativa. - GO condicional: itens não críticos pendentes, com plano de mitigação documentado.

A decisão fica registrada no documento de deploy com timestamp e nome do DRI.

Passo 10 — Pós-deploy: validar e fechar

Durante e após o deploy, confirmar:

- [ ] Métricas se mantiveram em SLO durante a janela.

- [ ] Alertas não dispararam (ou dispararam e foram tratados sem rollback). - [ ] Validação manual de funcionalidade-chave executada (smoke test). - [ ] Comunicação de fechamento enviada no canal. - [ ] Se houve incident → abrir postmortem com incident-postmortem`. - [ ] Se houve aprendizado → atualizar o runbook do serviço.