Quando há uma grande interrupção nos sistemas ou um problema de desempenho, as equipes de TI vêm ao resgate para restaurar os serviços o mais rápido possível. Algumas organizações de TI seguem práticas de gerenciamento de incidentes de gerenciamento de serviços de TI (ITSM) para restaurar o serviço e, em seguida, seguem procedimentos de gerenciamento de problemas para realizar análise de causa raiz (RCA). Organizações mais avançadas podem empregar engenheiros de confiabilidade de site (SREs) envolvidos no gerenciamento de incidentes e problemas, mas sua principal responsabilidade é conduzir medidas mais proativas para reduzir as taxas de erros e melhorar os objetivos de nível de serviço.
Embora grande parte das operações de TI tenda a se concentrar em incidentes graves, como interrupções, problemas de desempenho perturbadores e ataques à segurança, um dos desafios mais difíceis é encontrar a causa raiz por trás de problemas esporádicos e do tipo agulha no palheiro. Esses problemas são raros, afetam um pequeno subconjunto de usuários ou duram muito pouco. No entanto, podem ser muito prejudiciais para os negócios se ocorrerem durante operações críticas executadas por utilizadores finais importantes.
aqui estão alguns exemplos:
- Um usuário cria uma pesquisa complexa em um site ou consulta de banco de dados que acumula recursos do sistema e afunila todas as outras atividades de pesquisa.
- Uma transação bloqueia recursos do sistema e só cria um problema de desempenho quando vários usuários realizam a mesma transação simultaneamente.
- Um cabo, placa de rede ou outro dispositivo com defeito cria perda de pacotes, mas o impacto só é sentido pelos usuários finais durante períodos de pico de uso.
- A duração de um procedimento de backup de banco de dados aumenta à medida que os dados crescem, criando problemas de desempenho apenas para um subconjunto de usuários finais.
- Um serviço de terceiros tem tempos de resposta mais lentos que o normal e degrada o desempenho de aplicativos dependentes.
“Reduzir problemas difíceis de desempenho de aplicativos requer um ciclo funcional de depuração e feedback”, diz Liz Fong-Jones, CTO de campo da Honeycomb. “Problemas simples e rápidos muitas vezes resultam em um pico em uma única consulta pré-agregada em um painel, mas qualquer problema mais complicado do que isso é, por definição, um “desconhecido desconhecido” que não foi visto ou antecipado anteriormente pelo desenvolvedor em o momento em que escreveram o código.”
Encontrando a causa raiz de problemas esporádicos de desempenho
Como desenvolvedor na minha juventude e mais tarde como CIO, enfrentei muitos problemas de agulha no palheiro, e encontrar a causa raiz pode ser demorado e sujeito a erros.
Às vezes, o desafio é descobrir a causa raiz do excesso de dados, um problema que as plataformas AIops podem ajudar a resolver. Outras vezes, há dados faltantes, problemas de qualidade de dados ou conjuntos de dados que precisam ser unidos. Geoff Hixon, vice-presidente de engenharia de soluções da Lakeside Software, afirma: “Os problemas de desempenho de aplicativos nem sempre são fáceis de encontrar e corrigir, especialmente com lacunas nos dados que podem causar pontos cegos na verdadeira causa raiz”.
Como realizar análise de causa raiz (RCA)
O que é necessário é um processo que SREs, desenvolvedores e engenheiros operacionais de TI possam seguir para realizar a RCA em problemas que são mais difíceis de encontrar. Proponho quatro passos:
- Gerencie a observabilidade como um produto
- Planeje análises de cima para baixo e de baixo para cima
- Determine se é um problema de rede
- Colabore e triangule as causas raízes
Etapa 1: Gerencie a observabilidade como um produto
Em meu livro Digital Trailblazer, conto várias histórias sobre como corrigir problemas de desempenho usando observabilidade. “É fácil para as pessoas perseguirem os coelhos brancos e tomarem outros rumos errados, e os dados de observabilidade devem ajudar a orientar as equipes nas áreas de foco ideais.”
Uma prática recomendada de Devops é melhorar a observabilidade de microsserviços, pipelines de dados, aplicativos e outros softwares desenvolvidos internamente. O desafio para muitas organizações é criar e melhorar padrões de dados para que a consistência melhore a facilidade de uso quando a RCA for necessária.
Nick Heudecker, diretor sênior de estratégia de mercado e inteligência competitiva da Cribl, recomenda levar a padronização um passo adiante e tratar os logs de aplicativos como um produto de dados projetado para ser consumido pelas operações de TI. “O fator mais importante na identificação de problemas de desempenho de aplicativos é garantir que a telemetria proveniente dos aplicativos possa ser usada por sistemas downstream. Isso significa estruturar logs, enriquecê-los com o contexto certo e entregá-los às plataformas relevantes. Parece simples, mas o desafio é que os desenvolvedores que produzem os logs muitas vezes não são as pessoas que os utilizam no lado operacional.”
A padronização dos dados de observabilidade é uma forma de produzir a observabilidade e simplificá-la para necessidades operacionais. Outras práticas recomendadas para observabilidade de devops incluem consultoria com gerenciamento de riscos sobre dados confidenciais e políticas de retenção de dados. As equipes Devops também devem tomar medidas para educar os SREs e as pessoas que trabalham na rede e nos centros de operações de segurança (NOCs e SOCs) para conectar o que o software faz com a forma como os dados de observabilidade são representados em arquivos de log e outros repositórios.
Para grandes organizações que desenvolvem muitas aplicações e microsserviços, os padrões de observabilidade devem ser combinados com automação, ferramentas analíticas e modelos para facilitar a análise da causa raiz.
“Uma mudança para uma mentalidade de análise de dados mais direcionada e em tempo real na prática de observabilidade de uma empresa permite que os engenheiros consultem proativamente os dados e obtenham os insights necessários para resolver os problemas de desempenho de aplicativos mais desconcertantes”, afirma Asaf Yigal, cofundador e CTO de Logz.io. “Para chegar à causa raiz e resolver problemas críticos de desempenho de sistemas modernos com muitos microsserviços, é necessária uma solução mais eficiente que elimine os dados usando automação e permita uma resposta proativa em vez de reativa.”
É importante ter uma mentalidade de melhoria contínua e uma estratégia de lançamento incremental de acordo com os padrões de observabilidade. À medida que NOCs, SOCs e SREs encontram novos problemas, as equipes Devops devem usar o feedback para melhorar a coleta de dados.
Etapa 2: Planeje a análise de cima para baixo e de baixo para cima
É relativamente fácil encontrar uma consulta lenta com arquivos de log básicos do banco de dados. A identificação das causas principais torna-se mais complexa quando o desempenho da consulta só diminui quando o banco de dados está sob carga e várias consultas competem pelos mesmos recursos do sistema.
Grant Fritchey, defensor de devops da Redgate Software, compartilha um exemplo de consulta que estava sendo executada rapidamente, cerca de 6 ms em média. “Do ponto de vista da medição de desempenho, era uma consulta sem importância, até que você viu as contagens de execução e percebeu que a consulta era chamada milhares de vezes por minuto. Mesmo aos 6ms, não estava funcionando rápido o suficiente. Isso ressalta a necessidade de integrar ferramentas de observabilidade e monitoramento de banco de dados para alcançar uma compreensão holística e diferenciada do desempenho do sistema.”
A RCA eficaz requer ferramentas de monitoramento para fazer mais do que alertas básicos de interrupções ou desempenho importante. As operações e SREs precisam de indicadores quando o desempenho está fora da norma e de ferramentas de análise de cima para baixo para detalhar transações e atividades suspeitas. As ferramentas também devem ajudar a identificar valores atípicos de desempenho, especialmente para atividades de alto volume e baixo desempenho. As melhores ferramentas também ajudam a isolar as experiências do usuário final, de modo que, quando há uma chamada de suporte ao cliente sobre um problema, as operações tenham ferramentas para realizar uma RCA para esse usuário.
Etapa 3: determinar se é um problema de rede
É mais fácil para as equipes Devops apontarem problemas na rede e na infraestrutura como a causa raiz de um problema de desempenho, especialmente quando estes são de responsabilidade de um fornecedor ou outro departamento. Essa resposta instintiva era um problema significativo antes que as organizações adaptassem a cultura Devops e reconhecessem que a agilidade e a resiliência operacional são responsabilidade de todos.
“O vilão quando há problemas de desempenho de aplicativos é quase sempre a rede, e é sempre a primeira coisa que culpamos, mas também a coisa mais difícil de provar”, diz Nicolas Vibert da Isovalent. “O nativo da nuvem e as múltiplas camadas de virtualização e abstração de rede causadas pela conteinerização tornam ainda mais difícil correlacionar a rede como a causa raiz do problema.”
Identificar e resolver problemas complexos de rede pode ser mais desafiador ao criar microsserviços, aplicativos que se conectam a sistemas de terceiros, fluxos de dados de IoT e outros sistemas distribuídos em tempo real. Essa complexidade significa que as operações de TI precisam monitorar redes, correlacioná-las a problemas de desempenho de aplicativos e realizar RCAs de rede com mais eficiência.
“O monitoramento integrado de pacotes em ambientes virtualizados nos caminhos de tráfego norte-sul e leste-oeste fornece insights consistentes e em tempo real sobre o tráfego e o desempenho dos aplicativos”, afirma Eileen Haggerty, vice-presidente executiva de marketing de produtos e soluções da NETSCOUT. “Mas cada domínio e local deve ter o mesmo nível de análise, inteligência e visibilidade, independentemente de onde as cargas de trabalho, aplicativos e serviços estejam em execução. Uma abordagem de medição consistente em todos os ambientes de hospedagem permite uma determinação mais fácil e rápida da causa raiz e da localização dos problemas de desempenho para aplicativos em qualquer infraestrutura de rede.”
Etapa 4: Colaborar e triangular as causas raízes
Duas outras recomendações centram-se na forma como as equipas colaboram para resolver incidentes e realizar análises de causa raiz. Liderei mais do que o meu quinhão de chamadas de ponte e salas para encontrar e corrigir problemas, o que pode ser um mal necessário durante uma grande interrupção. No entanto, essas abordagens são muito menos eficazes na solução de problemas esporádicos de desempenho que exigem a correlação de dados de diversas ferramentas e fontes de dados de observabilidade. Muitas destas questões exigem uma equipa interdisciplinar para colaborar, partilhar conhecimentos e trabalhar em conjunto de forma eficiente quando é necessária uma RCA.
“Observei uma notável ausência de documentação de aplicação e comunicação limitada entre equipes em muitas organizações maiores e bem estabelecidas”, diz Chris Hendrich, CTO associado da SADA. “Destruir esses silos desarticulados pode ajudar as empresas a melhorar sua capacidade de conduzir análises de causa raiz.”
A segunda fala de como as equipes buscam as causas raízes. Fong-Jones, da Honeycomb, diz: “Não é necessário pular diretamente para a agulha no palheiro, apenas para ser capaz de restringir as partes do palheiro onde a agulha está ou não, até que você a encontre. Mas as ferramentas podem ajudar a gerar perguntas que o ajudarão a filtrar o palheiro.”
Todas as organizações de TI enfrentam problemas de desempenho difíceis de resolver. As equipes que colaboram, compartilham informações, criam padrões de observabilidade e desenvolvem experiência no uso de ferramentas de monitoramento podem diminuir o estresse, reduzir o tempo e melhorar a precisão de suas RCAs.
