127 lines
6.2 KiB
Markdown
127 lines
6.2 KiB
Markdown
# FASE 9 — Hardening e produção
|
||
|
||
## Objetivo
|
||
|
||
Provar que o sistema aguenta o mundo real: testes ponta a ponta, carga no SFU, injeção de falhas, revisão de segurança e deploy documentado.
|
||
|
||
## Pré-requisitos
|
||
|
||
FASES 0–8 concluídas. Ler `docs/06-LGPD-E-SEGURANCA.md` §5 e `docs/07-REQUISITOS-DE-CAMPO.md`.
|
||
|
||
## Tarefas
|
||
|
||
### 1. Testes ponta a ponta
|
||
|
||
Playwright para os webs, Maestro para os apps. Cenários obrigatórios:
|
||
|
||
1. Visita completa: QR → aviso → permissões → foto → unidade → morador atende → autoriza → PIN
|
||
2. Entrega em um toque, resolvida pela notificação, em menos de 10s
|
||
3. Escalonamento completo: ninguém atende → outros moradores → fila → operador → autorizado
|
||
4. Recado: ninguém atende, sem módulo de operador → grava → morador resolve depois
|
||
5. Unidade inexistente: visita criada, ninguém notificado, e a **sequência de estados vista pelo visitante é idêntica** à de uma visita real não atendida (visita-sombra) — incluindo os tempos das transições
|
||
6. Fora do geofence: bloqueado com mensagem acionável
|
||
7. Quiet hours: desvia sem tocar em ninguém
|
||
8. Dois moradores respondendo juntos: um vence, o outro vê quem resolveu
|
||
9. LiveKit fora: degrada para áudio, depois foto+texto
|
||
10. Backend reiniciado no meio de uma visita: escalonamento acontece mesmo assim
|
||
|
||
O cenário 10 é o que valida o padrão de timeouts persistidos. O 5 valida a busca cega.
|
||
|
||
### 2. Teste de carga
|
||
|
||
**SFU:** 50 chamadas simultâneas de 2 participantes, medindo banda, CPU e tempo até o primeiro frame. Confronte com o dimensionamento de `05-INFRA-DOCKER.md` §4.
|
||
|
||
**API:** 100 visitas/minuto sustentadas — muito acima do real (~0,3 req/s), de propósito.
|
||
|
||
**Fila:** 10 mil jobs agendados para o mesmo instante, verificando que nenhum é perdido ou executado duas vezes.
|
||
|
||
**Banco:** tabela de auditoria com 1 milhão de visitas; a tela do admin precisa continuar fluida.
|
||
|
||
### 3. Injeção de falhas
|
||
|
||
Derrube cada peça, uma por vez, com uma visita em andamento, e verifique o comportamento:
|
||
|
||
| Peça derrubada | Comportamento esperado |
|
||
|---|---|
|
||
| LiveKit | Degrada para áudio → foto+texto → operador |
|
||
| Redis | WebSocket degrada para polling; fila continua (está no Postgres) |
|
||
| MinIO | Visita prossegue sem foto, com aviso; upload entra em retry |
|
||
| FCM | WebSocket assume se o app está aberto; falha vai para o dashboard |
|
||
| Uma réplica do backend | Outra assume; jobs pendentes executam |
|
||
| Postgres (breve) | Erro claro ao visitante e contingência física acionada |
|
||
|
||
**Teste do relógio:** atrase o relógio de uma réplica em 30s e confirme que ShedLock não permite execução dupla.
|
||
|
||
### 4. Revisão de segurança
|
||
|
||
Percorra o modelo de ameaças de `06-LGPD-E-SEGURANCA.md` §5 e prove cada mitigação:
|
||
|
||
- [ ] **A.1 Busca cega** — tempo de resposta constante medido estatisticamente, não no olho, **e** linha do tempo de estados idêntica entre unidade real não atendida e visita-sombra. Este é o teste mais importante da fase
|
||
- [ ] **A.2 Geofence** — rejeita fora do raio; GPS falsificado é registrado
|
||
- [ ] **A.3 DoS social** — rate limit e quiet hours funcionam; varredura gera alerta
|
||
- [ ] **A.4 Mídia** — nenhuma URL pública; assinada expira; acesso auditado
|
||
- [ ] **A.5 Auditoria** — `UPDATE`/`DELETE` em `audit_log` falham no banco
|
||
- [ ] **A.6 Tokens** — JWT de visitante não serve para outra visita nem outra portaria
|
||
- [ ] **A.7 QR** — incrementar `qr_version` invalida os códigos antigos
|
||
|
||
Rode também: `pnpm audit`, `gradle dependencyCheck`, varredura de imagem Docker (Trivy), e headers verificados por observatório de segurança.
|
||
|
||
**Grep obrigatório:** nenhuma biblioteca de detecção ou reconhecimento facial em `build.gradle.kts` ou `package.json`. A tentação aparece disfarçada de UX ("só para enquadrar o rosto") e tem consequência jurídica direta.
|
||
|
||
### 5. Checklist de produção
|
||
|
||
**Infraestrutura**
|
||
- [ ] Faixa UDP 50000–60000 aberta (esquecer isso conecta a chamada e nunca mostra vídeo)
|
||
- [ ] TLS válido e renovação automática testada
|
||
- [ ] Backup automático com **restore testado e cronometrado**
|
||
- [ ] Segredos fora do repositório e fora das imagens
|
||
- [ ] Healthchecks respondendo em todos os serviços
|
||
- [ ] Alertas chegando em canal monitorado de verdade
|
||
|
||
**Aplicação**
|
||
- [ ] Perfil `prod`, sem stack trace exposto
|
||
- [ ] Rate limits ativos
|
||
- [ ] CORS restrito aos domínios reais
|
||
- [ ] Logs sem dado pessoal (nome, foto, coordenada) — **verificar linha a linha**
|
||
- [ ] Migrations aplicadas em ordem em banco limpo
|
||
|
||
**Apps**
|
||
- [ ] Builds de release assinados
|
||
- [ ] Testados em dispositivo físico, Android e iOS
|
||
- [ ] Ficha de privacidade da App Store e do Google Play preenchida
|
||
- [ ] Justificativa de VoIP documentada para a App Review
|
||
- [ ] Crash reporting **sem PII**
|
||
|
||
**Conformidade** — checklist completo de `06-LGPD-E-SEGURANCA.md` §9.
|
||
|
||
**Campo** — checklist de ativação de `07-REQUISITOS-DE-CAMPO.md` §2 para o condomínio piloto.
|
||
|
||
### 6. Deploy
|
||
|
||
`docs/anexos/deploy.md` com provisionamento, primeiro deploy, atualização sem downtime (rolling com healthcheck), rollback, aplicação de migration com dado em produção, e o procedimento de crescer para HA.
|
||
|
||
### 7. Piloto assistido
|
||
|
||
Antes da ativação definitiva, **duas semanas com o módulo de operador ligado**, monitoramento diário e reunião semanal com o síndico.
|
||
|
||
O que se mede: taxa real de atendimento, tempo médio de resolução, abandono de entregador, incidentes, e feedback qualitativo de moradores e entregadores.
|
||
|
||
**É esse número — não a expectativa comercial — que define se o condomínio fica no plano Autônomo ou no Assistido.**
|
||
|
||
## Critérios de aceite
|
||
|
||
- [ ] Os 10 cenários E2E passam em CI
|
||
- [ ] Carga do SFU dentro do dimensionamento previsto
|
||
- [ ] Toda injeção de falha se comporta como na tabela
|
||
- [ ] Todas as mitigações do modelo de ameaças verificadas
|
||
- [ ] Busca cega com tempo constante comprovado estatisticamente
|
||
- [ ] Checklist de produção 100% marcado
|
||
- [ ] Restore de backup executado e cronometrado
|
||
- [ ] Runbooks testados por alguém que não os escreveu
|
||
- [ ] Piloto de duas semanas concluído com métricas coletadas
|
||
|
||
## Não faça nesta fase
|
||
|
||
- Novas funcionalidades — se aparecer necessidade, vira v2
|
||
- Otimização sem métrica que a justifique
|