Como funciona o AIOps na prática: o fluxo completo de ponta a ponta

AIOps funciona em quatro momentos dentro de um mesmo incidente: detecção do desvio de baseline antes de qualquer limiar ser rompido, correlação dos sintomas em um problema único, determinação da causa raiz com a mudança recente correlacionada e registro que alimenta o post-mortem. Cada momento produz a informação que o seguinte consome.

Um painel de monitoramento espera que alguém formule a pergunta certa e olhe para o gráfico certo no minuto certo. Uma plataforma com AIOps parte do comportamento aprendido de cada componente e sinaliza o desvio sem que ninguém tenha perguntado, antes do primeiro alerta humano.

A sequência de decisões automáticas começa aí e termina no registro que alimenta a prevenção seguinte. O desvio detectado vira sintoma correlacionado, o conjunto de sintomas vira problema único, e o problema recebe causa raiz nomeada com caminho de impacto descrito.

O incidente descrito a seguir é ilustrativo e genérico, construído para exposição didática, e não descreve cliente, ambiente ou operação real. Os marcadores de tempo servem para ordenar os acontecimentos na narrativa, e nenhum valor de prejuízo, de economia ou de tempo médio de resolução aparece aqui, porque nenhum deles seria verificável.

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.

O cenário

O ambiente é uma aplicação de atendimento ao cliente distribuída em contêineres, com um punhado de serviços de negócio, bancos de dados próprios e integração com provedores externos de pagamento. A operação roda em nuvem, com implantações diárias e plantão de sobreaviso em regime de escala. Nada aqui é exótico, e essa é a forma de boa parte dos sistemas críticos em produção.

Três características desse ambiente decidem o que acontece a seguir.

A primeira é a profundidade da cadeia de chamadas. Uma requisição de usuário atravessa vários serviços antes de retornar resposta, e cada salto acrescenta um ponto onde a latência pode nascer.

A segunda é a assimetria de instrumentação. Os serviços de negócio recebem instrumentação automática pelo OneAgent, o agente unificado que descobre a stack sem configuração manual por componente, e essa cobertura é o que sustenta Application Performance Monitoring, ou APM, sobre a cadeia inteira de chamadas. Os serviços legados exportam telemetria por OpenTelemetry, padrão aberto e vendor-neutral da CNCF que funciona como o padrão USB-C da telemetria, e a plataforma Dynatrace consome as duas origens dentro do mesmo modelo de dados.

Ambiente com duas origens de telemetria carrega um risco que só aparece no incidente. O mesmo serviço precisa carregar o mesmo nome nas duas origens, porque a análise causal trabalha sobre identidade de entidade, não sobre semelhança de nome. Serviço batizado de dois jeitos vira dois vizinhos que nunca se encontram no mapa de dependências.

A terceira é a dependência externa. Quando um provedor de pagamento degrada, o sintoma aparece dentro do ambiente da organização, e a equipe de operações precisa distinguir o quanto antes o que é falha própria do que veio de terceiro.

Para o gerente de infraestrutura, esse desenho define o custo do diagnóstico manual: vários saltos, duas origens de telemetria e um terceiro fora do seu controle. Para o CIO, define outra coisa, a probabilidade de que uma indisponibilidade chegue ao cliente final antes de chegar ao relatório.

Minuto zero: o desvio de baseline

O incidente começa sem alerta.

No minuto zero, o tempo de resposta do serviço de consulta de saldo sobe de forma discreta. A elevação fica bem abaixo do limiar estático configurado para esse serviço, e nenhuma regra tradicional de alerta dispara. Um painel tradicional continuaria verde durante todo esse período.

A plataforma Dynatrace trabalha com baseline dinâmico, que é o comportamento normal aprendido para cada métrica de cada componente, em cada faixa de horário. Naquela faixa da tarde, o serviço de consulta de saldo opera historicamente dentro de uma banda estreita de tempo de resposta. A mediana observada sai dessa banda e configura desvio, ainda que fique longe do limiar estático.

A plataforma registra o desvio como anomalia, sem gerar notificação. A contenção é deliberada: anomalia isolada em um serviço de baixa criticidade não justifica plantão acionado, e a observação continua para verificar se o desvio se propaga, se estabiliza ou se reverte por conta própria.

Minutos depois, o desvio se propaga. O serviço de extrato, que consome o serviço de consulta de saldo, começa a acumular tempo em espera. As conexões do pool para o banco de contas ficam ocupadas por mais tempo do que o habitual naquele horário. Um dos serviços legados instrumentados por OpenTelemetry passa a emitir spans, os registros de cada operação individual dentro de uma requisição, com duração fora da faixa que ele mesmo pratica.

O intervalo entre o primeiro desvio e o primeiro alerta humano é o que costuma ficar invisível para o Site Reliability Engineer, ou SRE, de plantão. Nessa janela o problema já é observável e ninguém está olhando para ele, e a detecção por baseline dinâmico converte a janela invisível em tempo de vantagem.

A correlação: de dezenas de sintomas a um problema

Pouco depois do primeiro desvio, o ambiente produz sintoma em quantidade.

Dezenas de componentes registram anomalia ao mesmo tempo. A lista inclui latência elevada em vários serviços, saturação de pool no banco de contas e aumento de erro de servidor na borda. Aparecem também fila de mensagens crescendo e contêineres reiniciando por falha de verificação de saúde. Cada um desses sinais é verdadeiro. Nenhum deles, sozinho, diz o que fazer.

Este é o momento em que a operação sem correlação causal perde a partida. O canal de plantão recebe uma sequência de notificações, o SRE abre painel atrás de painel e começa a testar hipóteses na ordem em que os alertas chegaram, que é a ordem errada.

A plataforma agrupa antes de notificar, e a correlação usa duas dimensões ao mesmo tempo. A dimensão temporal observa quais anomalias começaram dentro da mesma janela. A dimensão topológica consulta o Smartscape, o mapa de dependências em tempo real, para verificar quais desses componentes de fato conversam entre si.

A segunda dimensão é a que separa diagnóstico de coincidência. Um trabalho de processamento em lote iniciado na mesma janela também apareceu como anomalia. Como o Smartscape mostra que esse trabalho não guarda dependência alguma com a cadeia de consulta de saldo, ele fica fora do agrupamento e não polui o diagnóstico.

O resultado é um problema único, com dezenas de anomalias vinculadas a ele e um responsável indicado.

A ordem de atendimento vem do impacto observado, não da ordem de chegada dos sintomas. A plataforma calcula quantas transações de usuário e quais operações de negócio o problema alcança, e usa esse alcance para dizer o que a equipe atende primeiro. Alerta priorizado por severidade fixada em arquivo de configuração envelhece junto com o arquivo, enquanto alerta priorizado por alcance medido acompanha o ambiente.

Para o profissional de DevOps, a consolidação em problema único muda o que chega no canal da equipe. Em vez de dezenas de notificações que exigem triagem, chega uma, com a lista de componentes afetados anexada, e o tempo que seria gasto lendo alerta redundante fica disponível para a correção.

A causa raiz e o caminho do impacto

O Davis, dentro do Dynatrace Intelligence, entrega o diagnóstico com o problema ainda recém-aberto. Ele é o motor de inteligência artificial causal da plataforma Dynatrace, e sua análise se apoia no mapa de dependências, não apenas na coincidência de horário. A IA causal atua na identificação da causa e do contexto do problema, enquanto os dashboards organizam e tornam exploráveis os sinais operacionais.

O motor percorre o grafo de dependências no sentido inverso da propagação. Sai dos sintomas mais visíveis, o erro na borda, e caminha para trás por cada serviço que contribuiu com latência. A parada acontece no componente cujo desvio precede todos os outros e que nenhum outro explica.

A origem, neste incidente, é uma consulta ao banco de contas que passou a fazer varredura completa de tabela depois de uma implantação feita pouco antes do primeiro desvio.

O diagnóstico apresentado à equipe carrega quatro elementos. O componente de origem, com o momento exato em que o comportamento mudou. O caminho de propagação, serviço por serviço, do banco até a borda. As transações de usuário afetadas, com a operação de negócio nomeada, informação que vem de Digital Experience Monitoring, ou DEM, a disciplina que observa a aplicação pelo lado de quem a usa. E a mudança recente correlacionada com o início do desvio, que é a implantação daquela tarde.

A mudança recente correlacionada é o elemento que mais encurta o tempo médio de resolução. Correlacionar o início do desvio com a mudança que o antecedeu elimina a etapa mais cara do plantão, que é descobrir o que mudou. A plataforma Dynatrace registra implantações, alterações de configuração e mudanças de infraestrutura no mesmo eixo de tempo da telemetria, e a pergunta deixa de ser feita por mensagem no grupo da equipe.

Para o SRE, o diagnóstico com mudança correlacionada reduz o incidente a uma decisão em vez de uma investigação. No lado DevOps, aponta a implantação específica e permite avaliar a reversão enquanto ela ainda sai barata. Para o gerente de infraestrutura, mostra que a saturação do pool foi consequência, e não causa, o que evita a decisão errada de ampliar capacidade do banco.

Chegar a esse nível de diagnóstico depende de instrumentação consistente, convenção de atributos acordada e baseline com histórico suficiente para merecer confiança. A Rike IS conduz implantação e governança de performance junto da equipe de operações do cliente, a partir de um diagnóstico do ambiente que já está em produção.

A resolução

Com a causa raiz nomeada, a equipe tem o que precisa para agir. A decisão sobre o que fazer permanece humana, e convém que permaneça, porque depende de contexto que não está na telemetria: janela de manutenção acordada, apetite a risco e compromisso contratual de disponibilidade.

Três caminhos estão abertos neste incidente. O primeiro é a reversão da implantação, que devolve o ambiente ao estado anterior em minutos e transfere o problema para a próxima tentativa de entrega. O segundo é a correção direta, com criação do índice ausente no banco de contas, que trata a origem sem desfazer as outras alterações daquela mesma implantação. O terceiro é a mitigação temporária, com ampliação do pool de conexões e cache na consulta, que compra tempo e não trata origem alguma.

A equipe escolhe o segundo caminho, porque a implantação continha outras correções já em produção e desfazê-la traria custo próprio.

A plataforma Dynatrace oferece o gatilho para automatizar parte dessa resposta. Um problema aberto pelo Davis dispara fluxo de trabalho externo: abertura de chamado com a causa raiz já preenchida, notificação do time dono do serviço de origem, execução de ação de remediação previamente aprovada. A automação segura em sistemas críticos é a que atua sobre efeito reversível, como reiniciar contêiner ou ampliar réplica, e deixa mudança de esquema ou de código para a decisão humana.

Aplicado o índice, a mediana do serviço de consulta de saldo volta à faixa aprendida, e a própria plataforma fecha o problema quando as anomalias vinculadas cessam.

Para o CEO e para o CTO, o interesse deste ponto está na propriedade da operação. O intervalo entre a falha existir e a equipe compreender sua causa deixou de depender de quem estava de plantão naquela tarde.

O post-mortem

O incidente termina na plataforma e continua na organização por mais alguns dias.

O post-mortem, o registro estruturado feito depois do incidente encerrado, é a etapa que converte incidente em prevenção, e depende de dado que ninguém precisou coletar às pressas durante a falha. O Grail retém logs, métricas, traces e eventos 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 todo o histórico, e o Dynatrace Query Language, ou DQL, consulta esse acervo sem exigir que a pergunta tivesse sido prevista no momento da ingestão. Retenção adequada somada a consulta livre permite reconstituir o incidente semanas depois com o mesmo detalhe do minuto em que ele aconteceu.

Quatro perguntas organizam o post-mortem deste caso.

A primeira trata do motivo pelo qual a implantação passou pelos testes. A consulta que passou a fazer varredura completa de tabela funcionava em ambiente de homologação, onde a tabela de contas tem volume reduzido. O achado aponta para a representatividade do dado de teste, e não para a consulta em si.

A segunda trata do tempo entre o primeiro desvio e o problema aberto. A resposta está na contenção deliberada, porque a plataforma esperou a propagação confirmar que aquele desvio isolado tinha consequência. A equipe pode ajustar a sensibilidade para esse serviço, aceitando mais alerta em troca de menos espera.

A terceira trata da saturação do pool de conexões. A análise de tendência sobre o histórico mostra que o pool já operava perto do teto em horário de pico havia semanas, sem que isso tivesse gerado incidente. O achado vira item de previsão de capacidade, e não de resposta a incidente.

A quarta trata do que fica automatizado a partir daqui, e tem duas partes. A primeira é uma verificação de plano de execução de consulta na esteira de entrega, que barra varredura completa em tabela acima de determinado volume. A segunda é um alerta de tendência sobre utilização de pool, que avisa antes do pico em vez de avisar durante.

Para o CIO, o post-mortem é o artefato que transforma incidente em argumento de investimento, porque nomeia causa e custo evitável em vez de apresentar contagem de ocorrências. Para o SRE, é o que devolve o orçamento de erro consumido em forma de melhoria estrutural.

O que muda no próximo plantão

O incidente descrito acima se passa em um ambiente que já opera com telemetria consistente, e essa condição não vem de graça. Três condições sustentam o fluxo, e ambientes que ignoram qualquer uma delas obtêm diagnóstico plausível e incompleto.

A primeira condição é cobertura. Componente sem instrumentação permanece invisível para a análise causal, e o motor apontará como origem o ponto mais próximo que consegue observar. O diagnóstico continuará chegando rápido, apenas apontará para o lugar errado.

A segunda condição é governança de atributos. O mesmo serviço precisa carregar o mesmo nome em toda a stack, e métricas conceitualmente iguais precisam usar a mesma unidade, ou a correlação trabalha com dado subaproveitado.

A terceira condição é histórico. Baseline dinâmico depende de tempo de observação para saber o que é normal, e ambiente recém-instrumentado atravessa um período em que a detecção ainda está aprendendo o comportamento de cada componente.

Nenhuma dessas três condições se resolve com mais licença de software.

A Rike IS trata as três como critério de aceite da implantação, e não como melhoria para depois. Ambiente entregue com componente crítico fora da instrumentação produz diagnóstico rápido e enganoso, que custa mais caro do que a ausência de diagnóstico, porque a equipe de operações confia nele.

Enquanto o histórico ainda é curto, a prática é manter o limiar estático ligado como rede de segurança. O desligamento vem depois que o baseline cobriu o ciclo semanal completo, com dia útil, fim de semana e fechamento. Confiar na detecção nova desde o primeiro dia troca ruído conhecido por silêncio desconhecido, que é a troca ruim em sistemas críticos.

Perguntas frequentes

E se a causa raiz estiver em um provedor externo?

A análise causal alcança até o limite instrumentado do ambiente. Quando a origem está no provedor de pagamento, o diagnóstico aponta a chamada de saída como último ponto sob observação e mostra a degradação a partir dali. O valor prático muda de correção para evidência: a equipe de operações abre o chamado com o trecho de telemetria que sustenta a reclamação, em vez de descrever sintoma por telefone. Compromisso com terceiro se cobra com dado, não com percepção.

A mudança correlacionada com o início do desvio é sempre a causa raiz?

Não. Correlação com mudança recente é a hipótese mais forte, nunca a sentença. Uma entrega pode coincidir com pico sazonal de tráfego ou com expiração de cache, e a plataforma mostra a coincidência sem afirmar causalidade onde não existe dependência. O critério de decisão é o caminho de propagação: quando o componente alterado não aparece no caminho que leva ao sintoma, a mudança é vizinha de horário e não origem.

AIOps permite reduzir a equipe de plantão?

A pergunta aparece cedo nas conversas com direção, e a resposta honesta é que a mudança recai sobre o tipo de trabalho, não sobre o tamanho do time. O que desaparece é a triagem de alerta redundante e a busca manual pelo que mudou. O que continua exigindo pessoa experiente é a decisão de risco, a negociação de janela e o trabalho estrutural que sai do post-mortem. Equipe menor com detecção madura vira aposta arriscada, e equipe igual com detecção madura passa a produzir prevenção.

O baseline dinâmico pode aprender um comportamento ruim como se fosse normal?

Pode, quando a degradação entra devagar e permanece. Serviço que piora ao longo de semanas empurra a própria faixa de normalidade junto com a piora, e o desvio deixa de aparecer para a detecção. A defesa é a análise de tendência sobre histórico longo, que compara o comportamento atual com o de meses atrás em vez de comparar com a semana anterior. Detecção de anomalia responde pelo agudo, e análise de tendência responde pelo crônico.

E quando dois incidentes independentes acontecem ao mesmo tempo?

A plataforma abre problemas separados quando as anomalias não compartilham dependência no mapa, e cada problema segue com sua própria análise causal. A dificuldade passa a ser humana: dois problemas simultâneos disputam a mesma pessoa de sobreaviso. A decisão que costuma faltar nas organizações é combinar antes do incidente quem assume o segundo problema, e em que ponto o plantão convoca reforço em vez de alternar entre dois diagnósticos.

Operar esse fluxo em sistemas críticos exige diagnóstico do ambiente atual, implantação conduzida com método e governança de performance depois da entrega. A Rike IS trabalha nas três frentes sobre a plataforma Dynatrace, com consultoria, implantação, treinamento e governança continuada, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte. Leve o último incidente do seu ambiente para uma conversa técnica com os especialistas da Rike IS.