ZUSAMMENFASSUNG
Im Juni 2024, insbesondere am 13. und 25. sowie an einigen Tagen im Juli, traten im Zendesk-Arbeitsbereich für Agenten eine Reihe von Problemen auf. Diese Vorfälle störten die Arbeitsabläufe der Agenten und erschwerten den Zugriff auf die Tickets. Zu den Hauptproblemen gehörten der Fehler „Messages not found“ und der Fehlercode „A_xxx“ beim Laden von Tickets. Diese Probleme traten hauptsächlich in verschiedenen Pods an mehreren Tagen auf. Jede dieser Störungen dauerte in der Regel durchschnittlich zwei Minuten. Kunden könnten zwar versuchen, das System zu aktualisieren, aber sie riskieren, dass dabei laufende Konversationen verloren gehen.
Zeitleiste
25. Juni 2024 16:05 UTC | 25. Juni 2024, 09:05 Uhr PT
Uns ist bekannt, dass am 25. Juni 2024 zwischen 15:40 und 15:47 UTC eine Spitze von Fehlern aufgetreten ist, die Kunden in mehreren Pods beschwerten und beim Versuch, Tickets in zu laden, zu „Nachrichten nicht gefunden"-Antworten und „Fehlercode A_xxx"-Nachrichten führten Support. Wir haben diese Fehler behoben. Das Problem sollte behoben sein, indem Sie den Browser neu laden und/oder den Cache und die Cookies löschen.
POST-MORTEM
Ursachenanalyse
Die Hauptursache für diese Vorfälle war ein unerwarteter Anstieg von HTTP-Anforderungen an den Server, häufig zu den Zeiten mit hohem Verkehrsaufkommen. Dieser Anstieg führte zu einem donnernden Herdeneffekt, der die Verbindungen des Agentendiagramm-Servers überlastete und dazu führte, dass die Bereitschaftsprüfungen fehlgeschlagen sind. Lotus, eine wichtige Komponente des Systems, spielt eine wichtige Rolle. Dadurch wurde der Ticket Data Manager (TDM) bei jeder erneuten Verbindung mit mehreren Anfragen überlastet. Dieser Anstieg des Verkehrsaufkommens ist in erster Linie darauf zurückzuführen, dass Abonnements für den Konversationsstatus nach einer Massentrennung, die offenbar auf die Bereitstellung von Zorg/Nginx und/oder abonnementdiensten zurückzuführen ist, die Verbindung wieder herstellen.
Der TDM ist hauptsächlich für die Verwaltung der Ticketdaten verantwortlich. Er organisiert und speichert Informationen, wenn ein Ticket erstellt wird, und ruft diese Daten ab, wenn ein Agent oder Kunde darauf zugreifen muss. Zudem ist er für alle Ticketdaten verantwortlich und gewährleistet so einen reibungslosen Betrieb im System.
Resolution
Als Reaktion auf diese Probleme wurden vorbeugende Maßnahmen ergriffen. Dazu gehörten der Verbindungs- und der Anfrageratenlimiter, die für die Regulierung des eingehenden Datenverkehrs zuständig sind. Gleichzeitig wurden Schritte unternommen, um die Ausfallsicherheit des Agentendiagramms bei Caching-Fehlern zu verbessern. Diese Strategie verhinderte systemweite Störungen durch unvermeidliche technische Störungen, die bei einem Stromausfall wie ein Notstromgenerator fungierten. Es wurden zahlreiche Schadensbegrenzungsmaßnahmen ergriffen, aber die eigentliche Behebung, die zum Abschluss des Servicevorfalls führte, war eine in Lotus vorgenommene Änderung. Durch die Änderung reduzierte sich die Anzahl von Szenarien, in denen Daten erneut abgerufen und anschließend der donnernde Herdeneffekt beendet wird.
Bearbeitet am 25. Juli: Nachdem wir am 10. Juli einige Anpassungen vorgenommen hatten, um eine Anhäufung von Anfragen zu verhindern, die Probleme verursachten, sahen wir keine weiteren Spitzen, die sich auf die Ticket-UI auswirkten. Wir beobachteten die Abläufe weiterhin genau und stellten mit Zufriedenheit fest, dass in den folgenden Tagen alles wie am Schnürchen lief.
Im Vormonat hatten wir zudem einige Leistungseinbußen bei bestimmten Pods festgestellt - am 12. Juli sah es allerdings besser aus, was das Vertrauen in unsere Veränderungen widerspiegelt. Am 15. Juli traten keine Leistungsschwankungen mehr an, und wir konnten davon ausgehen, dass das Problem behoben war.
Korrekturelemente
Es sind weitere Strategien geplant, um die Systemstabilisierung weiter zu verbessern und zukünftige Störungen zu verhindern:
- Auf Fehler bei der Bereitschaftsprüfung aufmerksam machen: Implementieren Sie einen Self-Service-Test, um das Technikteam umgehend auf potenzielle Probleme hinzuweisen, damit Sie sofort eingreifen können.
- Berücksichtigung von Abrufmustern: Wir raten Softwareentwicklern, das Volumen und die Häufigkeit des abgerufenen Informationsflusses sorgfältig zu bestimmen, um Systemungleichgewichte zu vermeiden.
- Festlegen einer Baseline für Anfragen: Bestimmen Sie die Kapazität des Systems in der Lage, gleichzeitige Anfragen nach Ticketinformationen zu verarbeiten, um einen Systemausfall zu verhindern.
- Verteilen Sie die Refetches: Fügen Sie einen Jitter hinzu, um womöglich auf den Donnerherdeneffekt zu reduzieren.
- Explore Erfahren Sie, wie Sie Ihr Abonnement ordnungsgemäß verwalten können: Untersuchen Sie, wie sich Abonnements während der Bereitstellung effektiver verwalten lassen.
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.