# 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`)

1. `git pull --ff-only` (se for um clone git).
2. `pnpm install --frozen-lockfile`.
3. `prisma migrate deploy` contra o Postgres (via `127.0.0.1:5432`, fora dos
   containers).
4. `docker compose build` — rebuilda só as imagens cujo contexto mudou
   (cache do Docker layer a layer).
5. `docker compose up -d` — recria containers com imagem nova.
6. `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:

1. Aumentar para pelo menos 4 vCPU / 8 GiB RAM.
2. Revisar `mem_limit` de cada serviço em `docker-compose.yml` (hoje
   conservador para caber em 1.9 GiB).
3. 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).
4. 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:

1. 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).
2. 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.
3. Publicar a porta 443 em `docker-compose.yml` (serviço `nginx`).
4. Atualizar `infrastructure/nftables/` se necessário (443 já não é
   bloqueado por padrão, só os serviços administrativos do Asterisk são).