Störungsverlauf von Sirv

1. 6. August 2026 um 10:17 UTCinvestigating

   Uploads zu einigen Sirv-Konten scheitern aufgrund eines Serverproblems. Dies kann auch verhindern, dass Bilder gelegentlich angezeigt werden. Wir arbeiten daran, das Problem so schnell wie möglich zu lösen.

2. 6. August 2026 um 15:22 UTCresolved

   Die Ursache des Problems wurde identifiziert und nun vollständig gelöst. Während des Zeitraums haben etwa 25% der Sirv-Konten möglicherweise einen Teil der Datei-Uploads fehlgeschlagen. Das Wiederholen der Uploads kurze Zeit später war möglicherweise erfolgreich, da dies nur eine kleine Anzahl von Anfragen betraf. Eine Überprüfung findet jetzt statt und weitere Informationen werden hier später zur Verfügung gestellt.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 27. Juni 2026 um 18:34 UTCmonitoring

   Eine kleine Anzahl von Uploads und Anfragen führt zu Fehlern aufgrund mehrerer Netzwerk-Switch-Ausfälle im primären Rechenzentrum von Sirv. CDN-Anfragen funktionieren wie gewohnt. Wir beobachten die Situation genau und werden Updates bereitstellen, sobald mehr Informationen verfügbar werden.

2. 27. Juni 2026 um 19:37 UTCresolved

   Alle Dienste sind wieder normal und Anfragen sind abgeschlossen.

3. 28. Juni 2026 um 09:03 UTCresolved

   Dieses Problem wurde durch einen Core-Router-Fehler verursacht, der das primäre Rechenzentrum von Sirv betraf. Dies führte zu kurzen, intermittierenden Ausfällen bei Dateispeicherung und Uploads, über alle Übertragungsarten hinweg: API, S3 und FTP. Sirv wechselte automatisch zu seinem Failover-Service, so dass die Dateiverarbeitung und -lieferung wie gewohnt fortgesetzt wurde. CDN-Anfragen wurden ebenfalls wie gewohnt fortgesetzt. Alle Dienste wurden wiederhergestellt, sobald das Rechenzentrum den Ausfall des Kernrouters behoben hatte.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 30. Januar 2026 um 12:46 UTCinvestigating

   Die Antwortzeit für einige Anfragen in Deutschland ist langsamer als normal und eine kleine Anzahl läuft ab. Das Problem wird untersucht.

2. 30. Januar 2026 um 14:28 UTCresolved

   Das Problem ist gelöst. Einer der Server, die Deutschland bedienten, war überlastet und reagierte langsamer als gewöhnlich. Der Server ist jetzt wieder gesund. Wir prüfen derzeit, welche Maßnahmen zu ergreifen sind, um die Wahrscheinlichkeit einer Wiederholung zu verringern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. März 2025 um 14:32 UTCinvestigating

   Einige Anfragen aus Kalifornien sind langsam und eine kleine Anzahl (unter 2%) scheitert. Dies wird untersucht und bezieht sich wahrscheinlich auf neue CDN-Server, die heute in Los Angeles eingesetzt wurden.

2. 31. März 2025 um 15:16 UTCresolved

   Das Problem ist gelöst. Das Problem wurde durch Paketverlust verursacht, der unser neues Rechenzentrum in Los Angeles betrifft. Das Rechenzentrum verfolgte das Problem zu ihrem Upstream-Provider, Arelion, der Netzwerkinstabilität erlebte. Das Problem wurde behoben, als Arelion vorübergehend als Upstream-Anbieter deaktiviert wurde und der Datenverkehr durch andere Anbieter umgeleitet wurde. Wir verlangen, dass unsere Rechenzentren den Datenverkehr in solchen Szenarien automatisch und schnell erkennen und umleiten. Die Lösung dieses Problems war jedoch nicht schnell genug und da es kurz nach der Einführung dieses neuen Rechenzentrums stattfand, haben wir beschlossen, es nicht mehr zu verwenden. Der gesamte Datenverkehr wird nun von unserem ursprünglichen Rechenzentrum in Los Angeles geleitet (Stand: 7. April 2025).

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. März 2025 um 17:56 UTCresolved

   Einige Datei-Uploads sind aufgrund eines Server-Cluster-Problems nicht abgeschlossen. Die Ursache wird untersucht. Das Problem betrifft eine kleine Anzahl von Konten. Wenn Ihr Datei-Upload fehlschlägt, warten Sie bitte, bis dieses Problem behoben ist.

2. 16. März 2025 um 08:40 UTCidentified

   Diese Frage ist noch nicht abgeschlossen. Die Ursache des Problems wurde identifiziert und wir arbeiten daran, es so schnell wie möglich zu lösen.

3. 16. März 2025 um 15:25 UTCresolved

   Das Problem ist gelöst. Das Problem wurde dadurch verursacht, dass zwei Server in einem Cluster gleichzeitig ausgefallen sind. Dies wirkte sich auf das Hochladen neuer Dateien auf etwa 20% der Sirv-Konten aus. Uploads sind so konzipiert, dass sie normal fortgesetzt werden, wenn ein server ausgefallen ist, aber wenn zwei server ausgefallen sind, können einige uploads fehlschlagen, was passiert ist. Sie scheiterten an einem exporteurdienst, der auf einem server nicht mehr lief, dann auf dem anderen server. Fehler verhinderten den Neustart der Dienste. Dann führte ein zweites Problem dazu, dass die Auflösung viel länger dauerte als erwartet, da die Server nicht neu gestartet werden konnten. Dies war auf ein veraltetes BIOS zurückzuführen. Nachdem das BIOS aktualisiert worden war, wurden die Server neu gestartet und die Ursache des zugrunde liegenden Problems wurde behoben. Um zu verhindern, dass sich dies wiederholt, haben wir mit unserem Rechenzentrum einen neuen BIOS-Managementprozess implementiert. Wir verkürzen auch unseren Hardware-Aktualisierungszyklus für häufigere Hardware-Upgrades. Um die Wahrscheinlichkeit zu verringern, dass der Exporteurdienst ausfällt, haben wir einen Prozess deaktiviert und überwachen die Servermetriken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 26. Februar 2025 um 09:29 UTCinvestigating

   Für einen Zeitraum von 3 Minuten zwischen 09:29 und 09:32 UTC wurden einige Anfragen nicht zurückgegeben. Dieses Problem betraf nur bestimmte Anfragen und nur bestimmte Konten. Die meisten Konten waren nicht betroffen.

2. 26. Februar 2025 um 09:32 UTCresolved

   Das Problem wurde innerhalb von 3 Minuten gelöst. Die Ursache war der Neustart mehrerer Server gleichzeitig, während nur 1 Server hätte neu gestartet werden sollen. Dies war ein versehen in unseren standardbetriebsverfahren. Wir untersuchen Möglichkeiten, dies automatisch zu schützen und zu verhindern, dass sich dies wiederholt.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 19. Dezember 2024 um 14:20 UTCresolved

   Ein Serverfehler führt dazu, dass einige Datei-Uploads für eine begrenzte Anzahl von Konten fehlschlagen. Das Problem wird gelöst. Wenn Sie fehlgeschlagene Uploads haben, halten Sie bitte an und versuchen Sie es später erneut.

2. 19. Dezember 2024 um 18:09 UTCresolved

   Das Problem ist gelöst. Eine ungewöhnlich große Anzahl von Servern scheiterte gleichzeitig. Sirv wurde entwickelt, um den normalen betrieb während eines serverausfalls fortzusetzen, und alle systeme wurden wie gewohnt fortgesetzt, aber einige datei-uploads sind fehlgeschlagen. Wir überlegen, welche möglichen Änderungen vorgenommen werden könnten, um in solchen Situationen in Zukunft zu helfen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. November 2024 um 09:52 UTCinvestigating

   Eine erhöhte Anzahl von 504 Timeouts wird für API-Datei-Upload-Anfragen zurückgegeben.

2. 14. November 2024 um 13:19 UTCinvestigating

   Es gibt weiterhin eine starke Belastung der API durch Upload-Anfragen. Ein beitragender Faktor ist die große Anzahl von AI-Image-Upscaling-Anfragen, deren Verarbeitung länger dauert als gewöhnlich. Die Verzögerung, die durch die Warteschlange von Anfragen verursacht wird, führt dazu, dass einige API-Datei-Upload-Anforderungen mit einer 504-Antwort fehlschlagen.

3. 14. November 2024 um 15:23 UTCresolved

   Es wurden Änderungen vorgenommen und das Problem ist fast gelöst. Die meisten Upload-Anfragen sind erfolgreich.

4. 14. November 2024 um 19:06 UTCresolved

   Die API-Upload-Überlastung ist fast vollständig gelöst.

5. 15. November 2024 um 04:42 UTCresolved

   Das Problem ist vollständig gelöst. Das Problem begann, als API-Anfragen zur Hochskalierung von schweren Bildern die Upload-API überlasteten, was dazu führte, dass einige API-Anfragen 504-Fehler zurückgaben. Dies wurde gelöst, aber ein Knock-on-Effekt führte dazu, dass etwa 5% der API-Anforderungen mit einer 502-Antwort fehlschlugen. Um zu verhindern, dass sich dieses Problem wiederholt, wurden Verbesserungen vorgenommen, um die Belastung durch Bild-Upscaling zu reduzieren und die Belastung besser zu verteilen. Es werden auch Änderungen an der Protokollierung und Alarmierung vorgenommen, um solche Szenarien schneller zu identifizieren. Der größte Einfluss dieses Problems war das Sirv WordPress Plugin. Das Plugin sendete eine API-Anfrage auf allen Admin-Seiten, wodurch das Laden der Seite blockiert wurde, bis die Antwort empfangen wurde - normalerweise weniger als 300 ms, aber bis zu 20 Sekunden, wenn API-Anfragen ausgefallen sind. Diese API-Anfragen waren nicht erforderlich, daher wurde eine neue WordPress-Plugin-Version v7.3.3 bei 1805 UTC (14. November) veröffentlicht, um solche Anfragen zu entfernen und zu verhindern, dass sich dieses Problem wiederholt: https://wordpress.org/plugins/sirv/ ------- Wenn Sie die Sirv-API verwenden, empfehlen wir, dass Ihre Skripte für Wiederholungsanforderungen geschrieben werden, die eine Antwort von 502 erhalten. Empfehlungen für den Umgang mit 502 und anderen Fehlerantworten finden Sie hier: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. Februar 2024 um 10:52 UTCinvestigating

   Einige Dateien werden nicht für eine kleine Anzahl von Konten zurückgegeben. Dieses Problem wird dringend angegangen.

2. 22. Februar 2024 um 12:06 UTCresolved

   Das Problem ist gelöst. Bei 1052 UTC gaben etwa 11% der Anfragen an eine kleine Anzahl von Konten (12 Konten, von 50.000+) 404 Antworten zurück (Datei nicht gefunden), obwohl sie 200 Antworten hätten zurückgeben sollen (OK). Als das Sirv-Team das Problem identifizierte, arbeitete es schnell daran, es zu lösen, und bis 1206 UTC gaben alle diese Anfragen die normale Antwort von 200 zurück. Das Problem trat aufgrund einer Fehlkonfiguration von Sirv-Ingenieuren auf, während sie einen neuen Storage-Cluster-Shard konfigurierten. Einige Anfragen gingen an die neue Scherbe, bevor sie bereit war, sie zu erhalten. Klassifiziert als Schweregrad 3: Geringfügige Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 5. Januar 2024 um 20:21 UTCinvestigating

   Eine hohe Anzahl von Anfragen an die 25 CDN-Standorte von Sirv gibt einen Fehler zurück. Unsere Ingenieure arbeiten schnell daran, das Problem zu identifizieren und zu lösen.

2. 5. Januar 2024 um 21:07 UTCresolved

   Das Problem ist gelöst. Es wurde durch den Ausfall eines Software-Daemons gleichzeitig auf mehreren Servern verursacht. Dies ist ein leichter und hocheffizienter Servicemanager, der in der Vergangenheit nie versagt hat. Während des Zeitraums gaben zwischen 3% und 58% der HTTPS-Anfragen einen Fehler zurück, je nachdem, welcher der 25 CDN-Standorte die Anfrage erhalten hatte. Wir untersuchen nun, warum dies passiert ist, und werden Maßnahmen ergreifen, um zu verhindern, dass sich dies in Zukunft auf die Verfügbarkeit des Dienstes auswirkt. Klassifiziert als Schweregrad 2: Bedeutungsvolle Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 5. Dezember 2023 um 15:03 UTCinvestigating

   Auf dem CDN tritt ein erhöhter Fehlerpegel von 415 auf. Unsere Ingenieure untersuchen die Ursache.

2. 5. Dezember 2023 um 18:32 UTCinvestigating

   Wir werden die Ursache dieses Problems weiter untersuchen. Die Natur ist komplex. Es stellt sich als 415-Fehler aus Dateien von Nullbytes dar. Es gibt auch eine erhöhte, aber niedrigere Rate von 500 Fehlern. Die meisten Anfragen sind erfolgreiche 200 Antworten. Unsere Ingenieure arbeiten hart daran, dies zu verstehen und zu lösen.

3. 5. Dezember 2023 um 22:56 UTCresolved

   Das Fehlerproblem 415 wurde dadurch verursacht, dass einige Dateien abgeschnitten wurden, was bedeutet, dass sie einen Teil ihres Inhalts verloren haben. Diese Dateien zeigen im Bedienfeld bei my.sirv.com 0 Bytes. Dateien, die heute hochgeladen wurden, wurden eher gekürzt, obwohl es scheint, dass die Verkürzung schon seit langem mit Dateien geschieht. Dies wurde nicht identifiziert, weil sie völlig normal durchgeführt, aufgrund von Caching von nicht-truncated Versionen. Das verkürzte Dateiproblem wurde erst heute nach einem Infrastruktur-Upgrade bemerkbar. Server-Caches wurden gelöscht und die verkürzten Versionen wurden offensichtlich. Es wird angenommen, dass die Ursache für die Verkürzung ein Softwarefehler war, der jetzt behoben wurde. Wir arbeiten derzeit daran, verkürzte Dateien wiederherzustellen - ein Prozess, der Stunden bis Tage dauern kann. Wenn Sie in der Lage sind, alle Dateien neu zu laden, die derzeit nicht geladen werden, tun Sie dies bitte jetzt. Es wird geschätzt, dass das Problem etwa ~0,2% der Dateien betrifft.

4. 5. Dezember 2023 um 23:33 UTCresolved

   Etwa 80% der abgeschnittenen Dateien wurden wiederhergestellt. Die Zahl von 415 Fehlern ist deutlich gesunken, obwohl sie erhöht bleiben. Um das Problem vollständig zu lösen, müssen die verbleibenden gekürzten Dateien durch die ursprüngliche Datei ersetzt werden. Wir arbeiten an Möglichkeiten, diese verbleibenden Dateien wiederherzustellen, obwohl sie schwer zu bekommen sind und es Stunden oder Tage dauern kann. Für die schnellstmögliche Auflösung wird empfohlen, die Dateien erneut hochzuladen. Solche Dateien werden in Ihrem Konto als 0 Bytes angezeigt. Beginnen Sie unter der folgenden URL, um eine Liste aller Dateien zu sehen, die in den letzten 30 Tagen hochgeladen wurden: https://my.sirv.com/#/search/?created=30d Finden Sie alle Null-Byte-Dateien, indem Sie die Ergebnisse nach Größe, Aufsteigend sortieren. Ein weiteres Update wird hier veröffentlicht, sobald wir Neuigkeiten zu den verbleibenden Dateien haben.

5. 6. Dezember 2023 um 01:48 UTCinvestigating

   Wir werden weiterhin die kleine Anzahl der verbleibenden abgeschnittenen Dateien wiederherstellen. Es wird geschätzt, dass dies weitere 12-24 Stunden erfordert. Wenn Sie Dateien haben, die nicht bedient werden, können Sie dies sofort lösen, indem Sie sie erneut hochladen. Wir erstellen ein Tool, um eine Liste von Null-Byte-Dateien zu generieren. Wenn Sie eine Liste mit Null-Byte-Dateien in Ihrem Konto wünschen, senden Sie bitte eine Anfrage unter https://sirv.com/help/support/#support und wir werden eine Liste erstellen, sobald das Tool fertig ist. Unabhängig davon werden wir weiterhin daran arbeiten, alle Dateien wiederherzustellen. Wenn Sie Dateien mit der Autofetch-Funktion von Sirv hochladen, können Sie die Null-Byte-Dateien einfach löschen und sie werden bei der nächsten Anforderung von Ihrem entfernten Standort erneut abgerufen.

6. 6. Dezember 2023 um 12:12 UTCresolved

   Weitere Dateien wurden wiederhergestellt. Die Rate von 415 Fehlern sinkt weiter. Sie können eine Liste von 415 Fehlern auf dieser Seite Ihres Kontos sehen: https://my.sirv.com/#/analytics/ersrors/415?from=20231206&to=20231206 Sie können Dateien hochladen, um 415 Fehler in Ihren Dateien zu beheben. Wir können Ihnen bei Bedarf eine Liste von Null-Byte-Dateien zur Verfügung stellen - fragen Sie bitte das Sirv-Support-Team über dieses Formular: https://sirv.com/help/support/#support Wir werden weiterhin so viele Dateien wie möglich wiederherstellen.

7. 6. Dezember 2023 um 19:47 UTCresolved

   Das Problem, das die erhöhte Rate von 415 Fehlern verursacht hat, wurde behoben. Die verkürzten Dateien wurden durch ein Softwareproblem verursacht, bei dem einige Dateien mit Nullbytes geschrieben wurden. Da es sich um Software handelte, wurden die verkürzten Dateien in allen Versionen der Masterdatei repliziert. Sirv verdreifacht jede Datei, um vor Hardwareproblemen (Server- oder Festplattenausfällen) zu schützen, die aktualisierten Dateien haben jedoch alle Prüfungen bestanden und die Dateien treu verdreifacht. Es existierte ohne Erkennung, da zwischengespeicherte Versionen der Dateien für die Verarbeitung und Lieferung verwendet wurden. Alle Systeme funktionierten perfekt, bis zum gestrigen Infrastruktur-Upgrade, als zwischengespeicherte Dateien gelöscht wurden. Die Ursache wurde durch die Identifizierung und Korrektur des Softwareproblems, das die Verkürzung verursachte, gelöst. Dies wurde von 1500 UTC am 5. Dezember abgeschlossen. Dann war die Aufgabe, die Dateien wiederherzustellen, die abgeschnitten worden waren. Auf der gesamten Plattform waren etwa 0,2% der Dateien betroffen. Von diesen Dateien konnten wir je nach Konto zwischen 95% und 100% wiederherstellen. Jedes Konto, das weniger als 100% Wiederherstellung hatte, wird eine Liste von Null-Byte-Dateien gesendet, die durch erneutes Hochladen der Dateien wiederhergestellt werden sollten. Bitte achten Sie auf unsere E-Mail mit einer Liste von Dateien. Bitte senden Sie uns eine Nachricht über die folgende URL, wenn Sie Hilfe benötigen: https://sirv.com/help/support/#support Eine gründliche Untersuchung des Problems ist im Gange, die ausführlich per E-Mail gemeldet wird. In dem Bericht wird eine Liste von Maßnahmen enthalten sein, die ergriffen werden, um eine mögliche Wiederholung dieses Problems zu verhindern, zusammen mit Verbesserungen und neuen Funktionen, die bereits entwickelt werden. Wir entschuldigen uns bei allen Kunden, die von diesem Problem betroffen waren. Es ist das erste Mal, dass Stammdaten verloren gehen. Wir werden jede mögliche Lektion daraus lernen und Sirv noch stärker und zuverlässiger machen als zuvor.

8. 21. Dezember 2023 um 10:05 UTCresolved

   Mehr als 99% der verbleibenden abgeschnittenen Dateien wurden nun ebenfalls wiederhergestellt. Jeder betroffene Benutzer hat eine genaue Liste der betroffenen Dateien erhalten. Es gibt keine verbleibenden Auswirkungen von diesem Problem. Einstufung als Schweregrad 1: Kritische Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 2. Dezember 2023 um 04:19 UTCinvestigating

   Ab 0419 UTC wurde ein erhöhtes Niveau von 429 Fehlern vom Sydney CDN-Standort zurückgegeben.

2. 2. Dezember 2023 um 10:31 UTCresolved

   Das Problem wurde bei 1031 UTC gelöst. Die Ursache war eine Server-Fehlkonfiguration, die den Sydney CDN-Standort dazu brachte, alle Anfragen von derselben IP-Adresse anstelle der wahren Client-IP-Adresse zu sehen. Dies löste einen DDOS-Schutz aus, um die übermäßige Anzahl von Anfragen aus derselben IP zu begrenzen. 429 Antworten wurden für viele der Anfragen zurückgegeben. Das Problem schien ein extrem kurzes Problem gewesen zu sein, als das Sydney Datacenter-Netzwerk nicht mehr verfügbar war. Dieses Problem dauerte nur etwa 1 Minute. Der eigentliche vorfall begann jedoch unmittelbar nachdem unser team den cdn-standort in sydney wiederhergestellt hatte, als die server-fehlkonfiguration angewendet wurde. Das Problem wurde gelöst, nachdem wir die Fehlkonfiguration entdeckt und korrigiert hatten. Es werden mehrere Maßnahmen ergriffen, um eine Wiederholung dieses Problems zu verhindern und die Auswirkungen ähnlicher, aber unterschiedlicher Probleme in Zukunft zu verringern: - Zusätzliche Überwachung und Warnung - Neues Einreichungsformular - Context sensitive resolution advice - Weitere interne Alarmierung Nur der Sydney CDN-Standort war betroffen. Klassifiziert als Schweregrad 3: Geringfügige Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. November 2023 um 18:30 UTCinvestigating

   Um ca. 1830 UTC am 22. November begannen wir ein Upgrade auf die primäre Dateidatenbank zu einem neuen, leistungsfähigeren Cluster. Während das Upgrade stattfand, scheiterten API-Suchanfragen.

2. 23. November 2023 um 10:35 UTCresolved

   Um 1035 UTC am 23. November war das Upgrade abgeschlossen und die Suche wurde wieder normalisiert. Es gab keine Ausfallzeiten und alle Systeme funktionierten normal, außer dass API-Suchanforderungen Fehlerantworten zurückgegeben hatten. Das Problem wurde nicht identifiziert, da andere API-Anforderungen wie gewohnt zurückkehrten, so dass die Gesamtantworten für API-Fehler nur geringfügig erhöht waren und keine Warnungen ausgelöst wurden. Das Problem wurde nach dem Ereignis identifiziert, nachdem ein Bericht eines Benutzers eine Untersuchung veranlasst hatte. Um solche Probleme in Zukunft automatisch zu erkennen, prüfen wir Möglichkeiten, die Such-API gezielt zu überwachen. Wir werden auch das sirv wordpress plugin aktualisieren, um eine klar beschriebene nachricht im falle einer fehlgeschlagenen suche anzuzeigen. Klassifiziert als Schweregrad 4: Minimale Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. November 2023 um 20:47 UTCinvestigating

   Die Dateiverwaltungstools bei my.sirv.com werden aufgrund eines ausgefallenen Servers langsam geladen. Dateiauflistung und Dateisuche dauert 2 bis 20 Sekunden, während es normalerweise 1 bis 4 Sekunden dauert. Der ausgefallene Server wird ersetzt und wir erwarten, dass die Geschwindigkeit innerhalb von 72 Stunden wieder normal wird. Es folgt ein umfangreiches Upgrade des gesamten Control Panel Server Clusters in den nächsten 3 Monaten.

2. 14. November 2023 um 21:33 UTCinvestigating

   Wir warten auf die Bereitstellung eines neuen Servers, der dem Cluster hinzugefügt wird, dann wird die UI-Navigationsgeschwindigkeit viel schneller.

3. 15. November 2023 um 14:09 UTCresolved

   Der neue Server wurde am Abend des 14. November eingesetzt und füllte nach und nach seine Caches. Das Bedienfeld ist nun zu seiner ursprünglichen schnellen Leistung zurückgekehrt. Zusätzliche Server werden jetzt aktualisiert, so dass das Bedienfeld in den kommenden 2 Wochen noch schneller geladen wird. Klassifiziert als Schweregrad 4: Minimale Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. Oktober 2023 um 13:10 UTCinvestigating

   Ein dramatischer Anstieg der Anfragen an den CDN-Standort in Washington DC erfolgte am 23. Oktober um 14:10 Uhr UTC, was dazu führte, dass ein kleiner Teil der Anfragen langsam zurückgegeben wurde - mehr als 2 Sekunden. Das Problem ließ in den nächsten 3 Stunden nach, obwohl die durchschnittliche Reaktionszeit erhöht blieb. Das Problem kehrte am folgenden Tag um 14: 32 UTC am 24. Oktober zurück, schwerer als zuvor, was dazu führte, dass 17% der Anfragen langsam geladen wurden - mehr als 2 Sekunden und einige so lange wie 30 Sekunden. Das Problem betraf zwei der 25 CDN-Standorte von Sirv.

2. 25. Oktober 2023 um 05:48 UTCresolved

   Das Problem wurde am 25. Oktober um 06:48 UTC gelöst. Die Untersuchung weist auf zwei Ursachen hin - der Anstieg wurde durch Sirvs DNS-Anbieter verursacht, der stattdessen POP-Anfragen in Los Angeles an den POP in Washington DC weiterleitete. Dies wäre isoliert in Ordnung gewesen, aber das Rechenzentrum scheint die Bandbreite der empfangenden Server gedrosselt zu haben, was zu den langsamen Reaktionen führte. Die Untersuchung ist im Gange, hat noch keine endgültigen Schlussfolgerungen gezogen und erfordert die Zusammenarbeit mit unseren DNS- und Rechenzentrumsanbietern. Es werden bereits Maßnahmen ergriffen, um eine mögliche Wiederholung dieses Problems zu verhindern. Ein ausführlicher Bericht wird hier später zur Verfügung gestellt.

3. 14. November 2023 um 13:37 UTCresolved

   Die detaillierte Untersuchung dieses Problems ergab zwei beitragende Faktoren. Das erste war ein Update auf AWS Route53, das anscheinend am 17. Oktober von AWS implementiert wurde. Diese Änderung wurde nicht von Sirv an seinen Route53-Regeln vorgenommen, sondern eine Änderung innerhalb des Route53-Dienstes selbst. Die Los Angeles POP hatte eine etwas andere Routing-Logik als andere POPs und das AWS-Update veranlasste das Routing, sich anders zu verhalten, wobei der Datenverkehr zum Fallback von Washington DC geleitet wurde. Dies ging unbemerkt, da die höhere Last noch in ihrer Kapazität war und Anfragen erfolgreich zurückgegeben wurden, so dass dies unbemerkt blieb, da Washington DC in der Lage war, die zusätzliche Last zu bewältigen. Der zweite beitragende Faktor war höher als der normale Verkehr während der US-Handelszeiten am 23. und 24. Oktober. Die beiden Faktoren zusammen führten dazu, dass die Festplatten in Washington DC Anfragen deutlich langsamer als normal zurückgaben. Seitdem das Problem aufgetreten ist, haben wir mehrere Maßnahmen ergriffen, um zu verhindern, dass es sich wiederholt; um ähnliche mögliche Vorfälle zu mildern; und um die Lösungszeit im Falle eines Vorfalls zu beschleunigen. Aktionen umfassen: - Neue Routing-Logik wurde angewendet. Die Kapazität von Washington DC wurde erhöht. - Die Reservekapazität wurde in allen anderen CDN-Standorten erhöht. - Neue Toleranz, die eingeführt wurde, damit ein CDN-Standort aus dem Routing entfernt wird. - Zusätzliche Festplattenüberwachung zur frühzeitigen Vorbereitung von Kapazitätsupgrades. HDDs werden durch SSDs ersetzt. - Aktualisierte SOP für unser Support-Team, um ähnliche Probleme zu untersuchen und zu beantworten. Klassifiziert als Schweregrad 3: Geringfügige Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. Mai 2023 um 14:57 UTCinvestigating

   Das frühere Problem der hohen Upload-Nutzung kehrte zurück, wobei eine kleine Anzahl von API-Uploads fehlschlug.

2. 22. Mai 2023 um 15:06 UTCresolved

   Das Problem löste sich innerhalb von 9 Minuten, nachdem sich das Upload-Volumen normalisiert hatte. Während des Zeitraums waren etwa 98% der Uploads erfolgreich und 2% scheiterten. REST-API-Uploads sind pro Stunde auf den auf der Nutzungsseite Ihres Sirv-Kontos angegebenen Betrag begrenzt https://my.sirv.com/#/account/usage. Wenn Sie die REST-API zum Hochladen von Bildern verwenden, ist es am besten, die Antwort für jede Upload-Anfrage zu überprüfen, und wenn Sie eine Fehlerantwort erhalten (400, 401, 429 usw.), dann halten Sie Uploads an und versuchen Sie es später erneut. Siehe die Dokumente hier: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Klassifiziert als Schweregrad 4: Minimale Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. Mai 2023 um 11:31 UTCinvestigating

   Eine kleine Anzahl von REST-API-Upload-Anforderungen schlägt aufgrund einer sehr hohen Belastung fehl.

2. 22. Mai 2023 um 12:37 UTCresolved

   Dieses Problem löste sich von selbst, sobald die Belastung der Upload-API zu sinken begann. Während des Zeitraums waren etwa 97% der Uploads erfolgreich und 3% scheiterten. REST-API-Uploads sind pro Stunde auf den auf der Nutzungsseite Ihres Sirv-Kontos angegebenen Betrag begrenzt https://my.sirv.com/#/account/usage. Wenn Sie die REST-API zum Hochladen von Bildern verwenden, ist es am besten, die Antwort für jede Upload-Anfrage zu überprüfen, und wenn Sie eine Fehlerantwort erhalten (400, 401, 429 usw.), dann halten Sie Uploads an und versuchen Sie es später erneut. Siehe die Dokumente hier: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Klassifiziert als Schweregrad 4: Minimale Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 27. April 2023 um 23:00 UTCinvestigating

   Einer der CDN-Server in Los Angeles wurde ungesund und begann, 4xx Fehler bei 0000 UTC zurückzugeben. Es wurde nach 90 Sekunden aus dem Routing entfernt und innerhalb von weiteren 60 Sekunden wurde der gesamte Datenverkehr an gesunde Server weitergeleitet.

2. 27. April 2023 um 23:03 UTCresolved

   Das Problem wurde automatisch innerhalb von 3 Minuten behoben. Klassifiziert als Schweregrad 4: Minimale Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. März 2023 um 12:17 UTCinvestigating

   Einige Anfragen an den Londoner POP von Sirv CDN geben Fehler aufgrund hoher Belastung zurück. Dieser POP dient Großbritannien und Irland. Wir arbeiten an einer Entschließung.

2. 16. März 2023 um 13:33 UTCresolved

   Das Problem ist gelöst und wird jetzt überwacht.

3. 16. März 2023 um 16:22 UTCresolved

   Einige anfragen, die von einem der londoner cdn-server erhalten wurden, scheiterten an einer kombination aus lokaler dns-auflösung und pulsierenden netzwerk-timeouts. Das Problem begann um 1215 UTC und wurde um 1332 UTC gelöst. Während dieses Zeitraums gaben 25% der Anfragen aus Großbritannien und Irland einen Fehler von 404 oder 500 zurück. Das Problem wäre früher gelöst worden, aber ein Fehler bei der Validierung eines nicht verwandten SSL-Zertifikats einige Stunden zuvor blockierte den Empfang von Warnungen durch unser Überwachungssystem. Es wurden bereits Änderungen vorgenommen, um zu verhindern, dass sich dieses Problem wiederholt. Das Problem mit dem SSL-Zertifikat wurde behoben; eine zweite Ebene der unabhängigen Überwachung wurde konfiguriert; eine zusätzliche Gesundheitsautomatisierung wird getestet, die das Potenzial hat, solche Probleme automatisch zu lösen. Klassifiziert als Schweregrad 3: Geringfügige Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. Februar 2023 um 07:55 UTCresolved

   Das Problem wurde um 0755 UTC gelöst. Um 0625 UTC begannen einige Anfragen an den Indore CDN POP, der Indien bedient, eine 404-Antwort (Datei nicht gefunden) anstelle einer 200-Antwort (OK) zurückzugeben. Das Problem trat 14 Stunden nach einem Update auf alle CDN-Server weltweit auf. Alle POPs verhielten sich gesund, einschließlich des Indien POP, aber der Indore POP hatte nicht erfolgreich aktualisiert und begann schließlich, Fehler zurückzugeben. Nachdem das Problem identifiziert worden war, wurde es durch die erneute Bereitstellung des Updates für den indischen POP behoben. Während des Vorfalls gaben 94% der Anfragen einen Fehler zurück. Anfragen an alle anderen Länder wurden wie gewohnt zurückgegeben. Um zu verhindern, dass sich dieses Problem wiederholt, wird eine neue automatisierte Bereitstellungsregel für einen Teil des Bereitstellungsprozesses erstellt, bei dem nur eine menschliche Überprüfung stattgefunden hat. Außerdem wird eine zusätzliche Alarmierungsmetrik erstellt, um eine Situation zu identifizieren, in der eine Bereitstellung fehlgeschlagen ist. Wir entschuldigen uns bei allen Kunden, die von diesem Vorfall betroffen waren, und prüfen weitere Änderungen, die dazu beitragen können, eine mögliche Wiederholung des Problems zu verhindern. Wenn ein CDN-Problem wie dieses auftritt, besteht eine sofortige Lösung Ihrer Kontrolle darin, das CDN vorübergehend in Ihren Sirv-Einstellungen zu deaktivieren: https://my.sirv.com/#/account/settings/domains Klassifiziert als Schweregrad 2: Bedeutungsvolle Auswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.