A observabilidade se tornou uma pedra angular das estratégias de engenharia modernas, embora se possa argumentar que nunca chegamos a uma definição unânime. É por isso que essa evolução mais recente — com a "observabilidade 2.0" — é tão emocionante: podemos finalmente alinhar o verdadeiro significado e potencial da observabilidade com seu nome. Vale a pena voltar no tempo para ver como chegamos ao ponto de precisar versionar o nome.
As Raízes da Observabilidade
Com suas raízes na teoria de sistemas de controle , o termo "observabilidade" foi popularizado pela equipe Honeycomb em 2016. Eles expandiram a definição de Rudolf E. Kálmán —"uma medida de quão bem os estados internos de um sistema podem ser inferidos a partir do conhecimento de suas saídas externas"— e a redefiniram para significar "o poder de fazer novas perguntas ao seu sistema, sem ter que enviar um novo código ou coletar novos dados para fazer essas novas perguntas".
Enquanto esse conceito ganhava força, em 2017, Peter Bourgon sugeriu que a observabilidade consiste em "três pilares" — métricas, logs e rastros — uma definição que encontrou forte apoio no setor de ferramentas de monitoramento de desempenho de aplicativos (APM), pois coincidentemente se alinhava perfeitamente com suas ofertas de produtos.
Nos anos subsequentes, esforços valentes foram feitos para esclarecer o verdadeiro escopo da observabilidade, como o livro de Ben Silgelman de 2021, "Desmascarando o mito dos 'três pilares da observabilidade'", no qual ele explicou que "métricas, registros e traços não são "a observabilidade;" eles são apenas a telemetria.
Infelizmente, a tendência de confundir observabilidade com telemetria ou monitoramento persiste, não importa quantos líderes da indústria de tecnologia tentem esclarecer que o monitoramento pode dizer quando algo está errado, mas a observabilidade permite que você entenda o porquê.
Observabilidade 1.0 vs. Observabilidade 2.0
Para simplificar, a observabilidade vai além do monitoramento tradicional e envolve revelar comportamentos do sistema, capacitando equipes a revelar "desconhecidos desconhecidos" e obter uma compreensão completa de sistemas complexos.
Em agosto deste ano, a Charity Majors propôs que nos referíssemos às soluções que se alinham estreitamente com os três pilares e ferramentas de APM como observabilidade 1.0. A observabilidade 2.0 representa um movimento além das estruturas de monitoramento tradicionais e ferramentas de APM e uma mudança na forma como os desenvolvedores abordam a compreensão e a depuração do sistema.
Observabilidade 1.0
Observabilidade 1.0, intimamente ligada às ferramentas APM, refere-se à abordagem tradicional em que grandes quantidades de dados de telemetria (métricas, registros e rastros) são coletados e exibidos com painéis — ou o tão desejado "painel único de vidro".
A Observabilidade 1.0 foca nas operações em seu núcleo: ela destaca problemas conhecidos quando o software está em produção. É útil se você já sabe o que procurar — o "desconhecido conhecido" — mas falhas de produção em sistemas distribuídos complexos são frequentemente não lineares e difíceis de prever, exigindo exploração manual para encontrar a causa raiz de um problema.
Como resultado, os desenvolvedores não gostam de depender de ferramentas de APM para coisas como depuração porque elas fornecem um grande volume de dados agregados em vez das informações específicas que você precisa para resolver o problema. Eles frequentemente sentem como se estivessem procurando uma agulha em um palheiro.
Por exemplo, digamos que você estava monitorando os erros do seu site e de repente viu um pico. Os dashboards do Observability 1.0 irão alertá-lo sobre o problema e ajudá-lo a entender onde, quando e o que, mas você precisa se aprofundar para entender o porquê.
Resumindo, embora a observabilidade 1.0 ainda seja uma ferramenta indispensável para monitorar e gerenciar sistemas distribuídos, ela não aborda totalmente os desafios diários que os desenvolvedores enfrentam, nem os ajuda a entender seus sistemas de forma proativa.
Observabilidade 2.0
Observabilidade 2.0 representa uma mudança de foco além de simplesmente identificar problemas operacionais para capacitar desenvolvedores em todo o ciclo de vida de desenvolvimento de software. É o reconhecimento de que nossa definição de "observabilidade" está evoluindo — ou melhor ainda — finalmente cumprindo a promessa de sua definição original.
Enquanto a Observabilidade 1.0 enfatizava a identificação de incêndios e o monitoramento da saúde do sistema, a observabilidade 2.0 é mais focada no desenvolvedor. Trata-se de abordar as causas raiz dos problemas e reduzir a frequência de incidentes ao incorporar a observabilidade no próprio processo de desenvolvimento — em outras palavras, resolver problemas antes que eles apareçam nos painéis da observabilidade 1.0!
Os dois principais problemas que o Observability 2.0 aborda para os desenvolvedores são:
- Eles precisam de insights precisos, em tempo real e ricos em contexto sobre seus sistemas para que possam depender de uma única fonte de verdade para entender incógnitas desconhecidas.
- Depuração mais rápida, onde os desenvolvedores podem facilmente introspectar ou entender sistemas complexos. Isso é possível porque o bloco de construção da observabilidade 2.0 são os eventos de log, que são mais poderosos, práticos e econômicos do que as métricas (o carro-chefe da observabilidade 1.0), pois preservam o contexto e os relacionamentos entre os dados.
Além disso, a observabilidade 2.0 é construída em padrões abertos como o OpenTelemetry, que permite que os desenvolvedores usem um padrão comum para rastros, logs e métricas.
Adotar um meio aberto e portátil de coletar dados de telemetria não é uma inovação insignificante: ainda me lembro dos dias em que as únicas duas alternativas eram contratar uma grande empresa para coletar dados de telemetria em nossa infraestrutura ou pagar uma pequena fortuna a um fornecedor para implantar seus agentes proprietários para coletar esses dados.
Como a Observabilidade 2.0 Mudará a Experiência do Desenvolvedor
A Developer Experience (DX) molda como os engenheiros percebem seu trabalho, impactando a produtividade, o engajamento, a felicidade e a retenção. Uma DX forte promove um ambiente onde as equipes podem ter o melhor desempenho, enfrentando desafios de forma eficiente e entusiasmada.
Nesse contexto, ter as ferramentas certas para gerenciar a integridade do software tem um grande impacto na DX: uma pesquisa recente da Atlassian revelou que mais de 8 horas por semana podem ser perdidas devido a ineficiências, entre dificuldades com dívidas técnicas, documentação deficiente e ferramentas de depuração insuficientes.
Para melhorar o DX — e, portanto, a capacidade da equipe de fornecer software confiável, escalável e sustentável — a pesquisa identificou três áreas principais:
- Ciclos de feedback: permitem melhorias contínuas por meio de aprendizado e ajustes rápidos.
- Gerenciamento de carga cognitiva: forneça documentação precisa e acessível.
- Estado de fluxo ideal: minimize as interrupções para manter o trabalho profundo.
A Observabilidade 2.0 aborda todas essas três áreas, capacitando os desenvolvedores com maior visibilidade e menos tarefas manuais:
Insights em tempo real e ricos em contexto
Os desenvolvedores obtêm feedback imediato sobre as alterações do sistema, ajudando-os a enviar o código com mais rapidez e confiança. Com a observabilidade 1.0, muitas vezes senti que a depuração é uma escavação arqueológica — descobrindo meticulosamente camada por camada para entender o design do sistema, a arquitetura e as decisões de design antes de identificar a causa raiz do problema. Com a observabilidade 2.0, você obtém visibilidade precisa e em tempo real de todos os componentes e seus relacionamentos e pode facilmente evitar adicionar dívida técnica arquitetônica não intencional com suas alterações.
Trabalho manual reduzido
Usar frameworks de observabilidade como OpenTelemetry para documentação significa que seu sistema em execução permanece consistente com sua documentação sem fazer atualizações manuais. A depuração também se torna mais eficiente com dados ricos em contexto, permitindo que os desenvolvedores diagnostiquem problemas sem vasculhar volumes enormes de dados.
Exemplo Prático: Depuração com Observabilidade 2.0
A Observabilidade 2.0 abre as portas para novos casos de uso e ferramentas que podem resolver os problemas diários dos desenvolvedores e economizar tempo e dores de cabeça significativos.
A depuração tradicional envolve uma abordagem de busca em primeiro lugar: você analisa dados de telemetria, pesquisa em registros e rastros infinitos, faz a correspondência de padrões usando a intuição e confia na experiência, em palpites fundamentados e em um modelo mental (possivelmente desatualizado) do sistema. Você tenta reproduzir o problema, embora isso nem sempre seja possível devido a relatórios vagos e incompletos, caso algum detalhe seja fornecido. Por fim, talvez você também precise navegar por recursos dispersos — documentação, diagramas de arquitetura, registros de decisão, APIs e repositórios — apenas para entender completamente o sistema.
Como eu sugeri, problemas em sistemas complexos e distribuídos raramente são isolados. Entender não apenas o que deu errado, mas também por que e como algo deu errado requer correlacionar dados em várias camadas do sistema, o que consome tempo e é propenso a erro humano.
Sem mencionar que às vezes as equipes são pressionadas a "simplesmente consertar o problema o mais rápido possível" por causa das necessidades e prazos do negócio. Com a observabilidade 1.0, isso pode resultar no tratamento dos "sintomas" de um problema, mas não dos problemas centrais reais.
Com o Observability 2.0, novas ferramentas de desenvolvedor como Multiplayer.app, alavancando OpenTelemetry, permitem depuração em nível de plataforma com replays de sessão profundos. Com um clique, os desenvolvedores podem capturar sessões mostrando etapas para reproduzir um bug, acompanhados por dados de telas de frontend para rastreamentos, métricas e logs profundos de plataforma.
Obter dados e documentação precisos e em tempo real sobre a arquitetura real do seu sistema reduz drasticamente o tempo gasto na solução de problemas e depuração.
