Files

B2BCall Bootstrap 80e72881b2 feat: Fase 9/10 — métricas, scripts operacionais, callback/wrap-up e aceite final

Fase 9 (segurança e produção):
- GET /api/metrics: endpoint Prometheus com métricas reais (chamadas,
  agentes, filas, CPS por campanha), protegido por permissão
- scripts/backup.sh, restore.sh, healthcheck.sh, install.sh, update.sh —
  testados contra o ambiente real (backup.sh e healthcheck.sh rodados de
  verdade; install.sh/update.sh validados por inspeção, ambiente atual já
  provisionado)
- POST /api/agent-console/dispose: aplica disposição de chamada de verdade
  (lacuna deixada aberta desde a Fase 6), com ações CALLBACK (agenda
  retorno) e DO_NOT_CALL (suprime automaticamente)
- apps/dialer-worker/src/callback-sweep.ts: reativa leads com callback
  vencido; GET /api/callbacks para consulta
- apps/dialer-worker/src/wrap-up-sweep.ts: transição automática
  WRAP_UP -> AVAILABLE + despausa real na fila do Asterisk. Exigiu corrigir
  main.ts para conectar ao AMI mesmo em DIALER_SIMULATION=true
  (DIALER_SIMULATION deve impedir só originação de chamada, não ações
  administrativas de fila)
- nftables revisado (sem alterações necessárias)
- Documentação completa: INSTALL, OPERATIONS, BACKUP_RESTORE, SECURITY,
  DATABASE, API, ASTERISK, OPENSIPS (não implementado, motivo
  documentado), TROUBLESHOOTING
- README.md e CHANGELOG.md reescritos

Fase 10 (testes e aceite):
- Quality gate completo executado: build/typecheck (7 workspaces), lint,
  46 testes unitários, docker compose config/ps, healthcheck — tudo verde
- Aceite de segurança (seção 92): 13 itens verificados ao vivo contra o
  sistema real, não só por inspeção de código
- Aceite Asterisk (seção 93): os 5 comandos executados e documentados,
  comunicação API->AMI->Asterisk validada
- docs/RELATORIO_FINAL.md: relatório final no formato da seção 96

Todos os fixtures de teste desta fase foram removidos/desativados ao
final. Credenciais de acesso entregues separadamente em CREDENCIAIS.txt
(fora do git, nunca versionado).

2026-08-27 19:16:14 -03:00

3.7 KiB

Raw Blame History

B2BCall — Operação

Comandos do dia a dia

Tarefa	Comando
Ver status de tudo	`bash scripts/healthcheck.sh`
Ver logs de um serviço	`docker compose logs -f api` (troque `api` pelo serviço)
Reiniciar um serviço	`docker compose restart api`
Aplicar atualização de código	`sudo ./scripts/update.sh`
Backup manual	`sudo ./scripts/backup.sh`
Restaurar backup	`sudo ./scripts/restore.sh backups/postgres-<ts>.dump`
Console do Asterisk	`docker exec -it b2bcall-asterisk asterisk -rvvv`
Ver regras de firewall ativas	`nft list table inet b2bcall_fw`

Atualização (`scripts/update.sh`)

git pull --ff-only (se for um clone git).
pnpm install --frozen-lockfile.
prisma migrate deploy contra o Postgres (via 127.0.0.1:5432, fora dos containers).
docker compose build — rebuilda só as imagens cujo contexto mudou (cache do Docker layer a layer).
docker compose up -d — recria containers com imagem nova.
scripts/healthcheck.sh.

Não há downtime zero: durante o rebuild/restart de api/frontend/nginx há uma janela curta de indisponibilidade (segundos). O Asterisk e as chamadas em andamento não são afetados a menos que a migration exija mudança incompatível em tabelas usadas pelo Realtime (raro — revisar a migration antes de rodar em produção com campanhas ativas).

Rotina recomendada de produção

Backup diário via cron (docs/BACKUP_RESTORE.md).
Monitoramento: apontar Prometheus para http://api:3000/api/metrics de dentro da rede Docker (b2bcall-net) — o endpoint exige uma sessão autenticada (permissão monitoring.view) e não é exposto via Nginx, então um scraper externo precisaria de uma integração dedicada (fora do escopo atual; hoje o uso pretendido é observabilidade interna/manual).
Alertas mínimos recomendados: b2bcall_calls_abandoned_total / b2bcall_calls_total acima do limiar de compliance (ver GET /api/compliance/indicators, que já calcula isso), containers não saudáveis (docker compose ps), espaço em disco (dumps + logs do Asterisk).
Rotação de logs do Asterisk: /var/log/asterisk dentro do volume asterisk-log cresce indefinidamente sem logrotate configurado — não incluído nesta fase (ver TODO.md, limitação conhecida).

Escalando além do laboratório atual

O ambiente original (1.9 GiB RAM / 2 vCPU) é suficiente para desenvolvimento e para o modo DIALER_SIMULATION=true, não para volume real de discagem (docs/ARCHITECTURE.md §1). Para produção real:

Aumentar para pelo menos 4 vCPU / 8 GiB RAM.
Revisar mem_limit de cada serviço em docker-compose.yml (hoje conservador para caber em 1.9 GiB).
Considerar mover Postgres/Redis para fora do mesmo host do Asterisk se o volume de CDR/CEL crescer muito (arquitetura já separa os dois logicamente — schema asterisk dedicado — o que facilita migrar depois).
Colocar OpenSIPS na frente do Asterisk para múltiplos troncos/roteamento avançado (não implementado nesta fase — ver docs/OPENSIPS.md).

HTTPS

Não configurado nesta fase (a rede é privada, sem IP público — seção 5). Para expor com TLS:

Obter certificado (Let's Encrypt via DNS challenge, já que não há IP público para HTTP-01, ou certificado interno/self-signed para uso só na LAN).
Editar infrastructure/nginx/nginx.conf: adicionar bloco listen 443 ssl; com ssl_certificate/ssl_certificate_key, e um bloco listen 80 que só redireciona para 443.
Publicar a porta 443 em docker-compose.yml (serviço nginx).
Atualizar infrastructure/nftables/ se necessário (443 já não é bloqueado por padrão, só os serviços administrativos do Asterisk são).

3.7 KiB Raw Blame History