Operação em produção¶
Produção usa a mesma aplicação serverless, com configuração e credenciais específicas. A presença de recursos no SAM e de testes locais não prova que uma conta esteja implantada, homologada ou aprovada para tratamento de dados reais. Esta referência foi produzida por inspeção do checkout, sem consultar produção.
Antes do go-live¶
| Controle | Evidência necessária |
|---|---|
| Versão e ambiente | Commit aprovado, stack/região/conta, build e validação SAM |
| Segurança HTTP | Assinatura Meta habilitada, verify token, HTTPS, DEV_UI_ENABLED=false |
| Operadores | Whitelist revisada, link correto, sessão diária, operadores cientes de disponivel/entrar |
| Providers | URLs, tokens, pipeline/stages, owner e cadastro eGestor homologados |
| Testes | Unitários/replay, avaliação de agentes e smokes controlados com resultados distintos |
| CRM durável | Worker ativo, backlog monitorado e procedimento para BLOCKED/UNCERTAIN |
| Alertas | AlertsSnsTopicArn válido e inscrição confirmada pelo responsável |
| Dados | Retenção, backup, restauração e acesso ao histórico definidos |
| Suporte | Responsável de plantão, critérios de escalonamento e rollback ensaiado |
| Privacidade | Termos, aviso, base de tratamento/consentimento e política de retenção aprovados pelos responsáveis |
O README e context/infra/deploy.md registram pendências históricas, inclusive LGPD. Não use esses registros nem esta página como parecer jurídico atualizado. O código contém registro de consentimento e solicitação de apagamento administrativa; isso não comprova que exista um processo completo de cumprimento de todas as obrigações legais.
Controles implementados e limites¶
O webhook rejeita assinatura inválida com 401 quando Cloud API está habilitada e rejeita payload interno nesse modo. O painel humano usa login de uso único, cookie protegido e CSRF. APIs /admin/api/* validam ADMIN_API_KEY; essa chave vazia retorna 503 em vez de permitir acesso. A UI local de desenvolvimento deve permanecer desligada no deploy.
WhatsAppFreeOnly no SAM aceita somente true. O envio humano e a renotificação controlam a janela de 24 horas. Isso não substitui a confirmação operacional de destino, permissões Meta ou regras comerciais aplicáveis.
O template define TTL na tabela, mas não declara PointInTimeRecoverySpecification, DeletionPolicy, UpdateReplacePolicy ou recursos de log group com retenção explícita. Também não cria alarme de tamanho da DLQ nem tópico SNS. Não atribua essas garantias ao projeto sem verificar/configurar a infraestrutura do ambiente.
Rotina de monitoramento¶
- Conferir falhas de webhook/orchestrator e backlog SQS/DLQ.
- Acompanhar
Pending,Blocked,UncertaineOldestPendingSecondsemGoGenetic/CRMe a página/atendimento/crm. - Verificar fila humana e disponibilidade do dia; a falta de operador não produz, por si só, um erro Lambda.
- Revisar renotificações e encerramentos por abandono da execução horária.
- Conferir exportação semanal quando configurada e destino autorizado.
Os alarmes de Errors Lambda não capturam automaticamente todas as falhas tratadas no domínio ou retornos de falha parcial SQS. Combine métricas com backlog e eventos da aplicação. Veja observabilidade.
Smoke controlado¶
Siga o runbook de homologação, com destinatários/objetos exclusivamente de teste, janela combinada e um alvo por vez. Permissões SMOKE_ALLOW_* não devem permanecer habilitadas em um shell de uso geral. Guarde o resultado sanitizado, IDs criados e confirmação de entrega/convergência. Um smoke de leitura success não atesta upsert nem envio.
Incidente e contenção¶
Primeiro preserve IDs, horários e estado observado, limitando exposição de PII. Identifique se a falha está na entrada, fila, orquestração, provider ou operação humana. Se houve envio confirmado mas gravação falhou, não repita cegamente: uma tentativa adicional pode duplicar mensagem ou negócio.
HUBSPOT_ENABLED=false pausa o worker e impede novas intenções executáveis; pendências anteriores ficam preservadas. Uma alteração desse switch em produção é uma mudança de configuração, com efeito sobre a operação. Mudanças de configuração, pausa de event sources e redrive devem ser revisadas no contexto do incidente, não executadas como rotina de diagnóstico.
Para UNCERTAIN, confira se o negócio já existe antes de liberar nova criação. Para fila DLQ, resolva a causa e revise idempotência e efeitos já consumados antes de redrive. Não há comando de reparo universal, nem promessa de entrega “exatamente uma vez” a todos os providers.
Rollback e continuidade¶
Reimplantar uma revisão anterior pode restaurar código, mas não desfaz mensagens, transações externas, intenções persistidas nem secrets SSM. Preserve a configuração compatível com dados atuais e a documentação da versão. O procedimento de deploy descreve rollback CloudFormation e nova publicação de revisão aprovada.
Não exclua stack, tabela ou fila para “reiniciar” a operação. A restauração de dados depende do backup efetivamente provisionado no ambiente e deve ser validada pelo responsável. Incidentes com possível exposição de dados exigem encaminhamento ao responsável de segurança/privacidade, com evidências protegidas.