6 gruselige Ausfallgeschichten

 (thenewstack.io)
7 Punkte von before30 2020-12-28 | 6 Kommentare | Auf WhatsApp teilen

1. Charity Majors, CTO von Honeycomb

  • Push-Benachrichtigungen kamen bei Nutzern in einer bestimmten Region (Osteuropa) nicht an

  • Trat direkt nach einer Änderung der ASG-Größe auf

  • Ursache war, dass der Round-Robin-DNS-Record die UDP-Paketgröße überschritt

2. Matthew Fornaciari, CTO von Gremlin

  • Ein Ausfall trat auf, weil die Festplatte voll war und keine Logs mehr geschrieben werden konnten

  • Funktion für Log-Rotation entwickelt

  • Alarm für Festplattenauslastung eingerichtet

  • Über Gremlin so ergänzt, dass Tests möglich sind (Chaos Engineering)

3. Lirran Haimovitch, CTO von Rookout

"Die urbane Legende, dass der Server jeden Tag zu einer bestimmten Uhrzeit abstürzt,

nach wochenlangen Untersuchungen wurde die Ursache in einer Sicherheitskamera entdeckt,

die Reinigungskraft hatte die Serververbindung getrennt, um den Staubsauger anzuschließen"

4. Daniel "Spoons" Spoonhower, CTO von Lightstep

  • Die App lud nicht

  • Es gab am selben Tag kein Deployment und keine Infrastrukturänderung

  • Es stellte sich heraus, dass nur interne Nutzer betroffen waren

  • Bei der Prüfung der API zum Laden der App wurde festgestellt, dass für interne Nutzer zusätzliche Daten zurückgegeben wurden

  • In den vergangenen Wochen war die Payload langsam gewachsen und überschritt an diesem Nachmittag die maximale Payload-Größe, wodurch das Laden der App fehlschlug

5. Lee liu, CTO von LogDNA

6. Ting Huang, CTO von Transpoit

  • In Twitter Mobile nicht lesbar

  • Es wurde ein Problem entdeckt, bei dem in einer neuen Bibliothek Session-Cookies nicht geparst werden konnten

Verwandte Beiträge

6 Kommentare

 
kunggom 2020-12-29

Im nicht zusammengefassten fünften Fall geht es offenbar um das Auslaufen von Zertifikaten.

Man dachte, dass es kein Problem wäre, wenn die Zertifikate wie geplant ablaufen, aber das galt nur für neu entwickelte Systeme; in den weiterhin genutzten Legacy-Systemen traten dennoch Probleme auf. Unglücklicherweise trat dasselbe Problem auch in der verwendeten CI/CD-Lösung auf, was die Sache noch komplizierter machte.
 
kbumsik 2020-12-29

„Die Reinigungskraft hat die Serververbindung getrennt, um einen Staubsauger anzuschließen“

Oje...
 
kunggom 2020-12-29

Als ich den Originaltext gelesen habe, stellte sich heraus, dass das nur als Einleitung gedacht war und der eigentliche Ausfall darauf zurückging, dass eine Query, die der Administrator auf Kundenseite bei Besprechungen oder gelegentlich nutzte, die gesamte Tabelle sperrte. Dadurch stieg die Latenz des Backend-Service jedes Mal unbegrenzt an. Man hat die verdächtige Query zwar optimiert, lag damit aber falsch, sodass dasselbe Phänomen jedes Mal erneut auftrat, wenn die Kundenseite die Seite wegen der großen Langsamkeit wiederholt aktualisierte.
 
kunggom 2020-12-29

Eine ähnliche persönliche Erfahrung habe ich auch. Das war, als ich als Freelancer kurzfristig einen Auftrag rund um einen Online-Shop übernommen hatte.

In der Nacht wurde am Shop eine große Arbeit durchgeführt (ein umfassendes Versions-Upgrade der Lösung), und nachdem bestätigt worden war, dass es bei wichtigen Funktionen wie der Produktbezahlung keine Probleme gab, wurde er wieder geöffnet. Doch am Nachmittag wurde die Shop-Website plötzlich extrem langsam und stand schließlich kurz davor, nahezu komplett stillzustehen. Wie sich herausstellte, lag die Ursache an einer separat angebundenen Seite für Verkäufer im Shop. Es wurde eine für die Shop-Lösung individuell entwickelte Verwaltungsseite für Verkäufer betrieben, und sobald man diese aufrief, wurde eine sehr schwere Query ausgeführt. Nach der Wiedereröffnung des Shops stieg die Last auf MySQL jedes Mal stark an, wenn einzelne Verkäufer sich einloggten, um ihren Verkaufsstatus zu prüfen, sodass am Ende der Shop selbst langsam wurde. Bei näherem Hinsehen stellte sich heraus, dass auf den betreffenden Tabellen aus irgendeinem Grund die Indizes nicht korrekt gesetzt waren. Letztlich ließ sich die Verlangsamung des Shops beheben, indem die Indizes korrekt angelegt und einige Parameter getunt wurden.
 
kbumsik 2020-12-31

Oh, danke fürs Teilen Ihrer Erfahrungen.

Allerdings dürfte es bei Materialien für Admin-Zwecke oder geschäftliche Entscheidungen durch den Einsatz von Aggregation ziemlich viel Last geben. Ich bin zwar kein Webentwickler und kenne mich damit nicht besonders gut aus, aber heutzutage scheint man so etwas unter dem Schlagwort Data Engineering zu lösen, indem man die Daten separat sammelt.
 
kunggom 2021-01-02

Wie Sie gesagt haben, wäre es eigentlich der richtige Ansatz, solche Daten getrennt auszulagern und zu verarbeiten, aber der Onlineshop, an dem ich gearbeitet habe, war ein Legacy-System mit ziemlich vielen fragwürdigen Stellen, sodass architektonische Überlegungen dieser Art überhaupt nicht berücksichtigt worden waren. Darin liefen eine sehr alte Version von MySQL — aus der Zeit, als nicht InnoDB, sondern MyISAM die Standard-Engine war — und ein ebenfalls veralteter Apache-Webserver innerhalb derselben VM-Instanz. Auch die Lösung zum Betrieb des Onlineshops war bereits als Legacy eingestuft und erhielt nur noch Patches. Die strukturellen Probleme der Lösung, die ich während der Arbeit bemerkt hatte, schienen in einer von Grund auf neu entwickelten neuen Version behoben worden zu sein, aber für mich, der an der Legacy-Version arbeitete, hatte das keinerlei Auswirkungen. Das ist auch schon wieder letztes Jahr gewesen.