Do Tempo de Atividade à Experiência: A Mudança Impulsionada por IA na Observabilidade Moderna

Em 2001, a IBM escreveu um manifesto de TI autônoma. A Visão da Computação Autonômica dividiu a autogestão em quatro pilares: auto-otimização, auto-cura, auto-configuração e auto-proteção. Eu estava na Microsoft quando a IBM apresentou essa visão de TI. Reagimos propondo ideias tecnológicas como o data center autônomo, mas, em última análise, era um sonho muito avançado para a época. Não havia uma forma prática de transformar essa visão em realidade.

Nos meus dias na Microsoft, eu fazia parte da equipe por trás do Clippy. Embora o assistente de clipe de papel animado fosse notoriamente intrusivo, a ideia por trás dele era sólida: os computadores devem ajudar ativamente os humanos a desempenharem seus trabalhos. Nós simplesmente não tínhamos o poder computacional e a IA necessários para torná‑la possível. 25 anos depois, finalmente conseguimos.

Do Nível de Serviço ao Nível de Experiência

O conceito de observabilidade não se originou em TI. Em 1960, o engenheiro e matemático húngaro‑americano Rudolf E. Kálmán criou o termo “observability” para descrever o quão bem um sistema pode ser medido por suas saídas. Depois, em 2013, o Twitter adotou o termo em uma série de posts no blog, efetivamente afirmando que o monitoramento tradicional, por meio de todas as ferramentas comerciais prontas que eles tinham disponíveis, foi projetado para uma era tecnológica diferente e não funcionava em arquiteturas de escala de microsserviços.

Pense nisso como um médico examinando um paciente. Ele pode checar o pulso, medir a pressão arterial e observar outras características externas para avaliar indiretamente a saúde interna do paciente. Em TI, precisamos fazer o mesmo. Quando há uma oscilação no pulso do paciente, precisamos saber se isso indica problemas nos rins ou no fígado. Na escala e complexidade das operações que o Twitter lidava há 20 anos (a empresa atendia apenas 100 milhões de usuários com tweets e feeds em tempo real), a observabilidade exigia uma abordagem de ferramentas e monitoramento diferente.

Os sistemas atuais tornaram‑se ainda maiores e mais complexos, com dependências de redes de entrega de conteúdo, cache e distribuição de bitmaps, fontes, arquivos JavaScript, etc., em todo o mundo. Compreender verdadeiramente o desempenho de aplicações do mundo real não é tarefa fácil.

Quando a TI recebe um alerta às 4 da manhã, alguém precisa sair da cama e descobrir se o problema se deve a um setor defeituoso em um disco rígido ou a um agente malicioso tentando penetrar e causar caos na infraestrutura. Na prática, não importa qual seja: no final das contas, o trabalho deles é manter todos os sistemas em funcionamento. Felizmente, para avaliar a saúde das aplicações hoje, podemos coletar toda a telemetria disponível: cada dispositivo de rede, cada aplicação, milhares de integrações prontas, fluxo de tickets pelo JIRA ou Atlassian, e inúmeros outros sinais.

É aqui que entram os Experience Level Objectives (XLOs). Você provavelmente já ouviu falar de Service Level Agreements (SLAs) e Service Level Objectives (SLOs), mas os XLOs dão o próximo passo ao medir se seus clientes e funcionários estão recebendo o nível de experiência que desejam. Trata‑se de qualidade, não apenas de tempo de atividade. Do ponto de vista técnico, a única maneira de alcançar os XLOs é ter visibilidade desde a NIC até o dispositivo do usuário final.

No último outubro, a AWS US‑EAST‑1 ficou indisponível. A Catchpoint detectou o problema 16 minutos antes de a Amazon reconhecê‑lo publicamente. Clientes com essa visibilidade puderam reagir antes que seus usuários sentissem as consequências da interrupção.

A promessa da observabilidade é semelhante ao Smokey Bear: detectar onde há fumaça antes que haja fogo. Quando feita corretamente, a observabilidade permite apagar um incêndio na pradaria antes que ele se transforme em uma conflagração que destrua as Palisades na Califórnia. Smokey é o sistema de alerta precoce que pode detectar esses pequenos cheiros de fumaça, independentemente de sua origem: um problema da AWS, da Oracle, do GCP, da Microsoft Azure ou algo errado em sua infraestrutura.

IA Amplia Sistemas de Segurança

Nenhum operador humano pode acompanhar os sistemas de infraestrutura atuais. A única maneira de monitorar sistemas em escala, ingerindo petabytes de dados de logs e trilhões de métricas por dia, é usar IA.

Por exemplo, suponha que você queira monitorar o desempenho de leitura/gravação de um disco ou os excessos de entrada/saída ou de buffer de pacotes em seu ambiente de rede. Você pode usar um limiar dinâmico para definir o que é considerado normal, ou uma abordagem determinística para analisar séries temporais da última semana, mês, ano ou qualquer intervalo que desejar, e estabelecer limites de desempenho normais. Depois de obter essa análise estatística, você pode definir níveis de duas desvios‑padrão da média, de modo que, quando algo ocorre fora desse intervalo, você receba um alerta de que o desempenho pode estar anormal.

Sistemas altamente complexos, no entanto, podem receber milhares de alertas por dia. Os painéis começam a piscar e as pessoas começam a ser acionadas. Filtrar todos esses alertas não é um bom uso do tempo humano. De fato, a Vectra estima que as organizações recebem, em média, 2,992 alertas de segurança por dia, 63 % dos quais ficam sem tratamento.

Ferramentas de IA podem reduzir essas milhares de alertas por dia para apenas algumas dezenas. Lembro de um caso em que um único problema em uma única NIC em uma única máquina gerou 2.000 alertas subsequentes. Graças à IA, o cliente conseguiu fazer a correlação de alertas e chegar a uma análise de causa raiz muito mais rápida, que, por sua vez, concluiu que um problema naquele momento estava fazendo todo o painel da empresa ficar vermelho.

A IA está tornando TI empolgante novamente

Tirei um tempo de folga depois que a Cisco adquiriu a Splunk em 2023. Nos dois anos seguintes, observei meus amigos e ex-colegas fundarem empresas para usar IA de maneiras que não eram possíveis nem há cinco anos. (Lembre-se de que, se o ChatGPT fosse uma criança humana, seria uma criança de três anos).

As equipes de TI precisam de ajuda para detectar fumaça antes que o alarme dispare, não de mais painéis para observar. Elas. De certa forma, esse é o mesmo problema que a IBM, o Twitter e até a Microsoft com o Clippy têm tentado resolver.

Essa é a razão pela qual decidi voltar a me envolver. A tecnologia finalmente chegou a um ponto em que podemos cumprir a promessa original de observabilidade e TI autônoma.