Operação e observabilidade

Movimentação financeira real permanece desativada. Acompanhe serviços e filas duráveis independentemente da interface pública.

Saúde dos serviços

/healthz verifica resposta da API e /readyz verifica PostgreSQL. O contêiner web verifica sua página /pt. Execute o worker separado de web e API; ele processa filas duráveis de webhooks, notificações da operadora e e-mail. Monitore falhas, leases vencidos e crescimento das filas pendentes. Um resultado SMTP uncertain exige revisão, sem reenvio cego.

Métricas e histórico

GET /v1/metrics exige metrics:read e retorna apenas os registros do negócio autenticado:

• receivedBrlCents: centavos BRL inteiros confirmados em pagamentos reais, sem usar o valor solicitado como recebido.
• settledUsdt: string decimal exata de liquidações reais confirmadas em USDT.
• settledCount: quantidade de liquidações reais confirmadas em USDT.
• sandboxPaymentCount: contagem separada de pagamentos sandbox.
• auditEventCount: quantidade de registros de auditoria do negócio.

Mantenha BRL e USDT separados. Não converta settledUsdt em ponto flutuante binário para cálculos financeiros e não trate esses acumulados como saldo custodiado.

O painel usa outro endpoint de visão geral, com ambiente e período selecionados por dias de calendário UTC. Um recebimento ou uma liquidação entra na data de confirmação, mesmo quando a cobrança foi criada antes. GET /v1/requests expõe método, rota, status, duração e correlação sanitizados, sem corpos, cabeçalhos secretos ou query strings. A auditoria registra ações relevantes de ator e recurso. Não há serviço público de status de infraestrutura ou integração externa de alertas incluídos.

Recuperação

• Falha de cotação: usar as fontes de contingência configuradas, sem servir preço vencido.
• Falha do worker: reiniciar; leases vencidos permitem retomada por outra instância.
• Notificação repetida: deduplicar antes de qualquer alteração do pagamento.
• Resultado desconhecido da operadora: reconciliar sem emitir outra cobrança.
• Credencial exposta: revogar ou substituir e revisar a atividade correspondente.
• Rollback da aplicação: usar o manifesto de imagens fixadas da release anterior; veja deploy.

Acompanhamento das releases

O workflow do GitHub Actions verifica a revisão antes de publicar a main pelo comando SSH restrito. Confira os jobs de validação e deploy, o REVISION do servidor, /opt/magnum/shared/deployed-commit, a saúde dos contêineres e a resposta HTTPS pública. Validação aprovada sozinha não comprova publicação; uma revisão antiga ignorada também não significa que ela foi publicada.

O servidor serializa deploys por /opt/magnum/shared/deploy.lock, usa acesso somente de leitura ao repositório, gera quatro imagens fixadas ao SHA e executa o backup antes de migrar. /opt/magnum/current só avança depois das verificações da aplicação e da origem pública. Falha de inicialização ou saúde pública restaura as imagens anteriores da aplicação, mantendo o banco na versão migrada. Revise o resultado e repita as verificações após qualquer rollback automático.

O rollback manual deve usar o compose.images.yaml da release anterior e reiniciar apenas api, worker e web com --no-build --no-deps. Não reenvie um SHA antigo ao comando restrito: ele aceita somente a origin/main atual. Preserve backups do banco e confira a compatibilidade das migrações antes de restaurar imagens antigas da aplicação. Veja em deploy o comando exato e os nomes dos secrets do GitHub.

Rotação e retenção

Trocar API_KEY_PEPPER invalida as chaves atuais. Substituir ENCRYPTION_KEY sem recriptografia torna os campos antigos ilegíveis. Planeje migração de segredos com versões e backup. Somente o operador gerencia a credencial global FOUR_P_API_KEY; trocá-la não concede autorização da operadora nem ativa pagamentos.

Estabeleça alertas externos, objetivos de recuperação, retenção de dados e restauração externa testada antes de operar financeiramente. Compose é uma base de implantação, não uma garantia de alta disponibilidade.