AIOps
Detectar um incidente é fácil. Difícil é construir o contexto para encontrar a causa raiz.
No artigo “Sua operação monitora tudo. Então por que ainda recebe tantos alertas?”, compartilhei uma reflexão sobre um problema que se tornou cada vez mais comum nas operações modernas de TI. À medida que ampliamos a cobertura do monitoramento, passamos a enxergar muito mais sinais sobre o comportamento dos ambientes, mas isso não significou, necessariamente, uma compreensão mais rápida dos incidentes.
Um único problema pode produzir dezenas ou até centenas de alertas distribuídos entre diferentes ferramentas. Cada plataforma registra corretamente aquilo que consegue observar e cumpre muito bem o papel para o qual foi projetada. O desafio começa quando a operação precisa transformar esse conjunto de informações em uma explicação coerente sobre o que realmente está acontecendo.
É justamente nesse momento que surge uma pergunta importante.
Se hoje conseguimos detectar um incidente em poucos segundos, por que ainda levamos tanto tempo para descobrir onde ele começou?
Essa questão merece atenção porque, em muitos ambientes, a etapa mais demorada já não é perceber que existe um problema. O verdadeiro desafio passou a ser compreender sua origem antes que o impacto para o negócio aumente.
Detectar é apenas o começo
Imagine uma situação relativamente comum em uma grande empresa.
São duas horas da manhã e uma aplicação crítica começa a apresentar lentidão. Em poucos segundos, o monitoramento registra aumento na utilização de CPU em alguns servidores. A plataforma de observabilidade identifica crescimento no tempo de resposta das aplicações. A solução de experiência digital detecta degradação na jornada dos usuários. O sistema de ITSM começa a receber chamados e, pouco depois, outras aplicações passam a apresentar comportamento semelhante, embora estejam hospedadas em ambientes diferentes.
Em menos de um minuto, a operação já sabe que existe um incidente relevante.
O curioso é que, nesse momento, ninguém sabe exatamente qual é o problema.
A equipe responsável pela infraestrutura verifica rapidamente a utilização dos servidores e não encontra nenhuma anormalidade capaz de explicar o comportamento observado. O banco de dados continua respondendo dentro dos parâmetros esperados. A rede aparenta estabilidade. Os serviços em nuvem não registram indisponibilidades. Cada equipe passa a analisar os componentes sob sua responsabilidade enquanto novas informações continuam chegando.
A pressão aumenta. Os gestores querem uma previsão de normalização. As áreas de negócio perguntam quais serviços foram afetados. Os usuários continuam abrindo chamados. Enquanto isso, as equipes técnicas ainda tentam responder a uma pergunta muito mais básica: o que, de fato, aconteceu?
Essa situação é muito mais comum do que parece.
Durante muitos anos, acreditamos que ampliar o monitoramento significaria reduzir automaticamente o tempo necessário para resolver incidentes. De certa forma, isso realmente aconteceu. Hoje detectamos problemas com muito mais rapidez do que no passado.
Mas os ambientes também mudaram.
Aplicações deixaram de depender apenas de servidores físicos e passaram a operar sobre infraestruturas distribuídas, serviços em nuvem, APIs, microsserviços, bancos de dados replicados, plataformas de mensageria e diversos componentes compartilhados. Ao mesmo tempo, surgiram novas ferramentas especializadas para monitorar cada uma dessas camadas.
Essa evolução trouxe ganhos importantes de escalabilidade, visibilidade e confiabilidade. Em contrapartida, aumentou significativamente a quantidade de informações produzidas durante um incidente.
Se antes uma operação analisava poucas fontes de eventos, hoje precisa lidar simultaneamente com plataformas de monitoramento de infraestrutura, observabilidade, APM, logs centralizados, monitoramento de rede, experiência digital, cloud, containers, Kubernetes, ferramentas de segurança, ITSM, CMDB e diversas soluções específicas de fabricantes.
Cada uma delas observa o ambiente sob uma perspectiva diferente.
Cada uma produz eventos, métricas, logs, indicadores e alertas que fazem sentido dentro do seu próprio contexto.
Cada uma descreve corretamente aquilo que consegue enxergar.
O problema é que nenhuma delas foi concebida para explicar, sozinha, um incidente que atravessa todas essas camadas.
É exatamente aí que a complexidade das operações modernas começa a aparecer.
Antes de encontrar a causa, é preciso construir contexto
Vamos voltar ao incidente.
Depois de quase quarenta minutos de investigação, alguém percebe que todas as aplicações afetadas compartilham o mesmo serviço de autenticação. Poucos minutos antes do início dos problemas havia sido implantada uma nova versão desse componente.
A partir desse momento, vários acontecimentos que pareciam independentes começam a fazer sentido.
Os erros de autenticação deixam de ser vistos como um problema isolado. A lentidão observada em outras aplicações passa a ser interpretada como consequência da mesma falha. Os chamados registrados pelo Service Desk apresentam exatamente o mesmo horário de início. A sequência temporal dos eventos começa a indicar uma relação clara entre a atualização realizada e os sintomas percebidos pelos usuários.
Perceba o que aconteceu.
A operação não encontrou imediatamente a causa raiz.
Antes disso, ela conseguiu reconstruir a história do incidente.
Essa diferença parece pequena, mas ajuda a explicar por que tantas investigações consomem tanto tempo.
Na prática, reconstruir essa história significa muito mais do que reunir alertas em uma única tela. Significa compreender como informações produzidas por diferentes plataformas se relacionam entre si e como cada uma delas representa apenas uma parte da realidade.
Um aumento na utilização de CPU pode ser apenas consequência de uma falha anterior. Um erro registrado na aplicação pode ter origem em um serviço compartilhado utilizado por dezenas de outros sistemas. Uma degradação percebida pelos usuários pode ter começado vários minutos depois da alteração que realmente iniciou o incidente. Um grande volume de chamados pode ser apenas o reflexo de um problema que já vinha se propagando silenciosamente pelo ambiente.
Nenhuma dessas informações é suficiente, isoladamente, para explicar o que aconteceu.
É justamente quando essas evidências começam a ser correlacionadas que a operação passa a construir o contexto do incidente.
Esse contexto não nasce de uma única ferramenta nem de uma única fonte de dados. Pelo contrário. Ele depende da capacidade de integrar informações provenientes de múltiplas plataformas e interpretá-las de forma conjunta.
Alertas de monitoramento precisam ser relacionados com métricas de observabilidade. Logs precisam ser confrontados com mudanças recentes realizadas no ambiente. Informações do ITSM ajudam a identificar o impacto percebido pelos usuários. A topologia revela dependências entre aplicações. O histórico de incidentes semelhantes oferece referências importantes. A sequência temporal mostra quais eventos aconteceram primeiro e quais surgiram apenas como consequência.
Separadamente, esses elementos representam apenas fragmentos da realidade.
Quando analisados em conjunto, passam a construir uma narrativa coerente sobre o comportamento do ambiente.
É isso que chamamos de contexto operacional.
Contexto não significa simplesmente consolidar dashboards ou centralizar eventos de diferentes fabricantes. Também não significa apenas reduzir o número de alertas exibidos para a operação.
Construir contexto significa correlacionar informações heterogêneas até que elas expliquem o comportamento do ambiente. Significa compreender quais alertas representam apenas sintomas, quais pertencem ao mesmo incidente, quais componentes compartilham dependências, quais mudanças podem ter iniciado a falha e quais evidências realmente ajudam a direcionar a investigação para sua origem.
Essa talvez seja uma das mudanças mais importantes pelas quais as operações de TI estão passando.
Durante muito tempo, acreditamos que produzir mais dados seria suficiente para tomar melhores decisões.
Hoje percebemos que o verdadeiro diferencial não está na quantidade de informações disponíveis, mas na capacidade de transformá-las rapidamente em entendimento.
O diferencial das operações mais maduras
Existe uma ideia bastante difundida de que operações maduras são aquelas que monitoram mais ativos, possuem mais dashboards ou utilizam ferramentas mais sofisticadas.
Sem dúvida, tudo isso é importante.
Mas, acompanhando projetos em diferentes organizações ao longo dos últimos anos, passei a perceber que o verdadeiro diferencial costuma aparecer em outro momento.
Ele aparece na velocidade com que a operação consegue construir contexto.
Essa talvez seja uma das competências menos discutidas e, ao mesmo tempo, uma das mais importantes das operações modernas.
Quanto mais complexo se torna o ambiente, maior tende a ser a quantidade de plataformas especializadas e, consequentemente, maior também é o número de fontes produzindo informações sobre um mesmo incidente. O problema é que cada uma delas utiliza sua própria linguagem, seus próprios modelos de dados e sua própria forma de representar aquilo que está acontecendo.
Enquanto uma ferramenta registra eventos, outra trabalha com métricas. Uma terceira produz logs. Outra apresenta traces distribuídos. O ITSM registra chamados. A CMDB descreve relacionamentos. As plataformas de nuvem informam mudanças na infraestrutura. Soluções de segurança identificam comportamentos suspeitos.
Cada uma dessas informações possui valor.
Mas nenhuma delas explica, isoladamente, um incidente que atravessa todas essas camadas.
Na prática, o trabalho da operação passou a ser muito menos encontrar dados e muito mais descobrir como esses dados se relacionam.
É exatamente por isso que construir contexto se tornou uma capacidade tão estratégica.
Quando a operação consegue correlacionar informações provenientes de múltiplas fontes, ela deixa de enxergar dezenas de eventos independentes e passa a compreender um único incidente.
Aquilo que antes parecia uma sucessão de problemas desconectados começa a revelar relações de causa e efeito. Alertas deixam de competir entre si. Sintomas passam a ser diferenciados da origem da falha. Dependências entre aplicações ajudam a eliminar hipóteses improváveis. Mudanças recentes passam a fazer parte da investigação desde os primeiros minutos. O histórico de incidentes semelhantes oferece referências que dificilmente seriam percebidas analisando apenas uma única ferramenta.
Perceba que essa transformação não acontece porque surgiram mais dados.
Ela acontece porque os dados passaram a fazer sentido em conjunto.
Talvez essa seja a melhor definição para contexto operacional.
Contexto é o que transforma dados em entendimento.
Essa compreensão muda completamente a forma como as equipes trabalham.
Em vez de cada especialista interpretar apenas a parcela do ambiente que consegue enxergar, a operação passa a compartilhar uma visão comum do incidente. A conversa deixa de girar em torno de dezenas de alarmes e passa a se concentrar naquilo que realmente importa: qual foi o primeiro desvio observado, como ele se propagou pelo ambiente, quais serviços foram impactados e quais evidências apontam para a origem do problema.
Isso não elimina a necessidade de profissionais experientes.
Muito menos significa que a causa raiz será identificada automaticamente.
Ambientes críticos continuarão exigindo conhecimento técnico, capacidade de análise e julgamento humano.
O que muda é o ponto de partida.
Em vez de iniciar cada investigação tentando organizar manualmente centenas ou milhares de informações dispersas, as equipes passam a trabalhar sobre um entendimento muito mais claro do cenário que estão enfrentando.
Essa diferença produz efeitos que vão muito além da identificação da causa raiz.
As equipes corretas são mobilizadas mais cedo. Sintomas deixam de ser tratados como incidentes independentes. A comunicação entre as áreas torna-se mais objetiva porque todos passam a trabalhar sobre a mesma interpretação dos fatos. O tempo gasto discutindo hipóteses improváveis diminui e a energia da operação passa a ser direcionada para aquilo que realmente precisa ser resolvido.
Talvez seja justamente essa a transformação mais importante pela qual as operações de TI estejam passando.
Durante muitos anos, nosso principal objetivo foi ampliar a capacidade de detectar falhas.
Hoje essa capacidade já é praticamente um requisito básico.
O que começa a diferenciar operações verdadeiramente maduras é a rapidez com que conseguem construir contexto, transformando milhares de informações produzidas por múltiplas fontes em uma compreensão consistente sobre aquilo que realmente aconteceu.
No próximo artigo da série, “Observabilidade não é uma ferramenta. É uma nova forma de operar.”, vamos aprofundar essa discussão e analisar por que observabilidade vai muito além da coleta de métricas, logs e traces. Seu verdadeiro valor está na capacidade de ampliar a compreensão das relações entre aplicações, infraestrutura e serviços, enriquecendo o contexto operacional necessário para que decisões sejam tomadas com muito mais rapidez e segurança.
Para refletir
Quando um incidente relevante ocorre na sua operação, quanto tempo é gasto corrigindo o problema e quanto tempo é consumido simplesmente tentando entender onde ele começou?
As diferentes equipes conseguem construir rapidamente uma visão comum do incidente ou cada uma trabalha, inicialmente, com uma interpretação diferente baseada apenas na ferramenta que utiliza?
As informações produzidas pelo monitoramento, pela observabilidade, pelos logs, pelo ITSM, pelas plataformas de nuvem e pelas demais soluções são realmente correlacionadas ou continuam sendo analisadas de forma isolada?
Mudanças recentes, dependências entre aplicações, topologia da infraestrutura, histórico de ocorrências semelhantes e impacto para o negócio fazem parte da investigação desde os primeiros minutos ou só passam a ser considerados depois de uma longa análise?
Responder a essas perguntas talvez revele que o maior desafio das operações modernas já não está em detectar incidentes.
Está em construir, com rapidez, o contexto necessário para compreender o que realmente aconteceu.
Sobre o autor
Paulo Florêncio de Menezes é cofundador da Target Solutions e atua há mais de 15 anos em projetos relacionados a infraestrutura, monitoramento, observabilidade, automação e operações de TI e Telecom.
É graduado em Processamento de Dados pela Universidade Federal do Amazonas (UFAM), possui MBA em Gestão Empresarial pela Fundação Dom Cabral (FDC) e Mestrado Profissional em Economia pela Fundação Getulio Vargas (FGV).
Em sua pesquisa de Mestrado, desenvolveu o IBEOP-IA (Índice Brasileiro de Exposição Ocupacional Potencial à Inteligência Artificial), investigando a exposição potencial das ocupações brasileiras às capacidades da IA por meio da combinação de dados ocupacionais, patentes de inteligência artificial e técnicas de processamento de linguagem natural.
Sobre a Target Solutions
A Target Solutions atua há mais de 15 anos apoiando organizações na evolução de suas operações de infraestrutura, monitoramento, observabilidade, automação e AIOps. Ao longo desse período, participou de projetos em ambientes complexos dos setores de Telecom, Tecnologia, Governo, Energia e grandes empresas, ajudando seus clientes a aumentar a confiabilidade dos serviços e a eficiência de suas operações.
Como parte dessa experiência, desenvolveu o ARGUS, uma plataforma de AIOps projetada para atuar sobre um dos maiores desafios das operações modernas: a construção de contexto operacional.
Em vez de substituir as ferramentas já existentes, o ARGUS integra informações provenientes de múltiplas fontes, como plataformas de monitoramento, observabilidade, logs, ITSM, topologia, CMDB, ambientes em nuvem e outras soluções especializadas. A partir da correlação dessas informações, constrói praticamente em tempo real uma visão integrada do incidente, identificando relações entre eventos, dependências entre componentes, mudanças recentes, histórico operacional e possíveis causas relacionadas.
Com isso, a operação deixa de analisar milhares de eventos isolados e passa a trabalhar sobre um contexto único, consistente e compartilhado, reduzindo o esforço de investigação, acelerando a identificação da causa provável e permitindo que as equipes concentrem seu tempo na resolução do problema, e não na tentativa de reconstruir manualmente a história do incidente.