Zeitleiste Internetausfälle

Am 1. Oktober 2024 kam es bei TIBCO Mashery, einer API-Verwaltungsplattform für Unternehmen, die von einigen der bekanntesten Marken der Welt genutzt wird, zu einem erheblichen Ausfall. Um etwa 7:10 AM ET traten bei den Benutzern SSL-Verbindungsfehler auf. Internet Sonar fand heraus, dass die Ursache nicht in einem SSL-Fehler lag, sondern in einer DNS-Fehlkonfiguration, die den Zugriff auf wichtige Dienste beeinträchtigte.

Der Ausfall von Mashery zeigt eine wichtige Lektion: SSL-Fehler können nur die Spitze des Eisbergs sein. Das eigentliche Problem liegt oft tiefer, wie in diesem Fall bei einer DNS-Fehlkonfiguration. Wenn DNS nicht richtig konfiguriert oder überwacht wird, kann das gesamte System ausfallen, und was wie ein einfacher SSL-Fehler aussieht, kann sich zu einem viel größeren Problem auswachsen. Um sich wirklich gegen die Anfälligkeit des Internets zu schützen, benötigen Sie einen vollständigen Einblick in jede Schicht des Internet-Stacks, von DNS bis SSL und darüber hinaus.

Am 17. September 2024 kam es bei Reliance Jio zu einem größeren Netzwerkausfall, von dem Kunden in mehreren Regionen in Indien und weltweit betroffen waren. Der Ausfall wurde zunächst bemerkt, als Nutzer beim Versuch, auf die AJIO- und Jio-Webseiten zuzugreifen, Verbindungszeitüberschreitungen aufwiesen. Der Ausfall wurde um 05:42 EDT behoben.

Die vollständige Transparenz des gesamten Internet-Stacks, einschließlich externer Abhängigkeiten wie CDN, DNS und ISPs, ist für Unternehmen entscheidend. Eine proaktive Überwachung ist für die frühzeitige Erkennung von Problemen wie Paketverlusten und Latenzzeiten unerlässlich und hilft Unternehmen, Risiken zu mindern, bevor sie zu größeren Ausfällen eskalieren.

Am 15. August, um 14:15 Uhr ET, kam es bei ServiceNow zu einem erheblichen Ausfall, der 2 Stunden und 3 Minuten dauerte. Catchpoint Der Internet-Sonar von ServiceNow entdeckte die Unterbrechung durch erhöhte Antwort- und Verbindungszeitüberschreitungsfehler an wichtigen geografischen Standorten. Die Unterbrechung, die durch eine instabile Konnektivität mit dem Upstream-Provider Zayo (AS 6461) verursacht wurde, beeinträchtigte die Kerndienste und Kundenintegrationen von ServiceNow. Der Ausfall führte zu einer unregelmäßigen Serviceverfügbarkeit, wobei die Benutzer mit hohen Verbindungszeiten und häufigen Timeouts konfrontiert wurden.

Ein proaktiver Ansatz bei der BGP-Überwachung ist entscheidend, um längere Ausfälle zu vermeiden. Die schnelle Reaktion von ServiceNow bei der Umleitung des Datenverkehrs ist ein gutes Beispiel dafür, wie ein effektives Störungsmanagement und die Übernahme von Verantwortung durch den Anbieter den Unterschied ausmachen können, damit der Betrieb aufrechterhalten wird und die Benutzer zufrieden sind.

Am 14. August, zwischen 8:00 und 8:25 UTC, kam es bei AWS zu einem Mikroausfall, der Dienste wie S3, EC2, CloudFront und Lambda betraf. Catchpoint Der Internet-Sonar von AWS erkannte Verbindungszeitüberschreitungen in mehreren Regionen, insbesondere an Standorten, die über CenturyLink AS209 und Lumen AS3356 geleitet wurden. Diese Unterbrechung wurde zwar nicht auf der AWS-Statusseite angezeigt, hatte jedoch erhebliche Auswirkungen auf den Zugriff dieser Regionen auf AWS-Dienste.

Statusseiten sind nicht immer zuverlässige Indikatoren für den Zustand des Dienstes. Wenn Sie sich nur auf Cloud-basierte Überwachungstools verlassen, haben Sie ein Problem, wenn deren Cloud ausfällt. Es ist eine gute Praxis, Ihre Überwachungsstrategie zu diversifizieren und einen Ausweichplan zu haben, um die Ausfallsicherheit des Internets zu gewährleisten. Eine klare Kommunikation hilft Ihnen außerdem, das Vertrauen Ihrer Nutzer zu erhalten.

Am 31. Juli um 20:12 EDT kam es bei Disney Plus zu einem kurzen Ausfall, der 38 Minuten dauerte. Catchpoint entdeckte 502 Bad Gateway-Fehler von mehreren Knotenpunkten, ein Problem, das sowohl durch automatisierte Tests als auch durch manuelles Browsing bestätigt wurde. Die Störung war um 20:50 Uhr EDT behoben.

Dieser Vorfall zeigt, warum es so wichtig ist, Ihre Dienste von mehreren Punkten aus zu überwachen, um Ausfälle schnell zu erkennen und zu verifizieren. Selbst kurzzeitige Unterbrechungen können die Benutzerfreundlichkeit beeinträchtigen, weshalb eine kontinuierliche Überwachung und schnelle Reaktion unerlässlich sind.

Am 23. Juli, von 14:35 bis 14:52 Uhr, trat auf der Website von Alaska Airlines (www.alaskaair.com) ein 404 Not Found-Fehler auf, der die Website für etwa 20 Minuten unzugänglich machte. Catchpoint erkannte das Problem und bestätigte die Fehler in mehreren Tests. Die Antwort-Header wiesen darauf hin, dass das Problem von Konfigurationsfehlern herrührte, was durch den 404-Fehler und die anschließenden Cache-Miss-Antworten belegt wurde.

Ab 21:23 Uhr EDT am 23. Juli kam es in mehreren Regionen zu zeitweiligen Ausfällen von Microsoft Outlook. Die Benutzer erhielten verschiedene Fehlermeldungen, darunter 404 Not Found, 400 Bad Request und 503 Service Unavailable, wenn sie versuchten, auf https://www.outlook.com/ und https://outlook.live.com/owa/ zuzugreifen. CatchpointDer Internet-Sonar von Microsoft hat das Problem durch mehrere Tests festgestellt, während die offizielle Statusseite von Microsoft zu diesem Zeitpunkt keine Ausfälle gemeldet hat.

Dies ist ein weiteres Beispiel dafür, dass intermittierende Probleme, die die größte Bedrohung für die Beobachtbarkeit darstellen können, möglicherweise nicht auf den offiziellen Statusseiten angezeigt werden. Angesichts der hohen Kosten von Internetunterbrechungen kann selbst eine kurze Verzögerung bei der Behebung dieser Probleme außerordentlich teuer werden. Und wenn Sie darauf warten, dass Ihr Provider Ihnen mitteilt, wenn etwas nicht in Ordnung ist, kann diese Verzögerung sogar noch länger sein.

Am 18. Juli, beginnend um 18:36 Uhr EDT, kam es in der Azure-Region US Central zu einem größeren Service-Ausfall, der bis 22:17 Uhr EDT dauerte. Zunächst wurden 502 Bad Gateway-Fehler gemeldet, gefolgt von 503 Service Unavailable-Fehlern. Von diesem Ausfall waren zahlreiche Unternehmen betroffen, die auf Azure-Funktionen angewiesen sind, sowie Microsoft 365-Dienste wie SharePoint Online, OneDrive und Teams, bei denen es zu erheblichen Unterbrechungen kam.

Dieser Vorfall ereignete sich innerhalb von 24 Stunden nach einem separaten CrowdStrike-Ausfall, was in den Medien zu Verwirrung führte, da beide Probleme gleichzeitig gemeldet wurden. Unternehmen, die sich ausschließlich auf Azure verlassen und keine Multi-Regionen- oder Multi-Cloud-Strategien verfolgen, waren erheblich betroffen, insbesondere diejenigen, die eCommerce-APIs verwenden. CatchpointInternet Sonar erkannte den Ausfall frühzeitig und half dabei, das Problem einzugrenzen und zu bestätigen, dass es nicht mit Netzwerkproblemen zusammenhing, wodurch Zeit für unnötige Fehlersuche gespart wurde.

Am 19. Juli kam es weltweit zu einem massiven Ausfall kritischer Dienste, von dem auch Systeme betroffen waren, die auf Microsoft-Computer angewiesen sind. Der Ausfall, der durch ein fehlerhaftes automatisches Software-Update des Cybersicherheitsunternehmens CrowdStrike verursacht wurde, setzte PCs und Server von Microsoft außer Betrieb und zwang sie in eine Wiederherstellungs-Bootschleife. Dieser beispiellose Ausfall hatte Auswirkungen auf das tägliche Leben auf globaler Ebene, legte Fluggesellschaften lahm, brachte Notdienste außer Betrieb und stoppte den Betrieb von Großbanken und Unternehmen.

Der Ausfall von CrowdStrike ist ein Weckruf dafür, wie anfällig unsere digitale Welt wirklich ist. Alles, was wir tun, hängt von diesen Systemen ab, und wenn sie ausfallen, sind die Auswirkungen enorm. Dieser Vorfall zeigt, wie wichtig es ist, vorbereitet zu sein. Kennen Sie Ihre Abhängigkeiten, testen Sie Aktualisierungen, als ob Ihr Unternehmen davon abhinge (denn das tut es), und haben Sie einen Plan für den Fall, dass etwas schief läuft. Gehen Sie nicht einfach davon aus, dass alles funktionieren wird, sondern stellen Sie es sicher. Und denken Sie daran, dass es bei der Ausfallsicherheit nicht nur um Ihre Technik geht, sondern auch um Ihr Team. Halten Sie sie geschult, halten Sie sie bereit, und stellen Sie sicher, dass sie wissen, was zu tun ist, wenn das Unerwartete passiert.

Am 23. Mai, beginnend um 01:39 EDT, kam es bei Bing zu einem Ausfall mit mehreren 50X-Fehlern, von dem Nutzer weltweit betroffen waren. Das Problem wurde von Catchpoint's Internet Sonar entdeckt und durch manuelle Überprüfungen bestätigt. Durch den Ausfall wurde der Zugriff auf die Bing-Startseite unterbrochen, was sich auf die Nutzererfahrung in verschiedenen Regionen auswirkte.

Dieser Vorfall zeigt, wie wichtig es ist, eine zuverlässige Überwachung einzurichten. Schnelle Erkennung und Bestätigung sind entscheidend, um die Auswirkungen solcher Ausfälle zu minimieren.

Am 1. Mai, ab 10:40 Uhr Ostküste, kam es zu einem 34-minütigen Ausfall der Google-Dienste in mehreren Regionen, bei dem die Nutzer 502 Bad Gateway-Fehler erhielten. Das Problem betraf die Erreichbarkeit in Australien, Kanada und dem Vereinigten Königreich. Internet Sonar entdeckte den Vorfall und der Ausfall wurde auch durch manuelle Überprüfungen bestätigt.

Am 29. April, ab 03:29 EDT, kam es bei X (früher bekannt als Twitter) zu einem Ausfall, bei dem die Nutzer beim Versuch, auf die Basis-URL "twitter.com" zuzugreifen, lange Wartezeiten hatten. Das Problem wurde von Internet Sonar entdeckt, wobei von mehreren Standorten Ausfälle gemeldet wurden. Auch manuelle Überprüfungen bestätigten den Ausfall. Darüber hinaus wurden während dieser Zeit Verbindungszeitüberschreitungen bei DFS- und Walmart-Tests beobachtet, die auf fehlgeschlagene Anfragen an den Analysedienst von Twitter zurückzuführen waren und beide Plattformen weiter beeinträchtigten.

Am 30. April, beginnend um 03:00 EST, kam es bei den APIs von ChatGPT zu zeitweiligen Ausfällen aufgrund von HTTP 502 (Bad Gateway) und HTTP 503 (Service Unavailable) Fehlern. Mikro-Ausfälle wurden in verschiedenen Intervallen beobachtet, darunter 03:00-03:05 EST, 03:49-03:54 EST und 03:58-03:59 EST. Diese Unterbrechungen wurden von Catchpoint's Internet Sonar entdeckt und durch weitere Untersuchungen bestätigt.

Selbst kurze Mikroausfälle können die Dienste und das Nutzererlebnis beeinträchtigen. Frühzeitige Erkennung ist der Schlüssel zur Minimierung der Auswirkungen.

Am 25. Februar 2024, um 23:29 EST, kam es bei der ChatGPT-API von OpenAI zu sporadischen Fehlern. Die Hauptprobleme waren HTTP 502 Bad Gateway und HTTP 503 Service Unavailable Fehler beim Zugriff auf den Endpunkt https://api.openai.com/v1/models. Der Ausfall wurde manuell bestätigt, und das Internet-Sonar-Dashboard von Catchpointidentifizierte die Störung in mehreren Regionen, einschließlich Nordamerika, Lateinamerika, Europa, dem Nahen Osten, Afrika und dem asiatisch-pazifischen Raum. Die Probleme hielten bis zum nächsten Tag an, wobei 89 Städte Fehler während des Ausfalls meldeten.

Wie bei vielen Ausfällen im Zusammenhang mit APIs ist eine Überwachung in Echtzeit unerlässlich, um die Auswirkungen auf die Benutzer schnell zu mildern und die Zuverlässigkeit der Dienste in verschiedenen Regionen zu gewährleisten.

Am 26. Januar kam es bei Microsoft Teams zu einer globalen Dienstunterbrechung, die wichtige Funktionen wie Anmeldung, Nachrichten und Anrufe betraf. In ersten Berichten wurden 503 Service Unavailable-Fehler angezeigt, wobei das Problem durch synthetische Tests von Autodesk erfasst wurde. Später identifizierte Microsoft die Ursache als Netzwerkprobleme, die einen Teil des Teams-Dienstes beeinträchtigten. Der Failover-Prozess trug zunächst dazu bei, den Dienst in einigen Regionen wiederherzustellen, aber in Nord- und Südamerika kam es weiterhin zu anhaltenden Ausfällen.

Failover-Prozesse können viele Service-Probleme schnell beheben, aber dieser Ausfall zeigte, wie wichtig eine kontinuierliche Optimierung für eine vollständige Wiederherstellung in allen Regionen ist. Außerdem wurde deutlich, wie wichtig die Überwachung aus Sicht der Nutzer ist. Während der Unterbrechung schien Teams teilweise verfügbar zu sein, was einige Benutzer zu der Annahme verleitete, das Problem läge auf ihrer Seite.

Am 15. Dezember, von 6:00 bis 9:11 Uhr Pazifikzeit, kam es bei Box zu einem erheblichen Ausfall, der wichtige Dienste wie das Tool "Alle Dateien", die Box-API und Benutzeranmeldungen beeinträchtigte. Der Ausfall führte zu einer Unterbrechung der Upload- und Download-Funktionen, so dass Benutzer keine Dateien freigeben oder auf ihre Konten zugreifen konnten. Die frühzeitige Erkennung durch proaktives Internet Performance Monitoring (IPM) half Box, die Auswirkungen des Ausfalls abzumildern. IPM löste bereits um 04:37 Uhr PST Warnmeldungen aus, lange bevor sich der Ausfall ausweitete.

Frühzeitige Erkennung und schnelle Reaktion sind der Schlüssel zur Minimierung von Ausfallzeiten, zur Verringerung finanzieller Verluste und zum Schutz des Markenrufs. Dieser Vorfall unterstreicht den Wert einer ausgereiften Strategie zur Überwachung der Internetleistung, der Festlegung der richtigen Schwellenwerte zur Vermeidung von Fehlalarmen und der Gewährleistung, dass die Teams die Ursachen schnell identifizieren können, um die Systeme widerstandsfähig zu halten.

Von 8:00 Uhr EST am 8. Dezember bis 1:45 Uhr EST am 9. Dezember kam es in der Experience Cloud von Adobe zu einem größeren Ausfall, von dem mehrere Dienste wie Datenerfassung, Datenverarbeitung und Berichtsanwendungen betroffen waren. Der Ausfall, der fast 18 Stunden dauerte, beeinträchtigte den Betrieb für Adobes umfangreichen Kundenstamm und hatte Auswirkungen auf Unternehmen weltweit. Catchpoint Internet Sonar von Adobe war das erste Tool, das das Problem erkannte und Ausfälle im Adobe Tag Manager und anderen Diensten identifizierte, lange bevor Adobe seine Statusseite aktualisierte.

Ein weiteres Beispiel für die Anfälligkeit des Internets und ein weiterer Fall für Internet Sonar, das für die frühzeitige Erkennung und schnelle Reaktion unerlässlich war und dazu beitrug, die Ursache des Problems zu lokalisieren und die Ausfallzeit zu minimieren. Der Ausfall macht auch deutlich, wie wichtig eine proaktive Überwachung und Vorbereitung ist und wie hoch die potenziellen finanziellen und rufschädigenden Kosten von Serviceunterbrechungen sind.

Am 20. September, ab 10:51 AM EST, kam es bei Salesforce zu einer größeren Serviceunterbrechung, von der mehrere Dienste betroffen waren, darunter Commerce Cloud, MuleSoft, Tableau, Marketing Cloud und andere. Der Ausfall dauerte mehr als vier Stunden und hinderte einen Teil der Salesforce-Kunden daran, sich anzumelden oder auf wichtige Dienste zuzugreifen. Die Ursache war eine Richtlinienänderung, die die Sicherheit verbessern sollte und unbeabsichtigt den Zugriff auf wichtige Ressourcen blockierte, was zu Systemausfällen führte. Catchpoint entdeckte das Problem um 9:15 AM EST - fast eineinhalb Stunden bevor Salesforce das Problem offiziell bestätigte.

CatchpointIPM half dabei, das Problem zu identifizieren, lange bevor das Salesforce-Team es entdeckte, wodurch wertvolle Zeit gespart und Störungen minimiert werden konnten. Für Unternehmen, die in hohem Maße auf Cloud-Dienste angewiesen sind, ist eine IPM-Strategie, die Echtzeitdaten und eine rasche Ursachenermittlung in den Vordergrund stellt, entscheidend für die Aufrechterhaltung der Internet-Resilienz und die Vermeidung kostspieliger Ausfallzeiten.

Am 28. Juni 2023 wurde die Webversion von Microsoft Teams (https://teams.microsoft.com) weltweit unzugänglich. Benutzer erhielten die Meldung "Operation failed with unexpected error", wenn sie versuchten, über einen beliebigen Browser auf Teams zuzugreifen. Catchpoint entdeckte das Problem um 6:51 Uhr Eastern, wobei interne Tests HTTP 500-Antwortfehler anzeigten. Das Problem wurde manuell bestätigt, obwohl zu diesem Zeitpunkt auf der offiziellen Statusseite von Microsoft keine Updates verfügbar waren.

Am 25. Januar 2023, um 07:08 UTC/02:08 EST, kam es bei Microsoft zu einem weltweiten Ausfall, der mehrere Dienste, darunter Microsoft 365 (Teams, Outlook, SharePoint Online), Azure und Spiele wie HALO, beeinträchtigte. Die Störung dauerte etwa fünf Stunden. Die Ursache wurde auf eine WAN-Routing-Änderung (Wide Area Network) zurückgeführt. Eine einzige Aktualisierung der Router-IP-Adresse führte zu Problemen bei der Paketweiterleitung im gesamten WAN von Microsoft und verursachte weitreichende Unterbrechungen. Microsoft nahm die Änderung zwar wieder zurück, aber der Vorfall hatte weltweit erhebliche Auswirkungen, insbesondere für Nutzer in Regionen, in denen der Ausfall während der Arbeitszeit auftrat.

CatchpointIPM half dabei, das Problem zu identifizieren, lange bevor das Salesforce-Team es entdeckte, wodurch wertvolle Zeit gespart und Störungen minimiert werden konnten. Für Unternehmen, die in hohem Maße auf Cloud-Dienste angewiesen sind, ist eine IPM-Strategie, die Echtzeitdaten und eine rasche Ursachenermittlung in den Vordergrund stellt, entscheidend für die Aufrechterhaltung der Internet-Resilienz und die Vermeidung kostspieliger Ausfallzeiten.

Ab 12:51 Uhr ET am 5. Dezember 2022 stellte Catchpoint zeitweilige Fehler im Zusammenhang mit der Suchfunktion von Amazon fest. Das Problem hielt 22 Stunden lang bis zum 7. Dezember an und betraf etwa 20 % der Nutzer weltweit sowohl auf Desktop- als auch auf mobilen Plattformen. Die betroffenen Nutzer konnten nicht nach Produkten suchen und erhielten eine Fehlermeldung. Catchpoint stellte fest, dass die Ursache ein HTTP 503-Fehler war, der von Amazon CloudFront zurückgegeben wurde und die Suchfunktion während des Ausfalls beeinträchtigte.

Auch wenn nur ein kleiner Teil der Nutzer betroffen ist, können partielle Ausfälle schwerwiegende Folgen haben. Wenn man sich ausschließlich auf herkömmliche Überwachungsmethoden wie Protokolle und Traces verlässt, kann dies zu einer verzögerten Erkennung führen, insbesondere bei intermittierenden Problemen. Die Möglichkeit, die für das Problem verantwortliche Schicht des Internet-Stacks genau zu bestimmen, hilft den Technikern bei der Fehlersuche und Problembehebung.

Am 8. Juli 2022 kam es bei Rogers Communications zu einem größeren Ausfall, der fast zwei Tage lang einen Großteil Kanadas betraf und Internet- und Mobilfunkdienste beeinträchtigte. Ein Code-Update-Fehler legte das Kernnetz gegen 4 Uhr morgens lahm und beeinträchtigte sowohl drahtgebundene als auch drahtlose Dienste. Durch den Ausfall wurden wichtige Dienste wie 911-Anrufe, Unternehmen, Regierungsdienste und Zahlungssysteme wie Interac unterbrochen. Einige Dienste konnten nach 15 Stunden wiederhergestellt werden, andere blieben jedoch bis zu vier Tage lang außer Betrieb. Der Vorfall betraf Millionen von Kanadiern, löste weit verbreitete Frustration aus und machte die Risiken deutlich, die mit der starken Abhängigkeit von einem einzigen Telekommunikationsanbieter verbunden sind.

Testen Sie gründlich, bevor Sie Änderungen am Netz vornehmen, und stellen Sie sicher, dass Redundanzen vorhanden sind und funktionieren. Rogers dachte, es gäbe Redundanzen, aber sie funktionierten nicht, als sie am meisten gebraucht wurden. Schnelle Erkennung und Behebung sind entscheidend. Die langsame Reaktion von Rogers führte zu erheblichen finanziellen Verlusten, Rufschädigung und einer möglichen Sammelklage.

Am 22. Februar 2022, um 9:09 AM ET, traten bei Slack Probleme auf, die sich vor allem auf die Fähigkeit der Nutzer auswirkten, Konversationen und Nachrichten abzurufen. Die Benutzer konnten sich zwar anmelden, aber wichtige Funktionen waren nicht verfügbar, was zu weitreichenden Störungen führte. Das Problem trat zeitweise auf und beeinträchtigte die Produktivität vieler Unternehmen, die auf Slack als Kommunikationsmittel angewiesen sind. Catchpoint Tests bestätigten Fehler auf API-Ebene, die auf Probleme mit den Backend-Diensten von Slack und nicht mit dem Netzwerk hinwiesen.

Frühzeitige Erkennung und Echtzeittransparenz der Serviceleistung sind entscheidend. Die Möglichkeit, ein Problem schnell zu diagnostizieren und die Nutzer zu benachrichtigen, bevor eine Flut von Support-Tickets eintrifft, kann Ausfallzeiten und Frustration erheblich reduzieren. Die Überwachung aus der Nutzerperspektive ist von entscheidender Bedeutung, da sie dazu beiträgt, Probleme schneller und genauer zu erkennen als das Warten auf offizielle Service-Updates.

Im Dezember 2021 kam es bei AWS zu drei erheblichen Ausfällen:

1. 7. Dezember 2021: Ein längerer Ausfall, der von der Region US-EAST-1 ausging, störte wichtige Dienste wie Amazon, Disney+, Alexa und Venmo sowie wichtige Apps, die von Amazons Lager- und Liefermitarbeitern während der geschäftigen Weihnachtszeit genutzt wurden. Die Ursache war eine Beeinträchtigung von Netzwerkgeräten.

2. Dezember 2021: Dieser Ausfall in den Regionen US-West-2 und US-West-1 dauerte etwa eine Stunde und beeinträchtigte Dienste wie DoorDash, PlayStation Network und Zoom. Das Problem wurde durch eine Netzwerküberlastung zwischen Teilen des AWS-Backbone und externen Internetdienstanbietern (ISPs) verursacht.

3. 22. Dezember 2021: Ein Stromausfall in der Region US-EAST-1 verursachte kurze Unterbrechungen bei Diensten wie Slack, Udemy und Twilio. Während der anfängliche Ausfall kurz war, gab es bei einigen Diensten anhaltende Auswirkungen von bis zu 17 Stunden.

Verlassen Sie sich nicht auf die Überwachung in derselben Umgebung. Viele Unternehmen, die ihre Beobachtungstools auf AWS hosten, hatten während der Ausfälle mit Überwachungsproblemen zu kämpfen. Es ist wichtig, Failover-Systeme zu haben, die außerhalb der überwachten Umgebung gehostet werden, um die Sichtbarkeit bei Zwischenfällen zu gewährleisten.

Am 16. November 2021 kam es ab 12:39 Uhr ET zu einem Ausfall der Google Cloud, der mehrere große Websites offline brachte, darunter Home Depot, Spotify und Etsy. Die Nutzer sahen eine Google 404-Fehlerseite. Der Ausfall betraf eine Reihe von Google Cloud-Diensten wie Google Cloud Networking, Cloud Functions, App Engine und Firebase. Die Ursachenanalyse von Google wies auf einen latenten Fehler in einem Netzwerkkonfigurationsdienst hin, der während einer routinemäßigen Ladung der Leader-Wahl ausgelöst wurde. Während die Dienste um 1:10 PM ET teilweise wiederhergestellt waren, dauerte die vollständige Wiederherstellung fast zwei Stunden.

Überwachen Sie Ihre Dienste von außerhalb Ihrer Infrastruktur, um Problemen zuvorzukommen, bevor die Kunden sie bemerken. Die Verfolgung Ihrer Service Level Agreements (SLAs) und der mittleren Wiederherstellungszeit (MTTR) ermöglicht es Ihnen, die Effizienz Ihrer Teams und Provider bei der Lösung von Störungen zu messen.