post mortems
1.0.0
Allegro. Die E-Commerce-Website ging nach einer plötzlichen Verkehrsspitze durch eine Marketingkampagne zurück. Der Ausfall wurde durch einen Konfigurationsfehler im Cluster -Ressourcenmanagement verursacht, der verhinderte, dass mehr Serviceinstanzen anfingen, obwohl Hardware -Ressourcen verfügbar waren.
Cloudflare. Eine schlechte Konfiguration (Router -Regel) veranlasste alle ihre Edge -Router zum Absturz und nahm die gesamte CloudFlare ab.
Cloudflare. Während einer Wartung seines privaten Backbone -Netzwerks erstellte ein Ingenieur in der Konfiguration des Atlanta Datacenter -Netzwerks einen Tippfehler, was dazu führte, dass der gesamte Datenverkehr aus Amerika und Europa zu diesem einzigen Rechenzentrum fließt und ihn zerkleinert hat.
Cloudflare. Eine falsche Bestellung der behinderten BGP -angekündigten Präfixe führte zu Fehlfunktionen von 19 Rechenzentren.
Cloudflare. Eine Änderung unseres abgestuften Cache -Systems führte dazu, dass einige Anfragen für Benutzer mit Statuscode 530 fehlschlagen. Die Auswirkungen dauerten insgesamt fast sechs Stunden. Wir schätzen, dass etwa 5% aller Anfragen am Spitzenwert fehlgeschlagen sind. Aufgrund der Komplexität unseres Systems und eines blinden Flecks in unseren Tests haben wir dies nicht festgestellt, als die Änderung in unsere Testumgebung freigegeben wurde.
Cloudflare. Am 24. Januar 2023 wurden mehrere CloudFlare -Dienste für 121 Minuten nicht verfügbar, da ein Fehler mit einem Fehler veröffentlicht wurde, der Service -Token verwaltet. Der Vorfall verschlechterte eine breite Palette von Cloudflare -Produkten, einschließlich Aspekten unserer Workers -Plattform, unserer Null -Trust -Lösung und der Steuerungsebene in unserem Content Delivery Network (CDN).
Cloudflare. Am 4. Oktober 2023 erlebte CloudFlare ab 07:00 Uhr UTC und endete um 11:00 Uhr UTC. Einige Benutzer von 1.1.1.1 oder Produkte wie Warp, Zero Trust oder DNS -Resolver, die 1.1.1.1 verwenden, haben möglicherweise ServFail -DNS -Antworten auf gültige Abfragen erhalten. Es tut uns sehr leid für diesen Ausfall. Dieser Ausfall war ein interner Softwarefehler und nicht das Ergebnis eines Angriffs. In diesem Blog werden wir darüber sprechen, was der Scheitern war, warum es geschah und was wir tun, um sicherzustellen, dass dies nicht wieder passiert.
Datadog. Eine schlechte Service -Discovery -Konfiguration in einem der Clients brachte die Erkennung von Service -Erkenntnissen weltweit ein, als ein abhängiger Kunde unterging.
Enom. Am 15. Januar 2022, um 9:00 Uhr ET, begann das technische Team von Tucows mit geplanten Wartungsarbeiten, um die ENOM -Plattform auf eine neue Cloud -Infrastruktur zu migrieren. Aufgrund der Komplexität des Cutovers stieß das Team auf viele Probleme, was zu kontinuierlichen Verzögerungen führte. Das Wartungsfenster wurde mehrmals erweitert, um Probleme im Zusammenhang mit Datenreplikation, Netzwerkrouting und DNS -Lösungsproblemen zu beheben, die sich auf die Zugänglichkeit der Website und die E -Mail -Zustellung auswirken.
Etsy. Das Senden von Multicast -Verkehr ohne ordnungsgemäß konfigurierende Switches führte zu einem globalen ETSY -Ausfall.
Facebook. Konfigurationsänderungen an den Backbone -Routern von Facebook führten zu einem globalen Ausfall aller Facebook -Eigenschaften und internen Tools.
Facebook. Eine schlechte Konfiguration hat sowohl Facebook als auch Instagram niedergeschlagen.
Firefox. Am 13. Januar 2022 löste ein spezifischer Codepfad im Netzwerkstapel von Firefox ein Problem in der HTTP/3 -Protokollimplementierung aus. Diese blockierte Netzwerkkommunikation und machte Firefox nicht mehr ansprechend und konnte Webinhalte fast zwei Stunden lang nicht laden.
Gernlos. Eine schlechte Konfiguration in Kombination mit einem ungewöhnlichen Satz von Fehlern führte zu einem Ausfall eines Datenbankclusters, der die API und das Dashboard offline stellte.
[Google] (https://cloud.google.com/blog/products/infrastructure/details-of-google-cloud-gcve-cident). Die anfängliche GCVE -Bereitstellung wurde mit einer älteren Option durchgeführt, die zum Ende dieses Zeitraums zu einem „festen Begriff“ -Vertrag mit automatischer Löschung führte.
Google. Eine schlechte Konfiguration (autogeneriert) hat alle Google Compute Engine -IP -Blöcke aus BGP -Ankündigungen entfernt.
Google. Eine schlechte Konfiguration (autogeneriert) hat die meisten Google -Dienste abgebaut.
Google. Eine schlechte Konfiguration führte dazu, dass ein Quotendienst fehlgeschlagen ist, was dazu führte, dass mehrere Dienste fehlschlagen (einschließlich Google Mail).
Google. / wurde in die URL Blacklist untersucht, wodurch jede URL eine Warnung zeigt.
Google. Ein Fehler in der Konfigurationsroll-Out zu einem Lastbalancer führt zu erhöhten Fehlerraten für 22 Minuten.
Google. Eine Konfigurationsänderung, die einen Anstieg der Nachfrage nach Metadatenspeicher beantworten soll, die einen Teil des Blob-Suchsystems überlastete, was zu einem kaskadierenden Fehler mit benutzerfreundlichen Service-Auswirkungen für Google Mail, Google-Fotos, Google Drive und andere GCP-Dienste führte, die vom BLOB-Speicher abhielten.
Google. Zwei falsche Konfigurationen sowie ein Softwarefehler verursachten einen massiven Google Cloud -Netzwerkfehler an der US -Ostküste.
Google. Der Front -End -Lastausgleichsdienst von Google hatte Fehler, was zu mehreren nachgeschalteten Google Cloud -Diensten in Europa ausgewirkt wurde. Aus der vorläufigen Analyse wurde die Hauptursache des Problems durch eine neue Infrastrukturfunktion verursacht, die ein latentes Problem innerhalb des internen Network -Last -Balancer -Codes auslöst.
Google. Google Cloud -Networking erlebte Probleme mit dem GCLB -Dienst (Google Cloud Load Balancing), was auf mehrere nachgeschaltete Google Cloud -Dienste ausgewirkt hat. Beobachtete Kunden beobachteten Google 404 -Fehler auf ihren Websites. Aus der vorläufigen Analyse war die Hauptursache des Problems ein latenter Fehler in einem Netzwerkkonfigurationsdienst, der während des Routine -Systembetriebs ausgelöst wurde.
Google. Google Cloud Networking erlebte eine verringerte Kapazität für den Verkehr mit niedrigerem Priorität wie Stapel-, Streaming- und Transferoperationen von 19:30 Uhr in den USA/Pazifik am Donnerstag, dem 14. Juli 2022, bis 15:02 US/Pacific am Freitag, dem 15. Juli 2022, war nicht betroffen. Diese Service -Störung resultierte aus einem Problem, das während einer Kombination aus Reparaturarbeiten und einem Upgrade -Rollout von Routine -Netzwerksoftware aufgetreten ist. Aufgrund der Art der Stör- und Resilienzfunktionen von Google Cloud -Produkten variierten die betroffenen Regionen und die individuellen Auswirkungen erheblich.
Heroku. Eine automatisierte Remote -Konfigurationsänderung hat sich nicht vollständig ausbreitet. Web Dynos konnten nicht gestartet werden.
Heroku. Ein falscher Bereitstellungsprozess führte dazu, dass neue Konfigurationsvariablen nicht verwendet werden, wenn der Code erforderlich war.
Keepthescore. Die Ingenieure haben die Produktionsdatenbank zufällig gelöscht. Datenbank ist eine verwaltete Datenbank von Digitalocean mit Backups einmal täglich. 30 Minuten nach der Katastrophe ging es wieder online, aber 7 Stunden Anzeigetafeldaten waren für immer verschwunden.
Microsoft. Eine schlechte Konfiguration hat den Azure -Speicher abgebaut.
NPM. Schnelles Konfigurationsänderungswechsel verursachte ein Problem mit dem Backend -Routing. Um genau zu sein, ist das Problem, dass wir den Req.backend in einer vcl_fetch-Funktion festgelegt haben und dann den Neustart neu starten, um die Regeln erneut zu festigen. Das Aufrufen von Neustart wird jedoch den Req.backend auf die erste in der Liste zurückgegriffen, die in diesem Fall zufällig Manta als die ladungsbalancierten CouchDB -Server war.
Owasa. Der falsche Druck eines Knopfes führt dazu, dass eine Wasseraufbereitungsanlage aufgrund eines zu hohen Fluoridgehalts heruntergefahren wurde.
Pagerduty. Am 15. Dezember 2021 bei 00:17 UTC haben wir eine DNS -Konfigurationsänderung in der Infrastruktur von PagerDuty bereitgestellt, die sich auf unseren Container -Orchestrierungs -Cluster auswirkte. Die Änderung enthielt einen Defekt, den wir in unseren Testumgebungen nicht erkannt haben, was dazu führte, dass alle Dienste, die im Container -Orchestrierungscluster ausgeführt wurden, nicht in der Lage waren, DNs zu lösen.
Razorpay. Bei einem RDS -Hardware -Fehler wurde eine falsche MySQL -Konfiguration hervorgehoben, die zu einem größeren Datenverlust in einem Finanzsystem führte.
Rost-Lang. Am Mittwoch, 2023-01-25 um 09:15 UTC, haben wir Änderungen an der Produktionsinfrastruktur für Kisten eingesetzt. Während des Einsatzes konnte der DNS-Datensatz für static.crate.io eine geschätzte Zeit von 10 bis 15 Minuten nicht lösen. Es lag daran, dass sowohl Zertifikate als auch DNS-Rekorde während der Ausfallzeit neu erstellt wurden.
Rost-Lang. Am 2023-07-20 zwischen 12:17 und 12:30 Uhr UTC wurden alle Kisten-Downloads von CRATES.IO aufgrund einer Bereitstellung unterbrochen, die einen Fehler in der Download-URL-Generation enthielt. Während dieser Zeit hatten wir durchschnittlich 4,71.000 Anfragen pro Sekunde nach Crapes.io, was zu etwa 3,7 m fehlgeschlagenen Anfragen führte, einschließlich der Wiederholungsversuche aus Fracht.
Stapelüberlauf. Eine schlechte Firewall -Konfiguration blockiert Stackexchange/Stackoverflow.
Posten. Falsche Amazon S3 -Einstellungen auf Sicherungen führen zu Datenlecks.
Travisci. Eine Konfigurationsprobleme (unvollständige Kennwortrotation) führte zu "undichten" VMs, was zu erhöhten Build -Wartezeiten führte.
Travisci. Ein Konfigurationsproblem (automatisierter altersbasierter Google Compute Engine VM Image Cleanup-Job) führte zu stabilen Basis-VM-Bildern.
Travisci. Eine Konfigurationsänderung ließ die Builds fehlschlagen. Manuelles Rollback brach.
Travisci. Variable für zufällige Umgebungen wurden getestet, die die Produktionsdatenbank verkürzen.
Tui. Vor dem Vorfallflug war das Reservierungssystem, aus dem das Lastblatt hergestellt wurde, verbessert. Ein Fehler im System führte dazu, dass weibliche Passagiere mit dem Titel "Miss" als Kinder gezählt wurden. Das System hat ihnen ein Standardgewicht eines Kindes von 35 kg im Gegensatz zum richtigen weiblichen Standardgewicht von 69 kg zugewiesen. Infolgedessen lag die G-Tawg-Startmasse aus dem Lastblatt mit 38 Frauen, die als Kinder falsch identifiziert wurden, 1.244 kg unter der tatsächlichen Masse des Flugzeugs.
Turso. Falsch konfigurierte DB -Backup -Kennungen führten zu Datenlecks für kostenlose Kundenkunden, und die anschließende Lösung führte zu einem möglichen Datenverlust.
Ventil. Obwohl es kein offizielles Postmortem gibt, sieht es aus wie eine schlechte BGP -Konfiguration, die Ventilverbindung zu Stufe 3, Telia und ABOVENET/ZAYO Ventile, was zu einem globalen Dampfausfall führte.
Amazonas. Ein unbekanntes Ereignis führte dazu, dass ein Transformator scheiterte. Eine der SPS, die überprüft, ob die Generatorleistung in Phase ist, ist aus einem unbekannten Grund fehlgeschlagen, wodurch eine Reihe von Sicherungsgeneratoren daran gehindert wurde, online zu kommen. Dies betroffene EC2, EBS und RDS in der EU West.
Amazonas. Schlechtes Wetter verursachte Kraftversagen in AWS US Ost. Ein einzelner Backup -Generator lieferte keine stabile Leistung, wenn die Leistung auf die Sicherung umgeschaltet wurde und der Generator geladen wurde. Dies ist trotz zwei Monaten zuvor eine Lastprüfung und ein wöchentlicher Stromversorgungstests bestanden.
Amazonas. Um 22:25 Uhr PDT am 4. Juni führte der Stromverlust in einer AWS -Einrichtung in Sydney, die aus Unwetter in diesem Bereich resultierte, zu einer erheblichen Anzahl von Fällen in einer Verfügbarkeitszone. Aufgrund der Signatur des Stromverlusts haben sich die Leistungsisolationschalter nicht engagiert, was dazu führte, dass Backup -Energiereserven in das degradierte Stromnetz abfließen.
Arpanet. Ein fehlerhafter IMP (Interface Message Processor) beschädigte Routing -Daten, Software -neu berechnete Überprüfungen, die schlechte Daten mit guten Prüfsummen, falsche Sequenznummern ausbreiteten, führten dazu, dass Puffer ausfüllten, vollständige Puffer verursachten den Verlust von Keepalive -Paketen und Knoten aus dem Netzwerk. Ab 1980.
Cloudflare. Ein partielles Fehlverhalten verursachte einen byzantinischen Kaskadenverhalten, der die Verfügbarkeit der API und des Armaturenbretts sechs Stunden und 33 Minuten beeinflusste.
Cloudflare. Stromausfall des Flexialtialdatenzentrums. Dieser Beitrag beschreibt die Ereignisse, die diesen Vorfall verursacht haben.
FirstEnergy / General Electric. FirstEnergy hatte einen lokalen Versagen, als einige Übertragungsleitungen das unbeklagte Laub trafen. Der normale Prozess besteht darin, einen Alarm auszulassen, der dazu führt, dass menschliche Operatoren die Stromversorgung neu verbreiten. Das GE -System, das dies überwachte, hatte jedoch einen Fehler, der verhinderte, dass der Alarm ausgelöst wurde, was schließlich zu einem kaskadierenden Fehler führte, bei dem schließlich 55 Millionen Menschen betroffen waren.
Github. Am 28. Januar 2016 erlebte Github eine Störung der Leistung in ihrem primären Datencenter.
Google. Aufeinanderfolgende Lightning-Streiks auf ihren europäischen Rechenzentrum (Europa-West1-B) verursachten den Stromverlust für Google Compute Engine-Speichersysteme in dieser Region. E/A -Fehler wurden an einer Untergruppe von Standard -Persistenten (HDDs) (HDDs) beobachtet, und es wurde ein dauerhafter Datenverlust an einem kleinen Bruchteil dieser beobachtet.
Google. Am Dienstag, den 19. Juli 2022, um 06:33 Uhr US/Pacific, ein gleichzeitiges Versagen mehrerer, redundanter Kühlsysteme in einem der Rechenzentren, in denen die Zone Europe-West2-A auf mehrere Google Cloud-Dienste ausgewirkt hat. Dies führte dazu, dass einige Kunden für betroffene Produkte nicht verfügbar waren.
Pythonanywhere. Ein Speichervolumenfehler auf einem der Speicherserver führte zu einer Reihe von Ausfällen, beginnend mit der Pythonanywhere -Website und auch mit den Programmen unserer Benutzer (einschließlich Websites), die von diesem Band abhängig waren, und sich später auf andere gehostete Websites ausbreiteten.
Sonne. Sun hat ECC bekanntlich nicht in ein paar Generationen von Serverteilen aufgenommen. Dies führte zu Datenbeschädigungen und Abstürzen. Nach Suns typischem MO machten sie Kunden, die ein Fehlerzeichen als NDA meldeten, bevor sie das Problem erläuterten.
CCP -Spiele. Ein Tippfehler und ein Name -Konflikt veranlassten das Installationsprogramm, die Datei boot.ini bei der Installation einer Erweiterung für EVE online manchmal zu löschen - mit Konsequenzen.
Github. Eine 43 zweite Netzwerkpartition während der Wartung verursachte MySQL-Master-Failover, aber der neue Meister hatte aufgrund der Kreuzkontinentlatenz nicht mehrere Sekunden lang geschrieben. Über 24 Stunden Restaurierungsarbeiten zur Aufrechterhaltung der Datenintegrität.
Gernlos. Alle Abfragen in einer kritischen PostgreSQL-Tabelle wurden durch die Kombination einer extrem schnellen Datenbankmigration und einer langjährigen Leserabfrage blockiert, die 15 Sekunden Ausfallzeiten verursacht.
Google. Viele Änderungen an einem selten modifizierten Lastausgleich wurden über einen sehr langsamen Codepfad angewendet. Dadurch wurden alle öffentlichen Änderungen für ~ 2 Stunden gefroren.
Google. Ein Versagen einer Komponente auf einem Faserweg von einem der zentralen US -Gateway -Campus in Googles Produktionsrückgrat führte zu einer Verringerung der verfügbaren Netzwerkbandbreite zwischen dem Gateway- und mehreren Randstandorten, was zu einem Paketverlust führte, während das Rückgrat automatisch den Verkehr auf die verbleibenden Pfade bewegte.
Ritterhauptstadt. Eine Kombination aus widersprüchlichen Versionen und die Wiederverwendung eines zuvor verwendeten Bits verursachte einen Verlust von 460 Mio. USD. Siehe auch eine längere Beschreibung.
Webkit -Code -Repository. Das Webkit-Repository, ein Subversion-Repository, das für die Verwendung von Deduplizierung konfiguriert ist, wurde nicht verfügbar, nachdem zwei Dateien mit demselben SHA-1-Hash als Testdaten überprüft wurden, um eine Sicherheitsprüfung für Kollisionen implementieren zu können. Die beiden Dateien hatten unterschiedliche MD5 -Summen, und so würde eine Checkout eine Konsistenzprüfung fehlschlagen. Für den Kontext wurde die erste öffentliche SHA-1-Hash-Kollision in letzter Zeit mit einem Beispiel für zwei kollidierende Dateien angekündigt.
Azurblau. Es wurden Zertifikate erstellt, die für ein Jahr gültig waren. Anstatt eine geeignete Bibliothek zu verwenden, schrieb jemand Code, der ein Jahr als aktuelles Datum plus ein Jahr berechnete. Am 29. Februar 2012 führte dies zur Erstellung von Zertifikaten mit einem Ablaufdatum vom 29. Februar 2013, die aufgrund des ungültigen Datums abgelehnt wurden. Dies führte zu einem globalen Azure -Ausfall, der den größten Teil eines Tages dauerte.
Cloudflare. Rückwärts-Zeitfluss von der Verfolgung des 27. Sprung zweitens in den Jahren 2016-12-31T23: 59: 60Z führte dazu, dass die gewichtete Auswahl von DNS-Resolvers (RRDNs) in Panik in Panik geraten und bei einigen CNAME-Lookups versagt. Go's time.Now() wurde fälschlicherweise als monoton angenommen; Dies injizierte negative Werte in Aufrufe an rand.Int63n() , die in diesem Fall in Panik geraten.
Linux. Sprung Second Code wurde aus dem Timer Interrupt -Handler genannt, der xtime_lock hielt. Dieser Code hat einen printk durchgeführt, um den Leap Second zu protokollieren. printk wacht klogd auf, was manchmal versuchen kann, die Zeit zu bekommen, die auf xtime_lock wartet und einen Deadlock verursacht.
Linux. Als ein Sprungbranche auftrat, wurde CLOCK_REALTIME um eine Sekunde wieder verwundet. Dies geschah nicht über einen Mechanismus, der hrtimer base.offset aktualisieren würde. Dies bedeutete, dass bei einem Timer -Interrupt Timer_abstime clock_realtime Timer in einer Sekunde vorzeitig abgelaufen wurde, einschließlich Timer für weniger als eine Sekunde. Dies führte zu Anwendungen, bei denen der Schlaf für weniger als eine Sekunde in einer Schleife ohne Schlafen gedreht wurde, was bei vielen Systemen eine hohe Belastung verursachte. Dies führte zu einer großen Anzahl von Webdiensten im Jahr 2012.
Mozilla. Die meisten Firefox-Add-Ons haben um den 4. Mai 2019 aufgehört, als ein Zertifikat abgelaufen ist. Firefox benötigt eine gültige Zertifikatskette, um Malware zu verhindern. Ungefähr neun Stunden später drückte Mozilla ein privilegiertes Add-On, das ein gültiges Zertifikat in den Zertifikatgeschäft von Firefox injizierte, wodurch eine gültige Kette erstellt und Add-Ons abgelöst wurden. Dies hat effektiv alle Add-Ons deaktiviert, ungefähr 15.000, und die Auflösung dauerte für die meisten Benutzer ungefähr 15-21 Stunden. Einige Benutzerdaten gingen verloren. Zuvor hat Mozilla zu den technischen Details gepostet.
Github. Die Github -Plattform stieß bei der Verarbeitung einer Schema -Migration auf einer großen MySQL -Tabelle auf einen neuartigen Fehlermodus. Schema -Migrationen sind eine häufige Aufgabe bei Github und dauern häufig Wochen. Der letzte Schritt in einer Migration besteht darin, eine Umbenennung durchzuführen, um die aktualisierte Tabelle an die richtige Stelle zu verschieben. Während des letzten Schritts dieser Migration trat ein erheblicher Teil unserer MySQL -Replikate in eine Semaphor -Deadlock ein. Unsere MySQL -Cluster bestehen aus einem primären Knoten zum Schreibverkehr, mehreren Lese -Replikationen für den Produktionsverkehr und mehreren Replikaten, die interner Leseverkehr für Sicherungs- und Analysezwecke bedienen. Die Read-Repliken, die den Deadlock erreichten, traten in einen Absturzabfindungszustand ein, der eine erhöhte Belastung für gesunde Replikate verursachte. Aufgrund der kaskadierenden Art dieses Szenarios gab es nicht genügend aktive Lese -Repliken, um Produktionsanforderungen zu bearbeiten, die die Verfügbarkeit von Kerngithub -Diensten beeinflussten.
Heroku. Um 15:05 Uhr UTC am 8. Juni 2023 trat ein Datenbankfehler auf, bei dem ein Fremdschlüssel einen kleineren Datentyp als der von ihm verwiesene Primärschlüssel verwendete. Dieser Fehler verursachte einen Überlauf, wenn der Primärschlüssel den zulässigen Wert überschritt, was zu einer Unfähigkeit führte, neue Autorisierungen innerhalb von Heroku zu erstellen. Dieser Fehler hinderte auch Kunden daran, neue Bereitstellungen zu erstellen. Die Oncall -Operationen lösten dann den Heroku -API vollständigen Ausfall aus.
Allegro. Die Allegro -Plattform erlitt einen Versäumnis eines Subsystems, das für die asynchrone verteilte Aufgabenverarbeitung verantwortlich ist. Das Problem beeinflusste viele Bereiche, z. B. Funktionen wie den Kauf zahlreicher Angebote über CART- und Bulk -Angebotsbearbeitung (einschließlich der Bearbeitung von Preislisten) haben überhaupt nicht funktioniert. Darüber hinaus schickte es teilweise versäumt, den täglichen Newsletter mit neuen Angeboten zu senden. Auch einige Teile des internen Verabreichungsgremiums waren betroffen.
Amazonas. Menschlicher Fehler. Am 28. Februar 2017 um 9:37 Uhr PST debugierte das Amazon S3 -Team ein kleines Problem. Trotz der Verwendung eines etablierten Spielbuchs wurde einer der Befehle, die eine kleine Anzahl von Servern entfernen sollen, mit einem Tippfehler ausgestellt, was versehentlich einen größeren Satz von Servern entfernt hat. Diese Server unterstützten kritische S3 -Systeme. Infolgedessen benötigten abhängige Systeme einen vollständigen Neustart, um korrekt zu arbeiten, und das System wurde bis zur endgültigen Auflösung um 13:54 Uhr PST für die US-East-1 (Nord-Virginia) weit verbreitet. Da die eigenen Dienste von Amazon wie EC2 und EBS auch auf S3 angewiesen sind, verursachte dies einen riesigen Kaskadenversagen, der Hunderte von Unternehmen betroffen hatte.
Amazonas. Die Korruption von Nachrichten führte dazu, dass die Funktion "Distributed Server Status" Ressourcen in der S3 -Anfrageverarbeitungsflotte überfordern.
Amazonas. Der menschliche Fehler während eines Routine -Netzwerk -Upgrades führte zu einer Ressourcenkrise, die durch Softwarefehler verschärft wurde und letztendlich zu einem Ausfall in allen US -Osten -Verfügbarkeitszonen sowie zu einem Verlust von 0,07% der Volumina führte.
Amazonas. Die Unfähigkeit, einen Datenerfassungsserver zu kontaktieren, löste einen latenten Speicher -Leck -Fehler im Berichtsagenten auf den Speicherservern aus. Und es gibt keine anmutige Verschlechterung des Abbaus, weshalb der Berichtsagent den Sammelserver so kontinuierlich kontaktiert hat, dass der Systemspeicher langsam verbrauchte. Auch das Überwachungssystem hat das Speicherleck dieses EBS -Servers nicht alarmieren. Außerdem nutzen EBS -Server im Allgemeinen sehr dynamische Verwendung des gesamten Speichers. Am Montagmorgen wurde die Rate des Speicherverlusts ziemlich hoch und verwirrt genug Speicher auf den betroffenen Speicherservern, die mit dem Anfrage zur Handhabung nicht aufbewahrt werden können. Dieser Fehler wurde durch die Unfähigkeit, das Failover durchzuführen, weiter abgetrennt, was zum Ausfall führte.
Amazonas. Elastic Last Balancer stieß auf Probleme, als "ein Wartungsprozess, der versehentlich gegen die Daten der Produktion von ELB -Staaten geführt wurde".
Amazonas. Eine "Netzwerkstörung" führte dazu, dass Metadatendienste eine Belastung erlebten, die die Reaktionszeiten für Zeitleitungswerte überschritten hat, was dazu führte, dass sich Speicherknoten selbst abbauen. Die Knoten, die sich selbst niederließen, töteten sich weiter und stellten sicher, dass die Last für Metadatendienste nicht abnehmen konnte.
Amazonas. Die Skalierung der Front-End-Cache-Flotte für Kinesis führte dazu, dass alle Server in der Flotte die maximale Anzahl von Threads überschreiten, die durch eine Betriebssystemkonfiguration zulässig sind. Mehrere kritische nachgeschaltete Dienste betroffen, von Cognito über Lambda bis CloudWatch.
Amazonas. Um 7:30 Uhr PST löste eine automatisierte Aktivität zur Skalierung der Kapazität eines der im Haupt -AWS -Netzwerk gehosteten AWS -Dienste ein unerwartetes Verhalten von einer großen Anzahl von Clients im internen Netzwerk aus. Dies führte zu einem großen Anstieg der Verbindungsaktivität, die die Netzwerkgeräte zwischen dem internen Netzwerk und dem Haupt -AWS -Netzwerk überwältigte, was zu Verzögerungen für die Kommunikation zwischen diesen Netzwerken führte. Diese Verzögerungen erhöhten die Latenz und Fehler für Dienste, die zwischen diesen Netzwerken kommunizieren, was zu noch mehr Verbindungsversuchen und -versagen führt. Dies führte zu anhaltenden Überlastungs- und Leistungsproblemen auf den Geräten, die die beiden Netzwerke verbinden.
Appnexus. Ein doppeltes freies freies Free, das ein Datenbank -Update enthüllt hat, führte dazu, dass alle "Impression -Bus" -Server gleichzeitig abstürzen. Dies war nicht in der Inszenierung gefangen und führte es in Produktion, da eine Zeitverzögerung erforderlich ist, um den Fehler auszulösen, und die Inszenierungsperiode hatte keine eingebaute Verzögerung.
AT & T. Eine schlechte Linie von C -Code führte eine Renngefahr ein, die zu gegebener Zeit das Telefonnetz einbrach. Nach einem geplanten Ausfall lösten die Quickfire Resumption -Nachrichten das Rennen aus, was zu mehr Neustarts führte, was das Problem abbrach. "Das Problem wiederholte sich iterativ in den 114 Switches im Netzwerk und blockierte in den neun Stunden, die es brauchte, um das System zu stabilisieren." Ab 1990.
Atlassian. Am Dienstag, dem 5. April 2022, verlor ab 7:38 UTC 775 Atlassian -Kunden den Zugang zu ihren Atlassian -Produkten. Der Ausfall umfasste bis zu 14 Tage für eine Teilmenge dieser Kunden, wobei die ersten Kunden am 8. April wiederhergestellt wurden und alle Kundenstandorte bis zum 18. April nach und nach wiederhergestellt wurden.
Basecamp, siehe auch. Das Netzwerk von Basecamp stand am 24. März 2014 unter einem DDOS-Angriff während eines 100-minütigen Fensters.
Basecamp, siehe auch. Im November 2018 traf eine Datenbank auf das Ganzzahl-Limit und ließ den Dienst im schreibgeschützten Modus.
BBC online. Im Juli 2014 erlebte BBC Online einen sehr langen Ausfall mehrerer seiner beliebten Online -Dienste, darunter der BBC iPlayer. Als das Datenbank -Backend überlastet wurde, hatte sie begonnen, Anfragen aus verschiedenen Diensten zu drosseln. Dienste, die die Datenbankantworten nicht vor Ort zwischengespeichert hatten, begannen mit dem Timing und scheiterten schließlich vollständig.
Bintray. Im Juli 2017 wurden in Jcenter mehrere böswillige Maven -Pakete mit einem Identitätsangriff aufgenommen. Diese Pakete lebten über ein Jahr in JCenter und betroffenen angeblich mehrere Android -Apps, die dazu führten, dass der Malware -Code von diesen Abhängigkeiten von JCenter injiziert wurde.
Bitly. Hosted Source Code Repo enthielt Anmeldeinformationen, die Zugriff auf Bitly -Backups, einschließlich Hashed -Passwörtern, gewähren.
Sträuber. Eine alte Prototypenmaschine mit der immer noch aktiven Anfälligkeit von Shellshock hatte geheime Schlüssel darüber, was letztendlich zu einer Sicherheitsverletzung des Produktionssystems führte.
Buildkite. Die Herabstufung der Datenbankkapazität, um die AWS -Ausgaben zu minimieren, führte zu einer mangelnden Kapazität, um Buildkite -Kunden auf dem Spitzenwert zu unterstützen, was zum Zusammenbruch der abhängigen Server führte.
Bungie. Nebenwirkungen einer Fehlerbehebung für falsche Zeitstempel verursachen Datenverlust. Die Servermehlkonfiguration für den Hotfix bewirkt, dass der Datenverlust in mehreren Servern in einem folgenden Update wieder auftaucht.
CCP -Spiele. Ein problematischer Protokollierungskanal führte dazu, dass Clusterknoten während der Cluster -Startsequenz nach einem neuen Spiel -Patch abgestorben waren.
CCP -Spiele. Dokumentiert einen stacklosen Python Memory -Wiederverwendungsfehler, der Jahre dauerte, bis es auffindig war.
Chef.io. Der Supermarkt der Rezept -Community -Site -Supermarkt stürzte zwei Stunden nach dem Start aufgrund intermittierender Nichtreagness und einer erhöhten Latenz. Einer der Hauptgründe für das im Post -Mortem identifizierte Misserfolg waren sehr niedrige Zeitüberschreitungen zur Gesundheit.
Circleci. Ein Github -Ausfall und eine Erholung verursachten eine unerwartet große Eingangslast. Aus Gründen, die nicht angegeben sind, verlangsamt sich eine große Last, dass das Warteschlangensystem von Circleci verlangsamt, in diesem Fall eine Transaktion pro Minute.
Circleci. Bis zum 4. Januar 2023 hatte unsere interne Untersuchung den Umfang des Eindringens durch den nicht autorisierten Dritten und den Einstiegspfad des Angriffs ermittelt. Bisher haben wir erfahren, dass ein nicht autorisierter Dritter, der Malware mit einem Circleci-Ingenieur-Laptop eingesetzt hat, um eine gültige, 2FA-unterstützte SSO-Sitzung zu stehlen. Diese Maschine wurde am 16. Dezember 2022 kompromittiert. Die Malware wurde von unserer Antivirus -Software nicht erkannt. Unsere Untersuchung zeigt, dass die Malware in der Lage war, Session Cookie -Diebstahl auszuführen, sodass sie den gezielten Mitarbeiter an einem abgelegenen Ort ausgeben und dann den Zugang zu einer Teilmenge unserer Produktionssysteme eskalieren können.
Cloudflare. Ein Parser -Fehler führte dazu, dass Cloudflare Edge -Server Speicher zurückgeben, das private Informationen wie HTTP -Cookies, Authentifizierungs -Token, HTTP -Postkörper und andere sensible Daten enthielt.
Cloudflare. Eine CPU -Erschöpfung wurde durch eine einzelne WAF -Regel verursacht, die einen schlecht geschriebenen regelmäßigen Ausdruck enthielt, der zu übermäßigem Backtracking führte. Diese Regel wurde schnell für die Produktion eingesetzt und eine Reihe von Veranstaltungen führte zu einer globalen Ausfallzeit von 27 Minuten der Cloudflare -Dienste.
Datadog. Nach einem automatischen Upgrade wurden alle Netzwerkregeln beseitigt und verursachten einen Dauer von 24 Stunden in allen kiliengeschützten Kubernetes -Clustern in allen Regionen und Cloud -Anbietern.
Zwietracht. Ein Flapping -Service führte zu einer donnernden Herde, die sich wieder mit sich anschließt, sobald er aufgetaucht ist. Dies führte zu einem Kaskadierungsfehler, bei dem Frontend -Dienste aufgrund interner Warteschlangen, die auffüllten, keinen Speicher mehr hatte.
Zwietracht. "Mit ungefähr 14:01 wurde eine Redis-Instanz, die als Primär für einen von Discords API-Diensten verwendeten Cluster fungierte, automatisch von der Cloud-Plattform von Google migriert. Diese Migration ließ den Knoten falsch abfallen, und zwang den Cluster, den Cluster wieder aufzusetzen, und lösten die Art und Weise, wie diskordte discord-api-Instanzen auf die Auflösung des Auflösungsmehls ausgelöst wurden. Zeitsystem.
Dropbox. Dieses Postmortem ist ziemlich dünn und ich bin mir nicht sicher, was passiert ist. Es klingt vielleicht nach einem geplanten Betriebssystem -Upgrade irgendwie dazu, dass einige Maschinen ausgelöscht wurden, das einige Datenbanken herausnahm.
Duo. Kaskadierungsfehler aufgrund einer Anforderung Warteschlangenüberladung der vorhandenen, unzureichenden Datenbankkapazität. Eine unzureichende Kapazitätsplanung und -überwachung könnte ebenfalls zugeschrieben werden.
Epische Spiele. Extreme Last (ein neuer Spitzenwert von 3,4 Millionen gleichzeitigen Benutzern) führte zu einer Mischung aus teillichen und totalen Servicestörungen.
Europäische Weltraumagentur. Ein Überlauf trat bei der Umwandlung einer 16-Bit-Zahl in eine 64-Bit-Numer im Ariane 5-Intertial-Leitsystem auf, wodurch die Rakete zum Absturz gebracht wurde. Der tatsächliche Überlauf ereignete sich im Code, der für den Betrieb nicht notwendig war, aber trotzdem ausgeführt wurde. Laut einem Konto wurde eine diagnostische Fehlermeldung zum Ausdruck gebracht, und die diagnostische Fehlermeldung wurde irgendwie als tatsächliche gültige Daten interpretiert. Laut einem anderen Bericht wurde kein Trap -Handler für den Überlauf installiert.
Elastisch. Elastische Cloud-Kunden mit Bereitstellungen in der Region AWS EU-WEST-1 (Irland) hatten ungefähr 3 Stunden lang einen stark verschlechterten Zugang zu ihren Clustern. In diesem Zeitraum gab es einen Zeitraum von ungefähr 20 Minuten, in dem alle Einsätze in dieser Region völlig nicht verfügbar waren.
Elastisch. Elastische Cloud-Kunden mit Bereitstellungen in der AWS US-East-1-Region erlebten einen verschlechterten Zugang zu ihren Clustern.
Eslint. Am 12. Juli 2018 hat ein Angreifer den NPM -Konto eines Eslint -Betreuers und schädliche Pakete in der NPM -Registrierung kompromittiert.
Etsy. Erstens führte ein Bereitstellungsbereich, der ein kleiner Bugfix -Bereitstellungsbereich sein sollte, auch Live -Datenbanken, um bei Ausführung von Produktionsmaschinen aufgerüstet zu werden. Um sicherzustellen, dass dies keine Korruption verursachte, hörte Etsy ein, den Verkehr zu servieren, um Integritätsprüfungen durchzuführen. Zweitens führte ein Überlauf in IDs (signierte 32-Bit-INTs) dazu, dass einige Datenbankvorgänge fehlschlagen. Etsy vertraute nicht, dass dies nicht zu einer Datenversorgung führen würde, und nahm die Website ab, während das Upgrade vorangetrieben wurde.
Schnell. Globaler Ausfall aufgrund eines unentdeckten Software -Fehlers, der am 8. Juni aufgetaucht ist, als er durch eine gültige Änderung der Kundenkonfiguration ausgelöst wurde.
Flowdock. Flowdock Instant Messaging war zwischen dem 21. und 22. April 2020 für ca. 24 Stunden nicht verfügbar. Die Covid-19-Pandemie führte zu einer plötzlichen und drastischen Erhöhung der Arbeit von zu Hause aus, was zu einer höheren Verwendung von Flowdock führte, was dazu führte, dass die Anwendungsdatenbank hang. Einige Benutzerdaten gingen dauerhaft verloren.
Foursquare. MongoDB fiel unter Last um, als ihm der Gedächtnis ausging. Das Versagen war katastrophal und nicht anmutig, da ein AA-Abfragemuster mit geringer Localitätsniveaus eine Lesebelastung beinhaltete (jeder Einchecken des Benutzers las alle Check-Ins für den Verlauf des Benutzers, und die Aufzeichnungen waren 300 Bytes ohne räumliche Lokalität, was bedeutet, dass die meisten der von jeder Seite gezogenen Daten nicht erforderlich waren). Durch die mangelnde Überwachung der MongoDB -Instanzen wurde die hohe Belastung unentdeckt, bis die Last katastrophal wurde, was in zwei Tagen 17 Stunden Ausfallzeiten über zwei Vorfälle überspannte.
Gentoo. Ein Unternehmen erhielt Zugang zur Gentoo Github -Organisation, entfernte den Zugriff auf alle Entwickler und fügte in verschiedenen Repositories Commits hinzu.
Github. Am 28. Februar 2018 erlebte Github einen DDOS -Angriff und traf die Website mit 1,35 tbps Verkehr.
Gitlab. Nachdem die primäre gesperrte und neu gestartet wurde, wurde es mit dem falschen Dateisystem wieder aufgerufen, was zu einem globalen Ausfall führte. Siehe auch HN -Diskussion.
Gitlab. Der Zustrom von Anfragen überlastete die Datenbank, löste eine Replikation zu Verzögerungen, müde Administratoren löschte das falsche Verzeichnis und sechs Datenstunden verloren. Siehe auch früheren Bericht und HN -Diskussion.
Google. Ein Mail -System schickte Personen mehr als 20 Mal per E -Mail. Dies geschah, weil Mail mit einem Stapel -Cron -Job geschickt wurde, der Mail an alle schickte, die als Warten auf Mail gekennzeichnet waren. Dies war ein nichtatomarer Operation, und der Batch-Job markierte keine Leute als nicht als Warten, bis alle Nachrichten gesendet wurden.
Google. FilESTORE erzwingt eine globale Begrenzung für API -Anfragen, um die Auswirkungen in Überlastungsszenarien zu begrenzen. Der Ausfall wurde ausgelöst, als ein interner Google -Dienst eine große Anzahl von GCP -Projekten mit Fehlfunktionen und Überlastung der FilESTORE -API mit Anfragen durchführte, was zu einer globalen Drosselung der Filestore -API führte. Dies dauerte, bis der interne Dienst manuell innehiert wurde. Infolge dieser Drosselung war der schreibgeschützte API-Zugang für alle Kunden nicht verfügbar. Dies betroffene Kunden an allen Standorten aufgrund einer globalen Quote, die für FileStore gilt. Konsole, GCloud- und API -Zugriff (Liste, Getoperation usw.) Anrufe sind für eine Dauer von 3 Stunden, 12 Minuten fehlgeschlagen. Mutate operations (CreateInstance, UpdateInstance, CreateBackup, etc.) still succeeded, but customers were unable to check on operation progress.
Google. The Google Meet Livestream feature experienced disruptions that caused intermittent degraded quality of experience for a small subset of viewers, starting 25 October 2021 0400 PT and ending 26 October 2021 1000 PT. Quality was degraded for a total duration of 4 hours (3 hours on 25 October and 1 hour on 26 October). During this time, no more than 15% of livestream viewers experienced higher rebuffer rates and latency in livestream video playback. We sincerely apologize for the disruption that may have affected your business-critical events. We have identified the cause of the issue and have taken steps to improve our service.
Google. On 13 October 2022 23:30 US/Pacific, there was an unexpected increase of incoming and logging traffic combined with a bug in Google's internal streaming RPC library that triggered a deadlock and caused the Write API Streaming frontend to be overloaded. And BigQuery Storage WriteAPI observed elevated error rates in the US Multi-Region for a period of 5 hours.
GPS/GLONASS. A bad update that caused incorrect orbital mechanics calculations caused GPS satellites that use GLONASS to broadcast incorrect positions for 10 hours. The bug was noticed and rolled back almost immediately due to (?) this didn't fix the issue.
Healthcare.gov. A large organizational failure to build a website for United States healthcare.
Heroku. Having a system that requires scheduled manual updates resulted in an error which caused US customers to be unable to scale, stop or restart dynos, or route HTTP traffic, and also prevented all customers from being able to deploy.
Heroku. An upgrade silently disabled a check that was meant to prevent filesystem corruption in running containers. A subsequent deploy caused filesystem corruption in running containers.
Heroku. An upstream apt update broke pinned packages which lead to customers experiencing write permission failures to /dev .
Heroku. Private tokens were leaked, and allowed attackers to retrieve data, both in internal databases, in private repositories and from customers accounts.
Heroku. A change to the core application that manages the underlying infrastructure for the Common Runtime included a dependency upgrade that caused a timing lock issue that greatly reduced the throughput of our task workers. This dependency change, coupled with a failure to appropriately scale up due to increased workload scheduling, caused the application's work queue to build up. Contributing to the issue, the team was not alerted immediately that new router instances were not being initialized correctly on startup largely because of incorrectly configured alerts. These router instances were serving live traffic already but were shown to be in the wrong boot state, and they were deleted via our normal processes due to failing readiness checks. The deletion caused a degradation of the associated runtime cluster while the autoscaling group was creating new instances. This reduced pool of router instances caused requests to fail as more requests were coming in faster than the limited number of routers could handle. This is when customers started noticing issues with the service.
Homebrew. A GitHub personal access token with recently elevated scopes was leaked from Homebrew's Jenkins that allowed access to git push on several Homebrew repositories.
Bienenwabe. A tale of multiple incidents, happening mostly due to fast growth.
Bienenwabe. Another story of multiple incidents that ended up impacting query performance and alerting via triggers and SLOs. These incidents were notable because of how challenging their investigation turned out to be.
Bienenwabe. On September 8th, 2022, our ingest system went down repeatedly and caused interruptions for over eight hours. We will first cover the background behind the incident with a high-level view of the relevant architecture, how we tried to investigate and fix the system, and finally, we'll go over some meaningful elements that surfaced from our incident review process.
Bienenwabe. On July 25th, 2023, we experienced a total Honeycomb outage. It impacted all user-facing components from 1:40 pm UTC to 2:48 pm UTC, during which no data could be processed or accessed. The full details of incident triage process is covered in here.
incident.io. A bad event (poison pill) in the async workers queue triggered unhandled panics that repeatedly crashed the app. This combined poorly with Heroku infrastructure, making it difficult to find the source of the problem. Applied mitigations that are generally interesting to people running web services, such as catching corner cases of Go panic recovery and splitting work by type/class to improve reliability.
Indian Electricity Grid. One night in July 2012, a skewed electricity supply-demand profile developed when the northern grid drew a tremendous amount of power from the western and eastern grids. Following a series of circuit breakers tripping by virtue of under-frequency protection, the entire NEW (northern-eastern-western) grid collapsed due to the absence of islanding mechanisms. While the grid was reactivated after over 8 hours, similar conditions in the following day caused the grid to fail again. However, the restoration effort concluded almost 24 hours after the occurrence of the latter incident.
Instapaper. Also this. Limits were hit for a hosted database. It took many hours to migrate over to a new database.
Intel. A scripting bug caused the generation of the divider logic in the Pentium to very occasionally produce incorrect results. The bug wasn't caught in testing because of an incorrect assumption in a proof of correctness. (See the Wikipedia article on 1994 FDIV bug for more information.)
Joyent. Operations on Manta were blocked because a lock couldn't be obtained on their PostgreSQL metadata servers. This was due to a combination of PostgreSQL's transaction wraparound maintenance taking a lock on something, and a Joyent query that unnecessarily tried to take a global lock.
Joyent. An operator used a tool with lax input validation to reboot a small number of servers undergoing maintenance but forgot to type -n and instead rebooted all servers in the datacenter. This caused an outage that lasted 2.5 hours, rebooted all customer instances, put tremendous load on DHCP/TFTP PXE boot systems, and left API systems requiring manual intervention. See also Bryan Cantrill's talk.
Kickstarter. Primary DB became inconsistent with all replicas, which wasn't detected until a query failed. This was caused by a MySQL bug which sometimes caused order by to be ignored.
Kings College London. 3PAR suffered catastrophic outage which highlighted a failure in internal process.
Launchdarkly. Rule attribute selector causing flag targeting web interface to crash.
Mailgun. Secondary MongoDB servers became overloaded and while troubleshooting accidentally pushed a change that sent all secondary traffic to the primary MongoDB server, overloading it as well and exacerbating the problem.
Mandrill. Transaction ID wraparound in Postgres caused a partial outage lasting a day and a half.
Medium. Polish users were unable to use their "Ś" key on Medium.
Metrist. Azure published a breaking change that affected downstream systems like Metrist's service without warning them, the post covers how to identify the issue and how to recover from it.
NASA. A design flaw in the Apollo 11 rendezvous radar produced excess CPU load, causing the spacecraft computer to restart during lunar landing.
NASA. Use of different units of measurement (metric vs. English) caused Mars Climate Orbiter to fail. There were also organizational and procedural failures[ref] and defects in the navigation software[ref].
NASA. NASA's Mars Pathfinder spacecraft experienced system resets a few days after landing on Mars (1997). Debugging features were remotely enabled until the cause was found: a priority inversion problem in the VxWorks operating system. The OS software was remotely patched (all the way to Mars) to fix the problem by adding priority inheritance to the task scheduler.
Netflix. An EBS outage in one availability zone was mitigated by migrating to other availability zones.
North American Electric Power System. A power outage in Ohio around 1600h EDT cascaded up through a web of systemic vulnerabilities and process failures and resulted in an outage in the power grid affecting ~50,000,000 people for ~4 days in some areas, and caused rolling blackouts in Ontario for about a week thereafter.
Okta. A hackers group got access to a third-party support engineer's laptop.
OpenAI. Queues for requests and responses in a Redis cache became corrupted and out of sequence, leading to some requests revealing other people's user data to some users, including app activity data and some billing info.
Pagerduty. In April 2013, Pagerduty, a cloud service proving application uptime monitoring and real-time notifications, suffered an outage when two of its three independent cloud deployments in different data centers began experiencing connectivity issues and high network latency. It was found later that the two independent deployments shared a common peering point which was experiencing network instability. While the third deployment was still operational, Pagerduty's applications failed to establish quorum due to to high network latency and hence failed in their ability to send notifications.
PagerDuty. A third party service for sending SMS and making voice calls experienced an outage due to AWS having issues in a region.
Parität. $30 million of cryptocurrency value was diverted (stolen) with another $150 million diverted to a safe place (rescued), after a 4000-line software change containing a security bug was mistakenly labeled as a UI change, inadequately reviewed, deployed, and used by various unsuspecting third parties. See also this analysis.
Platform.sh. Outage during a scheduled maintenance window because there were too much data for Zookeeper to boot.
Reddit. Experienced an outage for 1.5 hours, followed by another 1.5 hours of degraded performance on Thursday August 11 2016. This was due to an error during a migration of a critical backend system.
Reddit. Outage for over 5 hours when a critical Kubernetes cluster upgrade failed. The failure was caused by node metadata that changed between versions which brought down workload networking.
Roblox. Roblox end Oct 2021 73 hours outage. Issues with Consul streaming and BoltDB.
Salesforce. Initial disruption due to power failure in one datacenter led to cascading failures with a database cluster and file discrepancies resulting in cross data center failover issues.
Salesforce. On September 20, 2023, a service disruption affected a subset of customers across multiple services beginning at 14:48 Coordinated Universal Time (UTC). As a result, some customers were unable to login and access their services. A policy change executed as a part of our standard security controls review and update cycle to be the trigger of this incident. This change inadvertently blocked access to resources beyond its intended scope.
Posten. Transaction ID Wraparound in Postgres caused Sentry to go down for most of a working day.
Shapeshift. Poor security practices enabled an employee to steal $200,000 in cryptocurrency in 3 separate hacks over a 1 month period. The company's CEO expanded upon the story in a blog post.
Skyliner. A memory leak in a third party library lead to Skyliner being unavailable on two occasions.
Locker. A combination of factor results in a large number of Slack's users being disconnected to the server. The subsequent massive disconnection-reconnection process exceeded the database capacity and caused cascading connection failures, leading to 5% of Slack's users not being able to connect to the server for up to 2 hours.
Locker. Network saturation in AWS's traffic gateways caused packet loss. An attempt to scale up caused more issues.
Locker. Cache nodes removal caused the high workload on the vitness cluster, which in turn cased the service outage.
Spotify. Lack of exponential backoff in a microservice caused a cascading failure, leading to notable service degradation.
Quadrat. A cascading error from an adjacent service lead to merchant authentication service being overloaded. This impacted merchants for ~2 hours.
Stackdriver. In October 2013, Stackdriver, experienced an outage, when its Cassandra cluster crashed. Data published by various services into a message bus was being injested into the Cassandra cluster. When the cluster failed, the failure percolated to various producers, that ended up blocking on queue insert operations, eventually leading to the failure of the entire application.
Stack Exchange. Enabling StackEgg for all users resulted in heavy load on load balancers and consequently, a DDoS.
Stack Exchange. Backtracking implementation in the underlying regex engine turned out to be very expensive for a particular post leading to health-check failures and eventual outage.
Stack Exchange. Porting old Careers 2.0 code to the new Developer Story caused a leak of users' information.
Stack Exchange. The primary SQL-Server triggered a bugcheck on the SQL Server process, causing the Stack Exchange sites to go into read only mode, and eventually a complete outage.
Strava. Hit the signed integer limit on a primary key, causing uploads to fail.
Streifen. Manual operations are regularly executed on production databases. A manual operation was done incorrectly (missing dependency), causing the Stripe API to go down for 90 minutes.
Schweden. Use of different rulers by builders caused the Vasa to be more heavily built on its port side and the ship's designer, not having built a ship with two gun decks before, overbuilt the upper decks, leading to a design that was top heavy. Twenty minutes into its maiden voyage in 1628, the ship heeled to port and sank.
Tarsnap. A batch job which scans for unused blocks in Amazon S3 and marks them to be freed encountered a condition where all retries for freeing certain blocks would fail. The batch job logs its actions to local disk and this log grew without bound. When the filesystem filled, this caused other filesystem writes to fail, and the Tarsnap service stopped. Manually removing the log file restored service.
Telstra. A fire in a datacenter caused SMS text messages to be sent to random destinations. Corrupt messages were also experienced by customers.
Therac-25. The Therac-25 was a radiation therapy machine involved in at least six accidents between 1985 and 1987 in which patients were given massive overdoses of radiation. Because of concurrent programming errors, it sometimes gave its patients radiation doses that were thousands of times greater than normal, resulting in death or serious injury.
trivago. Due to a human error, all engineers lost access to the central source code management platform (GitHub organization). An Azure Active Directory Security group controls the access to the GitHub organization. This group was removed during the execution of a manual and repetitive task.
Twilio. In 2013, a temporary network partition in the redis cluster used for billing operations, caused a massive resynchronization from slaves. The overloaded master crashed and when it was restarted, it started up in read-only mode. The auto-recharge component in This resulted in failed transactions from Twilio's auto-recharge service, which unfortunately billed the customers before updating their balance internally. So the auto-recharge system continued to retry the transaction again and again, resulting in multiple charges to customer's credit cards.
Twilio. Twilio's incident of having high filtering on SMS towards AT&T Network In United States.
Ventil. Steam's desktop client deleted all local files and directories. The thing I find most interesting about this is that, after this blew up on social media, there were widespread reports that this was reported to Valve months earlier. But Valve doesn't triage most bugs, resulting in an extremely long time-to-mitigate, despite having multiple bug reports on this issue.
Yeller. A network partition in a cluster caused some messages to get delayed, up to 6-7 hours. For reasons that aren't clear, a rolling restart of the cluster healed the partition. There's some suspicious that it was due to cached routes, but there wasn't enough logging information to tell for sure.
Zerodha. The Order Management System (OMS) provided to Zerodha, a stock broker, collapsed when an order for 1M units of a penny stock was divided into more than 0.1M individual trades against the typical few hundreds, triggering a collapse of the OMS, which was not encountered prior by its provider - Refinitiv (formerly Thomson Reuters), a subsidiary of the London Stock Exchange.
Zerodha. A failure of the primary leased line to a CTCL between a stock broker and a stock exchange led to the activation of a backup leased line that was operating sporadically over the following hour, affecting bracket and cover orders. Subsequently, the process of placing and validating orders had been modified to incorporate the unreliability of the CTCL's leased lines, but the reliability of the primary and the backup leased lines was not fundamentally improved by the providers.
Unfortunately, most of the interesting post-mortems I know about are locked inside confidential pages at Google and Microsoft. Please add more links if you know of any interesting public post mortems! is a pretty good resource; other links to collections of post mortems are also appreciated.
AWS Post-Event Summaries
Availability Digest website.
Postmortems community (with imported archive from the now-dead G+ community).
John Daily's list of postmortems (in json).
Jeff Hammerbacher's list of postmortems.
NASA lessons learned database.
Tim Freeman's list of postmortems
Wikimedia's postmortems.
Autopsy.io's list of Startup failures.
SRE Weekly usually has an Outages section at the end.
Lorin Hochstein's list of major incidents.
Awesome Tech Postmortems.
Nat Welch's parsed postmortems is an attempt to build a database out of this markdown file.
Postmortem Templates is a collection of postmortem templates from various sources.
How Complex Systems Fail
John Allspaw on Resilience Engineering
