Fase 04 — Operação de Produto

Deploy strategy, SLOs, DORA metrics, experimentos A/B e monitoramento.

Estratégia de Deploy

Ambiente v1

Desenvolvimento Local

O ECP Pay v1 opera como serviço local no ecossistema de desenvolvimento. O deploy é feito via npm run dev com hot reload via tsx.

API Server: Fastify na porta 3335
Admin Panel: Vite dev server na porta 5176
Banco de dados: SQLite — database-pay.sqlite (auto-criado)
Provider padrão: Internal (modo simulação)

Inicialização

# Na raiz do projeto
npm install
npm run dev

# Ou separadamente
cd server && npm run dev  # API :3335
cd web && npm run dev     # Admin :5176

Seed de Dados

O banco é populado automaticamente no startup com:

3 apps registrados (ecp-bank, ecp-emps, ecp-food)
1 admin user (admin@ecpay.dev / Admin@123)
Feature flags padrão (PAYMENT_PROVIDER=internal)
Transações de exemplo para cada tipo

Service Level Objectives (SLOs)

API Availability

99.9%

Uptime medido via GET /pay/health. O endpoint retorna status do servidor e provider ativo.

Webhook 1st Attempt Delivery

> 99%

Taxa de callbacks entregues na primeira tentativa. Medido via callback_status = delivered no primeiro attempt.

API Latency (p95)

< 300ms

Latência no percentil 95 dos endpoints de pagamento, excluindo latência do gateway externo.

DORA Metrics

Deployment Frequency

On-demand

Deploy local sob demanda. Cada mudança é refletida instantaneamente via hot reload (tsx watch mode).

Lead Time for Changes

Minutos

Hot reload via tsx. Mudanças no código são refletidas em segundos no servidor de desenvolvimento.

Change Failure Rate

Rastreado via audit_logs

Todas as mudanças de configuração e provider switch são registradas no audit log para rastreabilidade.

Mean Time to Restore

Segundos

Restart do servidor resolve a maioria dos problemas. SQLite single-file não requer recovery de banco externo.

Experimentos A/B Planejados

EXP-001 planejado

Internal Mode Auto-Approve Delay

Hipótese: Reduzir o delay de auto-approve do Pix de 5s para 1s melhora a velocidade de testes dos desenvolvedores.

Métrica: Tempo para completar um ciclo de teste de pagamento.

Variantes: 5s delay (controle) vs. 1s delay (variante)

KR vinculado: KR-04

EXP-002 planejado

Transaction Timeline Granularity

Hipótese: Adicionar elapsed time entre steps na timeline reduz o tempo de investigação para operadores.

Métrica: Tempo entre abrir detalhe da transação e identificar root cause.

Variantes: Timestamps only (controle) vs. Timestamps + elapsed (variante)

KR vinculado: KR-05

EXP-003 planejado

Provider Switch Confirmation Flow

Hipótese: Adicionar preview de impacto (contagem de tx pendentes) reduz provider switches acidentais.

Métrica: Switch-backs acidentais dentro de 5 minutos.

Variantes: Confirmação simples (controle) vs. Impact preview (variante)

KR vinculado: KR-03

Endpoints de Monitoramento

GET/pay/health — Health check: status do servidor, provider ativo, uptime

GET/admin/dashboard — KPIs: volume, transações, success rate, tokens, webhooks pendentes

GET/admin/audit-logs — Log de auditoria: todas as ações admin com filtros

GET/admin/providers — Status do provider ativo e configuração

GET/admin/feature-flags — Feature flags atuais e seus valores

operations-output.json