ZUSAMMENFASSUNG
Am 9. August 2024 von 15:46 UTC bis 15:57 UTC traten bei Support-Kunden in Pod 17 verschiedene Probleme wie Fehlercodes, langsame Ladezeiten und Unfähigkeit, Tickets zu öffnen oder Nachrichten in der Produktoberfläche anzuzeigen.
Zeitleiste
09. August 2024 16:13 Uhr UTC | 09. August 2024, 09:13 Uhr PT
Wir untersuchen Berichte, denen zufolge Benutzer keine Support-Tickets in Pod 17 anzeigen können, und zeigen bereits eine Wiederherstellung. Wir werden spätestens 30 Minuten weitere Updates bereitstellen, sobald wir die vollständige Stabilität bestätigt haben.
09. August 2024 16:32 UTC | 09. August 2024, 09:32 Uhr PT
Von 15:46 UTC bis 15:57 UTC hatten Support-Kunden in Pod 17 Probleme beim Laden von Tickets. Die Leistung hat sich stabilisiert und wird weiter überwacht. Nächste Aktualisierung in einer Stunde bzw. wenn neue Informationen verfügbar sind.
09. August 2024 16:51 UTC | 09. August 2024, 09:51 Uhr PT
Die Support-Leistungsprobleme, die in Pod 17 zwischen 15:46 UTC und 15:57 UTC auftraten, sind jetzt vollständig behoben. Wir entschuldigen uns für etwaige Unannehmlichkeiten und danken Ihnen für Ihr Verständnis.
POST-MORTEM
Ursachenanalyse
Dieser Vorfall wurde durch einen unerwarteten Neustart eines Systems verursacht, das den Datenabruf beschleunigt, indem es Informationen im Arbeitsspeicher speichert. Aufgrund einer unzureichenden Reaktion auf diesen Fehler wartete die Komponente „Agent-Diagramm“ weiterhin bis zu 60 Sekunden auf eine Antwort, was zu Timeout-Fehlern und damit zu Servicefehlern vom Typ 503 führte. Dazu beigetragen haben beispielsweise folgende Faktoren: Das System wurde nicht rechtzeitig auf eine alternative Datenquelle umgestellt und die eingesetzten Monitore lösten keine Alarme aus, da das Problem bereits vor Erreichen der Schwellenwerte behoben war.
Lösung
Um dieses Problem zu beheben, wurde das System automatisch wiederhergestellt, als das Speicher-Caching-System wieder online war. Wir stellten fest, dass der Neustart dieses Systems die Verzögerungen verursachte, und es wurde bestätigt, dass sich das Problem von selbst löste und kein unmittelbares manuelles Eingreifen zur Wiederherstellung des Dienstes erforderte.
Korrekturelemente
- Reduzierter Timeout für den Abruf aus dem Benutzercache.
- Führen Sie Chaostests durch, um solche Fehler in einer kontrollierten Umgebung zu simulieren.
- Überprüfen Sie die Alarmschwellen und passen Sie sie entsprechend an, um die Erkennung und Antwortzeit zu verkürzen.
- Wenden Sie sich an AWS , um den unerwarteten Neustart des Speicher-Caching-Systems zu untersuchen und ähnliche zukünftige Ereignisse zu verhindern.
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, wenden Sie sich an den Zendesk-Kundensupport.
Hinweis zur Übersetzung: Dieser Beitrag wurde mit automatischer Übersetzungssoftware übersetzt, um dem Leser ein grundlegendes Verständnis des Inhalts zu vermitteln. Trotz angemessener Bemühungen, eine akkurate Übersetzung bereitzustellen, kann Zendesk keine Garantie für die Genauigkeit übernehmen.
Sollten in Bezug auf die Genauigkeit der Informationen im übersetzten Beitrag Fragen auftreten, beziehen Sie sich bitte auf die englische Version des Beitrags, die als offizielle Version gilt.
0 Kommentare