RESUMO
Em junho de 2024, especialmente nos dias 13 e 25 e alguns dias em julho, surgiram vários problemas no Espaço de trabalho do agente do Zendesk Support. Esses incidentes interromperam o fluxo de trabalho dos agentes, dificultando o acesso aos tickets. Os principais problemas encontrados incluíam um erro "Mensagens não encontradas" e um código de erro "A_xxx" ao tentar carregar os tickets. Esses problemas ocorreram principalmente em vários pods em vários dias. Cada pico de interrupção normalmente durava, em média, 2 minutos. Embora os clientes pudessem tentar atualizar o sistema como solução alternativa, eles corriam o risco de perder conversas em andamento no processo.
Linha do tempo
25 de junho de 2024 16h05 UTC | 25 de junho de 2024 09:05 PT
Estamos cientes de um pico de erros que afetaram os clientes em vários pods entre 15h40 e 15h47 UTC em 25 de junho de 2024, o que resultou em respostas "Mensagens não encontradas" e mensagens "Código de erro A_xxx" ao tentar carregar tickets em Support. Nós nos recuperamos desses erros e o problema deve ser resolvido recarregando seu navegador e/ou limpando seu cache e cookies.
POST-MORTEM
Análise da causa raiz
A principal causa desses incidentes foi um aumento inesperado nas solicitações HTTP para o servidor, geralmente em horários de pico de tráfego. Esse pico levou a um efeito de "rebanho trovejante" que sobrecarregou as conexões do servidor do gráfico de agentes, causando falha nas sondagens de prontidão. O Lotus, um componente vital do sistema, foi identificado como desempenhando um papel significativo. Ele sobrecarregava o Ticket Data Manager (TDM) com várias solicitações sempre que era reconectado. Esse aumento no tráfego é atribuído principalmente a assinaturas de estado de conversa que se reconectam após desconexões em massa, aparentemente devido a implantações do Zorg/Nginx e/ou serviço de assinatura.
O TDM é o principal responsável pelo gerenciamento de dados do ticket. Ele organiza e armazena informações quando um ticket é gerado e, em seguida, recupera e apresenta esses dados quando um agente ou cliente precisa acessá-los e atua como o controlador mestre de todos os dados relacionados ao ticket, garantindo operações otimizadas dentro do sistema.
Resolução
Medidas preventivas foram implementadas em resposta a esses problemas. Isso inclui o limitador de taxa de conexão e solicitação, responsável por regular o tráfego de entrada. Ao mesmo tempo, foram tomadas medidas para aumentar a resiliência do gráfico do agente durante falhas de cache. Essa estratégia serviu para evitar interrupções em todo o sistema devido a falhas técnicas inevitáveis, agindo como um gerador de backup durante uma queda de energia. Embora várias mitigações tenham sido implementadas, a correção real que concluiu o incidente de serviço foi uma alteração feita no Lotus. A alteração reduziu o número de cenários em que ocorreria uma nova busca de dados, encerrando posteriormente o efeito manada.
Editado em 25 de julho: Depois de fazer alguns ajustes em 10 de julho para evitar que um acúmulo de solicitações causasse problemas, não vimos mais picos afetando a interface do usuário do ticket. Continuamos a acompanhar de perto as coisas e ficamos satisfeitos ao descobrir que as coisas estavam funcionando bem nos dias seguintes.
Além disso, em relação ao mês anterior, notamos algumas quedas de desempenho em pods específicos às sextas-feiras. No entanto, as coisas estavam melhorando em 12 de julho, o que nos deu mais confiança em nossas alterações. Depois disso, em 15 de julho, não encontramos nenhum aumento ou pico de desempenho, o que nos leva a acreditar que o problema foi resolvido.
Itens de correção
Estratégias adicionais foram planejadas para melhorar ainda mais a estabilidade do sistema e evitar interrupções futuras:
- Alerta para falhas na sondagem de prontidão: Implemente um teste de fumaça para alertar a equipe técnica imediatamente sobre possíveis problemas, permitindo uma ação rápida.
- Consideração de padrões de busca: Aconselhe os desenvolvedores de software a considerarem cuidadosamente o volume e a frequência da recuperação de informações para evitar desequilíbrios no sistema.
- Estabelecimento de uma linha de base de solicitações: Determine a capacidade do sistema de lidar com solicitações simultâneas de informações de ticket para evitar uma falha do sistema.
- Espace as novas buscas: Apresente uma variação de sinal para mitigar efeitos de manada trovejantes.
- Retenção otimizada de assinaturas do Explore: Investigue maneiras de manter as assinaturas com mais eficiência durante as implantações.
PARA OBTER MAIS INFORMAÇÕES
Para obter informações atuais sobre o status do sistema do seu Zendesk, consulte nossa página de status do sistema. O resumo de nossa investigação post mortem geralmente é publicado aqui alguns dias após o término do incidente. Se você tiver mais perguntas sobre esse incidente, entre em contato com o suporte ao cliente Zendesk.
Aviso sobre a tradução: este artigo foi traduzido por um software de tradução automática para oferecer a você uma compreensão básica do conteúdo. Medidas razoáveis foram tomadas para fornecer uma tradução precisa, no entanto, a Zendesk não garante a precisão da tradução.
Em caso de dúvidas relacionadas à precisão das informações contidas no artigo traduzido, consulte a versão oficial do artigo em inglês.