Quando pensamos em “observabilidade”, a maioria de nós a define como “métricas, registros e rastreamentos”. Não é. O que realmente queremos dizer é enriquecer e observar esses conjuntos de dados predefinidos e, em seguida, colocar a análise sobre eles para medir e compreender melhor os principais indicadores de desempenho (KPIs) de negócios – de forma proativa.
Em outras palavras, observabilidade não envolve apenas coletar e classificar conjuntos de dados. Não se trata apenas de alertas, correlações e tempo de atividade. Observabilidade significa permitir que cada engenheiro, especialmente fora do DevOps, priorize proativamente os esforços de trabalho com base na análise de dados de todos os seus sistemas e aplicativos.
E esses dados vão muito além de métricas, logs e rastreamentos.
Precisamos conectar esses três sinais aos verdadeiros impulsionadores da nossa empresa – os KPIs de negócios. Isso requer mudar a forma como nossas equipes operam. Em vez de se concentrarem em simulações de incêndio e KPIs técnicos, devem trabalhar apenas naquilo que proporciona o maior valor de negócio, seja o aumento da receita, a melhoria da experiência do utilizador final ou a redução da rotatividade. Mais fácil falar do que fazer.
Vamos abordar como chegamos ao estado atual de observabilidade e onde precisamos repensar nossa abordagem no futuro.
Antigamente, o objetivo era observar os dados que chegavam de vários aplicativos, sejam eles hospedados em servidores dedicados, na nuvem ou em dispositivos do usuário final (móveis e web). Pense em um fluxo de dados que poderíamos observar à medida que ele fluía.
Usamos agentes para integrar e coletar dados com mais facilidade; no entanto, eles nunca coletaram todos os dados, apenas alguns tipos durante períodos de tempo específicos. Imagine um riacho com uma represa no topo que escorria o fluxo e periodicamente deixava passar gotas específicas de água. Vendo esse riacho, só víamos o que a barragem deixava passar e queria que víssemos.
Essa abordagem APM fez com que fôssemos muito reativos. Instrumentamos logs de erros e métricas para coletar mais informações, procuramos falhas e basicamente confiamos em nossos fornecedores para decidir quais dados deveriam ser transmitidos. Perdemos a visão completa de nossos sistemas e, quando víamos um erro ou uma métrica de tendência estranha, muitas vezes não tínhamos os dados contextuais circundantes para resolvê-lo — pelo menos dentro de um prazo razoável.
Deixamos os problemas passarem despercebidos e, em vez disso, focamos nos problemas mais facilmente solucionáveis, como erros de rede. Inadvertidamente, fechamos os olhos para os problemas que realmente afetavam nossos KPIs de negócios.
É compreensível que fizemos isso porque responder às seguintes perguntas com os tipos de dados limitados das soluções APM estava longe de ser trivial:
O que queríamos saber não era: “Essas questões estavam abaixo de um determinado limite?” Foi: “Estávamos impedindo os clientes de se envolverem com sucesso com nosso negócio?”
Como solução potencial, nos perguntamos: “E se não fizéssemos amostras e, em vez disso, deixássemos passar todos os dados?” E se rompermos a barragem?” A promessa desta pergunta era atraente e definitivamente melhor do que nossos APMs anteriores (e ainda existentes) baseados em agentes.
E então abrimos a barragem.
Com tamanho dilúvio de dados, a complexidade tornou-se enorme, por isso manipulamos esse fluxo de dados não estruturados em formas que entendemos — métricas, logs e rastreamentos. Era muito melhor e mais fácil de usar do que a metodologia APM anterior. Poderíamos identificar melhor erros e métricas de tendências estranhas; poderíamos instrumentar menos nosso código em cada versão; poderíamos detectar problemas mais rapidamente; e tínhamos a esperança de possuir mais dados contextuais para uma resolução mais rápida.
Mesmo assim, à medida que transferimos todos os nossos dados para os familiares três pilares da observabilidade, voltamos aos velhos hábitos. Surgiram bancos de dados e serviços que atendiam aos diferentes pilares, e criamos fluxos de trabalho que muitas vezes eram excessivamente tendenciosos para um dos pilares, em vez de pensar no resultado coeso que os três pilares poderiam fornecer em conjunto.
Quando um engenheiro resolveu um problema – ou mesmo entendeu se valia a pena investir recursos para resolvê-lo – ele geralmente começava com uma abordagem que estava vinculada a um dos três pilares. Eles então tiveram que fazer conexões ou consultas complexas com os outros dois pilares, que poderiam ser sintetizadas em um registro de atividades. Este trabalho normalmente acabou não sendo trivial, sem conexão suficiente fornecida pelas ferramentas para vincular efetivamente os três pilares separados.
E assim estávamos de volta a um lugar – embora com mais dados – não muito distante de onde estávamos com o paradigma APM.
EUTambém ficou dolorosamente claro que mais dados não resolveriam inerentemente todos os problemas. Até certo ponto, apenas substituímos problemas antigos por novos. Tínhamos mais dados para resolver problemas, mas isso frequentemente levava a uma maior expansão do painel, em vez de destilar os dados em informações úteis.
Nossas equipes construíram sistemas que coletavam dados não estruturados, mas não conseguimos aproveitar todo o seu potencial.
E, portanto, nossas equipes de engenharia ainda são reativas e se concentram em Apdex, SLOs e SLAs – e não em verdadeiros KPIs que impulsionam os negócios.
O que deveria ser a observabilidade
Todos nós nos encontramos numa busca contínua por identificação e resolução cada vez mais rápidas, mas o que realmente queremos é mudar para um paradigma de sermos “proativos”. Afinal de contas, se nos concentrarmos apenas em resolver problemas mais rapidamente – equiparando falsamente proatividade com velocidade – estaremos sempre respondendo a simulações de incêndio com base em KPIs técnicos. Claro, seremos mais rápidos nisso, mas não tomaremos as melhores decisões para o nosso negócio.
“Proatividade” significa executar todos os esforços de engenharia com base em indicadores antecedentes das principais métricas de negócios. Indicadores que mapeiam fluxos de compra, tempos de inicialização, abandono de usuários – os KPIs específicos de nossos aplicativos que refletem o que interessa ao nosso negócio, como rotatividade, receita e LTVs.
Esses indicadores antecedentes devem ser específicos para o nosso negócio e, em última análise, devem conectar-se com o usuário final dos nossos aplicativos. E, portanto, o verdadeiro objetivo de qualquer estrutura de dados que tenhamos é que ela reflita a experiência do usuário final – e não métricas e KPIs de back-end míopes e desconectados. Qualquer coisa menos e não poderemos conectar falhas técnicas a falhas de negócios – e definitivamente não sem enormes quantidades de trabalho e suposições.
Afinal, os aplicativos não são um back-end. Não basta se preocupar se uma chamada de rede falha ou se um processo é interrompido. Os aplicativos também não são apenas um frontend. Não basta se preocupar se um aplicativo móvel trava ou um site congela. Observabilidade significa compreender tudo o que o usuário individual experimenta.
Específico para a forma atual de observabilidade, a proatividade não se trata de indicadores antecedentes baseados em nossos logs, métricas e rastreamentos. Em vez disso, proatividade consiste em procurar indicadores antecedentes com base em nossos usuários e, em seguida, usar métricas, registros, rastreamentos e outros tipos de dados para entender onde nosso aplicativo está falhando, por que os indicadores conectados ao usuário estão apresentando tendências incorretas e o que precisa ser feito para resolver problemas.
Então, quando analisamos nossas métricas de back-end, nossos dados revelam quando um usuário final tem uma experiência ruim? Nosso conjunto de fornecedores de observabilidade mede o impacto posterior de experiências interrompidas e perda de receita?
Infelizmente, a resposta agora é: não.
Sabemos onde a observabilidade precisa ir. Compreender o estado dos nossos sistemas é apenas o primeiro passo. A próxima etapa é compreender o estado de nossas experiências de usuário. Dessa forma, tomamos decisões com base em KPIs de negócios, em vez de decisões meramente técnicas.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
