‍

‍

O que é observabilidade?

Observabilidade é entender o quadro completo: há algo que está acontecendo com o cenário de aplicativos que está começando a afetar seus usuários, seus clientes ou sua empresa.

E a observabilidade também é a prática de poder detalhar os dados quando algo assim acontece. Você pode saber o que está acontecendo, corrigi-lo, o que significa consertá-lo rapidamente, e também colocar uma solução de longo prazo para que isso não aconteça novamente.

Muitas organizações fazem monitoramento ou monitoramento de desempenho de aplicativos. Elas monitoram a infraestrutura, monitoram a computação, monitoram a rede; basicamente, analisam as camadas típicas da infraestrutura (veja a figura abaixo).

Queremos levar as empresas a monitorar de fora para dentro; elas estão monitorando principalmente a camada entre a extremidade da TI e a conexão dos usuários, ou onde outras empresas se conectam ao aplicativo.

Olhar a experiência do usuário de dentro para fora também permitiria que as organizações se aprofundassem além da camada de computação, que é onde a maioria das equipes de monitoramento e de operações de TI está fazendo seu monitoramento atualmente. Com uma mentalidade e ferramentas de observabilidade de pilha completa, as equipes também podem se aprofundar até a camada de rede. Isso ajuda as equipes de operações de TI a entender se o problema é a computação, se o problema é a rede ou se é o próprio aplicativo.

Ou ainda mais, é um problema que nem mesmo é meu? É um problema que pode estar fora do meu perímetro por meio de uma API de terceiros, por exemplo.

Mas o importante é que a priorização de problemas e o gerenciamento de KPIs se baseiem em como o problema afeta a experiência do usuário e, portanto, afeta a receita, a satisfação do cliente/ Net Promoter Score ou (dependendo do setor) operações como remessa, logística, fabricação ou usuários internos de software.

Em geral, as organizações têm dificuldades porque há uma área central que fornece as ferramentas e oferece treinamento sobre elas. Mas não há diálogo suficiente sobre "como fazer uma boa observabilidade".

Na Evolutio, temos uma recomendação muito forte sobre como as empresas devem fazer uma boa observabilidade. E isso é realmente focar de fora para dentro.

‍

Como a falta de uma cultura de observabilidade se manifesta atualmente?

O resultado número um que observamos é que a maioria dos usuários e clientes está relatando problemas. E, se um usuário está relatando um problema, há 10 usuários que não estão dizendo nada.

Se eles estão tendo uma interrupção grande e persistente, estão descobrindo tarde. E quando você descobre que está tendo uma interrupção tarde, é muito difícil saber qual é a causa principal.

O Full Stack Observability da Cisco tem uma parte chamada APM (Application Performance Monitoring, monitoramento de desempenho de aplicativos). E apenas com o APM básico, é fácil dizer o que iniciou as coisas, porque a linha do tempo completa de uma interrupção parece uma grande bola de pelos, mas o início de uma interrupção realmente lhe dirá qual era o problema. O APM pode até mesmo apontar os problemas que surgiram em cascata antes do início da interrupção.

Apenas no mundo do APM, ele tem um rápido tempo de retorno do investimento porque, apenas com a instalação dos agentes, as organizações podem olhar no espelho retrovisor e obter respostas.

Qual é a diferença da verdadeira observabilidade? É quando você começa a ter esses indicadores principais que dizem: "Muito bem, equipe, normalmente, quando isso acontece, vamos ter uma interrupção e você vai querer colocar alguém para trabalhar nisso imediatamente e fazer com que eles analisem exatamente esse problema para que possam eliminar a causa raiz e corrigi-lo antes que comece a afetar a maior parte da sua base de clientes."‍

O que descobrimos é que, muitas vezes, as organizações nem sequer chegam a descobrir a causa raiz. O processo para chegar ao problema pode levar cinco dias ou mais. E se suas equipes não encontrarem a causa raiz dentro desses cinco dias, muitas vezes a equipe terá que abandonar a busca.

Quanto à solução de problemas típica, a equipe está examinando diferentes logs de aplicativos para tentar descobrir o que aconteceu. O aplicativo em questão tem várias dependências externas, portanto, como ele reagiu quando uma dependência foi alterada? E quanto a uma segunda dependência? Uma análise bem-sucedida da causa raiz depende muito de você ter o tipo certo de registro e de ferramentas. E, muitas vezes, quando as equipes de solução de problemas encontram algo que parece errado, elas imediatamente atribuem a causa a esse motivo. E, muitas vezes, esse não é o motivo (ou o motivo completo).

E é por isso, meus leitores, que as organizações têm interrupções persistentes: porque acham que encontraram a causa principal, e o problema tem todas as características que poderiam ter sido a causa principal, e as equipes atribuem tudo a isso, apenas para descobrir mais tarde que não era a causa principal, porque o problema volta a ocorrer.

Por que a AppDynamics é a melhor solução de observabilidade do mercado?

Somos parceiros da AppDynamics porque acreditamos que ela é a melhor plataforma de observabilidade para atingir os objetivos que acabei de expor. Seus recursos de análise são muito flexíveis e permitem que os operadores de TI e os usuários corporativos segmentem os dados de forma significativa para a correção e a tomada de decisões comerciais.

Digamos que você tenha vários usuários entrando e aproveitando uma plataforma, e você pode ver que tipo de cliente ou usuário é afetado, de que região eles vêm, o que exatamente eles estão fazendo e como essas peças que, no back-end, não parecem conectadas porque não estão conectadas por um fio, mas na verdade fazem parte de um processo comercial completo.

Tomando como exemplo uma experiência de comércio eletrônico, um processo comercial completo (ou transação comercial) para um usuário é ter a capacidade de fazer um pedido com cartão de crédito, porque muitas vezes é assim que as empresas ganham dinheiro. Portanto, para poder fazer o check-out, o usuário precisa fazer o login, ir à página inicial, fazer uma pesquisa eficaz no site, colocar algo no carrinho, clicar em check-out, passar pelo processo de pagamento da conta e receber uma confirmação de que o check-out foi bem-sucedido.

Esse é um processo comercial completo.

Ser capaz de observar e monitorar esse processo comercial completo como um único objeto, mesmo que não esteja conectado por um thread, é algo que o AppDynamics é capaz de fazer de forma única. E essa é realmente a abordagem que adotamos com a maioria de nossos clientes. Obviamente, queremos observar a atividade dos usuários de nossos clientes, mas é nesses processos comerciais importantes que queremos que nossos clientes se concentrem, porque se esses processos comerciais forem interrompidos ou ficarem fora do ar, nossos clientes perderão receita e a satisfação do cliente será prejudicada. Queremos ajudar a implementar processos para evitar isso e uma cultura para avaliar proativamente esses processos de negócios.

‍

Cenário competitivo

O cenário competitivo em que a AppDynamics está inserida é, na verdade, bastante concorrido. Há vários concorrentes que têm boas ofertas para seus clientes.

DataDog e Dynatrace

Um dos que encontramos de tempos em tempos é o DataDogque é uma plataforma extremamente fácil de ser conectada.

É fácil obter métricas de infraestrutura no DataDog. A plataforma tem um grande recurso sintético que, antes de você entrar no monitoramento de APM, aplicativo, monitoramento de desempenho, muitas pessoas começam com o sintético, que é um tráfego falso que basicamente testa seu site para garantir que determinados processos de negócios sejam funcionais.

O que são os sintéticos? Imagine um servidor da Web que esteja no Amazon Web Services e que esteja realmente realizando um processo de checkout. Monitorar esse servidor é uma ótima maneira de verificar se você tem uma interrupção total e completa, mas, na verdade, é uma maneira muito ruim de verificar se uma grande quantidade de usuários de um determinado tipo está tendo uma experiência degradada ou com falhas.

Usando o Application Performance Monitoring e a análise, você pode dizer que esse segmento de usuários ou clientes está sendo afetado e em que nível. O que o Datadog não tem é a capacidade de segmentar usuários com tráfego real, com monitoramento APM real. Portanto, como ele não tem os recursos avançados de análise, ele realmente não pode lhe dar a capacidade de dividir o tráfego que você está vendo de uma forma significativa.

Com o DataDog, um usuário operacional pode dizer: "OK, estamos sofrendo um impacto". No entanto, ele não pode examinar apenas um segmento específico de usuários que está sendo afetado, nem pode ver a porcentagem de usuários que estão sendo afetados pelo evento impactante.

Dynatracepor outro lado, também tem uma interface de plug-in muito fácil de usar. A maneira como você obtém dados no Dynatrace é muito fácil. Ele também tem agentes realmente excelentes para software legado, o que também é um grande ponto forte do app dynamics. Mas, novamente, ele não tem os recursos de análise. Portanto, na minha opinião, muitas das coisas que fazemos para os clientes simplesmente não são possíveis com ele.

A outra diferença entre o Datadog e o AppDynamics é que, no AppDynamics, você faz a maior parte da configuração no back plane, o que significa que você não precisa mexer na ajuda e, portanto, não precisa mexer no código, basta fazer toda a configuração no controlador do AppDynamics e isso é extremamente eficaz.

É um grande sopro de ar fresco e um desvio da forma como as pessoas sempre fizeram monitoramento. Elas fazem logs para fazer logs. É preciso fazer o que se quer, escrever em um arquivo de registro, testar o código, liberar o código e divulgá-lo.

Na verdade, para o DataDog, o cenário é o mesmo. Se você quiser mudar a aparência de algo no DataDog, terá de mudar o código para que isso aconteça. Portanto, é preciso fazer alterações no código, testá-lo e fazer com que ele seja lançado no AppDynamics. Você não precisa fazer isso. Portanto, essa é uma grande vantagem que você tem. Outra coisa que adoramos no AppDynamics é a linha de base e os recursos dinâmicos. Ele é pronto para uso, direto, fácil de usar e está sempre ativo.

Outras plataformas

Em muitas outras plataformas, você precisa fazer configurações dizendo à ferramenta: "Quero essa linha de base, quero que ela seja assim". Agora, essas outras plataformas têm mais dicas e truques que podem ser usados, como o aproveitamento de linhas de base sazonais, e você pode realmente moldar como essas linhas de base funcionarão.

O AppDynamics não tem esses recursos específicos de modelagem de linha de base, mas tem linhas de base simples em todos os lugares.

Exemplos de cenários para observabilidade

1. Grandes transformações: Para os grandes clientes que têm um cenário de TI muito grande, não ter que colocar limites específicos ou configurar uma linha de base para cada ponto de dados que você deseja alertar é uma grande vantagem, pois economiza muito trabalho. Normalmente, o Evolutio é utilizado quando um usuário ou uma empresa está passando por algum tipo de grande transformação. Talvez o cliente esteja trazendo toneladas de novos recursos de aplicativos e novas capacidades para o mercado e tenha feito um grande investimento para implementar as mudanças. Ele não pode falhar.
   ‍
2. Migrar para a nuvem ou migrar para um ambiente diferente: As migrações são um esforço enorme e programático; às vezes, é um projeto de vários anos que não pode falhar. E os grandes projetos têm trabalho árduo. Basicamente, o trabalho árduo é quando as equipes de TI gastam muito tempo solucionando problemas, tentando fazer análises de problemas e lidando com a análise da causa raiz de forma manual e demorada. Quando a Evolutio consulta nossos clientes, muito do que estamos fazendo é tentar evitar o trabalho árduo, evitar que as pessoas gastem tempo fazendo algo que não está direcionando os objetivos de negócios, ou seja, queremos que novos recursos sejam trazidos ao mercado ou queremos ir para a nuvem, ou queremos fazer as duas coisas ao mesmo tempo. Quando ajudamos nossos clientes a reduzir o trabalho, conseguimos realmente causar um enorme impacto na eficácia de uma organização de TI, na qual eles estão desenvolvendo seus novos recursos. Sua estrutura de suporte está realmente capacitada enquanto esses novos recursos estão chegando ao mercado. A experiência que a Evolutio traz para o processo de implementação do AppDynamics é que nós simplesmente entendemos como ajudar as empresas a escalar o esforço com governança e mudança cultural, e elas são mais rápidas... e eu quero dizer anos-luz mais rápidas.

Centro de Excelência: Treinamento do cliente para usar o AppDynamics

Para que uma empresa adote o AppDynamics, ela precisa ser totalmente treinada na ferramenta e entender todos os princípios de observabilidade, como fazer isso exatamente da maneira correta e como treinar suas equipes para fazer isso de forma escalonável. É realmente uma tarefa intransponível.

Mas como fizemos muitas dessas implementações grandes e bem-sucedidas, temos o manual e podemos treinar as equipes quando integramos um aplicativo.

A implementação bem-sucedida é um processo de cinco etapas

E isso é algo sobre o qual fornecemos treinamento em vídeo colateral por meio de nosso Centro de Excelência. Quando terminamos, permitimos que o cliente se aproprie totalmente de um recurso que é suportado pela tecnologia da AppDynamics, e isso está muito mais relacionado a ter o recurso de observabilidade.

O objetivo da Evolutio é garantir que nossos clientes não sintam que algum parceiro de implementação aleatório chegou, simplesmente instalou o AppDynamics, agora ele está funcionando e eles foram embora sem nenhum impacto nos negócios ou mudança cultural na equipe.

Nosso Centro de Excelência está permitindo uma capacidade completa, de ponta a ponta. Está em nosso ethos que a Evolutio equipa a organização para adotar uma cultura em torno da observabilidade.

Por que treinar e viabilizar uma cultura de observabilidade?

Ao planejar um projeto relativamente pequeno, bem planejado e executado, e ao usar apenas uma pequena quantidade de tempo organizacional para organizar e configurar o monitoramento, podemos fazer com que os clientes possam se concentrar em seu trabalho normal do dia a dia, que geralmente é o desenvolvimento de aplicativos, onde estão criando novos recursos ou fazendo uma migração para a nuvem. Assim, eles obtêm o benefício de fazer principalmente o trabalho planejado e as equipes podem permanecer no campo do trabalho do roteiro de transformação digital em vez de fazer simulações de incêndio durante uma interrupção.

Quando ocorre uma interrupção e quando um usuário é afetado, isso é trabalho não planejado. E, muitas vezes, é um problema muito grande, e todos deixam de lado tudo para resolver o problema agora.

Se as organizações entram em um ciclo em que é preciso fazer constantemente esse trabalho não planejado, que equivale a uma labuta, isso realmente tem um impacto psicológico sobre as equipes de TI. Elas nunca atingem seus resultados, nunca atingem suas metas.

E a equipe de TI sente que toda vez que tem uma reunião de sprint ou de burn down para falar sobre o que aconteceu, está dizendo: "o motivo pelo qual não atingi minhas metas é que eu estava fazendo um trabalho muito importante para a empresa, garantindo que essa interrupção fosse resolvida".

Não queremos que nossas equipes estejam nesse estado. Queremos que elas estejam em um estado em que estejam levando as coisas adiante. Elas sentem que estão sendo produtivas nos projetos que iniciam e conseguem concluir. E isso se deve ao fato de não estarem sendo empurrados para fora do roteiro de trabalho planejado por trabalhos forçados e não planejados que consertam interrupções.

‍

O que as equipes de TI da Big Tech e do Google estão fazendo?

Considere como nossa cultura mudou para ser muito mais voltada para a TI e orientada para a TI. Observe a adoção cultural do Facebook, a cultura do Instagram: A geração do milênio e a geração Z, que cresceram com essas plataformas e ferramentas literalmente na ponta dos dedos, sua paciência como usuários para lidar com aplicativos que não funcionam continua a diminuir a cada dia. Uma ação do usuário em um aplicativo que levava 2 segundos em 2013, deveria levar 2 milissegundos em 2022. Eles têm esse nível de sintonia.

Se você é uma companhia aérea e um usuário está tentando comprar uma passagem de avião, ele quer poder comprar a passagem sem problemas, ou ele irá para outro site e comprará a passagem.

Está se tornando cada vez mais obrigatório que as organizações enfrentem esses problemas dos usuários se quiserem ter retenção, se quiserem ter crescimento nos negócios, se quiserem que os novos recursos lançados sejam bem-sucedidos, portanto, isso se torna cada vez mais essencial.

É por isso que vemos iniciativas de observabilidade surgindo. Os líderes de tecnologia decidem: "OK, precisamos de equipes que sejam responsáveis por isso".

Os clientes da Evolutio estão se desenvolvendo em um modelo de Engenharia de Confiabilidade do Site (SRE), que é algo que permitimos que eles façam porque a SRE tem a mentalidade de observabilidade enraizada em toda a linha. A SRE é realmente parte de como eles começam a operar diariamente como equipes de desenvolvimento, incorporando o pensamento de monitoramento como código no início do SDLC.

O manual de engenharia de confiabilidade do site (SRE)

A Evolutio realmente segue o modelo SRE que foi posicionado pelo Google há cerca de três anos.

O que é isso? O modelo de Engenharia de Confiabilidade do Site é aquele em que você tem uma equipe de engenheiros de confiabilidade do site que é realmente mantida unida por um líder que está no topo. A equipe de SRE está, na verdade, integrada às equipes de desenvolvimento de software, mas seu alcance de controle é de dezenas ou centenas de aplicativos. Portanto, um único engenheiro ou analista de SRE pode ter dois, três ou dez aplicativos sob sua alçada. A partir daí, esse SRE estabelece todos os seus padrões e as regras são implementadas pelo SRE Guild.

Com o modelo do Google SRM, as organizações querem se concentrar nos quatro sinais de ouro que o usuário final está recebendo.

Os Quatro Sinais de Ouro são:

1. Quantidade de chamadas que estão passando pelo sistema
2. Tempo médio de resposta (ou tempo de resposta do percentil 95, dependendo do formato dos dados)
3. Número de erros que estão no sistema
4. Taxa de transferência

Pense da seguinte forma: a quantidade de tráfego que está chegando em relação ao que está disponível também é chamada de saturação. Quanto de um determinado pipe está saturado? Quanto de uma determinada plataforma de armazenamento está saturado? Normalmente, o que vemos é que na parte externa, onde o usuário vive, é preciso ter todos os quatro Golden Signals.

Você precisa entender em que ponto está. E, à medida que você desce, às vezes você tem apenas um ou dois desses sinais, porque o número de erros que passam pode não ser um problema.

Mas talvez a saturação seja mais importante se for como uma camada de armazenamento. Portanto, em quatro camadas diferentes da sua pilha de tecnologia, você tem versões diferentes desses sinais, mas é nessas que você quer se concentrar. E temos uma estratégia de alerta padrão que implementamos com nossos clientes quando eles estão implementando o AppDynamics. E isso realmente se concentra nos Quatro Sinais de Ouro em escala padrão para todos os aplicativos que fazemos.

A Evolutio trabalha arduamente com nossos clientes para trazer uma cultura de observabilidade, de modo que, à medida que seus negócios crescem e mudam, a observabilidade esteja imediatamente na plataforma, seja no desenvolvimento, seja nas iniciativas de observabilidade, para que não tenham que fazer uma tonelada de retrabalho no final.

A melhor sensação é quando vejo as organizações terem aquele momento de iluminação: os clientes têm visão de futuro e conseguem enxergar além do horizonte: "Onde estaremos daqui a 3 ou 5 anos?" E eles estão ansiosos para empregar as ferramentas e os KPIs adequadamente hoje para obter os resultados desejados no futuro. Eles começam a dizer coisas como: "Vamos iniciar uma iniciativa de monitoramento como código agora para nos preparar para o sucesso em 36 meses, porque estamos começando a coletar os dados."‍

Adoro quando nossos clientes não só estão equipados para tomar decisões de desempenho no futuro, mas também estão capacitados para tomar decisões sobre como administrar nossos negócios e aproveitar o software para resolver os maiores problemas operacionais que enfrentarão.

‍

‍

A Evolutio pode ajudá-lo com suas iniciativas de Observabilidade e a conduzir a mudança cultural para colocar a Engenharia de Confiabilidade do Site no roteiro de suas equipes. Visite nossa página de contato para entrar em contato e saber mais.