Vor Kurzem aufgerufene Suchen


Keine vor kurzem aufgerufene Suchen

Attila Takacs's Avatar

Attila Takacs

Beigetreten 14. Apr. 2021

·

Letzte Aktivität 05. Feb. 2025

Folge ich

0

Follower

2

Gesamtaktivitäten

72

Stimme

1

Abonnements

63

AKTIVITÄTSÜBERSICHT

Neueste Aktivität von Attila Takacs

Attila Takacs hat einen Beitrag erstellt

BeitragServicebenachrichtigungen

ZUSAMMENFASSUNG

05. Februar 2025 11:48 UTC | 05. Februar 2025 03:48 PT
Wir freuen uns, Ihnen mitteilen zu können, dass die Anmeldeprobleme mit unserem Guide-Service von unserem Engineering-Team identifiziert und gelöst wurden. Sie sollten jetzt problemlos auf den Dienst zugreifen können. Vielen Dank für Ihre Geduld und Ihr Verständnis während dieses Vorfalls. Wenn Sie weiterhin Probleme haben, wenden Sie sich an unser Supportteam.

05. Februar 2025 11:29 UTC | 05. Februar 2025, 03:29 Uhr PT
Bei der Anmeldung beim Guide-Service über mobile Browser kommt es zu Servicebeeinträchtigungen. Wenn beim Zugriff auf Ihr Konto ein Fehler auftritt, versuchen Sie bitte, sich von einem Desktop aus anzumelden. Unser Team arbeitet aktiv an der Lösung dieses Problems.

POST-MORTEM

TBD

WEITERE INFOS

Weitere Informationen zum aktuellen Systemstatus von Zendesk und zu spezifischen Auswirkungen auf Ihr Konto finden Sie auf der Systemstatusseite. Sie können diesem Beitrag folgen, damit Sie benachrichtigt werden, wenn unser Post-mortem-Bericht veröffentlicht wird. 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.

Bearbeitet 05. Feb. 2025 · Attila Takacs

0

Follower

1

Stimme

0

Kommentare


Attila Takacs hat einen Beitrag erstellt

BeitragServicebenachrichtigungen

ZUSAMMENFASSUNG

Am 1. Februar 2025 von 00:13 UTC bis 00:59 UTC hatten Kunden im POD 26 Probleme beim Zugriff auf archivierte Tickets. Zu diesem Zeitpunkt konnten mehrere Datenbanklesegeräte aufgrund eines Fehlers im Datenbanksystem eine Tabelle nicht öffnen. Dies führte zu fehlgeschlagenen Abfragen für archivierte Tickets.

CHRONIK

01. Februar 2025 01:13 UTC | 31. Januar 2025, 17:13 Uhr PT
Wir freuen uns, Ihnen mitteilen zu können, dass das Problem, das Fehler bei einer Gruppe unserer Support-Kunden auf POD 26 verursachte, jetzt behoben ist. Vielen Dank für Ihr Verständnis.

01. Februar 2025 0:57 UTC | 31. Januar 2025, 16:57 Uhr PT
Unsere Ingenieure gehen davon aus, die Hauptursache für die Fehler identifiziert zu haben, die eine Gruppe unserer Support-Kunden auf POD 26 betreffen, und arbeiten an der Behebung des Problems.

01. Februar 2025 0:57 UTC | 31. Januar 2025, 16:57 Uhr PT
Wir untersuchen potenzielle Fehler für unsere Support-Kunden, die auf POD 26 gehostet werden.


POST-MORTEM

Ursachenanalyse

Dieser Vorfall wurde durch einen Fehler im Datenbanksystem verursacht, der den Zugriff der Cluster-Leserknoten auf eine Tabelle mit archivierten Tickets verhinderte. Der Fehler wurde vom technischen Support unseres Anbieters bestätigt und begab sich auf die zum Zeitpunkt installierte Datenbankversion.


Lösung

Um dieses Problem zu beheben, haben unsere Ingenieure die Bereitstellung auf anderen Shards angehalten und die laufenden Änderungen auf den betroffenen Shards abgeschlossen lassen. Zu diesem Zeitpunkt war die Datenbanktabelle zugänglich. Anschließend plant das Team ein Upgrade auf eine neue Version unseres Datenbanksystems, die einen Patch für den identifizierten Fehler enthält.


Korrekturelemente

  1. Upgraden Sie auf die gepatchte Version oder später, bevor Sie mit den Schemaänderungen fortfahren.
  2. Hinzufügen von Spalten und Einfügen von Indizes in separate Aktionen, um das Risiko bei der Bereitstellung zu minimieren.
  3. Aktualisieren Sie das Runbook so, dass bei umfangreichen Migrationen zunächst nur ein Cluster erreicht und dann auf weitere Cluster erweitert werden kann.
  4. Implementieren Sie einen regelmäßigen Reviewprozess (mindestens einmal pro Jahr) für Datenbank-System-Patches und legen Sie einen Zeitpunkt für Upgrades fest.

WEITERE INFOS

Weitere Informationen zum aktuellen Systemstatus von Zendesk und zu spezifischen Auswirkungen auf Ihr Konto finden Sie auf der Systemstatusseite. Sie können diesem Beitrag folgen, damit Sie benachrichtigt werden, wenn unser Post-mortem-Bericht veröffentlicht wird. 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.

Bearbeitet 06. Feb. 2025 · Attila Takacs

0

Follower

1

Stimme

0

Kommentare


Attila Takacs hat einen Beitrag erstellt

BeitragServicebenachrichtigungen

ZUSAMMENFASSUNG
Am 13. Januar 2025 von 11:07 UTC bis 12:07 UTC hatten Kunden in Pod 17 Probleme mit der Ausführung von Messaging-Auslösern.

CHRONIK

13. Januar 2025 12:24 UTC | 13. Januar 2025, 04:24 Uhr PT
Das jüngste Messaging-Problem wurde vollständig gelöst und unsere Dienste sind wieder voll funktionsfähig! Vielen Dank für Ihr Verständnis. Unser Team wird unsere Systeme auch weiterhin genau überwachen, um sicherzustellen, dass alles reibungslos läuft. Wir bedanken uns für Ihre Unterstützung und sind jederzeit für Sie da!

13. Januar 2025 11:51 UTC | 13. Januar 2025, 03:51 Uhr PT
Wir untersuchen Probleme mit der Ausführung von Messaging-Auslösern für unsere Kunden auf POD17.


POST-MORTEM

Ursachenanalyse

Dieser Vorfall wurde durch die vorzeitige Kündigung von Verbrauchern des Dienstes für Messaging-Ticketprotokollereignisse verursacht, der auftrat, während der Dienst noch lief. Dies hatte zur Folge, dass die Verbraucher eingehende Ereignisse nicht verarbeiten konnten, was zu einem vollständigen Anhalten der Auswertung und Ausführung der Messaging-Auslöser in Pod 17 führte.

Lösung

Um dieses Problem zu beheben, haben wir den Konfigurationsfehler identifiziert, der die maximale Anzahl von Datensätzen, die in einem einzelnen Batch verarbeitet werden sollen, auf 500 statt auf die beabsichtigten 250 festlegt. Durch Korrektur dieses Tippfehlers und Verringern des Werts für die maximale Anzahl von Datensätzen wollten wir die Wahrscheinlichkeit verringern, dass Verbraucher den Dienst aufgrund von Timeout-Problemen abbrechen.

Korrekturelemente

  1. Gesundheitsprüfung durchführen, um vorzeitige Kündigungen von Verbrauchern zu erkennen.
  2. Erstellen Sie eine Überwachung, um die Anzahl laufender Verbraucher zu verfolgen.
  3. Richten Sie eine Überwachung ein, um gestoppte Abschnitte für den Verbraucher Tessaging ticket log events zu überwachen.
  4. Dem Dashboard „Messaging Trigger Service“ ein Widget für den Status „Consumer lag“ hinzufügen.
  5. Erstellen Sie eine neue Metrik zum Messen der Zeit für die Verarbeitung eines Nachrichtenstapels aus dem Thema „Messaging-Ticketprotokollereignisse“.

Diese Behebungen sollen die Überwachung verbessern, ähnliche Vorfälle in Zukunft verhindern und die Stabilität und Zuverlässigkeit des Messaging Trigger Service gewährleisten.


WEITERE INFOS

Weitere Informationen zum aktuellen Systemstatus von Zendesk und zu spezifischen Auswirkungen auf Ihr Konto finden Sie auf der Systemstatusseite. Sie können diesem Beitrag folgen, damit Sie benachrichtigt werden, wenn unser Post-mortem-Bericht veröffentlicht wird. 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.

Bearbeitet 29. Jan. 2025 · Attila Takacs

0

Follower

1

Stimme

0

Kommentare


Attila Takacs hat einen Beitrag erstellt

BeitragServicebenachrichtigungen

ZUSAMMENFASSUNG

Am 9. Dezember 2024 von 8:08 UTC bis 13:03 UTC traten bei Kunden, die die Multibrand-Funktionalität nutzten, Fehler beim Erstellen von Tickets oder Aktualisieren von Tickettiteln auf, aber die Änderungen wurden gespeichert.

Zeitleiste

09. Dezember 2024, 22:21 Uhr UTC | 14:21 PST

Wir freuen uns, Ihnen mitteilen zu können, dass die jüngste Änderung erfolgreich rückgängig gemacht wurde und das Problem bei der Erstellung von Multibrand-Tickets jetzt behoben ist.
Wenn weiterhin Probleme auftreten, versuchen Sie, einen Hard Refresh durchzuführen (Strg + F5) oder löschen Sie den Browser-Cache und die Cookies, da dies helfen kann, bestehende Probleme zu lösen.
Wir können uns jederzeit an Sie wenden, wenn weiterhin Probleme auftreten. Vielen Dank für Ihre Geduld.

09. Dezember 2024 12:58 UTC | 04:58 PST
Wir haben leider gerade Probleme mit der Erstellung von Tickets für mehrere Marken. Unser Engineering-Team ist sich des Problems bewusst und arbeitet aktiv daran, es so schnell wie möglich zu lösen.
Wir werden Sie informieren, sobald weitere Informationen verfügbar sind. Vielen Dank für Ihre Geduld und Ihr Verständnis!

 

POST-MORTEM

Ursachenanalyse

Die Ursache des Vorfalls war ein Fehler in der Logik zur Ticketinitialisierung. Wenn die ID des Anfragenden nicht definiert war, versuchte das System, sie anhand des Ticketschlüssels abzurufen. Dies führte bei jeder Feldänderung in der Ticketbenutzeroberfläche zu Fehlern. Die Einführung einer neuen Logik zum Lesen der Benutzer-ID von der Benutzerprofilseite und zum Festlegen der Anfragenden-ID bewirkte, dass das Anfragende-Objekt versehentlich auf nicht definiert gesetzt wurde, was die erwartete Funktionalität beeinträchtigte.


Lösung

Um das Problem zu beheben, wurde die problematische Aktualisierung rückgängig gemacht.


Korrekturelemente

  1. Fehlerhaften Code korrigieren: Stellen Sie sicher, dass das System die Daten zum Anfragenden beim Erstellen von Tickets richtig festlegt, um leere Einträge zu vermeiden.
  2. Automatische Tests hinzufügen: Erstellen Sie einen Test, um zu prüfen, ob die Informationen zum Anfragenden beim Speichern des Tickets korrekt verarbeitet werden.
  3. Manuellen Test bestätigen: Verlangen Sie von den Deployment-Mitarbeitern, Änderungen vor der Bereitstellung manuell an „kanarischen“ PODs zu testen und sicherzustellen, dass alles funktioniert.
  4. Überwachung verbessern: Richten Sie die Überwachung ein, um bei Browserfehlern Benachrichtigungen anzuzeigen (etwas ist schief gelaufen), damit Probleme schnell identifiziert werden können.

WEITERE INFOS

Aktuelle Systemstatusinformationen zu Ihrem Zendesk finden Sie in unserer 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.

Bearbeitet 17. Dez. 2024 · Attila Takacs

0

Follower

1

Stimme

0

Kommentare


Attila Takacs hat einen Beitrag erstellt

BeitragServicebenachrichtigungen

ZUSAMMENFASSUNG

Am 3. Dezember 2024 von 21:09 UTC bis 3:36 UTC am 7. Dezember 2024 traten bei einigen Kunden, die das Mobile SDK verwendeten, 400-Fehler beim Erstellen von Tickets auf. Aufgrund einer Änderung wurde neu erstellten OAuth Token eine Standardablaufzeit von 8 Stunden zugewiesen. Diese Änderung führte zu einem Fehler in den Legacy-Mobile-SDKs, die keine neuen Token abrufen konnten, wenn ihre vorhandenen Token ungültig wurden, was zu einem frustrierten Benutzererlebnis führte. Das Problem wurde durch Rückgängigmachen der Änderung behoben.


Zeitleiste

6. Dezember 2024 18:20 UTC | 6. Dezember 2024, 10:20 Uhr PST

Wir freuen uns, Ihnen mitteilen zu können, dass das Problem, das bei manchen Kunden zu 400-Fehlern beim Erstellen von Tickets über das SDK führte, behoben wurde. Wir entschuldigen uns für etwaige Störungen und danken Ihnen für Ihre Geduld während unserer Untersuchung.

6. Dezember 2024 12:06 UTC | 6. Dezember 2024, 04:06 Uhr PST
Unser Team arbeitet weiter daran, das Verhalten zu beheben, das 400-Fehler beim Einreichen von Tickets über die API durch unser Mobile SDK verursacht. Wenn Endbenutzer auf diesen Fehler stoßen, können sie die App-Tickets vorerst neu erstellen.


6. Dezember 2024 09:45 UTC | 6. Dezember 2024, 01:45 Uhr PST

Uns ist bekannt, dass bei manchen Kunden beim Erstellen von Tickets über unser Mobile SDK 400-Fehler auftreten. Wenn dieser Fehler auftritt, starten Sie die App neu, um das Problem zu beheben.


POST-MORTEM

Ursachenanalyse

Dieser Vorfall war darauf zurückzuführen, dass Authentifizierungstoken produktübergreifend genutzt wurden, bevor eine Änderung der Ablaufzeit eingeführt wurde. Die Legacy-SDKs können keine neuen OAuth -Token abrufen, wenn die vorhandenen Token ablaufen. Dieser Aspekt wurde jedoch bei der Planungs- und Integrationsphase nicht vollständig berücksichtigt. Durch verstärkte Zusammenarbeit und eine gründlichere Untersuchung der Tokennutzung hätte diese Störung vermieden werden können.


Lösung

Um das Problem zu beheben, deaktivierte das Authentifizierungsteam zunächst den Auffüllprozess, der Verfallszeiten zu vorhandenen Token hinzufügt. Anschließend wurde eine Pull-Anforderung bereitgestellt, die die Ablaufeinstellungen für neue Token rückgängig machte und einen Backfill einleitete, um den Ablauf für vorhandene Token zu entfernen. Durch diese Aktion wurde die Funktionalität für die meisten betroffenen Kunden wiederhergestellt.


Korrekturelemente

  1. Etablieren Sie ein klares Kommunikationsprotokoll zwischen den Teams, um sicherzustellen, dass bekannte Fehler ordnungsgemäß dokumentiert und überprüft werden, bevor größere Änderungen vorgenommen werden.
  2. Verbessern Sie vorhandene Implementierungstools, um den Authentifizierungsfluss besser zu managen und die mit Legacy SDKs verbundenen technischen Probleme zu reduzieren.
  3. Erstellen Sie zusätzliche Alarm- und Überwachungssysteme, um in Zukunft ähnliche Probleme zu erkennen. Dabei sollten Sie sich besonders auf OAuth Token-Fehler konzentrieren.
  4. Legen Sie Verbindungslimits für bestimmte Anwendungen fest, um eine übermäßige Generierung von Token zu verhindern und die Entwicklung der Datenbankgröße zu verhindern.

WEITERE INFOS

Aktuelle Systemstatusinformationen zu Ihrem Zendesk finden Sie in unserer 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.

Bearbeitet 20. Dez. 2024 · Attila Takacs

0

Follower

1

Stimme

0

Kommentare


Attila Takacs hat einen Beitrag erstellt

BeitragServicebenachrichtigungen

ZUSAMMENFASSUNG

Am 21. November 2024 von 21:02 UTC bis 21:56 UTC traten bei einigen Kunden, die auf Pod 17 gehostete Sunshine Conversations verwendeten, Verlangsamung und Leistungsprobleme auf.

 

CHRONIK

24. November 2024, 22:23 Uhr UTC | 24. November 2024 14:23 Uhr PT
Wir freuen uns, Ihnen mitteilen zu können, dass die Latenzprobleme, die Sunshine Conversations bei einigen unserer Kunden auf POD 17 betreffen, jetzt behoben sind. Vielen Dank für Ihre Geduld.

24. November 2024 22:09 Uhr UTC | 24. November 2024 14:09 Uhr PT
Wir glauben, die Ursache für die Leistungsprobleme, die SunCo für unseren Kunden auf Pod17 betreffen, identifiziert zu haben. Wir sehen jetzt Verbesserungen und werden das Verhalten weiterhin überwachen.

24. November 2024, 21:53 Uhr UTC | 24. November 2024, 13:53 Uhr PT
Wir untersuchen weiterhin Leistungsprobleme aus Pod 17. Diese können Sunshine Conversations. Wir werden in Kürze weitere Updates bereitstellen.

24. November 2024, 21:36 Uhr UTC | 24. November 2024, 13:36 Uhr PT
Wir untersuchen potenzielle Leistungsprobleme, die einige unserer auf Pod 17 gehosteten Kunden betreffen. Wir werden in Kürze ein Update mit weiteren Details veröffentlichen.


POST-MORTEM

Ursachenanalyse

Dieser Vorfall wurde durch einen unerwarteten Anstieg des Verkehrsaufkommens auf Pod17 verursacht, der sich in der Woche zuvor mehr als verdoppelt und am Tag des Vorfalls fast verdreifacht hatte. Das von einem Kunden verwendete Unity-SDK sendete übermäßig viele Anforderungen an die SunCo-API, um die Anzahl ungelesener Nachrichten abzurufen, was zu einer erhöhten Systemlast führte. Die automatische Skalierung von Ressourcen hatte bereits ihre maximale Kapazität erreicht, sodass keine weiteren Ressourcen zur Bewältigung des zusätzlichen Datenverkehrs hinzugefügt werden mussten. In der Folge führte diese Überlastung zu langsameren Antwortzeiten und letztendlich zu Integritätsprüfungen, die einen Neustart einleiteten, was das Problem noch verschlimmerte.

Lösung

Um die Leistungsprobleme zu beheben, haben wir die maximale Anzahl von Replikationen für die SunCo-API auf Pod17 erhöht. Dank dieser Anpassung konnte das System das erhöhte Verkehrsaufkommen besser bewältigen, und für alle Kunden wurden die normalen Antwortzeiten wiederhergestellt.

Korrekturelemente

  1. Untersuchen Sie das Unity-SDK, um zu verstehen, warum es zu viele Anfragen an SunCo sendet, und optimieren Sie es.
  2. Dokumentieren Sie Backend-Interaktionsmuster in Embeddables, um die Nutzung zu verdeutlichen und potenzielle Ineffizienzen zu identifizieren.
  3. Prüfen Sie die Implementierung einer Caching-Strategie für SDK-APIs in SunCo, um die Anzahl der gesendeten Anfragen zu reduzieren.
  4. Fügen Sie Überwachungsfunktionen hinzu, um ein ungewöhnliches Wachstum des Datenverkehrs in bestimmten Zeiträumen zu erkennen, damit Sie proaktiv auf mögliche Überlastungen reagieren können.

 

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.

Bearbeitet 04. Dez. 2024 · Attila Takacs

0

Follower

1

Stimme

0

Kommentare


Attila Takacs hat einen Beitrag erstellt

BeitragServicebenachrichtigungen

ZUSAMMENFASSUNG

Zwischen 23:30 UTC am 12. November 2024 und 11:26 UTC am 15. November 2024 kam es bei Support-Kunden, die SLA in Pod 25 und 30 verwendeten, zu verzögerten SLA -Berechnungen, und die SLA -Badges in ihren Tickets wurden nach Ablauf des Gültigkeitsdatums nicht wie erwartet angezeigt Ticketaktualisierungen.

 

CHRONIK

15. November 2024 13:00 UTC | 15. November 2024, 05:00 Uhr PST
Wir freuen uns, Ihnen mitteilen zu können, dass die Probleme, die sich auf die SLA -Leistung von Metriken auf Pod 25 und 30 auswirken, jetzt behoben sind. Vielen Dank für Ihre Geduld.

15. November 2024 12:16 UTC | 15. November 2024, 04:16 Uhr PST
Wir sehen jetzt Verbesserungen bei dem Problem, das sich auf die SLA -Leistung von Metriken auf Pod 25 und 30 auswirkt. Wir beobachten die Entwicklung weiterhin und liefern weitere Updates, sobald wir sie haben.

 

POST-MORTEM

Ursachenanalyse

Dieser Vorfall wurde durch ein falsch konfiguriertes Geheimnis für den Metrik-Ereignisdienst verursacht. Dies bedeutete, dass bei der Bereitstellung eines Updates mit zusätzlicher Validierung durch Zendesk der Dienst für Bereitstellungen im Asien-Pazifik-Raum nicht initialisiert werden konnte, was zu Verarbeitungsverzögerungen führte.

Lösung

Um dieses Problem zu beheben, wurde am 15. November 2024 ein „Standardwert“ für das betroffene Geheimnis hinzugefügt. Dadurch konnte der Metrik-Ereignisdienst ordnungsgemäß initialisiert werden und den normalen Betrieb wieder aufnehmen. Zendesk hat außerdem ein Geheimnis des Talk-Transkriptionsdienstes identifiziert und einen Standardwert festgelegt, um zukünftige Risiken zu minimieren.

Korrekturelemente

  1. Führen Sie eine gründliche Überprüfung aller Geheimnisse durch, um sicherzustellen, dass Werte für alle Orte festgelegt sind, besonders im Asien-Pazifikraum.
  2. Verbessern Sie Ihre vorhandenen Implementierungstools, um ähnliche Fehlkonfigurationen in Zukunft zu verhindern.
  3. Erstellen Sie zusätzliche Benachrichtigungen, um relevante Teams über Initialisierungsfehler und -probleme zu informieren.
  4. Untersuchen Sie die Fehlerverfolgungsmetriken, um sicherzustellen, dass solche Vorfälle Warnungen auslösen, damit zeitnahe Lösungen möglich sind.

Durch die Implementierung dieser Abhilfemaßnahmen möchten wir die Belastbarkeit unserer Dienste verbessern und ähnliche Vorfälle in Zukunft 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.

Bearbeitet 04. Dez. 2024 · Attila Takacs

0

Follower

1

Stimme

0

Kommentare


Attila Takacs hat einen Beitrag erstellt

BeitragServicebenachrichtigungen

ZUSAMMENFASSUNG

Am 14. November 2024 von 14:15 UTC bis 23:20 UTC traten bei Kunden mit Explore Netzwerkfehler beim Zugriff auf Berichte und Dashboards auf. 

 

Zeitleiste

14. November 2024 18:11 UTC | 14. November 2024, 10:11 Uhr PT
Wir freuen uns, Ihnen mitteilen zu können, dass das Problem, das beim Laden von Explore-Dashboards oder -Berichten zu Netzwerkfehlern führt, behoben wurde. Vielen Dank für Ihr Verständnis.

14. November 2024 15:18 UTC | 14. November 2024, 07:18 Uhr PST
Manche Explore-Benutzer erhalten beim Laden von Dashboards oder Berichten möglicherweise die Meldung „Netzwerkfehler“. In diesem Fall sollte das Problem behoben werden, indem Sie die Cookies und den Cache Ihres Browsers löschen. Wir bitten um Ihr Verständnis.

POST-MORTEM

Ursachenanalyse

Dieser Vorfall wurde durch eine Netzwerkänderung verursacht, die das konfigurierte Limit für die Anzahl von an den Explore-Dienst gesendeten Headern übersteigt. Dies führte zu einem unbemerkten Dienstausfall, sodass die Dashboards für Kunden nicht geladen wurden.

Lösung

Um dieses Problem zu beheben, wurde das Netzwerkteam angefragt, um die Änderungen zu untersuchen. Nachdem das Problem erkannt wurde, machten sie die Änderungen rückgängig, die übermäßig viele Kopfzeilen hinzugefügt hatten, und stellten die normale Funktionalität der Explore-Dashboards wieder her.

Korrekturelemente

  • Vorhandene Implementierungstools verbessern: Die Tools zur Verwaltung der Kopfzeilenlimits in API-Anfragen überprüfen und verbessern, um ähnliche Vorfälle zu verhindern.
  • Zusätzliche Warnungen erstellen: Richten Sie Benachrichtigungen zur Überwachung der Anzahl der Kopfzeilen und anderer kritischer Metriken ein, um Probleme zu erkennen, bevor sie sich auf Kunden auswirken.
  • Verbindungslimits für bestimmte Anwendungen hinzufügen: Implementieren Sie Verbindungslimits für APIs, um sicherzustellen, dass sie die betrieblichen Schwellenwerte nicht überschreiten, um das Risiko zukünftiger Vorfälle zu verringern.


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.

Bearbeitet 03. Dez. 2024 · Attila Takacs

1

Follower

1

Stimme

0

Kommentare