À medida que as organizações adotam microsserviços e arquiteturas em contêineres, elas frequentemente percebem que precisam repensar sua abordagem para tarefas operacionais básicas, como segurança ou observabilidade. Faz sentido: em um mundo onde os desenvolvedores — em vez de equipes de operações — estão mantendo os aplicativos ativos e funcionando, e onde os sistemas são altamente distribuídos, efêmeros e interconectados, como você pode adotar a mesma abordagem que adotou no passado?
De uma perspectiva tecnológica, houve uma mudança clara para padrões de código aberto, especialmente no reino da observabilidade. Protocolos como OpenTelemetry e Prometheus, e agentes como Fluent Bit , agora são a norma — de acordo com a pesquisa CNCF de 2023 , o uso do Prometheus aumentou para 57% de adoção em cargas de trabalho de produção, com OpenTelemetry e Fluent ambos com 32% de adoção em produção.
Mas ferramentas de código aberto sozinhas não podem ajudar as organizações a transformar suas práticas de observabilidade. Como tive a oportunidade de trabalhar com organizações que resolveram o desafio da observabilidade em escala, vi algumas tendências comuns em como essas empresas operam suas práticas de observabilidade. Vamos nos aprofundar.
Meça a si mesmo — Defina metas inteligentes com objetivos de nível de serviço
Os Objetivos de Nível de Serviço foram introduzidos pela primeira vez pelo livro Google SRE em 2016 com grande alarde. Mas descobri que muitas organizações não os entendem verdadeiramente, e ainda menos os implementaram. Isso é lamentável porque eles são secretamente uma das melhores maneiras de prever falhas.
SLOs (Service Level Objectives) são metas específicas que mostram o quão bem um serviço deve ser executado, como almejar 99,9% de tempo de atividade. SLIs (Service Level Indicators) são as medições reais usadas para ver se os SLOs são atendidos — pense em rastrear a porcentagem de solicitações bem-sucedidas.
O orçamento de erros é o processo de permitir uma certa quantidade de erros ou tempo de inatividade dentro dos SLOs, o que ajuda as equipes a equilibrar a confiabilidade e os novos recursos — isso garante que elas não forcem demais, correndo o risco de tornar as coisas instáveis. Ter SLOs em seus principais serviços e usar o orçamento de erros permite que você identifique problemas iminentes e aja sobre eles.
Uma das organizações mais maduras que vi praticando SLOs é a Doordash. Para eles, os bifes são altos (trocadilho intencional). Se eles têm alta queima de SLO para um serviço, isso pode levar um comerciante a não receber um pedido de comida na hora certa, ou de forma alguma. Ou pode levar um consumidor a não receber sua refeição na hora certa ou a ter erros no aplicativo.
Começar com SLOs não precisa ser assustador. Minha colega escreveu recentemente suas dicas sobre como começar com SLOs . Ela aconselha manter os SLOs práticos e atingíveis, começando com as metas que realmente encantam os clientes.
Comece pequeno, definindo um SLO para uma jornada de usuário-chave. Colabore com SREs e usuários empresariais para definir metas realistas. Seja flexível e ajuste os SLOs conforme seu sistema evolui.
Abrace os eventos — a única constante em seu ambiente nativo da nuvem é a mudança
No DevOps, as coisas estão sempre mudando. Estamos constantemente enviando novos códigos, ativando e desativando recursos, atualizando nossa infraestrutura e muito mais. Isso é ótimo para inovação e agilidade, mas também introduz mudanças, o que abre a porta para erros. Além disso, o mundo fora dos nossos sistemas também está sempre mudando, desde a hora do dia até o que está acontecendo nas notícias. Tudo isso pode dificultar manter tudo funcionando perfeitamente.
Esses eventos cotidianos que resultam em mudanças são as causas mais comuns de problemas em sistemas de produção. E o desafio é que essas mudanças são iniciadas por muitos tipos diferentes de sistemas, desde gerenciamento de sinalizadores de recursos até CI/CD, infraestrutura de nuvem, segurança e muito mais.
Curiosamente, 67% das organizações não têm a capacidade de identificar mudanças em seus ambientes que causaram problemas de desempenho, de acordo com o Digital Enterprise Journal . A única maneira de ficar por dentro de todas essas mudanças é conectá-las a um hub central para rastreá-las. Quando as pessoas falam sobre "eventos" como um quarto tipo de telemetria, fora de métricas, logs e rastreamentos, isso é normalmente o que elas querem dizer.
Uma organização que vi fazer isso muito bem é a Dandy Dental. Eles descobriram que a capacidade de entender a mudança em seu sistema e correlacioná-la rapidamente com as mudanças no comportamento tornou a depuração muito mais rápida para os desenvolvedores. Criar o hábito de entender o que mudou permitiu que a Dandy melhorasse sua eficácia de observabilidade.
Adote a solução de problemas orientada por hipóteses — permita que qualquer desenvolvedor corrija problemas mais rapidamente
Quando um desenvolvedor começa a solucionar um problema, ele começa com uma hipótese. Seu objetivo é provar ou refutar rapidamente essa hipótese. Quanto mais contexto ele tiver sobre o problema, mais rápido ele poderá formar uma boa hipótese para testar. Se ele tiver várias hipóteses, precisará testar cada uma em ordem de probabilidade para determinar qual é a culpada. Quanto mais rápido um desenvolvedor puder provar ou refutar uma hipótese, mais rápido ele poderá resolver o problema.
Os desenvolvedores usam ferramentas de observabilidade para formar suas hipóteses iniciais e para prová-las/refutá-las. Uma boa ferramenta de observabilidade dará ao desenvolvedor o contexto de que ele precisa para formar uma hipótese provável. Uma ótima ferramenta de observabilidade tornará o mais fácil possível para um desenvolvedor com qualquer nível de especialização ou familiaridade com o serviço formar rapidamente uma hipótese provável e testá-la.
Organizações que desejam melhorar seu MTTR podem começar reduzindo o tempo para criar uma hipótese. Ferramentas que fornecem ao desenvolvedor de plantão alertas altamente contextuais que o focam imediatamente nas informações relevantes podem ajudar a reduzir esse tempo.
A outra vantagem de adotar explicitamente uma abordagem de solução de problemas baseada em hipóteses é a simultaneidade. Se o problema for de alta gravidade ou tiver complexidade significativa, eles podem precisar chamar mais desenvolvedores para ajudá-los a provar ou refutar cada hipótese simultaneamente para acelerar o tempo de solução de problemas. Uma empresa de software de IA com a qual trabalhamos usa solução de problemas baseada em hipóteses.
Recentemente, ouvi uma história sobre como eles estavam investigando uma alta taxa de erros em um serviço e usaram sua ferramenta de observabilidade para reduzi-la a duas hipóteses. Em 10 minutos, eles provaram que sua primeira hipótese estava correta — que os erros estavam todos ocorrendo em uma única região que havia perdido a implantação de software mais recente.
Dando o próximo passo
Se você está comprometido em levar sua prática de observabilidade para o próximo nível, esses hábitos testados e comprovados podem ajudar você a dar os primeiros passos. Comece definindo SLOs para seus principais serviços, adote uma mentalidade de eventos para entender as mudanças em seu ambiente e permita que seus desenvolvedores resolvam problemas de forma mais eficiente com uma abordagem baseada em hipóteses. Com essas práticas em vigor, sua organização estará bem a caminho de uma observabilidade madura e eficaz.
