Componentes da AIOps: as camadas que sustentam a automação de TI

AIOps é uma arquitetura em camadas, não um produto único. A observabilidade full-stack é a base permanente, e sobre ela se apoiam quatro camadas: ingestão de telemetria, armazenamento consultável, correlação com inteligência artificial causal e ação integrada à operação. Cada camada consome o que a anterior entrega e não compensa o que recebeu com defeito.

Uma falha na base raramente se manifesta na base. Ela aparece como diagnóstico impreciso no topo, semanas depois, quando a equipe de operações já está sob pressão de um incidente em sistemas críticos e precisa confiar no que a tela mostra.

AIOps é uma arquitetura em camadas, e não um produto único que se instala. A observabilidade full-stack sustenta a base, e sobre ela se organizam quatro camadas: ingestão de telemetria, armazenamento e consulta, correlação com inteligência artificial causal e, no topo, ação integrada à operação. Cada uma responde por uma função distinta e consome o que a camada abaixo dela entrega.

A Rike IS conduz consultoria, implantação, treinamento e governança contínua em observabilidade sobre a plataforma Dynatrace, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte.

A base: observabilidade full-stack

Observabilidade full-stack é a camada zero da arquitetura, e a expressão descreve uma dependência permanente, não uma etapa preliminar que se conclui. Ela dá visibilidade sobre aplicações, infraestrutura, cloud e experiência digital do usuário em ambientes distribuídos, e sem esse alcance a análise de causa raiz opera sobre um recorte parcial do ambiente e acerta por coincidência.

Duas disciplinas cobrem as pontas desse alcance. Application Performance Monitoring, ou APM, observa a aplicação por dentro: transações, chamadas entre serviços, consultas a banco e o código que responde por cada uma. Digital Experience Monitoring, ou DEM, observa a mesma transação do lado de fora, no navegador ou no aplicativo, onde o usuário percebe lentidão que o servidor não registra.

Nenhuma das duas sustenta a base sozinha. APM sem DEM descreve um sistema saudável por dentro enquanto o correntista desiste da tela de pagamento. DEM sem APM registra a lentidão sem apontar o componente responsável por ela.

A base entrega quatro tipos de sinal, e cada um responde a uma pergunta diferente sobre o mesmo sistema. Métricas são o painel do carro: números em série temporal que mostram velocidade, temperatura e nível, sem explicar por que o ponteiro subiu. Logs são o diário de bordo, com o registro textual do que cada componente fez e em que ordem. Traces são o GPS de uma viagem, mostrando cada parada do trajeto de uma requisição entre serviços. Eventos marcam mudanças de estado, como uma implantação nova, uma alteração de configuração ou o crescimento de um cluster.

Um quinto elemento sustenta os outros quatro: a topologia. Saber quais serviços existem e quem depende de quem transforma sinal solto em contexto de análise, e é o que separa uma lista de anomalias de um diagnóstico de causa raiz.

A qualidade da base define o teto de tudo que vem acima. Se um componente não está instrumentado, ele permanece invisível para a análise causal, e o motor de correlação apontará como origem o ponto mais próximo que consegue observar. O resultado fica plausível e errado, que é o pior dos desfechos possíveis em plantão.

Para o gerente de infraestrutura, a observabilidade full-stack é o inventário vivo do ambiente, com consumo real por componente em vez de planilha desatualizada de capacidade. Para o Site Reliability Engineer, ou SRE, é a diferença entre reconstruir o que aconteceu a partir de consoles separados e ler o caminho do impacto em uma única tela.

A camada de ingestão

A camada de ingestão é o ponto de entrada da telemetria na plataforma, e responde por coletar, normalizar e transportar os sinais até o armazenamento. Três decisões estruturais vivem aqui, e todas têm consequência direta de custo e de precisão.

A primeira decisão é o mecanismo de coleta. Na plataforma Dynatrace, a escolha se dá entre OneAgent, OpenTelemetry ou modelo híbrido. O OneAgent é o agente unificado que descobre automaticamente a stack do host, instrumenta processos suportados e reporta topologia sem configuração manual por serviço. O OpenTelemetry, ou OTel, é o padrão aberto e vendor-neutral da CNCF para gerar telemetria, e funciona como o padrão USB-C da telemetria: um formato que qualquer linguagem, biblioteca ou serviço pode falar, o que resolve a coleta em cargas onde o agente não alcança.

O modelo híbrido é o mais comum em ambientes grandes. OneAgent cobre a stack convencional com profundidade e baixo esforço, enquanto OpenTelemetry cobre funções sem servidor, sistemas legados e componentes com instrumentação própria já escrita.

A segunda decisão é o transporte. O OpenTelemetry Protocol, ou OTLP, é o envelope dos correios da telemetria, que leva a carga até o destino sem alterar seu conteúdo. Ele funciona sobre gRPC, na porta 4317, mais eficiente em volume por usar formato binário, ou sobre HTTP com protobuf, na porta 4318, mais simples para atravessar controles de rede.

A terceira decisão é a governança de atributos, e é a que costuma ser adiada. Atributos são as etiquetas que identificam cada sinal: nome do serviço, ambiente, versão, unidade de negócio. Quando o mesmo serviço chega ao armazenamento com três nomes diferentes, vindos de três times diferentes, o motor de correlação trata três entidades onde existe uma. A análise causal degrada sem emitir erro algum, e ninguém percebe até o primeiro incidente grande.

Sampling, ou amostragem, entra nessa camada como política, não como configuração isolada. Sampling é a pesquisa eleitoral da telemetria, que observa uma parte para inferir o todo. Em sistemas críticos, o sampling tail-based é geralmente preferido, porque decide o que preservar depois de conhecer o resultado da transação, mantendo erro e latência elevada na amostra enquanto reduz a coleta de rotina de baixo risco.

Para o profissional de DevOps, a camada de ingestão é onde a instrumentação encosta na esteira de entrega: cada implantação precisa nascer já instrumentada e etiquetada, sem passo manual depois. Para o CIO, é o ponto em que o custo da plataforma se define, porque volume ingerido e retenção decidem a fatura mais do que qualquer outra escolha da arquitetura.

A camada de armazenamento e consulta

A camada de armazenamento guarda a telemetria coletada e a devolve sob consulta, em janelas que vão de segundos a anos. Duas exigências convivem aqui, e costumam brigar entre si.

A primeira é volume. Um ambiente distribuído de grande porte gera volume massivo de logs, métricas, traces e eventos em janelas curtas, e a análise causal precisa de série histórica longa para distinguir desvio real de comportamento sazonal.

A segunda é velocidade de consulta sobre esse volume. Arquiteturas tradicionais resolvem uma exigência sacrificando a outra: indexam pouco para baratear a escrita, e a leitura fica lenta, ou indexam tudo previamente e o custo cresce junto com a retenção. Nos dois casos a equipe de operações passa a decidir o que descartar com base em orçamento, não em risco.

Na plataforma Dynatrace, essa camada é o Grail, que retém logs, métricas, traces, eventos e topologia em volume massivo, com períodos de retenção que variam conforme o tipo de dado e a configuração adotada, com consulta rápida sobre o dado bruto. A linguagem de consulta é o Dynatrace Query Language, ou DQL, que permite interrogar todos esses tipos de sinal em uma única sintaxe, em vez de exigir uma ferramenta por tipo de dado.

Onde os dados de AIOps ficam armazenados é uma pergunta de governança, e não apenas técnica. Setores supervisionados tratam a retenção de telemetria como política formal, porque a auditoria pode pedir a reconstituição de um evento passado muito depois de ele ter acontecido. Retenção curta demais cria exposição, e retenção indiscriminada cria custo sem retorno.

Para o CIO e para o CTO, essa camada é o registro auditável que sustenta a conversa com órgão regulador e com conselho. Para o SRE, é a capacidade de abrir a análise de um incidente antigo com o dado original intacto, em vez de um resumo agregado que já perdeu a granularidade onde estava a resposta.

A camada de correlação e inteligência artificial

A camada de correlação é onde os sinais deixam de ser dados e viram diagnóstico. A função dela é agrupar eventos que pertencem ao mesmo problema e nomear qual deles causou os demais.

Correlação temporal observa apenas que dois eventos aconteceram próximos no tempo. É um sinal útil e insuficiente, porque em ambiente distribuído dezenas de anomalias coincidem na mesma janela de segundos sem relação de causa entre si, e uma equipe que age sobre coincidência gasta plantão corrigindo o que não estava quebrado.

Causalidade exige contexto estrutural. Para afirmar que o evento A causou o evento B, o motor precisa saber que B depende de A e conhecer a topologia real que ligava os dois no instante do incidente.

Na plataforma Dynatrace, dois componentes ocupam essa camada. O Smartscape é o mapa de dependências em tempo real, que se atualiza conforme o ambiente muda e mostra quais serviços conversam entre si, quais bancos cada aplicação consome e por onde o impacto se propaga. O Davis, dentro do Dynatrace Intelligence, é responsável pela análise causal e percorre esse mapa para determinar o evento gerador da cadeia de falhas.

Dashboards organizam e tornam exploráveis os sinais operacionais, enquanto a Dynatrace Intelligence complementa essa análise com detecção de anomalias, correlação e investigação causal para reduzir a triagem e orientar a resposta.

O produto dessa camada muda de natureza em relação ao alerta tradicional. Em vez de uma lista de anomalias ordenadas por horário, aparece um problema único, com causa raiz nomeada, caminho de impacto descrito e a indicação de quais transações de usuário o problema atingiu.

Para o SRE, a correlação é o que devolve tempo de plantão, porque o diagnóstico chega pronto em vez de a equipe construí-lo sob pressão, e o tempo médio de resolução cai por redução de triagem. Para o CEO, o efeito visível é outro: a operação passa a relatar causas ao conselho, não contagem de incidentes.

A camada de ação e integração

A camada de ação converte diagnóstico em movimento, e é a que mais varia de maturidade entre organizações. Quatro formas de ação convivem, em ordem crescente de autonomia.

A primeira é notificação qualificada. O problema priorizado chega ao canal do plantão com causa e impacto, em vez de dezenas de alertas de sintoma. A segunda é a abertura automática de registro no sistema de chamados, com o contexto técnico já anexado, o que elimina o preenchimento manual que atrasa o início do atendimento.

A terceira forma é a integração com a esteira de entrega. A esteira consulta as métricas de qualidade depois de cada implantação e barra a promoção de uma versão que degradou latência ou taxa de erro, antes que o usuário sinta o efeito.

A quarta é a remediação executada sem intervenção humana: reiniciar um processo, ampliar capacidade, redirecionar tráfego ou reverter uma versão.

Autonomia se conquista por etapas, e organizações que pulam etapas costumam voltar atrás. A recomendação prática é começar por ação reversível e de baixo risco, medir a taxa de acerto do diagnóstico ao longo de meses e só então ampliar o escopo do que a plataforma executa sozinha.

Para o profissional de DevOps, essa camada é o retorno do ciclo de entrega: o efeito de cada implantação aparece enquanto a reversão ainda é barata. Para o gerente de infraestrutura, é a chance de tratar saturação previsível por regra automática e reservar a atenção da equipe para o que exige julgamento.

Nenhum manual genérico decide o que automatizar primeiro, porque o risco de cada ação muda com a criticidade do sistema que ela toca. A Rike IS faz esse recorte junto com a equipe de operações do cliente, separando o que já roda sem intervenção do que ainda precisa de supervisão humana.

Como as camadas se sustentam umas às outras

As camadas formam uma cadeia de dependência, e a direção dessa dependência é sempre de baixo para cima. Cada uma consome o produto da anterior e não consegue compensar o que recebeu com defeito.

Instrumentação incompleta na base produz correlação incompleta no topo, mesmo com o melhor motor causal disponível. Atributos inconsistentes na ingestão produzem agrupamento errado na correlação, porque o motor separa entidades que deveriam ser uma só. Retenção curta no armazenamento impede a comparação com o comportamento histórico, e a detecção de desvio perde a referência do que é normal. Correlação imprecisa produz ação automatizada sobre o componente errado, que é o cenário em que a automação piora o incidente em vez de resolvê-lo.

Observabilidade full-stack não é uma etapa opcional antes da AIOps. Ela é o insumo permanente da AIOps, e a adoção madura da disciplina começa pela qualidade do dado.

Existe um erro de sequência que aparece com frequência em projetos reais. Times contratam a camada de correlação esperando que ela conserte a base, e a análise causal opera sobre a consistência do dado, que não se corrige com mais licença.

A ordem inversa também custa caro. Organizações que passam anos aperfeiçoando a coleta sem nunca ativar correlação acumulam dado bonito e continuam apagando incêndio manualmente, com custo de armazenamento crescente e sem redução do tempo médio de resolução.

Como avaliar cada camada antes de contratar

Avaliar uma arquitetura de AIOps exige perguntar camada por camada. São cinco perguntas, e cada uma revela mais sobre o nível que examina do que qualquer outra que se possa fazer ali.

Na base, a pergunta é de cobertura: qual porção do ambiente está instrumentada hoje, incluindo componentes legados, funções sem servidor e serviços de terceiros que participam de transação crítica. Cobertura parcial não é ponto de partida ruim, e sim informação que precisa estar declarada antes da implantação, para que ninguém confie em um diagnóstico que o alcance atual não sustenta.

Na ingestão, a pergunta é de convenção: existe padrão de nomes e etiquetas acordado entre os times antes de instrumentar? Definir convenção depois de o dado estar em produção custa mais do que definir antes, e costuma exigir reprocessamento de histórico.

No armazenamento, a pergunta é de prazo: quanto tempo de histórico o negócio precisa consultar, considerando a política de retenção acordada com a área de conformidade e a necessidade de análise de tendência. O prazo decide o custo, e o custo decide o que sobrevive à primeira revisão de orçamento.

Na correlação, a pergunta é de insumo: o motor recebe o mapa de dependências atualizado ou apenas uma sequência de eventos com horário? A resposta separa diagnóstico de ordenação cronológica.

Na ação, a pergunta é de reversibilidade: cada automação prevista pode ser desfeita sem impacto adicional, e quem responde por ela quando o diagnóstico erra?

As cinco perguntas expõem o estado real da arquitetura antes de qualquer contrato, e respondê-las com honestidade evita o projeto que promete correlação causal sobre uma base que ainda não a sustenta.

Perguntas frequentes

A AIOps substitui a equipe de operações?

Não. A arquitetura muda o objeto do trabalho da equipe de operações, não o tamanho dela. Triagem manual de alerta e reconstrução de linha do tempo saem da rotina. Entram decisões que a plataforma não toma: qual risco aceitar, quando declarar indisponibilidade ao negócio e que ação automatizada merece autorização prévia.

Qual a diferença entre AIOps e automação por runbook?

Automação por runbook executa um roteiro fixo quando um gatilho previsto dispara, sem interpretar o ambiente. A AIOps determina o que aconteceu antes de escolher o que fazer. Runbook não é concorrente da AIOps: um runbook bem escrito é justamente uma das ações que a camada superior aciona depois do diagnóstico.

OpenTelemetry sozinho monta a arquitetura de AIOps?

Não. OpenTelemetry resolve coleta e transporte, que vivem na camada de ingestão, e padroniza o formato do sinal. Armazenamento consultável, mapa de dependências, correlação causal e ação continuam fora do escopo do padrão aberto e precisam de plataforma. Ambientes que param no OpenTelemetry ficam com telemetria bem formatada e diagnóstico manual.

Quem responde por cada camada dentro da organização?

A base costuma se dividir entre os times de aplicação e de infraestrutura, que instrumentam o que constroem. A ingestão pertence a quem mantém a esteira de entrega. O prazo de retenção no armazenamento é decisão conjunta de arquitetura e conformidade. A correlação é território do SRE, e cada ação automatizada precisa de um dono nomeado no time do serviço que ela toca.

Existe caso em que a camada de ação automática não deve ser ativada?

Sim. Ação irreversível sobre transação financeira em curso, mudança que exige registro prévio em janela aprovada e componente cujo comportamento a equipe ainda não consegue prever ficam fora da automação. A regra prática é simples: automação sem caminho de volta só entra depois que a equipe de operações já acompanhou o histórico de acerto do diagnóstico naquele componente.

Montar essas camadas em sistemas críticos raramente falha por escolha de tecnologia. Falha por diagnóstico apressado do ambiente atual, por convenção de atributos definida tarde demais e por implantação que tenta cobrir tudo de uma vez. A Rike IS acompanha esse percurso sobre a plataforma Dynatrace, da avaliação inicial à governança de performance continuada, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte. Leve o desenho da sua arquitetura atual para uma conversa técnica com os especialistas da Rike IS.