Análise automática com Davis AI: menos alertas, mais respostas

Análise automática com Davis AI agrupa por causa compartilhada os eventos que o limiar fixo notificaria um a um, entregando problema único com entidade afetada e escopo. Combina três modelos de detecção, limiar estático, limiar auto-adaptativo e baseline sazonal, que permitem adotar estratégias diferentes conforme o comportamento do sinal, classifica ocorrência frequente como não notificável e separa detectar de notificar.

Equipe de plantão raramente sofre por falta de dado. Sofre por excesso de notificação sem hierarquia, o que treina o operador a ignorar o alerta seguinte. Quando o alerta que importa finalmente chega, ele encontra um canal que a própria equipe silenciou para conseguir trabalhar.

O que é análise automática com Davis AI (e o que ela não é)

A análise automática com Davis AI é o processo pelo qual a plataforma Dynatrace identifica desvios de comportamento e reúne, em uma única unidade de trabalho, tudo o que nasce da mesma origem. A finalidade é substituir a triagem manual por uma fila curta de problemas reais, com entidade afetada e escopo já resolvidos antes de a notificação sair.

O mecanismo central é o Davis AI, motor de inteligência artificial causal que trabalha sobre o mapa de dependências construído pelo OneAgent e correlaciona eventos por relação causal, e não por proximidade no tempo. O requisito principal é cobertura de instrumentação, porque sem topologia completa não existe cadeia causal para percorrer.

Essa cobertura é o mesmo alicerce da observabilidade full-stack para sistemas críticos, que reúne aplicações, infraestrutura, cloud e experiência digital no mesmo contexto correlacionado. A restrição também é clara: a análise automática entrega contexto, e não decide por ninguém.

Quatro confusões aparecem com frequência. A análise automática não é regra de alerta mais esperta, porque a detecção deixa de ser declarativa e passa a ser comportamental. Não é correlação temporal, que agrupa por coincidência de horário. E não é supressão cega, que derruba o sinal junto com o ruído.

A quarta confusão é a mais cara. Dashboard mostra estado, e análise automática entrega julgamento sobre o estado. 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.

Evento não é problema: a distinção que muda tudo

Evento é a ocorrência individual: violação de limiar, degradação de linha de base, queda de processo, implantação e mudança de configuração. Problema é o agrupamento de eventos que compartilham causa raiz, impacto e ciclo de vida.

A triagem é o que a análise automática substitui, e não o dashboard. O trabalho que sai da rotina é o humano de olhar vinte notificações e decidir quais são o mesmo assunto.

Por que o alerta por limiar fixo produz ruído

O ruído operacional é resultado previsível de um modelo de detecção, e não descuido da equipe. The SRE Report 2025, publicado pela Catchpoint em janeiro de 2025 com 301 respostas, mostra que a maioria das organizações opera entre 2 e 10 ferramentas de monitoramento ou observabilidade. Cada ferramenta traz a própria régua de anormalidade.

O limiar fixo envelhece

Um número escolhido em janeiro descreve a carga de janeiro. Sazonalidade, crescimento de base e mudança de perfil de uso deslocam o normal, e o limiar continua onde estava. Limiar apertado gera falso positivo diário, o alerta que se resolve sozinho antes de alguém abrir o notebook. Limiar folgado perde a degradação real.

Um incidente, dezenas de sintomas

Um banco de dados degrada. Os serviços que dependem dele acumulam latência, a fila enche, o gateway responde com erro e a jornada do usuário quebra. Cinco camadas, cinco famílias de alerta, uma causa só. Sem correlação por dependência entre serviços, cinco pessoas investigam a mesma coisa em paralelo.

Cardinality: o multiplicador silencioso

Cardinality é o número de valores distintos que uma dimensão pode assumir. Quando o alerta é dividido por pod, por versão ou por código de status, um problema vira dezenas de notificações idênticas. A recomendação da documentação da plataforma Dynatrace é alertar sobre dado agregado no escopo do serviço.

Alerta sem dono e sem régua

Notificação que chega em canal coletivo, sem responsável nomeado e sem critério de anormalidade, acumula até ninguém mais olhar. A dessensibilização é a consequência técnica: a equipe silencia o canal para conseguir trabalhar, e o alerta que importava chega no canal silenciado.

Para o gerente de infraestrutura, o ruído tem uma segunda fatura. Cada detector mal calibrado sustenta ingestão e retenção que ninguém consulta, e o custo aparece no ciclo seguinte sem que exista um responsável capaz de explicá-lo.

Como a análise automática consolida eventos em um problema único

O critério de agrupamento é causa compartilhada, e não janela de tempo. A correlação de eventos usa topologia, transação e informação de nível de código para identificar o que compartilha origem e impacto. Duas falhas independentes no mesmo minuto viram um pacote errado sob correlação temporal, e dois problemas separados sob correlação causal.

A topologia sustenta o agrupamento

A correlação percorre duas direções. Na vertical está a pilha: processo, host, serviço, aplicação. Na horizontal está a cadeia de chamadas entre serviços, que atravessa times e domínios.

Quem sustenta esse mapa é o OneAgent, agente unificado da plataforma. Uma instalação descobre toda a stack de um host, contêiner ou ambiente cloud, incluindo linguagens, frameworks, bancos, filas e dependências, sem configuração manual por componente.

O Smartscape mantém essa representação atualizada em tempo real. Para o arquiteto, é registro de território que a documentação nunca acompanhou. Para o Site Reliability Engineer, ou SRE, em plantão, é o atalho que mostra o caminho do impacto.

O problema tem ciclo de vida

Um problema permanece ativo enquanto houver entidade afetada em estado anormal. Novos eventos que compartilham a mesma causa entram no problema existente e o enriquecem em tempo real. Não chegam vinte notificações novas ao longo de meia hora, e sim uma, que evolui.

A plataforma aceita informação incompleta e duplicidade eventual para privilegiar velocidade de alerta, e essa escolha de projeto está declarada na documentação. Depois que o problema abre, a análise causal percorre as dependências por árvore de falhas até a origem, descartando os ramos cujo comportamento permaneceu dentro do esperado.

Detecção sem limiar fixo: os três modelos disponíveis

A detecção de anomalias na plataforma Dynatrace oferece três abordagens. Cada uma serve a um tipo de métrica, e a escolha errada é uma das origens do falso positivo.

Um parâmetro separa pico isolado de degradação: a janela deslizante. Por padrão, a violação precisa se sustentar por 3 minutos dentro de uma janela de 5 minutos. Para sinal esparso de log, a documentação recomenda janela de agregação de 60 minutos.

O ruído que a plataforma decide não notificar

A detecção de problemas frequentes identifica ocorrências regulares que nascem de condições sub-ótimas, porém toleradas pela operação. O exemplo típico é o job da madrugada que sempre estica a latência de um serviço secundário.

Os conjuntos de referência de 24 horas e 7 dias

A classificação usa critério numérico publicado, e ocorrência classificada como frequente não dispara notificação.

Isso não é esconder problema

A objeção é legítima e merece o mecanismo, e não uma promessa. A supressão de alerta só se aplica quando a ocorrência é menos severa e mais curta que o padrão histórico daquele mesmo problema. Se a condição piorar ou durar mais, ela volta a alertar.

Aí está a diferença em relação ao silenciamento manual, que é o medo real por trás da objeção. O silenciamento humano vale até alguém desfazer, e ninguém desfaz. A classificação é reavaliada a cada ocorrência, contra o histórico daquela mesma condição.

Detectar não é notificar: a camada de política

Reduzir ruído não significa monitorar menos. Detecção e notificação são decisões separadas, e confundir as duas leva à conclusão errada de que cobertura ampla produz plantão barulhento. O perfil de alerta é o instrumento dessa separação: um filtro reutilizável que reduz o total detectado a um subconjunto notificável por severidade, duração e tag. O roteamento por ambiente vem daí.

A régua: 0,1% do tempo observado

A documentação da plataforma Dynatrace publica um critério objetivo de saúde de alerta. Um alerta existe para sinalizar estado anormal, e estado anormal deve ocupar no máximo 0,1% do tempo observado, algo entre 1 e 1,5 minuto por dia.

Essa régua vira auditoria em uma tarde. Basta tomar o detector que mais dispara e somar quanto tempo por dia ele considera o sistema anormal. Se o resultado passa muito de um minuto, o alerta não acionável tem causa de critério, e não de disciplina do time.

Evento informativo entra como contexto

Implantação, mudança de configuração e movimentação de máquina virtual entram na linha do tempo como evento informativo, sem poluir a fila de problemas. Aqui o time de DevOps ganha o que pede há anos: a degradação aparece ao lado da implantação que a antecedeu, sem cruzamento manual de horários.

O que muda na rotina de plantão do SRE

São 3h12. O telefone vibra pela quarta vez em vinte minutos, e as três primeiras notificações eram o mesmo assunto. O engenheiro de plantão sabia disso, mas abriu as três para ter certeza. Ele abre o dashboard de sempre, aquele com dezoito gráficos do qual olha três.

Quinze minutos depois, ele confirma o que suspeitava: era uma coisa só. Quinze minutos que entraram inteiros no tempo de resolução e não aparecem em relatório nenhum como trabalho. Na reunião da manhã, a resposta honesta não cabe no formato, então ele diz que foi problema no banco.

Com consolidação em problema único, o turno começa em outro ponto. A notificação chega com entidade afetada, escopo de impacto e linha do tempo montada, e o primeiro trabalho passa a ser decidir a resposta, em vez de montar o quadro.

O efeito sobre detecção, resolução e orçamento de erro

O Mean Time To Detect, ou MTTD, é o tempo médio até detectar, e o Mean Time To Resolve, ou MTTR, o tempo médio até restaurar o serviço. O MTTD cai porque a detecção não depende de alguém olhar o gráfico, e o MTTR cai porque a montagem de contexto sai do caminho crítico.

O orçamento de erro, a margem de indisponibilidade que um Service Level Objective, ou SLO, autoriza consumir, passa a ser gasto em incidente real, e não em triagem. Para o CIO, o CTO e o CEO, a tradução é mais dura, porque ruído e cegueira chegam ao conselho de administração como o mesmo risco não demonstrável: em ambos os casos, a organização não consegue explicar o que aconteceu.

O que não muda

Runbook continua necessário. Post-mortem continua necessário. A decisão de reversão continua humana, e a escalação de alertas continua exigindo dono nomeado por serviço. A análise automática com Davis AI muda o que a pessoa faz no primeiro minuto do plantão, e não se ela existe.

Como o ruído aparece em cada setor

Em órgãos públicos, a stack é heterogênea por regra e cada camada trouxe sua régua de alerta. Em pico sazonal, prazo de tributo ou matrícula escolar, a soma dessas réguas produz uma enxurrada que a equipe reduzida não consegue triar, e o custo da falha percebida é social e político antes de ser técnico.

Em instituições financeiras, o ponto não é volume, é explicabilidade. Uma decisão de não notificar precisa ser justificável para auditoria e para o regulador. O critério publicado de classificação torna essa decisão auditável, e o histórico retido no Grail sustenta a demonstração meses depois do evento.

Em cooperativas, cada praça gera seus próprios sintomas para a mesma causa, e a governança regional recebe vinte relatos de um problema só. A consolidação em problema único é o que permite comparar praças pelo mesmo critério na reunião de governança, em vez de comparar volume de reclamação.

Em empresas privadas de grande porte, a degradação silenciosa não gera alerta de indisponibilidade, gera abandono. O sistema segue no ar, a jornada piora aos poucos, e o efeito aparece na conversão antes de aparecer em qualquer painel de infraestrutura.

Erros comuns ao ativar análise automática

Seis erros aparecem com regularidade nas primeiras semanas de operação. O primeiro é subir detector sensível demais, o que faz a equipe perder confiança antes de a calibração terminar; começar folgado e observar por duas semanas custa menos que recuperar credibilidade. O segundo é alertar por dimensão de alta cardinality, com um problema virando um alerta por pod, quando o agregado no escopo do serviço resolveria.

O terceiro é tratar sinal esparso de log como métrica contínua, porque cada janela vazia produz falso positivo, e a correção é a janela de agregação maior. O quarto é deixar alerta aberto por semanas, até a fila de problemas deixar de significar alguma coisa; o que ninguém investiga precisa ser encerrado.

O quinto é ignorar a governança de atributos, já que o mesmo serviço com nomes diferentes não agrupa, e a convenção semântica precisa estar padronizada antes da coleta. O sexto é não revisar configuração, porque detector inerte e alvo obsoleto acumulam em silêncio, e revisão trimestral é o mínimo que impede o acúmulo.

Nenhum desses erros aparece na fatura da licença. Eles aparecem no turno da madrugada, meses depois, quando alguém pergunta por que o ambiente continua barulhento.

Como a Rike IS estrutura a redução de ruído operacional

O mecanismo é público e bem documentado. O que separa um ambiente calmo de um ambiente barulhento não é a licença, e sim a implantação, a governança de atributos e a calibração ao longo do tempo.

Esse trabalho é de campo e acontece em ondas, com valor visível em poucas semanas e expansão de cobertura nos meses seguintes. O escopo cobre diagnóstico inicial, implantação, treinamento por perfil profissional, incluindo o Dynatrace Query Language, ou DQL, e governança contínua, com experiência acumulada em ambientes de complexidade equivalente.

Perguntas frequentes

Qual a diferença entre fadiga de alertas e ruído de alertas?

Ruído de alerta é propriedade do sistema, a proporção de notificações que não exigem ação. Fadiga de alertas é o efeito sobre as pessoas, a dessensibilização que faz a equipe deixar de reagir. O ruído é mensurável, e a fadiga é observável nos sintomas, como canal silenciado e rotatividade de gente sênior no plantão.

Como a análise automática lida com ambiente heterogêneo e legado?

Cobertura é o requisito, e é onde ambiente heterogêneo exige trabalho. O OneAgent descobre a stack de um host, contêiner ou ambiente cloud sem configuração por componente. O que sobra, como componentes que não aceitam o agente, exige instrumentação manual na borda e governança de atributos coerente. É esse trecho que separa a implantação que reduz ruído da que troca a origem dele.

A análise automática dispensa a configuração de alertas?

Não. Ela muda o que se configura. A detecção deixa de exigir limiar por métrica, e a decisão passa para a camada de política: quais problemas detectados viram notificação, com qual severidade, para qual destinatário e em qual ambiente. Perfil de alerta continua sendo trabalho de quem opera.

Quanto tempo até o ambiente ficar calmo?

A calibração de cada detector pede cerca de duas semanas de observação antes do primeiro ajuste, e a linha de base sazonal precisa de ciclos completos, incluindo fechamento de mês. Ambiente com governança de atributos instável demora mais, porque a consolidação depende de o mesmo serviço ter sempre o mesmo nome.

Como demonstrar para auditoria que uma ocorrência deixou de ser notificada?

Pelo critério publicado e pelo histórico. A classificação de ocorrência frequente segue cortes numéricos documentados, e a decisão é reavaliada a cada nova ocorrência contra o padrão daquela mesma condição. O evento continua registrado e consultável no histórico retido, mesmo quando não gerou notificação.

Reduzir ruído operacional não é ajuste de configuração, é decisão de arquitetura que depende de cobertura de instrumentação, governança de atributos e calibração acompanhada ao longo do tempo. A Rike IS conduz esse trabalho em sistemas críticos sobre a plataforma Dynatrace, com consultoria, implantação, treinamento e governança contínua, junto a órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte. O ponto de partida é sempre a leitura da configuração que já existe, antes de qualquer proposta de mudança.

Escopo: os parâmetros técnicos citados vêm da documentação oficial e podem mudar entre versões, e a configuração de cada ambiente é definida no diagnóstico. A responsabilidade pela operação e pela resposta a incidente permanece do contratante.