Justin

ZUSAMMENFASSUNG

Am 5. März 2024 von 19:50 UTC bis 22:06 UTC traten bei einigen Talk-Kunden möglicherweise Verbindungsprobleme auf, darunter die Unfähigkeit, Anrufe zu tätigen, zu empfangen oder weiterzuleiten. 

 

Zeitleiste

21:36 UTC | 13:36 PT

Wir untersuchen Berichte über Verbindungsprobleme mit Talk, darunter die Unfähigkeit, Anrufe zu tätigen, zu empfangen oder weiterzuleiten. Nächste Aktualisierung in 15 Minuten bzw. dann, wenn wir weitere Informationen haben.

22:06 UTC | 14:06 PT

Unsere Techniker gehen laufend Berichten über Verbindungsprobleme mit Talk nach, darunter die Unfähigkeit, Anrufe zu tätigen, anzunehmen oder weiterzuleiten. Nächste Aktualisierung in 30 Minuten bzw. sobald weitere Informationen vorliegen.

22:32 UTC | 14:32 PT

Wir untersuchen weiterhin Probleme im Zusammenhang mit Talk, die dazu führen, dass Anrufe nicht getätigt, entgegengenommen oder weitergeleitet werden können. Nächste Aktualisierung in 1 Stunde bzw. wenn neue Informationen verfügbar sind.

23:31 UTC | 15:31 PT

Unsere Techniker haben eine Änderung rückgängig gemacht, und wir sehen, dass sich die Ursache teilweise erholt hat. Wir werden die Leistung in den nächsten 24 Stunden weiter überwachen und dann über die entsprechenden Updates informieren.

6. März - 10:59 UTC | 02:59 PT

Die Talk-Funktionalität wurde wiederhergestellt und es wurde sowohl durch Kundenfeedback als auch durch interne Überwachung bestätigt, dass es normal funktioniert. Wir danken Ihnen für Ihr Verständnis. Dieser Vorfall ist jetzt gelöst.

 

POST-MORTEM

Ursachenanalyse

Dieser Vorfall scheint durch ein lokales ISP-Problem bei einigen Kunden in den USA verursacht worden zu sein.

Lösung

Um dieses Problem zu beheben, haben wir zunächst eine kürzlich vorgenommene Änderung an Talk rückgängig gemacht. unsere Untersuchung deutet jedoch auf einen ISP-Ausfall hin, der eher zum Zeitfenster der Auswirkungen passt.

Korrekturelemente

1. Verbessern Sie die Überwachung und Benachrichtigung bei Fehlern bei abgehenden Anrufen.
2. Arbeiten Sie mit unserem Anbieter zusammen, um die Alarmschwellen anzupassen, damit wir in ähnlichen Situationen schneller benachrichtigt werden können.
3. Verbessern Sie die Troubleshooting-Runbooks, um den Umfang genauer zu bestimmen.

 

WEITERE INFOS

Aktuelle Systemstatusinformationen zu Ihrem Zendesk finden Sie auf der Systemstatusseite. Die Zusammenfassung unserer Post-mortem-Untersuchung wird in der Regel hier einige Tage nach Abschluss des Vorfalls gepostet. Wenn Sie weitere Fragen zu diesem Vorfall haben, reichen Sie bitte über ZBot Messaging im Widget ein Ticket bei uns ein.

ZUSAMMENFASSUNG

Am 5. März 2024 von 15:30 UTC bis 18:25 UTC kam es bei Sunshine Conversations-Kunden in allen Pods, die Social-Media-Messaging-Kanäle verwenden, möglicherweise zu einer erheblichen Störung aufgrund eines Ausfalls bei Meta. Betroffen war in erster Linie WhatsApp, aber auch Facebook Messenger und Instagram waren betroffen und der abgehende Datenverkehr über diese Kanäle wurde teilweise unterbrochen.

Zeitleiste

16:30 UTC | 08:30 PT
Wir haben ein Problem bestätigt, das sich auf alle von Meta bereitgestellten Social-Media-Messaging-Kanäle auswirkt, einschließlich Facebook, Messenger, WhatsApp und Instagram. Wir werden ein weiteres Update bereitstellen, wenn unser Partneranbieter das Problem behoben hat.

17:51 UTC | 09:51 PT
Die Auswirkungen auf alle Social-Media-Messaging-Kanäle, die von Meta bereitgestellt werden, erholen sich allmählich. Wir werden weiterhin mit unserem Partneranbieter zusammenarbeiten und die Situation bis zur vollständigen Lösung überwachen.

19:15 UTC | 11:15 PT
Wir freuen uns, Ihnen mitteilen zu können, dass das Problem, das zu Verzögerungen bei ein- und abgehenden Nachrichten auf allen von Meta bereitgestellten Social-Media-Messaging-Kanälen führt, behoben wurde und dass diese Kanäle Nachrichten wie erwartet verarbeiten. Vielen Dank für Ihr Verständnis.

 

POST-MORTEM

Ursachenanalyse

Dieser Vorfall wurde durch ein Problem mit den Diensten von Meta verursacht, das insbesondere die WhatsApp Cloud API betrifft. Die genaue Ursache wurde von Meta nicht bekannt gegeben, aber man erkannte, dass die Störung auftrat, und arbeitete daran, die Services wiederherzustellen. Während dieser Zeit stellten die Überwachungssysteme von Sunshine Conversations eine hohe Anzahl von Fehlern beim Senden von Nachrichten über die betroffenen Kanäle fest.

Lösung

Die Behebung des Ausfalls hing vollständig von den Wiederherstellungsbemühungen von Meta ab. Sunshine Conversations beobachtete die Situation genau und informierte die Kunden, sobald sie verfügbar wurden. Nachdem Meta die Wiederherstellung der Dienste angekündigt hatte, konnte Sunshine Conversations bestätigen, dass der abgehende Datenverkehr wieder normal war und die Nachrichten erfolgreich über die Social-Media-Messaging-Kanäle zugestellt wurden.

Korrekturelemente

1. Verbessern Sie die Überwachung des abgehenden Verkehrs.
2. Überprüfen und aktualisieren Sie den Plan zur Reaktion auf Vorfälle und berücksichtigen Sie alternative Kommunikationskanäle mit Meta für den Fall, dass das primäre Support-Portal von Meta nicht verfügbar ist.

 

WEITERE INFOS

Aktuelle Systemstatusinformationen zu Ihrem Zendesk finden Sie auf der Systemstatusseite. Die Zusammenfassung unserer Post-mortem-Untersuchung wird in der Regel hier einige Tage nach Abschluss des Vorfalls gepostet. Wenn Sie weitere Fragen zu diesem Vorfall haben, reichen Sie bitte über ZBot Messaging im Widget ein Ticket bei uns ein.

ZUSAMMENFASSUNG

POST-MORTEM

Ursachenanalyse

Dieser Vorfall wurde durch einen entkommenen Fehler verursacht, bei dem der Ereignisverarbeitungsdienst beim Versuch, Webhook-Ereignisse mit einem Nullwert in den Metadaten zu analysieren, Fehler generierte.

Lösung

Um dieses Problem zu beheben, wurde die Codelogik aktualisiert, damit Nullwerte in Metadatenobjekten akzeptiert werden.  Wir haben die Situation weiter überwacht und in den Protokollen bestätigt, dass die Fehler auf Pod 26 nach dieser Änderung nicht mehr auftraten.

Korrekturelemente

1. Öffentliche Dokumentation zu Sunshine Conversation aktualisieren, damit in Metadatenobjekten Nullwerte akzeptiert werden [geplant]
2. Hinzufügen zusätzlicher Überwachungswarnungen bei solchen Fehlern [Fertig]

WEITERE INFOS

Aktuelle Systemstatusinformationen zu Ihrem Zendesk finden Sie auf der Systemstatusseite. Die Zusammenfassung unserer Post-mortem-Untersuchung wird in der Regel hier einige Tage nach Abschluss des Vorfalls gepostet. Wenn Sie weitere Fragen zu diesem Vorfall haben, reichen Sie bitte über ZBot Messaging im Widget ein Ticket bei uns ein.

ZUSAMMENFASSUNG

Am 28. November 2023 von 13:14 UTC bis 17:14 UTC wurde bei Zendesk Talk-Kunden in mehreren Pods das Talk-/Telefonsymbol verschwand und einige Kunden Explore-Berichte mit einer hohen Anzahl verpasster Anrufe sahen. 

Zeitleiste

POST-MORTEM

Ursachenanalyse

Dieser Vorfall wurde durch eine Softwarekorrektur verursacht, die einen entkommenen Fehler enthielt, der während des Testprozesses nicht sichtbar war.  Diese Korrektur bezog sich auf eine Variable, die beim Laden der Voice-Aktivität nicht immer verfügbar war, was dazu führte, dass der Ladevorgang abgebrochen wurde und das Anrufsymbol in Szenarien, in denen Agenten Apps von Drittanbietern installiert hatten, nicht angezeigt wurde.

Lösung

Um dieses Problem zu beheben, haben wir ein Rollback auf die vorherige Softwareversion durchgeführt und die Wiederherstellung bestätigt.

Korrekturelemente

1. Hinzufügen eines Testszenarios zum Prüfen, ob das Anrufsymbol geladen wird, wenn Apps von Drittanbietern vorhanden sind. [Geplant]
2. Hinzufügen von Monitoren und Benachrichtigungen bei Fehlern bei der Voice-Aktivität. [Geplant]

WEITERE INFOS

Aktuelle Systemstatusinformationen zu Ihrem Zendesk finden Sie auf der Systemstatusseite. Die Zusammenfassung unserer Post-mortem-Untersuchung wird in der Regel hier einige Tage nach Abschluss des Vorfalls gepostet. Wenn Sie weitere Fragen zu diesem Vorfall haben, reichen Sie bitte über ZBot Messaging im Widget ein Ticket bei uns ein.

ZUSAMMENFASSUNG

Am 16. November 2023 von 18:02 UTC bis 20:00 UTC kam es bei einigen Support-Kunden in Pod 13, 17, 19, 23, 28 und 29 zu Verzögerungen oder einem Totalausfall beim Empfang eingehender E-Mails. Die Verzögerungsdauern zwischen dem Senden von E-Mails und der Ticketerstellung in Zendesk über von Google verwaltete Dienste variierten von 15 bis 60 Minuten.

Zeitleiste

18:53 UTC | 10:53 PT
Wir untersuchen Berichte über eingehende E-Mails, die für Kunden in Pod 28 und 29 nicht verarbeitet werden. Wir werden in Kürze weitere Informationen bereitstellen.

18:57 UTC | 10:57 PT
Wir haben ein Problem bestätigt, das zu Verzögerungen bei der Verarbeitung eingehender E-Mails für Kunden in Pod 13, 19, 23, 28 und 29 führt. Unser Team untersucht dies und wir werden weitere Updates bereitstellen, sobald sie verfügbar sind.

19:33 UTC | 11:33 PT
Unser Team untersucht weiterhin das Problem, das zu Verzögerungen bei der Verarbeitung eingehender E-Mails auf den Pods 13, 17, 19, 23, 28 und 29 führt. Wir arbeiten daran, die Auswirkungen zu minimieren, und werden so schnell wie möglich neue Informationen bereitstellen.

19:54 UTC | 11:54 PT
Wir sehen allmählich eine Besserung des Problems, das zu Verzögerungen bei der Verarbeitung eingehender E-Mails auf den Pods 13, 17, 19, 23, 28 und 29 führt. Unser Team wird dies weiterhin überwachen, um eine vollständige Wiederherstellung sicherzustellen. 

21:14 UTC | 13:14 PT
Wir haben das Problem behoben, das zu Verzögerungen bei eingehenden E-Mails für Kunden in Pod 13, 17, 19, 23, 28 und 29 führt. Eingehende E-Mails werden wie erwartet verarbeitet. Vielen Dank für Ihr Verständnis.

 

POST-MORTEM

Ursachenanalyse

Dieser Vorfall wurde durch Verbindungsprobleme des Mail-Fetcher-Dienstes mit Gmail verursacht, die die Verarbeitung eingehender E-Mails in Support unterbrichten. Die 302 verschobenen Antworten von Gmail wurden von der Liveness-Probe als Fehler interpretiert, was für den Container Orchestrator bedeutet, dass die Pods fehlerhaft waren. Dies führte dazu, dass Orchestrator die Pods ersetzte und die E-Mail-Verarbeitung in den entsprechenden Containern angehalten wurde, was zu Verzögerungen oder einem Ausfall des E-Mail-Verkehrs führte.

Lösung

Um dieses Problem zu beheben, wurde der eingehende E-Mail-Verkehr wiederhergestellt, nachdem Gmail die Blockierung dieser Integritätsprüfungen aufgehoben hat. Auf diese Weise konnte Zendesk Support die Erstellung seiner Pods abschließen und die E-Mail-Verarbeitung fortsetzen. Nicht lange danach bildeten sich die Warteschlangen für eingehende E-Mails ein und der Datenverkehr begann, reibungslos über die Bühne zu gehen.

Korrekturelemente

1. Verbessern Sie vorhandene Implementierungstools für E-Mail-Gesundheitsprüfungen. 
2. Erstellen Sie zusätzliche Benachrichtigungen. 
3. Korrekturcodezeilen für spezifische Anwendungen hinzufügen.

 

WEITERE INFOS

Aktuelle Systemstatusinformationen zu Ihrem Zendesk finden Sie auf der Systemstatusseite. Die Zusammenfassung unserer Post-mortem-Untersuchung wird in der Regel hier einige Tage nach Abschluss des Vorfalls gepostet. Wenn Sie weitere Fragen zu diesem Vorfall haben, reichen Sie bitte über ZBot Messaging im Widget ein Ticket bei uns ein.

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?