O sistema sempre fala: uma história sobre arquitetura de plataformas, observabilidade e dados

Lições de anos construindo plataformas de observabilidade: legado sem telemetria, contexto na ingestão, alertas em camadas, custo como decisão de arquitetura e o ciclo fechado com ITSM.

Ao longo da minha trajetória trabalhando com arquitetura de plataformas, observabilidade e dados, fui percebendo um padrão que se repetia em praticamente todos os projetos: o problema raramente era falta de tecnologia. Na maioria das vezes, o desafio estava em transformar dados em decisões sem construir algo caro, complexo ou impossível de manter.

Também fui percebendo outra coisa: diferentes times costumam olhar para o mesmo dado e chegar a conclusões diferentes. O desenvolvimento enxerga comportamento da aplicação. A operação procura estabilidade. O negócio quer entender impacto financeiro. A gestão quer saber se o produto está saudável.

O dado é o mesmo. A interpretação é que muda.

Foi nesse ponto que entendi que observabilidade nunca foi apenas sobre infraestrutura. Ela conecta tecnologia, negócio e pessoas.

O começo: achar que existe uma ferramenta para tudo

Como muita gente, durante bastante tempo eu também procurei a ferramenta ideal. A ideia parecia simples: concentrar dashboards, consultas, alertas e indicadores em uma única plataforma. E, durante um bom tempo, isso realmente funcionou.

Extraí praticamente tudo o que a stack podia entregar: consultas extremamente rápidas, dashboards para acompanhamento operacional, alertas, APIs, regras de negócio, visualizações executivas e indicadores técnicos.

Mas conforme os produtos evoluíam, as perguntas também evoluíam. Já não bastava saber se um serviço estava disponível. Era preciso entender se um fornecedor específico estava impactando pagamentos, se o volume daquele dia fazia sentido para uma quinta-feira, se um comportamento era realmente uma anomalia ou apenas um feriado nacional.

Foi aí que percebi que o desafio deixava de ser tecnológico e passava a ser arquitetural.

Quando o dado não está onde gostaríamos

Outro aprendizado veio dos ambientes legados.

Nem tudo produz logs. Nem tudo gera traces. Nem tudo pode ser instrumentado. Em alguns casos, a informação mais importante simplesmente existia apenas dentro de uma transação de banco de dados.

A decisão nunca foi tentar forçar a ferramenta. Foi construir uma arquitetura que permitisse transformar aquele dado operacional em informação útil, respeitando segurança, performance e as limitações do ambiente.

Telemetria não nasce apenas da instrumentação. Às vezes, ela nasce das decisões de arquitetura.

Nem todo erro se resolve com uma regra mais inteligente

Um dos erros que mais me ensinou aconteceu durante a construção dos alertas.

No início, algumas comparações eram feitas entre dias completamente diferentes: segunda-feira comparada com domingo, feriados comparados com dias úteis. O resultado era previsível — alertas falsos.

A primeira reação foi tentar deixar as regras mais inteligentes. Foi um erro. As regras ficaram maiores, mais difíceis de entender, mais difíceis de manter.

A solução acabou sendo muito mais simples: a inteligência precisava estar no dado. Durante a ingestão, cada documento passou a carregar contexto:

• Dia da semana
• Calendário de feriados
• Datas equivalentes

Com isso, tanto dashboards quanto alertas passaram a comparar períodos realmente compatíveis. O número de falsos positivos caiu e as regras ficaram muito menores.

Contexto adicionado na ingestão é complexidade removida de todas as regras futuras.

Detalhes que decidem se o dado mente ou fala a verdade

Nem toda lição veio de arquitetura. Algumas vieram de detalhes que parecem pequenos até o dia em que o número no dashboard não bate com a realidade.

Um exemplo clássico: contadores cumulativos. Quando um contador acumula valores ao longo do dia, somar os pontos coletados infla o resultado.

SUM inventa um número. MAX conta a verdade.

Parece óbvio depois que você entende. Mas até lá, o dashboard mostra um volume que não existe — e a confiança na plataforma é a primeira vítima.

Outro detalhe que virou disciplina: governança de campos. Nomenclatura padronizada e separação clara entre o que é dado técnico e o que é indicador de negócio. Parece burocracia até o dia em que alguém precisa criar uma regra às três da manhã e encontra tudo exatamente onde deveria estar.

Uma plataforma só escala quando outras pessoas conseguem evoluí-la sem precisar decifrar as decisões de quem a construiu.

Nem toda lógica precisa morar na mesma ferramenta

Em alguns momentos, fazia muito sentido utilizar os mecanismos nativos da própria plataforma para construir alertas. Eles funcionavam muito bem para thresholds, ausência de eventos e diversas validações operacionais.

Mas algumas necessidades começaram a exigir lógica de negócio:

• Comparações entre D-1, D-7 e D-14
• Tratamento de feriados
• Consultas em múltiplas fontes
• Geração de relatórios executivos
• Integrações externas

Era possível continuar colocando tudo dentro da mesma ferramenta? Em muitos casos, sim. Mas a pergunta deixou de ser "é possível?" e passou a ser "vale a pena?".

Quando a manutenção começa a depender de poucas pessoas do time, quando as regras ficam difíceis de evoluir e a curva de aprendizado cresce demais, talvez a melhor decisão seja separar responsabilidades.

Foi exatamente esse caminho que comecei a seguir. A plataforma continuou fazendo aquilo que faz muito bem: indexação, consultas, dashboards e visualizações. Já a lógica de negócio passou a viver em componentes serverless — consumindo os dados via API, aplicando regras específicas, tratando calendários, comparando janelas temporais e gerando relatórios automatizados.

Não porque uma abordagem era melhor que a outra. Mas porque cada uma fazia melhor aquilo para o qual foi construída.

Arquitetura também é uma decisão financeira

Com o tempo, outra variável começou a pesar tanto quanto performance: o custo.

Nem todo dado precisa estar na plataforma mais sofisticada. Nem toda funcionalidade precisa da solução mais cara disponível no mercado. Ferramentas excelentes existem — mas elas também têm custos excelentes: licenciamento, ingestão, retenção, processamento.

Em muitos projetos, a melhor arquitetura foi justamente combinar tecnologias diferentes, cada componente assumindo uma responsabilidade específica. Essa decisão reduziu custos, simplificou manutenção e tornou a evolução muito mais sustentável.

No final das contas, arquitetura também é gestão financeira. Cada decisão técnica precisa continuar fazendo sentido meses depois da implantação.

Quando a observabilidade começa a falar a língua do negócio

Talvez a maior mudança tenha acontecido quando os indicadores deixaram de atender apenas a operação.

Os dashboards passaram a responder perguntas do negócio. Os alertas passaram a chegar automaticamente no celular de gestores, PMs e responsáveis pelos produtos — sem abrir notebook, sem acessar dashboard. Recebendo, por exemplo:

"O volume de pagamentos está 12% abaixo do esperado para uma quinta-feira."

"A taxa de erros de um fornecedor aumentou acima do comportamento histórico."

Nesse momento, a observabilidade deixou de ser apenas uma ferramenta operacional. Ela passou a fazer parte da tomada de decisão.

Fechar o ciclo: quando o alerta vira processo

Mas ainda faltava uma peça.

Alerta que não vira ação é apenas ruído com timestamp.

O passo seguinte foi integrar a plataforma ao ecossistema de gestão de serviços. Eventos relevantes passaram a gerar registros rastreáveis no ITSM. Com isso, o que antes era percepção virou métrica:

• Quanto tempo levamos para responder
• Quantas mudanças causaram incidentes
• O que é recorrente e o que é exceção

Exatamente na linha do que o DORA propõe: medir a engenharia com os mesmos dados que ela produz.

A observabilidade deixou de terminar no alerta. Ela passou a alimentar o processo — e o processo passou a melhorar a plataforma.

O ciclo fechou.

O maior aprendizado

Depois de tantos projetos, ferramentas, acertos e alguns tropeços, ficou uma conclusão que continua fazendo sentido:

Arquitetura nunca foi sobre escolher a melhor tecnologia. É sobre tomar boas decisões considerando contexto, pessoas, manutenção, custo, curva de aprendizado e evolução.

A ferramenta muda. O problema muda. O negócio muda. Mas boas decisões continuam valendo.

E talvez essa seja a principal lição que a telemetria me ensinou: os sistemas sempre estiveram contando uma história. Nosso trabalho é construir a melhor forma de escutá-la e transformá-la em decisões que realmente gerem valor.

E o próximo capítulo dessa história já começou: em vez de abrir um dashboard, perguntar em linguagem natural — "como estão os pagamentos hoje?" — e receber a resposta direto dos dados.

Mas isso é assunto para o próximo texto. 👋