Justin H

RESUMO

Em 5 de março de 2024, das 19h50 UTC às 22h06 UTC, alguns clientes do Talk podem ter problemas de conectividade, incluindo a incapacidade de fazer, receber ou transferir chamadas. 

 

Linha do tempo

21:36 UTC | 13:36 PT

Estamos investigando relatórios de problemas de conectividade do Talk, incluindo a incapacidade de fazer, receber ou transferir chamadas. Próxima atualização em 15 minutos ou quando tivermos mais informações.

22:06 UTC | 14:06 PT

Nossos engenheiros continuam investigando relatórios de problemas de conectividade do Talk, incluindo a incapacidade de fazer, receber ou transferir chamadas. Próxima atualização em 30 minutos ou quando tivermos mais informações.

22:32 UTC | 14:32 PT

Nossa investigação continua sobre os problemas relacionados ao Talk que resultam na incapacidade de fazer, receber ou transferir chamadas. Próxima atualização em 1 hora ou quando tivermos novas informações para compartilhar.

23:31 UTC | 15:31 PT

Nossos engenheiros reverteram uma alteração e estamos vendo alguma recuperação do nosso lado. Continuaremos a monitorar o desempenho nas próximas 24 horas e forneceremos uma atualização nesse momento.

6 de março - 10:59 UTC | 02:59 PT

A funcionalidade do Talk foi totalmente restaurada e seu funcionamento normal foi confirmado pelo feedback dos clientes e nosso monitoramento interno. Agradecemos sua paciência durante esse período. Esse incidente foi resolvido.

 

POST-MORTEM

Análise da causa raiz

Esse incidente parece ter sido causado por um problema de provedor de serviços de Internet local para alguns clientes nos EUA.

Resolução

Para corrigir esse problema, inicialmente revertemos uma alteração recente do Talk; no entanto, nossa investigação aponta para uma interrupção do ISP que se alinha com mais precisão à janela de impacto.

Itens de correção

1. Melhore o monitoramento e os alertas sobre falhas de chamadas feitas.
2. Trabalhe com nosso provedor para ajustar os limites de alerta para que possamos ser notificados mais rapidamente em situações semelhantes.
3. Melhore os runbooks de solução de problemas para avaliar o escopo com mais precisão.

 

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, registre um ticket conosco por mensagens do ZBot no Widget.

RESUMO

Em 5 de março de 2024, das 15h30 UTC às 18h25 UTC, os clientes do Sunshine Conversations em todos os pods que usam canais de conversas por redes sociais podem ter sofrido uma interrupção significativa no serviço devido a uma interrupção na Meta. Essa interrupção afetou principalmente o WhatsApp, com impactos substanciais também no Facebook Messenger e no Instagram, levando a uma interrupção parcial no tráfego de saída por esses canais.

Linha do tempo

16:30 UTC | 08:30 PT
Confirmamos um problema que afeta todos os canais de conversas por redes sociais da Meta, incluindo Facebook, Messenger, WhatsApp e Instagram. Forneceremos outra atualização quando nosso provedor parceiro tiver resolvido o comportamento.

17:51 UTC | 09:51 PT
Estamos começando a ver a recuperação do problema que afeta o uso de todos os canais de conversas por redes sociais da Meta. Continuaremos a trabalhar com nosso provedor parceiro e monitorar a situação até a resolução completa.

19:15 UTC | 11:15 PT
Temos o prazer de informar que o problema que causava atrasos nas mensagens recebidas e enviadas em todos os canais de conversas por redes sociais da Meta foi resolvido e esses canais estão processando as mensagens conforme o esperado no momento. Agradecemos sua paciência enquanto trabalhávamos com nosso fornecedor parceiro.

 

POST-MORTEM

Análise da causa raiz

Esse incidente foi causado por um problema com os serviços da Meta, afetando especificamente a API do WhatsApp Cloud. A causa raiz exata não foi divulgada pela Meta, mas eles reconheceram a interrupção e trabalharam na restauração dos serviços. Durante esse período, os sistemas de monitoramento do Sunshine Conversations detectaram uma alta ocorrência de erros ao tentar enviar mensagens pelos canais afetados.

Resolução

A resolução da interrupção dependia totalmente dos esforços de recuperação da Meta. O Sunshine Conversations monitorou a situação de perto e forneceu atualizações aos clientes assim que elas ficaram disponíveis. Depois que a Meta anunciou que os serviços foram restaurados, o Sunshine Conversations verificou que o tráfego de saída voltou aos níveis normais e que as mensagens estavam sendo entregues com êxito pelos canais de conversas por redes sociais.

Itens de correção

1. Melhore o monitoramento da integridade do tráfego de saída.
2. Revise e atualize o plano de resposta a incidentes para incluir canais de comunicação alternativos com a Meta caso o portal de suporte principal esteja indisponível.

 

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, registre um ticket conosco por mensagens do ZBot no Widget.

RESUMO

POST-MORTEM

Análise da causa raiz

Esse incidente foi causado por um defeito de escape, no qual o serviço de processamento de eventos gerava erros ao tentar analisar eventos do webhook com um valor nulo em seus metadados.

Resolução

Para corrigir esse problema, a lógica do código foi atualizada para que valores nulos em objetos de metadados sejam aceitos.  Continuamos monitorando a situação e confirmamos nos registros que os erros no pod 26 não estavam mais ocorrendo após essa alteração.

Itens de correção

1. Atualizar a documentação pública do Sunshine Conversation para aceitar valores nulos em objetos de metadados [Programado]
2. Inclusão de alertas de monitoramento adicionais para esses erros [Concluído]

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, registre um ticket conosco por mensagens do ZBot no Widget.

RESUMO

Em 28 de novembro de 2023, das 13h14 UTC às 17h14 UTC, os clientes do Zendesk Talk em vários pods perceberam que o ícone do Talk/telefone desapareceu, com alguns clientes vendo relatórios do Explore mostrando números altos de chamadas perdidas. 

Linha do tempo

POST-MORTEM

Análise da causa raiz

Esse incidente foi causado por uma correção de software que continha um defeito não visível durante o processo de teste.  Essa correção envolvia uma variável que nem sempre estava disponível durante o carregamento da atividade de voz, fazendo com que o carregamento falhasse e o ícone de chamada não aparecesse em situações em que os agentes tinham aplicativos de terceiros instalados.

Resolução

Para corrigir esse problema, fizemos uma reversão para a versão anterior do software e recebemos a confirmação da recuperação.

Itens de correção

1. Adição de um cenário de teste para verificar o carregamento do ícone de chamada quando aplicativos de terceiros estão presentes. [Programado]
2. Adição de monitores e alertas quando a atividade de voz falhar. [Programado]

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, registre um ticket conosco por mensagens do ZBot no Widget.

RESUMO

Em 16 de novembro de 2023, das 18h02 UTC às 20h UTC, alguns clientes do Support nos pods 13, 17, 19, 23, 28 e 29 encontraram atrasos ou uma interrupção total no recebimento de emails recebidos. As durações do atraso variaram de 15 a 60 minutos entre o envio de emails e a criação de tickets no Zendesk por meio de serviços gerenciados pelo Google.

Linha do tempo

18:53 UTC | 10:53 PT
Estamos investigando relatórios de e-mails recebidos que não foram processados para clientes nos pods 28 e 29. Forneceremos informações adicionais em breve.

18:57 UTC | 10:57 PT
Confirmamos um problema que está causando atrasos no processamento de e-mails recebidos para clientes nos pods 13, 19, 23, 28 e 29. Nossa equipe está investigando e forneceremos mais atualizações assim que estiverem disponíveis.

19:33 UTC | 11:33 PT
Nossa equipe continua investigando o problema que causa atrasos no processamento de e-mails recebidos nos pods 13, 17, 19, 23, 28 e 29. Estamos trabalhando diligentemente para mitigar o impacto e compartilharemos novas informações assim que possível.

19:54 UTC | 11:54 PT
Estamos começando a ver melhorias no problema que causa atrasos no processamento de e-mails recebidos nos pods 13, 17, 19, 23, 28 e 29. Nossa equipe continuará monitorando para garantir a recuperação total. 

21:14 UTC | 13:14 PT
Resolvemos o problema que causa atrasos nos e-mails recebidos para os clientes nos pods 13, 17, 19, 23, 28 e 29, e os e-mails recebidos estão sendo processados conforme o esperado no momento. Agradecemos sua paciência durante nossa investigação.

 

POST-MORTEM

Análise da causa raiz

Esse incidente foi causado pelo fato de o serviço Coletor de e-mail ter problemas de conectividade com o Gmail, interrompendo o processamento de e-mails recebidos no Support, onde as respostas 302 do Gmail foram interpretadas como falhas pela investigação de atividade, indicando ao orquestrador de contêiner que os pods não estavam íntegros. Isso levou o orquestrador a substituir os pods e interromper o processamento de e-mails nos contêineres associados, causando atrasos ou interrupções nos e-mails recebidos.

Resolução

Para corrigir esse problema, o tráfego de e-mails recebidos foi restaurado depois que o Gmail parou de bloquear essas verificações de integridade, permitindo que os e-mails recebidos do Support concluíssem a criação de seus pods e começassem a processar e-mails novamente. Não muito tempo depois, as filas de e-mails recebidos se recuperaram e o tráfego começou a fluir normalmente.

Itens de correção

1. Melhore as ferramentas de implementação existentes para verificações de integridade de email. 
2. Crie alertas adicionais. 
3. Adicione linhas de código de correção em aplicativos específicos.

 

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, registre um ticket conosco por mensagens do ZBot no Widget.

Hey shelley,

I suspect that this could be achieved using a custom attribute to filter out tickets with singular engagements. 

Hello Oanh Chau, 

You should be able to make a report like this in the Support: Tickets Dataset. The screenshot below is a bare bones idea of what metrics and attributes you would need to use: 

The Test Tag Inclusion metric I have here uses the following formula to display only solved tickets with the tags you specify: 

IF (([Ticket status - Unsorted] = "Solved" OR [Ticket status - Unsorted] = "Closed")) 
AND (INCLUDES_ANY([Ticket tags], "your_tag_here"))
THEN [Ticket ID]
ENDIF

You would need to make two custom metrics for your Large and Super Large tags, so they will show as separate columns in your report. 

Hey Bobby Koch, 

The backlog snapshots occur at midnight daily. To view the most current totals for outstanding tickets, we recommend using the Tickets dataset. 

Hey Joel Sandi, 

To answer your first question, you should be able to report on ticket information with an Explore Report using the Guide: Knowledge Capture dataset. There is a set of attributes categorized as "ticket" that allow you to look closer at ticket data from the Knowledge Capture App. 

As for your second question, the articles linked per ticket metric, as well as all the metrics under the "Knowledge Capture" Dashboard tab, are meant to gauge performance metrics of the Knowledge Capture application, primarily. From a business value perspective, the articles linked per ticket metric could show pain points for your staff in your Knowledge Base. I would assume that ideally, you would want this number to be as close to 1 as possible (1 article for each ticket). 

Hey Jacqui, 

Are you using bookmarks to capture the desired time range in this dashboard?