Observabilidade não é uma ferramenta. É uma nova forma de operar.

No artigo “Detectar um incidente é fácil. Difícil é construir o contexto para encontrar a causa raiz.”, explorei uma questão que considero central para as operações modernas de TI. Hoje conseguimos identificar rapidamente que alguma coisa está errada. O problema começa quando precisamos compreender o que aconteceu, onde a falha realmente se originou e como diferentes sinais produzidos pelo ambiente se relacionam.

Essa discussão nos leva naturalmente à observabilidade.

Nos últimos anos, poucas palavras ganharam tanto espaço no vocabulário das operações de TI. Surgiram novas plataformas, arquiteturas, metodologias e funcionalidades associadas ao tema. Métricas, logs e traces passaram a ocupar um lugar cada vez mais importante nas estratégias de monitoramento, especialmente em ambientes distribuídos, aplicações modernas, microsserviços, containers e infraestruturas em nuvem.

Essa evolução foi necessária. À medida que os sistemas se tornaram mais dinâmicos e interdependentes, simplesmente acompanhar se um servidor estava disponível ou se determinada métrica havia ultrapassado um limite deixou de ser suficiente.

Mas existe um risco quando uma ideia importante ganha rapidamente espaço no mercado.

Ela pode acabar sendo reduzida à ferramenta utilizada para implementá-la.

Tenho observado isso acontecer com a observabilidade. Em algumas conversas, a pergunta “sua empresa possui observabilidade?” acaba sendo respondida simplesmente com o nome de uma plataforma.

A resposta pode fazer sentido do ponto de vista tecnológico, mas deixa de lado uma questão muito mais importante.

A organização consegue utilizar as informações disponíveis para compreender, com rapidez, como seus serviços realmente estão se comportando?

Essa diferença é fundamental.

Observabilidade não deveria ser tratada apenas como uma nova geração de ferramentas. Ela representa uma mudança na maneira como enxergamos os ambientes de tecnologia. Em vez de perguntar apenas se determinado componente está funcionando, começamos a perguntar por que o serviço está se comportando daquela maneira, quais relações podem explicar esse comportamento e o que isso significa para os usuários e para o negócio.

E, quanto mais complexos se tornam os ambientes, mais importante se torna essa mudança de perspectiva.

Monitorar componentes é diferente de compreender serviços

Imagine uma empresa que disponibiliza uma aplicação crítica para milhares de usuários.

A arquitetura é moderna. A aplicação utiliza microsserviços, APIs, containers e serviços em nuvem. Parte dos dados permanece em infraestrutura própria, enquanto outros componentes são executados em provedores externos. Existem mecanismos de autenticação compartilhados, integrações com terceiros e diferentes camadas de rede conectando todo esse ecossistema.

Em determinado momento, os usuários começam a perceber lentidão. A operação detecta rapidamente o problema.

Os servidores estão disponíveis. Os containers continuam ativos. O banco de dados responde. A rede não apresenta uma indisponibilidade generalizada. Ainda assim, a experiência dos usuários piorou significativamente.

Uma abordagem tradicional de monitoramento poderia levar a equipe a verificar componente por componente, procurando algum indicador que estivesse claramente fora dos limites esperados. Em uma arquitetura relativamente simples, esse processo talvez fosse suficiente.

Em ambientes modernos, entretanto, o problema pode estar justamente nas relações entre esses componentes.

Uma API passou a responder alguns segundos mais lentamente. Esse pequeno atraso aumentou o tempo de execução de outro serviço, que começou a acumular requisições. Um microsserviço passou a consumir mais recursos. O número de conexões com o banco aumentou. Outros serviços dependentes começaram a apresentar degradação e, algum tempo depois, os usuários perceberam o impacto.

Nenhum componente necessariamente parou de funcionar. O serviço, porém, deixou de funcionar adequadamente.

Essa diferença ajuda a compreender por que a observabilidade ganhou tanta importância.

Monitoramento tradicional continua sendo indispensável. Precisamos saber se equipamentos estão disponíveis, acompanhar utilização de recursos, identificar desvios e receber alertas quando determinados comportamentos ultrapassam limites definidos.

Mas isso responde principalmente a perguntas que já conhecemos.

A observabilidade amplia essa capacidade ao permitir investigar comportamentos que nem sempre foram previstos antecipadamente. Métricas mostram como determinadas variáveis evoluíram. Logs registram acontecimentos relevantes dentro dos sistemas. Traces permitem acompanhar uma transação enquanto ela percorre diferentes componentes de uma arquitetura distribuída.

Quando essas informações são analisadas em conjunto, começamos a sair de uma visão baseada exclusivamente em componentes para uma compreensão mais próxima do comportamento dos serviços.

Esse é um avanço importante. Mas ele também cria uma nova questão.

Quanto mais profundamente conseguimos observar uma parte do ambiente, mais evidente se torna que muitos incidentes relevantes não respeitam os limites de uma única plataforma, tecnologia ou equipe.

Vamos voltar ao exemplo.

Depois de algum tempo investigando a degradação da aplicação, a equipe responsável pela observabilidade percebe que determinado serviço começou a apresentar aumento no tempo de resposta aproximadamente às 10h17. Os traces mostram que diversas transações passaram a aguardar mais tempo por uma chamada externa.

Essa é uma informação extremamente valiosa. Mas ainda não explica por que isso começou a acontecer. A resposta pode estar em outra fonte.

Talvez uma alteração de rota tenha ocorrido alguns minutos antes em um componente de rede. Talvez um serviço externo tenha iniciado uma degradação. Talvez uma política de segurança tenha sido modificada. Talvez uma nova versão de algum componente tenha sido implantada. Ou talvez a origem esteja em um elemento da infraestrutura que sequer faça parte do universo observado pela mesma plataforma.

A observabilidade ajudou a aproximar a equipe do problema.

O contexto completo do incidente, porém, pode continuar distribuído pelo ambiente. Essa distinção será cada vez mais importante.

Profundidade de observação e amplitude de contexto não são a mesma coisa.

Uma plataforma pode oferecer uma visão extraordinariamente profunda de aplicações, infraestrutura ou experiência digital e, ainda assim, possuir apenas uma parte das evidências necessárias para explicar um incidente que atravessa diferentes domínios tecnológicos.

Não existe contradição nisso. Existe complementaridade.

Quanto mais ferramentas enxergam o ambiente, maior o desafio de conectar as perspectivas

Essa talvez seja uma das ironias das operações modernas.

Investimos durante anos para ampliar nossa capacidade de enxergar a infraestrutura e os serviços. Criamos especialização, implantamos ferramentas melhores e aumentamos significativamente a quantidade e a qualidade dos dados disponíveis.

E fomos bem-sucedidos.

Hoje uma grande operação pode utilizar plataformas específicas para infraestrutura, aplicações, redes, experiência digital, logs, segurança, cloud, containers, ITSM e diversos outros domínios. Cada uma dessas soluções pode ser excelente no problema que se propõe a resolver.

O resultado, porém, é que um mesmo incidente passa a ser observado simultaneamente por muitas perspectivas.

Considere novamente a degradação da aplicação.

A plataforma de observabilidade identifica aumento no tempo de resposta de determinados serviços. O monitoramento de rede registra crescimento de latência em alguns enlaces. O ambiente de cloud informa alteração no comportamento de determinadas instâncias. O sistema de experiência digital mostra aumento no tempo necessário para concluir uma jornada. O ITSM começa a registrar chamados dos usuários. Os logs apresentam erros que não existiam antes e uma plataforma de automação possui o registro de uma alteração realizada pouco antes do início do incidente.

Separadamente, cada uma dessas informações conta uma história. Juntas, podem contar outra.

É exatamente nesse ponto que o conceito de contexto operacional, discutido no artigo anterior, volta a ganhar importância.

O desafio já não está apenas em obter informações detalhadas. Está em correlacionar informações provenientes de múltiplas fontes para compreender como elas se relacionam.

No exemplo, saber que uma aplicação ficou lenta é importante. Saber que a latência de rede aumentou no mesmo período também é importante. Descobrir que houve uma alteração de configuração alguns minutos antes acrescenta outra evidência. Identificar que todas as aplicações afetadas dependem do mesmo caminho de comunicação começa a reduzir significativamente o universo de hipóteses.

Nenhuma dessas informações, isoladamente, precisa revelar a causa. É a relação entre elas que começa a explicar o incidente.

Isso muda também a forma como devemos pensar sobre o volume de dados.

Durante algum tempo, parecia razoável imaginar que quanto mais dados uma operação coletasse, maior seria sua capacidade de compreender os problemas.

Na prática, existe um limite para essa lógica.

Mais métricas podem significar mais visibilidade, mas também mais informação para interpretar. Mais logs aumentam a capacidade de investigação, mas podem gerar milhões de registros durante poucos minutos de operação. Mais ferramentas especializadas ampliam a profundidade da análise, mas também criam novas fontes que precisam ser consultadas e relacionadas durante um incidente.

O desafio passa gradualmente da coleta para a interpretação. É possível perceber isso claramente nas chamadas war rooms.

Quando ocorre um incidente crítico, diferentes especialistas são reunidos porque cada um conhece profundamente uma parte do ambiente. A equipe de aplicações consulta sua plataforma. Infraestrutura verifica seus indicadores. Rede analisa seus eventos. O time de banco de dados procura anormalidades. Segurança verifica alterações. O Service Desk informa o comportamento dos chamados.

Todos possuem dados.

A reunião existe justamente porque o contexto ainda precisa ser construído.

As pessoas começam a comparar horários, procurar dependências, descartar hipóteses e reconstruir a sequência dos acontecimentos. Muitas vezes, uma informação que parecia pouco relevante em uma ferramenta passa a ser decisiva quando comparada com um evento observado em outra.

Esse processo pode funcionar muito bem, principalmente quando existem profissionais experientes envolvidos. Mas ele também revela uma limitação importante.

Quanto maior o número de fontes e maior o volume de informações produzido por elas, mais difícil se torna construir esse contexto manualmente na velocidade exigida pelo negócio.

Esse não é um problema causado pelas ferramentas. É uma consequência natural da complexidade.

Por isso, acredito que a evolução da observabilidade precisa ser acompanhada por uma evolução igualmente importante na maneira como integramos e interpretamos aquilo que observamos.

Observabilidade precisa levar a entendimento, não apenas a mais dados

É nesse ponto que, na minha percepção, observabilidade deixa de ser apenas uma discussão tecnológica e passa a ser uma discussão sobre a própria forma de operar.

Uma organização pode adquirir uma excelente plataforma de observabilidade e continuar trabalhando de maneira fragmentada.

Pode possuir traces extremamente detalhados, mas analisá-los separadamente dos eventos de infraestrutura.

Pode coletar milhões de logs, mas não relacioná-los automaticamente com mudanças recentes.

Pode conhecer profundamente o comportamento de uma aplicação e, ainda assim, levar muito tempo para descobrir que a origem de sua degradação estava em um componente externo.

A tecnologia cria a possibilidade de compreender melhor. A operação precisa transformar essa possibilidade em capacidade real de decisão.

Isso exige uma mudança de perspectiva.

Em vez de organizar a investigação apenas em torno das ferramentas, precisamos organizá-la em torno do incidente. Parece uma diferença pequena, mas não é.

Quando a investigação começa pela ferramenta, cada equipe pergunta: “o que minha plataforma está mostrando?”.

Quando começa pelo incidente, a pergunta passa a ser: “quais informações, independentemente de onde estejam, ajudam a explicar o que está acontecendo?”.

Essa segunda pergunta naturalmente atravessa fronteiras.

Ela pode exigir dados de observabilidade, monitoramento, rede, cloud, ITSM, experiência digital, topologia, mudanças, automação ou qualquer outra fonte relevante para aquele incidente.

Nesse modelo, nenhuma plataforma perde importância. Ao contrário.

Quanto melhores forem as informações produzidas por cada uma delas, melhor será o contexto que a operação poderá construir.

Essa é uma distinção importante porque existe uma tendência natural de imaginar a evolução tecnológica como uma sucessão de substituições.

Uma ferramenta nova substitui a anterior. Uma nova categoria torna a anterior obsoleta. Uma plataforma mais abrangente elimina a necessidade das demais.

A realidade das grandes operações costuma ser diferente.

Ambientes complexos acumulam tecnologias porque diferentes problemas exigem diferentes níveis de especialização. Uma ferramenta de observabilidade pode conviver com monitoramento de infraestrutura, ITSM, soluções de rede, experiência digital e plataformas específicas de fabricantes porque cada uma possui uma função importante.

A questão deixa de ser qual delas possui toda a verdade. Provavelmente nenhuma possui.

A pergunta mais relevante passa a ser como transformar as diferentes perspectivas produzidas por esse ecossistema em uma compreensão compartilhada do incidente.

Essa mudança também ajuda a explicar por que algumas organizações, mesmo utilizando plataformas semelhantes, apresentam níveis muito diferentes de eficiência operacional.

A diferença pode não estar na quantidade de dados coletados nem na sofisticação das ferramentas.

Pode estar na velocidade com que conseguem conectar as informações disponíveis e transformá-las em contexto.

Voltemos uma última vez ao incidente da aplicação.

Imagine duas empresas com arquiteturas semelhantes e praticamente as mesmas ferramentas.

Nas duas, a observabilidade detecta rapidamente a degradação.

Na primeira, cada equipe inicia sua própria investigação. Aplicações analisa traces. Rede verifica latência. Infraestrutura acompanha recursos. Service Desk consolida chamados. Uma reunião é criada e, durante os quarenta minutos seguintes, os especialistas comparam informações até perceberem que uma mudança realizada na rede pouco antes do incidente alterou o comportamento de um caminho utilizado por vários serviços.

Na segunda empresa, essas mesmas informações são relacionadas desde os primeiros minutos. O aumento do tempo de resposta é associado temporalmente à mudança. Os serviços afetados compartilham a mesma dependência. Os eventos de rede aparecem dentro da mesma janela temporal e os chamados dos usuários confirmam o impacto.

As duas empresas possuíam praticamente os mesmos dados. As duas detectaram o problema. As duas tinham profissionais qualificados.

O que mudou foi o tempo necessário para transformar informações dispersas em entendimento.

Essa diferença pode representar dezenas de minutos de indisponibilidade, centenas de usuários afetados e, dependendo do serviço, impactos financeiros significativos.

É por isso que acredito que a discussão sobre observabilidade precisa avançar.

O próximo salto não virá simplesmente da capacidade de coletar ainda mais dados. Virá da capacidade de utilizar melhor aquilo que já conseguimos observar.

Isso significa combinar profundidade com amplitude. Precisamos enxergar profundamente o comportamento dos componentes, mas também compreender as relações que atravessam diferentes tecnologias, plataformas e domínios operacionais.

Em outras palavras, observabilidade gera ainda mais valor quando deixa de ser uma ilha de informação e passa a contribuir para a construção de um contexto operacional mais amplo.

Essa visão também muda a pergunta que gestores deveriam fazer ao avaliar a maturidade de suas operações.

Talvez não seja suficiente perguntar:

“Temos observabilidade?”

Uma pergunta mais interessante seria:

“Quando ocorre um incidente crítico, conseguimos conectar rapidamente aquilo que nossas diferentes plataformas estão nos dizendo?”

A resposta revela muito mais sobre a capacidade real da operação.

No próximo artigo da série, “MTTR começa antes da resolução do incidente”, pretendo avançar exatamente sobre essa questão. Vamos analisar quanto do tempo total de um incidente é realmente gasto corrigindo o problema e quanto é consumido tentando compreendê-lo, localizar sua origem, mobilizar as equipes corretas e decidir qual ação deve ser tomada.

Porque reduzir o MTTR talvez dependa menos de executar a solução mais rapidamente e muito mais de chegar mais cedo à decisão correta.

Para refletir

Ao observar sua operação, vale analisar se observabilidade representa apenas uma nova fonte de informações ou se realmente mudou a maneira como os incidentes são compreendidos.

Quando uma aplicação apresenta degradação, as equipes conseguem relacionar rapidamente os dados de observabilidade com eventos de infraestrutura, rede, ITSM, experiência digital, mudanças e outras fontes relevantes?

Durante um incidente crítico, os profissionais trabalham sobre uma visão compartilhada do problema ou cada equipe continua investigando principalmente aquilo que sua própria plataforma consegue enxergar?

E, talvez a pergunta mais importante: quando todas essas ferramentas produzem informações ao mesmo tempo, quem constrói o contexto que permite compreender o incidente como um todo?

As respostas podem revelar que o próximo passo da observabilidade não está necessariamente em observar mais.

Pode estar em conectar melhor aquilo que já conseguimos enxergar.

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, com foco no aumento da eficiência operacional e da confiabilidade dos serviços.

Como parte dessa experiência, desenvolveu o ARGUS, uma plataforma de AIOps que complementa as ferramentas já utilizadas pelas organizações e atua como uma camada de inteligência contextual sobre o ecossistema operacional existente.

O ARGUS não parte da premissa de que uma organização precisa substituir suas plataformas de monitoramento, observabilidade ou ITSM. Parte da premissa de que existe muito valor ainda disperso entre elas.

Por meio da integração e correlação de informações provenientes de múltiplas fontes, o ARGUS combina eventos, alarmes, dados de observabilidade, relacionamentos entre componentes, topologia, mudanças, histórico e outras evidências disponíveis no ambiente para construir contexto operacional praticamente em tempo real.

Com isso, informações que antes precisavam ser analisadas separadamente podem ser relacionadas dentro de uma visão comum do incidente, ajudando as equipes a reduzir o ruído operacional, identificar sintomas relacionados, compreender dependências e acelerar a investigação da causa provável.

O objetivo não é substituir a profundidade das ferramentas especializadas. É conectar as perspectivas produzidas por elas, aproveitando os investimentos que a organização já realizou e transformando informações dispersas em contexto para decisões mais rápidas e seguras.

Conheça mais em ARGUS AIOps.