KPIs e dashboards que você deve exigir de um parceiro de observabilidade para automações

O conjunto de KPIs deve começar pelo comportamento do fluxo e depois aprofundar a infraestrutura. Uma forma prática é separar as métricas em quatro camadas: resultado, confiabilidade, desempenho e custo operacional.

Na camada de resultado, exija volume processado, percentual de fluxos concluídos, percentual de exceções, itens rejeitados por regra de negócio e tempo até a conclusão. Para uma integração entre APIs, inclua também respostas incompletas, reprocessamentos, duplicidades e divergências entre origem e destino.

Na camada de confiabilidade, acompanhe taxa de sucesso por etapa, erros por código HTTP, indisponibilidade de dependências, falhas de autenticação, expiração de credenciais e tamanho da fila. Um percentual geral de sucesso pode esconder uma API específica que falha em 30% das chamadas.

O desempenho deve incluir latência no p50, p95 e p99 quando houver volume suficiente, além do tempo total do fluxo. O p95 mostra quanto tempo levam as 5% execuções mais lentas e costuma revelar degradações que uma média suaviza.

Para a equipe de operação, inclua MTTA, tempo médio até reconhecer um incidente, e MTTR, tempo médio até restaurar o serviço. Também acompanhe intervenções manuais por período, horas gastas em correções e quantidade de reprocessamentos. Se a automação exige ação humana toda semana, a taxa de sucesso isolada não representa saúde operacional.

O mapeamento deve chegar ao nível SLI, SLO e SLA. Por exemplo: o SLI pode ser o percentual de pedidos concluídos sem intervenção em até cinco minutos; o SLO pode ser 99% em uma janela mensal; e o SLA pode definir a comunicação e a responsabilidade quando o compromisso não for cumprido. O guia sobre SLIs, SLOs e SLAs práticos para PMEs detalha como transformar essa estrutura em acordos acionáveis.

Peça ainda a fórmula, a fonte dos dados, a periodicidade de cálculo e o responsável por agir quando o indicador sair da faixa. KPI sem definição matemática é uma opinião visual, não um instrumento de gestão.

Um dashboard útil começa com uma pergunta operacional. Em vez de pedir um painel genérico de infraestrutura, solicite visualizações como: quais fluxos estão atrasados agora, qual integração concentra erros, qual automação consumiu mais recursos e quantas intervenções ocorreram nos últimos sete dias?

Para o Metabase, peça um modelo semântico que relacione execução, fluxo, etapa, resultado e incidente. Filtros por período, automação, ambiente, cliente e severidade devem funcionar sem exigir alteração manual da consulta. A página inicial pode exibir volume processado, conclusão dentro do SLO, exceções abertas e tendência de intervenções.

Para o CloudWatch, o fornecedor deve informar namespace, nome da métrica, dimensões, estatística e período. Uma soma de erros pode ser adequada para contagem, enquanto a média de latência pode ocultar picos. A documentação oficial sobre métricas e séries temporais do CloudWatch ajuda a conferir se a proposta está usando corretamente dimensões e períodos.

Para o Prometheus, solicite as expressões PromQL, as regras de alerta e a definição das etiquetas. Uma consulta de taxa de erro deve considerar o intervalo e o volume de requisições, evitando disparar por uma única ocorrência em um fluxo de baixo volume. A referência oficial sobre consultas básicas do Prometheus é útil para revisar filtros, intervalos e operadores apresentados pelo parceiro.

Um exemplo de consulta conceitual para taxa de erro seria dividir a quantidade de falhas pela quantidade total de execuções na mesma janela. O fornecedor precisa adaptar a expressão ao modelo de dados da sua operação, controlar ausência de séries e explicar como evitar que nomes de fluxo ou clientes gerem cardinalidade excessiva.

Peça também o caminho inverso: partindo de um ponto vermelho no dashboard, a equipe deve conseguir identificar a execução, consultar o log relacionado, localizar a etapa que falhou e verificar se houve reprocessamento. Se o painel mostra apenas um gráfico sem contexto, a investigação continuará dependente de conhecimento informal.

Para integrações entre APIs, inclua uma visão de dependência. Ela deve mostrar chamadas por endpoint, códigos de resposta, tempo de resposta, volume de tentativas e estado do circuito de recuperação, quando aplicável. O mapa de dependências entre APIs oferece uma base para validar se o escopo contempla os pontos que podem interromper a cadeia.

Uma prova de conceito curta é suficiente para verificar se os KPIs propostos medem valor operacional. A Trait aplica uma abordagem de 14 dias em projetos compatíveis, começando por um único fluxo crítico, uma integração relevante e um conjunto limitado de indicadores que possam ser comparados antes e depois.

Nos dois primeiros dias, o time registra o processo atual: volume, tempo de execução, exceções, intervenções e dependências. Também define o evento de sucesso. Em um fluxo de sincronização de clientes, por exemplo, sucesso não é apenas executar o nó final, mas atualizar o destino sem duplicar registros e dentro do prazo acordado.

Entre o terceiro e o quinto dia, o parceiro instrumenta os pontos necessários e entrega uma primeira versão dos painéis. A equipe contratante deve participar da revisão, pois conhece exceções de negócio que não aparecem na infraestrutura, como pedidos que precisam de aprovação ou respostas válidas que exigem tratamento especial.

Na segunda semana, provoque cenários controlados: indisponibilidade de uma API, aumento de latência, credencial inválida, mensagem malformada e crescimento de fila. O monitoramento deve detectar o problema, identificar a automação afetada e orientar uma ação sem criar uma tempestade de alertas.

No encerramento, compare os resultados com a linha de base. Um mini caso fictício baseado em operações de SaaS ilustra o tipo de ganho esperado: depois de separar falhas de negócio de falhas técnicas, criar um indicador de fila antiga e ajustar os limiares, a equipe reduziu intervenções manuais recorrentes e encurtou o MTTR de horas para menos de uma hora.

Esse resultado não vem de um gráfico adicional. Ele surge quando o indicador leva a uma decisão, a decisão está documentada e a recuperação pode ser executada por mais de uma pessoa. O runbook de observabilidade para automações ajuda a estruturar essa ligação entre sinal, diagnóstico e resposta.

O relatório final da prova deve registrar indicadores antes e depois, alertas disparados, falhas não detectadas, consultas entregues, limitações e próximos passos. Se o parceiro não consegue demonstrar o que foi aprendido em 14 dias, dificilmente uma implantação maior resolverá a falta de clareza.