Este guia é uma introdução para melhorar sua habilidade em diagnosticar problemas que impactam os clientes. Você poderá se recuperar de problemas de desempenho do aplicativo mais rapidamente seguindo os procedimentos deste guia.
Este guia faz parte de nossa série sobre maturidade de observabilidade.
Pré-requisitos
Aqui estão alguns requisitos e algumas recomendações para usar este guia:
Cobertura de observabilidade da New Relic:
- Required : APM com distributed tracing, logs contextualizados de APM e agente de infraestrutura
- Recomendado: log e Monitoramento de rede (NPM)
Required: gerenciamento a nível de serviço
Recomendado: alguma experiência com o uso New Relic APM, distributed tracing, consultas NRQL e interface
Recomendado: você leu estes guias:
Visão geral
Antes de começar a usar este guia, ele o ajudará a entender o que aprenderá. Este guia ajudará você a entender:
Como seu negócio é impactado ao melhorar suas habilidades de diagnóstico.
Os principais indicadores de desempenho operacionais usados para medir o sucesso.
Como seu usuário final percebe diferentes tipos de problemas de confiabilidade.
A diferença entre a causa direta e a causa raiz subjacente de um problema.
As etapas básicas de diagnóstico para encontrar e resolver problemas, que incluem:
- Definindo o problema - criando uma declaração do problema
- Encontrando a origem do problema
- Encontrando a causa direta desse problema
Algumas categorias de problemas de desempenho (desempenho de saída, desempenho de entrada e desempenho do cliente) e o recurso New Relic utilizado para diagnosticar esses problemas (APM, Sintético, e monitoramento de Mobile).
Como usar uma matriz de problemas, que é uma folha de dicas para compreender problemas comuns e suas prováveis fontes.
No final, revisaremos alguns exemplos de problemas de desempenho, que devem ajudá-lo a entender melhor esses conceitos.
Resultados desejados
Resumo
O valor para o negócio é:
- Reduzir o número de incidentes que perturbam os negócios
- Reduza o tempo necessário para resolver problemas (MTTR)
- Reduza o custo operacional do incidente
O valor para as operações de TI e SRE é:
- Melhore o tempo para entender e resolver
Resultado de business
Em 2014, o Gartner estimou que o custo médio do período de inatividade de TI foi de US$ 5.600 por minuto. O custo cumulativo do incidente que impacta os negócios é determinado por fatores como tempo para saber, frequência, tempo para reparo, impacto na receita e o número de engenheiros que fazem a triagem e resolvem o incidente. Simplificando, você deseja menos incidentes com impacto nos negócios, menor duração dos incidentes e diagnósticos mais rápidos, com menos pessoas necessárias para resolver os impactos no desempenho.
Em última análise, o objetivo do negócio é maximizar o tempo de operação e minimizar o período de inatividade onde o custo do período de inatividade é:
Downtime minutes x Cost per minute = Downtime cost
O período de inatividade é determinado pelo número de incidentes que perturbam os negócios e pela sua duração. O custo do período de inatividade inclui muitos fatores, mas os mais diretamente mensuráveis são os custos operacionais e a perda de receitas.
A empresa deve promover uma redução no seguinte:
- número de incidentes que perturbam os negócios
- custo operacional do incidente
Resultado operacional
O resultado operacional necessário é manter a conformidade dos objetivos de nível de serviço da camada de produto. Você faz isso diagnosticando níveis de serviço degradados, comunicando seu diagnóstico e realizando uma resolução rápida. Mas degradações e incidentes inesperados sempre acontecem e você precisa responder de forma rápida e eficaz.
Em outros guias desta série, nos concentramos em melhorar time to know. Em nosso guia de gerenciamento de qualidade de alerta, nos concentramos em reactive maneiras de melhorar o tempo de conhecimento, e em nosso guia de gerenciamento a nível de serviço, nos concentramos em proactive métodos.
No guia que você está lendo agora, nos concentramos em melhorar time to understand e time to resolve.
Principais indicadores de desempenho - operacionais
Existem muitas métricas discutidas e debatidas no mundo da “gestão de incidentes” e da teoria SRE; contudo, a maioria concorda que é importante concentrar-se num pequeno conjunto de principais indicadores de desempenho.
Os KPIs abaixo são os indicadores mais comuns usados por práticas bem-sucedidas de SRE e gestão de incidentes.
Percepção de confiabilidade do usuário final
A forma como os clientes percebem o desempenho do seu produto é fundamental para entender como medir a urgência e a prioridade. Além disso, compreender a perspectiva dos clientes ajuda a compreender como o negócio vê o problema, bem como a compreender o fluxo de trabalho necessário para suportar as capacidades impactadas. Depois de entender a percepção dos clientes e do negócio, você poderá entender melhor o que pode estar impactando a confiabilidade dessas capacidades.
Em última análise, a observabilidade da perspectiva do cliente é o primeiro passo para se tornar proativo e proficiente em engenharia de confiabilidade.
Existem duas experiências principais que impactam a percepção do usuário final sobre o desempenho do seu produto digital e seus recursos. Os termos abaixo são da perspectiva dos clientes, usando a linguagem comum dos clientes.
Causa raiz vs causa direta
A causa raiz de um problema não é a mesma que a causa direta desse problema. Da mesma forma, corrigir a causa direta (curto prazo) geralmente não significa que você corrigiu a causa raiz (longo prazo) do problema. It's very important to make this distinction.
Ao procurar um problema de desempenho, você deve primeiro tentar encontrar a causa direta do problema fazendo a pergunta “O que mudou?”. O componente ou comportamento que mudou geralmente não é a causa raiz, mas é na verdade a causa direta que você precisa resolver primeiro. Resolver a causa raiz é importante, mas geralmente requer uma discussão retroativa pós-incidente e um gerenciamento de problemas de longo prazo.
Por exemplo: o nível de serviço da sua capacidade de login cai repentinamente. É imediatamente descoberto que os padrões de tráfego são muito mais elevados do que o normal. Você trace o problema de desempenho até uma configuração de limite de conexão TCP aberta que está causando uma fila de conexão TCP muito maior. Você resolve o problema imediatamente implantando um aumento de limite de TCP e alguma instância extra de servidor. Você resolveu a causa direta do problema no curto prazo, mas a causa raiz pode ser qualquer coisa, desde planejamento de capacidade inadequado, falta de comunicação do marketing ou uma implantação relacionada com consequências indesejadas nas cargas upstream.
Essa distinção também é feita em ITIL/ITSM Incident management versus Problem management. As causas profundas são discutidas em negociações pós-incidente e depois resolvidas em processos de gestão de problemas de longo prazo.
Etapas de diagnóstico (visão geral)
Etapa 1: Defina o problema
A primeira regra é estabelecer rapidamente a definição do problema. Existem muitos guias sobre como criar declarações de problemas, mas simples e eficazes são o melhor. Uma declaração de problema bem formada fará o seguinte:
- Descreva o que o usuário final está enfrentando. Qual é o problema que o usuário final está enfrentando?
- Descreva o comportamento esperado da capacidade do produto. O que o usuário final deve experimentar?
- Descreva o comportamento atual da capacidade do produto. Qual é a avaliação técnica do que o usuário está vivenciando?
Evite quaisquer suposições na declaração do problema. Atenha-se aos fatos.
Etapa 2: Encontre a fonte
A “fonte” é o componente ou código que está mais próximo da causa direta do problema.
Pense em muitos canos de água conectados através de muitas junções, divisores e válvulas. Você está alertado que seu nível de serviço de saída de água está degradado. Você trace o problema desde a saída de água através dos canos até determinar qual junção, divisão, válvula ou tubo está causando o problema. Você descobre que uma das válvulas elétricas está em curto. Essa válvula é a fonte do seu problema. O curto é a causa direta do seu problema. Você resolve facilmente a causa direta substituindo o valor. Tenha em mente que a causa raiz pode ser algo mais complexo, como condições climáticas, produtos químicos na água ou fabricação.
Este é o mesmo conceito para diagnosticar pilha complexa de tecnologia. Se a sua capacidade de login for limitada (saída), você deverá trace o problema até o componente (fonte) que está causando esse limite e corrigi-lo. Pode ser o software API (limite de serviço), os serviços de middleware, o banco de dados, restrições de recursos, um serviço de terceiros ou qualquer outra coisa.
Em TI, existem três categorias principais de pontos de interrupção para melhorar seu ritmo de resposta:
Output
Input
Client
Definir sua métrica de desempenho dentro dessas categorias, também conhecida como nível de serviço, melhorará significativamente seu tempo de resposta para determinar onde está a origem do problema. A medição dessas categorias é abordada em nosso guia de gerenciamento a nível de serviço. Para entender como usá-los em diagnósticos, continue lendo.
Etapa 3: Encontre a causa direta
Quando estiver perto da origem do problema, determine o que mudou. Isso o ajudará a determinar rapidamente como resolver o problema imediatamente no curto prazo. No exemplo da Etapa 2, a mudança foi que a válvula não estava mais funcionando devido ao hardware degradado causando um curto-circuito.
Exemplos de mudanças comuns em TI são:
- Taxas de transferência (tráfego)
- Código (implantação)
- Recursos (alocação de hardware)
- Mudanças de dependência upstream ou downstream
- Volume de dados
Para outros exemplos comuns de problemas que afetam o desempenho, consulte a matriz de problemas abaixo.
Use pontos de dados de saúde
Conforme mencionado anteriormente, existem três categorias principais de desempenho que impulsionam sua jornada de diagnóstico. Compreender esses pontos de dados de saúde reduzirá significativamente o seu tempo para entender onde está a origem do problema.
Matriz do problema
A matriz de problemas é uma folha de referências de problemas comuns categorizados pelos três pontos de dados de saúde.
As fontes dos problemas são organizadas de acordo com sua frequência, sendo as mais comuns na linha superior e à esquerda. Uma análise mais detalhada está listada abaixo. gerenciar um nível de serviço bem feito irá ajudá-lo a descartar rapidamente dois desses três pontos de dados.
Esta tabela é uma matriz de problemas classificada por ponto de dados de saúde:
| Ponto de dados | Capacidade New Relic | Fontes comuns de problemas | | ---------- | --------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Saída | APM, infra, log, NPM | aplicativo, fontes de dados, alteração de configuração de hardware, infraestrutura, rede interna, provedor terceirizado (AWS, GCP) | | Entrada | Sintético, log | Roteamento externo (CDN, gateways, etc.), roteamento interno, coisas na internet (ISP, etc.) | | Cliente | navegador, celular | código do navegador ou celular |
Os problemas tendem a ser agravados, mas o objetivo é “encontrar a fonte” e então determinar “o que mudou” para restaurar rapidamente o nível de serviço.
Problemas de exemplo
Vejamos um exemplo de problema. Digamos que sua empresa implante um novo produto, e o aumento significativo de solicitações provoque um tempo de resposta inaceitável. A origem é descoberta no serviço de middleware de login. O problema é um salto nos tempos de fila TCP.
Aqui está um resumo desta situação:
- Category: desempenho de saída
- Source: middleware de login
- Direct cause: tempos de fila TCP de carga de solicitação adicional
- Solution: aumento do limite de conexão TCP e recursos escalonados
- Root-cause: planejamento de capacidade e testes de garantia de qualidade insuficientes no serviço downstream, afetando o middleware de login
Outro exemplo de problema
Aqui está outro exemplo de problema:
- Houve um aumento repentino de 500 erros de gateway no login...
- O tempo de resposta da API de login aumentou até o ponto em que o tempo limite começou...
- Os tempos limite foram rastreados para as conexões de banco de dados na camada de middleware...
- Trace da transação revelou aumento significativo no número de consultas ao banco de dados por solicitação de login...
- Foi encontrado um marcador de implantação para uma implantação que ocorreu logo antes do problema.
Aqui está um resumo desta situação:
- Category: degradação do desempenho de saída levando à falha no desempenho de entrada
- Source: banco de dados de chamada de serviço de middleware
- Direct cause: Aumento de 10x na consulta ao banco de dados após implantação do código
- Solution: reversão de implantação
- Root-cause: testes de garantia de qualidade insuficientes
Matriz do problema por fonte
Aqui está uma tabela com a matriz do problema classificada por fontes.
Source | Common direct causes |
|---|---|
Aplicativo |
|
Fonte de dados |
|
Rede interna e roteamento |
|
Identificando anomalia no padrão de desempenho
Dica
Ter um nível de serviço bem formado em seus limites de serviço em relação à transação principal (capacidades) ajudará você a identificar mais rapidamente em qual fluxo de trabalho de ponta a ponta reside o problema.
Identificar anomalias de padrão melhorará sua capacidade de identificar qual e onde pode estar a causa direta dos problemas.
Há muitas informações excelentes e aulas on-line gratuitas sobre identificação de padrões, mas o conceito geral é bastante simples e pode desbloquear poderosas habilidades de diagnóstico.
A chave para identificar padrões e anomalias nos dados de desempenho é que você não precisa saber como o serviço deveria estar funcionando: você só precisa determinar se o comportamento recente mudou.
Os exemplos fornecidos nesta seção usam tempo de resposta ou latência como métrica, mas você pode aplicar a mesma análise a quase qualquer conjunto de dados, como erros, taxas de transferência, métricas de recursos de hardware, profundidade de fila, etc.
Normal
Abaixo está um exemplo de gráfico de tempo de resposta aparentemente volátil (7 dias) no APM. Olhando mais de perto, você pode ver que o comportamento do tempo de resposta é repetitivo. Em outras palavras, não há mudança radical no comportamento durante um período de 7 dias. Os picos são repetitivos e comuns em comparação com o resto da linha do tempo.
Na verdade, se você alterar a visualização dos dados de average over time para percentiles over time, fica ainda mais claro o quão "regulares" são as alterações no tempo de resposta.
Anormal
Este gráfico mostra um tempo de resposta do aplicativo que parece ter aumentado de forma incomum em comparação com o comportamento recente.
Isso pode ser confirmado usando a comparação semana após semana.
Vemos que o padrão mudou e parece estar piorando em relação à comparação da semana passada.
Encontrando a fonte
A seguir, veremos como você encontraria a fonte no New Relic. Observe que esse fluxo de trabalho depende de distributed tracing.
Primeiro, você encontrará um aplicativo relacionado à latência ou aos erros sofridos pelo usuário final. Isso não significa que o aplicativo ou o código seja o problema, mas encontrar qualquer aplicativo dentro do fluxo (first) leva você mais rapidamente para perto da fonte. Depois que esse aplicativo for encontrado, você poderá descartar rapidamente componentes como código, host, banco de dados, configuração e rede.
Uma vez identificado o aplicativo, a questão é quais transações dentro desse aplicativo fazem parte do problema. Use o aplicativo que você identificou como tendo um problema de desempenho e identifique quais transações ou transações foram impactadas. Aqui você pode repetir a habilidade de anomalia de padrão de desempenho descrita acima em Identificar anomalias de padrão de desempenho, mas desta vez na própria transação.
Os documentos a seguir ajudarão você a usar o New Relic para identificar problemas de transação:
- Página de transação: Encontre problemas específicos de desempenho
- Transação lenta na página de resumo do serviço
Depois que as transações problemáticas forem identificadas, você poderá usar distributed tracing para revisar os componentes de ponta a ponta que dão suporte a essa transação. distributed tracing ajuda a identificar rapidamente onde está a latência e/ou onde os erros estão ocorrendo em toda stack, tudo em uma única visualização.
Os recursos a seguir ajudarão você a aprender como usar distributed tracing para identificar o componente de origem do problema:
- Introdução ao distributed tracing
- Como usar a interface distributed tracing
- Webinars on-line gratuitos sobre distributed tracing
- Um vídeo sobre como usar distributed tracing para análise de causa direta
Aqui está um breve resumo das etapas para encontrar a fonte:
- Examine um aplicativo relacionado ao desempenho afetado.
- Identifique quais transações estão contribuindo para o problema.
- Use distributed tracing para identificar o componente do problema no fluxo de ponta a ponta.
Podemos agora passar para a etapa final, identificando a causa direta.
Encontrando a causa direta
Depois que o componente de origem for encontrado, você poderá começar a determinar a causa direta.
Usando o conhecimento das etapas anteriores, você saberá se o problema é latência, sucesso ou ambos.
Problemas de latência podem ser encontrados usando trace da transação e/ou "span em processamento" dentro do trace distribuído.
Problemas de sucesso A mensagem de erro também pode ser vista no rastreamento, mas os melhores detalhes para problemas de sucesso geralmente são encontrados no log do aplicativo.
De qualquer forma, se você for o respondente de incidentes de primeiro nível ou um SRE, encontrar a causa direta caberia aos especialistas no assunto (SMEs), que normalmente são os desenvolvedores e engenheiros responsáveis pelo componente de origem encontrado.
A próxima etapa mais eficaz após descobrir o componente de origem é entrar em contato com os especialistas no assunto desse componente. Mostre a eles os dados descobertos na triagem e no diagnóstico que você concluiu para ter uma vantagem inicial na resolução de problemas.
Dica
Observe que tanto o login no contexto quanto distributed tracing são ativados por padrão com nosso mais novo agente. (Se você não atualiza seu agente há algum tempo, recomendamos atualizá-lo regularmente.)
Log-in-context e distributed tracing são recursos essenciais necessários para reduzir o tempo de triagem, diagnóstico e resolução de problemas a longo prazo.
Agora vá em frente e seja um excelente engenheiro de confiabilidade do site com a New Relic!
Próximos passos
Se ainda não o fez, você pode querer ler alguns de nossos guias de maturidade de observabilidade relacionados, incluindo: