Justin H

RIEPILOGO

Il 5 marzo 2024, dalle 19:50 UTC alle 22:06 UTC, alcuni clienti Talk potrebbero aver riscontrato problemi di connettività, tra cui l’impossibilità di effettuare, ricevere o trasferire chiamate. 

 

Cronologia

21:36 UTC | 13:36 PT

Stiamo esaminando le segnalazioni di problemi di connettività Talk, tra cui l’impossibilità di effettuare, ricevere o trasferire chiamate. Prossimo aggiornamento tra 15 minuti o quando avremo maggiori informazioni.

22:06 UTC | 14:06 PT

I nostri tecnici continuano a indagare sulle segnalazioni di problemi di connettività Talk, inclusa l’impossibilità di effettuare, ricevere o trasferire chiamate. Prossimo aggiornamento tra 30 minuti o quando avremo maggiori informazioni.

22:32 UTC | 14:32 PT

La nostra indagine continua sui problemi relativi a Talk che hanno portato all’impossibilità di effettuare, ricevere o trasferire chiamate. Prossimo aggiornamento tra 1 ora o quando avremo nuove informazioni da condividere.

23:31 UTC | 15:31 PT

I nostri ingegneri hanno annullato una modifica e stiamo assistendo a una ripresa da parte nostra. Continueremo a monitorare le prestazioni nelle prossime 24 ore e forniremo un aggiornamento in quel momento.

6 marzo - 10:59 UTC | 02:59 PT

La funzionalità Talk è stata completamente ripristinata e confermata dal normale funzionamento sia dal feedback dei clienti che dal nostro monitoraggio interno. Apprezziamo la pazienza dimostrata durante questo periodo. Questo incidente è stato risolto.

 

POST-MORTEM

Analisi della causa principale

Questo incidente sembra essere stato causato da un problema con un ISP locale per alcuni clienti negli Stati Uniti.

Soluzione

Per risolvere questo problema, abbiamo inizialmente ripristinato una recente modifica di Talk; tuttavia, la nostra indagine indica un'interruzione dell'ISP che si allinea in modo più accurato alla finestra di impatto.

Elementi correttivi

1. Migliora il monitoraggio e gli avvisi in caso di chiamate in uscita non riuscite.
2. Collabora con il nostro provider per modificare le soglie di avviso in modo da poter ricevere notifiche più rapidamente in situazioni simili.
3. Migliora i runbook per la risoluzione dei problemi per valutare più accuratamente l’ambito.

 

PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk, consulta la nostra pagina sullo stato del sistema. Di solito, il riepilogo della nostra indagine post mortem viene pubblicato qui pochi giorni dopo la fine dell’incidente. Per ulteriori domande su questo incidente, registra un ticket con noi tramite la messaggistica ZBot nel Widget.

RIEPILOGO

Il 5 marzo 2024, dalle 15:30 UTC alle 18:25 UTC, i clienti Sunshine Conversations di tutti i pod che usano i canali di messaggistica social potrebbero aver subito un’interruzione significativa del servizio a causa di un’interruzione di Meta. Questa interruzione ha interessato principalmente WhatsApp, con impatti sostanziali anche su Facebook Messenger e Instagram, portando a un’interruzione parziale del traffico in uscita attraverso questi canali.

Cronologia

16:30 UTC | 08:30 PT
Abbiamo confermato un problema che riguarda tutti i canali di messaggistica social basati su Meta, inclusi Facebook, Messenger, WhatsApp e Instagram. Forniremo un altro aggiornamento quando il nostro provider partner avrà risolto il problema.

17:51 UTC | 09:51 PT
Stiamo iniziando a vedere una ripresa dal problema che influisce sull’uso di tutti i canali di messaggistica social basati su Meta. Continueremo a collaborare con il nostro provider partner e a monitorare la situazione fino alla soluzione completa.

19:15 UTC | 11:15 PT
Siamo lieti di comunicare che il problema che causava i ritardi nei messaggi in ingresso e in uscita su tutti i canali di messaggistica social basati su Meta è stato risolto e questi canali stanno elaborando i messaggi come previsto al momento. Grazie per la pazienza dimostrata durante la collaborazione con il nostro provider partner.

 

POST-MORTEM

Analisi della causa principale

Questo incidente è stato causato da un problema con i servizi di Meta, che ha avuto un impatto specifico sull’API Cloud di WhatsApp. La causa esatta non è stata rivelata da Meta, ma ha riconosciuto l’interruzione e ha lavorato al ripristino dei servizi. Durante questo periodo, i sistemi di monitoraggio di Sunshine Conversations hanno rilevato un numero elevato di errori durante il tentativo di inviare messaggi attraverso i canali interessati.

Soluzione

La soluzione dell’interruzione dipendeva interamente dagli sforzi di ripristino di Meta. Sunshine Conversations ha monitorato da vicino la situazione e ha fornito aggiornamenti ai clienti non appena sono diventati disponibili. Una volta che Meta ha annunciato il ripristino dei servizi, Sunshine Conversations ha verificato che il traffico in uscita fosse tornato a livelli normali e che i messaggi venissero consegnati correttamente attraverso i canali di messaggistica social.

Elementi correttivi

1. Migliora il monitoraggio dello stato del traffico in uscita.
2. Rivedi e aggiorna il piano di risposta agli incidenti per includere canali di comunicazione alternativi con Meta nel caso in cui il portale di assistenza principale non sia disponibile.

 

PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk, consulta la nostra pagina sullo stato del sistema. Di solito, il riepilogo della nostra indagine post mortem viene pubblicato qui pochi giorni dopo la fine dell’incidente. Per ulteriori domande su questo incidente, registra un ticket con noi tramite la messaggistica ZBot nel Widget.

RIEPILOGO

POST-MORTEM

Analisi della causa principale

Questo incidente è stato causato da un difetto con escape, per cui il servizio di elaborazione eventi generava errori durante il tentativo di analizzare gli eventi webhook con un valore nullo nei relativi metadati.

Soluzione

Per risolvere questo problema, la logica del codice è stata aggiornata in modo da accettare i valori Null negli oggetti di metadati.  Abbiamo continuato a monitorare la situazione e abbiamo confermato nei registri che gli errori nel pod 26 non si verificavano più dopo questa modifica.

Elementi correttivi

1. Aggiorna la documentazione pubblica di Sunshine Conversation per accettare valori Null negli oggetti di metadati [Pianificata]
2. Aggiunta di ulteriori avvisi di monitoraggio per tali errori [Fine]

PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk, consulta la nostra pagina sullo stato del sistema. Di solito, il riepilogo della nostra indagine post mortem viene pubblicato qui pochi giorni dopo la fine dell’incidente. Per ulteriori domande su questo incidente, registra un ticket con noi tramite la messaggistica ZBot nel Widget.

RIEPILOGO

Il 28 novembre 2023 dalle 13:14 UTC alle 17:14 UTC, i clienti Zendesk Talk su più pod hanno riscontrato la scomparsa dell’icona Talk/telefono e alcuni clienti hanno visto i report Explore che mostravano un numero elevato di chiamate perse. 

Cronologia

POST-MORTEM

Analisi della causa principale

Questo incidente è stato causato da una soluzione software che conteneva un difetto non visibile durante il processo di test.  Questa soluzione riguardava una variabile che non era sempre disponibile durante il caricamento dell’attività vocale, causando l’arresto anomalo del caricamento e la mancata visualizzazione dell’icona di chiamata negli scenari in cui agli agenti erano installate app di terzi.

Soluzione

Per risolvere il problema, abbiamo eseguito il rollback alla versione software precedente e abbiamo ricevuto la conferma del ripristino.

Elementi correttivi

1. Aggiunta di uno scenario di test per verificare il caricamento dell’icona di chiamata quando sono presenti app di terzi. [Pianificato]
2. Aggiunta di monitoraggi e avvisi quando l’attività vocale non riesce. [Pianificato]

PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk, consulta la nostra pagina sullo stato del sistema. Di solito, il riepilogo della nostra indagine post mortem viene pubblicato qui pochi giorni dopo la fine dell’incidente. Per ulteriori domande su questo incidente, registra un ticket con noi tramite la messaggistica ZBot nel Widget.

RIEPILOGO

Il 16 novembre 2023, dalle 18:02 alle 20:00 UTC, alcuni clienti Support nei pod 13, 17, 19, 23, 28 e 29 hanno riscontrato ritardi o un’interruzione totale nella ricezione delle email in ingresso. La durata del ritardo variava da 15 a 60 minuti tra l’invio delle email e la creazione dei ticket in Zendesk tramite i servizi gestiti da Google.

Cronologia

18:53 UTC | 10:53 PT
Stiamo esaminando le segnalazioni di email in ingresso non elaborate per i clienti nei pod 28 e 29. Forniremo ulteriori informazioni a breve.

18:57 UTC | 10:57 PT
Abbiamo confermato un problema che causa ritardi nell’elaborazione delle email in ingresso per i clienti nei pod 13, 19, 23, 28 e 29. Il nostro team sta indagando e forniremo ulteriori aggiornamenti non appena saranno disponibili.

19:33 UTC | 11:33 PT
Il nostro team continua a indagare sul problema che causa ritardi nell’elaborazione delle email in ingresso nei pod 13, 17, 19, 23, 28 e 29. Stiamo lavorando diligentemente per mitigare l’impatto e ci assicureremo di condividere nuove informazioni il prima possibile.

19:54 UTC | 11:54 PT
Stiamo iniziando a notare un miglioramento del problema che causa ritardi nell’elaborazione delle email in ingresso nei pod 13, 17, 19, 23, 28 e 29. Il nostro team continuerà a monitorare per garantire il completo recupero. 

21:14 UTC | 13:14 PT
Abbiamo risolto il problema che causava ritardi nelle email in ingresso per i clienti nei pod 13, 17, 19, 23, 28 e 29 e le email in ingresso vengono elaborate come previsto al momento. Grazie per la pazienza dimostrata durante la nostra indagine.

 

POST-MORTEM

Analisi della causa principale

Questo incidente è stato causato da problemi di connettività con Gmail da parte del servizio Mail Fetcher, che hanno interrotto l’elaborazione della posta in ingresso in Support, per cui le risposte 302 spostate di Gmail sono state interpretate come errori dal sondaggio di attività, indicando all’orchestratore del contenitore che i pod non erano integri. Ciò ha portato l’agente di orchestrazione a sostituire i pod e a interrompere l’elaborazione della posta nei contenitori associati, causando ritardi o interruzioni della posta in ingresso.

Soluzione

Per risolvere il problema, il traffico di posta in ingresso è stato ripristinato dopo che Gmail ha smesso di bloccare tali controlli di integrità, consentendo così alle email in ingresso di Support di completare la creazione dei propri pod e ricominciare a elaborare la posta. Non molto tempo dopo, le code di posta in ingresso si sono bloccate e il traffico ha iniziato a fluire normalmente.

Elementi correttivi

1. Migliora gli strumenti di implementazione esistenti per i controlli di integrità delle email. 
2. Crea ulteriori avvisi. 
3. Aggiungi righe di codice di correzione in applicazioni specifiche.

 

PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk, consulta la nostra pagina sullo stato del sistema. Di solito, il riepilogo della nostra indagine post mortem viene pubblicato qui pochi giorni dopo la fine dell’incidente. Per ulteriori domande su questo incidente, registra un ticket con noi tramite la messaggistica ZBot nel 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?