Dashboard de operações

(Seção Operações e Gerenciamento)

1) Atribuição e princípios

O dashboard operacional é uma janela única para monitorar a saúde da plataforma e tomar medidas. Ele agrega métricas, eventos, alertas e indicadores de negócios no contexto do papel do usuário (SRE, Product, Finanças, Compliance, Apoio, Associados).

• Actionable by design: cada widget tem um botão de ação (rollback, paul, re-run, re-road).
• Role-aware: Os direitos e níveis de detalhe dependem do papel/tenante/região.
• Fonte-of-truth: os números coincidem com o bilhete/revistas/recibos.
• Near-real-time + histórico: segundos/minutos para incidentes, meses/anos para tendências.
• Explainability: Qualquer unidade se desenvolve para um evento crude com 'trace _ id'.

2) Papéis e cenários (quem e por que vem)

SRE/Plataforma: disponibilidade, latência p50/p95/p99, erro/retrai, capacity, per 1k eventos.
Produto/Operações: E2E-Sucess Rate, conversão, tempo de negociação de parceiros, ficheflags.
Finanças/FinOps: receita/COGS/CM por unidade, egress/insress, orçamentos e caps, desvios.
Complaens/Segurança: recibos/assinaturas, solicitações PII, violações SoD, status de ressocialização.
Apoio/CS: fila de tíquetes, MTTA/MTTR, SLA para parceiros e regiões.
Associados/Tenentes: métricas SLO próprias, estatais de webhooks, usage e quotas.

3) North Star e SLI/SLO chave

North Star: E2E Sucess Rate através de rotas críticas, com p95 em cada região.

• Disponibilidade per-canal/região.
• Latência p50/p95/p99.
• Error-rate e parte de retrações.
• Entrega de webhooks bem sucedida (% com recibos).
• Custo de 1k eventos e egress/ingress por unidade.
• Resumo de incidentes: MTTA, MTTR, erro-budet burn.

• Disponibilidade ≥ 99. 95 %/região/canal.
• p95 ≤ 120 ms (vitrine), ≤ 250 ms (checkout/cote).
• O sucesso dos webhooks ≥ 99. 5% por 5-min. janela.
• Entre quote e checkout = 0 (£1 menor unit de acordo com as regras de distribuição).
• Tempo de resposta para P1 ≤ 10 min, MTTR ≤ 60 min

4) Arquitetura de dados dashbord

Pneu de evento: telemetria (traces/metrics/logs), negócios, billing, complacência.
Estirpe/agregação: janelas T + 5s/T + 1m para near-real-time; CDC/outbox para entrega garantida.
Armazéns: time-series, OLAP (longa história), revistas WORM (auditoria).
Camada semântica: dicionário de métricas, unidades, normalização por região e tenentes.
Link de matéria-prima: drill-down a 'trace _ id '/' event _ id' e assinaturas (receipt _ hash).

5) Design de interface e widgets

Chapéu global: filtros (tempo, região, tenante, produto, ambiente), indicadores de estado.
Azulejos (KPIs): E2E Sucess, disponibilidade, p95, erro-rate, vale/1k, egress.
Gráficos: tendências sparkline, heat-map por região, gráficos de percurso.
Tabelas: melhores erros, parceiros com degradação, excesso de quotas, incidentes não revelados.
Secções de ação: «Pausa promoção», «Retrocesso de fichas», «Aumento de quota», «Reiniciar entrega».
Context-help: dicas de métricas/técnicas e comunicação com SLO.

6) Módulos de dashbord (conjunto recomendado)

1. Plataforma de saúde: disponibilidade/latência/erros, orçamento burn-down.
2. Integração de parcerias: status de webhooks, recibos, duplicações idumpotentes, filas.
3. Checkout & Preços: Alinhamento vitrina↔checkout, 'fx _ versão', 'tax _ rule _ versão', falha de mala.
4. Conteúdo/Diretórios: hora de publicação, erro de cachê/deficiente, freshness.
5. RTP & Limits (se aplicável): teor. vs observed RTP, executar limites, exposição.
6. FinOps: COGS/unidade, egress/ingress, compute/armazenamento, orçamentos/caps-alerts.
7. Segurança/Compliance: SoD, JIT, MFA, transações assinadas, consultas PII e revistas.
8. Apoio: filas, MTTA/MTTR, razões, carros runbooks.
9. Release/Substância Flags: estados de lançamento, regiões canárias, regravação automática com incidentes.
10. Experiments: A/B guardrails, influência do fique no SLI/ROY.

7) Alertas, runas e escalada

Alertas de nível P1-P3 com capacidade de ruído e dedução por 'trace _ id'.
Runbooks automáticos: Quando ativado, execute as verificações/fixações (limpeza do cachê, alteração do routing, pausa da promoção).
Escaladas: matriz 24 x 7, SLO resposta, canais (chat/voice/SMS), botão vermelho.
Post-invident: modelos de relatórios com relações de causa e ação items.

8) Multiregionalidade e multi-tenant

Cortes: região/tenante/canal/provedor, SLO e orçamentos independentes.
Zonas de confiança: dados PII/finanças - visíveis apenas nas áreas apropriadas, e outras unidades.
Costa-aware: comparação de rotas de preço com o mesmo p95; recomendação de otimização.

9) Segurança e privacidade

RBAC/ABAC: visibilidade e ações de papel; para a propriedade do produto/tenante.
Assinaturas e recibos: para eventos financeiros/críticos - hasts e recibos DSSE.
Higiene PII: toquenização, camuflagem, acesso somente através de jobs aprovados.
Auditoria: registros WORM para alterações de configurs/papéis/limites, reprodução.

10) Modelo de dados de métricas (exemplo)

`metric` `{name, unit, type: counter/gauge/hist, owner, sla_ref}`

`dim` `{region, tenant, product, provider, version, environment}`

`point` `{metric, value, ts, dims{}, trace_id, signature?}`

`event` `{type, severity, subject_id, payload_hash, receipt_hash, ts}`

`slo` `{name, target, window, burn_rate, owners[], runbook_url}`

`alert` `{slo_ref, condition, status, ack_by, acknowledged_at, runbook_step}`

11) API/webhooks dashbord

'POST/ingest/metrics' - recepção de métricas (esquema, limites, autenticação).
'POST/ingest/events' é um evento de negócios (versões/assinaturas).
`GET /kpis? filters... 'são máquinas para widgets.
O'GET/pistas/SE _ D.D.P. 'é uma promoção profunda.
Вебхуки: `IncidentRaised`, `QuotaCapReached`, `PriceMismatch`, `WebhookDeliveryLag`, `SecuritySoDViolation`.

12) Qualidade dos dados e testes

Data contracts: esquemas e validação na recepção, versionização ('expand → migrate → contract').
Anomalias: monitoramento de omissões/corridas, liminares flatline/noise.
Sampling: Para alta-QPS, a métrica é deslizante, mantendo a representatividade.
Backfill: downloads seguros com uma versão marcada.

13) Métricas do próprio dashbord (métricas de métricas)

Disponibilidade UI/API ≥ 99. 9%.
Latency p95 consultas API ≤ 300 ms.
Completeness: a proporção de fontes que enviaram os dados para a janela ≥ 99. 5%.
Freshness: Lote de atualizações incorporativas ≤ 30 s.
Cortness: discrepância com relatórios de referência ≤ 0. 1%.

14) Economia e FinOps em dashbord

Costa por 1k eventos com decomposição por provedor/região.
Egress/Origins cartões térmicos, recomendações de cachê/routing.
Orçamento/caps-alert: 80/90/100%, auto-roteamento e priorização.

15) Disponibilidade e UX

Tema noturno, assinaturas curtas, ícones de estatais.
Navegação por teclado e a11y: contraste, alt, ária-marca.
Os presídios guardados são «serviço SRE», «finanças», «parceiro».
Snapshots e shering: verifique o estado com filtros e referência/exportação.

16) Riscos e anti-pattern

Dash-sprawl: 20 dashboards diferentes sem um único dicionário de métricas.
Métricas Vanity: gráficos bonitos sem conexão com SLO/ação.
Números não acessíveis: relatórios ≠ billing/auditoria.
Alertas ruidosas, cansaço e omissões P1.
Falta de drill-down - Não é possível chegar aos primórdios e causas.

17) Folha de cheque de implementação

• Definir papéis e cenários; alinhar North Star e SLI/SLO.
• Criar um dicionário de métricas e unidades; formalizar data contracts.
• Configurar ingest (metrics/events/pistas), OLAP e auditoria WORM.
• Implementar plug-ins (saúde, parceiros, checkout, FinOps, Security).
• Incluir alertas com rumas e escaladas; «botão vermelho».
• Adicionar ações: rollback/pause/re-road/raise-limit.
• Construir heat-map por região/tenante; filtros e presídios.
• Verifique o recuo dos números com o bilhete/recibos.
• Jogo-dia (GameDay): desligamento do provedor, avalanche de retrações, descolonização de preços.
• Revo semanal SLO e pós-mortem-qualidade.

18) RACI

19) FAQ

Todos os relatórios podem ser substituídos por um dashboard?
Não. Dashboard - para operações e acções; relatórios e auditorias formais são artefatos individuais.

Quanto tempo é que precisas?
Para incidentes - segundos/minutos, para economia - minutos/relógio; o que importa é a coerência, não o «online» absoluto.

Como combater o barulho de alertas?
Condições orientadas SLO, agregação, dedução por 'trace _ id', priorização e runbooks automáticos.

Como verificar se as métricas estão corretas?
Verificações regulares com relatórios de referência, fidas de teste, amostras de controle e registros WORM.

Resumo: O dashboard operacional não é uma «bela prancha», mas uma ferramenta de controle: SLI/SLO unificado, ações da interface, rastreamento até a matéria-prima e coerência rigorosa com o billet e o áudio. Construa-o na arquitetura de eventos, dê um contexto de papéis, adicione runas e escalações - e você terá operações previsíveis, soluções rápidas e crescimento sustentável.