Am 19. Juli 2024 erlebte die Welt einen der grössten IT-Ausfälle der Geschichte. Ein Sensor-Konfigurationsupdate von CrowdStrike, das um 4:09 UTC an alle Windows-Systeme ausgeliefert wurde, brachte 8,5 Millionen Microsoft-Windows-PCs weltweit zum Absturz. Fluggesellschaften, Banken, Krankenhäuser, Behörden, Börsen und unzählige weitere Organisationen standen still. In diesem Video analysiere ich, was passiert ist und, noch wichtiger, was man tun kann, um so etwas in der eigenen Organisation zu verhindern.
Was bei CrowdStrike passiert ist#
CrowdStrike ist ein amerikanisches Cybersecurity-Unternehmen, gegründet 2011, mit einer Marktkapitalisierung von rund 83 Milliarden Dollar. Ihre Falcon-Software ist ein Endpoint-Detection-and-Response-System (EDR), das Organisationen auf ihren Computern installieren, um Malware und verdächtige Aktivitäten zu erkennen. An jenem Freitagmorgen verursachte ein Konfigurationsupdate, das zwischen 4:09 und 5:27 UTC verteilt wurde, den sofortigen Absturz jedes Windows-7- und Windows-11-Systems (oder höher), das es heruntergeladen hatte. Das Ergebnis: eine globale Welle von Bluescreens.
Ein Blick auf Down Detector an jenem Tag war erschreckend. Unternehmen um Unternehmen meldeten Ausfälle. Und der Aktienkurs von CrowdStrike fiel deutlich, sobald die Welt sie als Ursache identifizierte.
Deployment- und Release-Strategie planen#
Das erste Prinzip, das ich betonen möchte: Planen Sie Ihre Deployment- und Release-Strategie. In DevOps unterscheiden wir klar zwischen Deployment und Release. Ein Deployment bringt kompilierten Code mit ausgeschalteten Feature Toggles in die Produktion. Ein Release schaltet diese Feature Toggles für die Nutzer ein. Diese Trennung gibt enorme Kontrolle darüber, wann und wie neue Funktionalität die Nutzer erreicht.
Qualität während der Entwicklung#
Während der Entwicklung helfen mehrere Praktiken, die Code-Qualität sicherzustellen, bevor irgendetwas die Produktion erreicht:
- Pair Programming: Zwei Entwickler arbeiten zusammen, ein zweites Gehirn überprüft ständig den Code. Das ist eine wirkungsvolle Methode, um Fehler zu erkennen, einschliesslich der Art von Null-Pointer-Exception, die den CrowdStrike-Absturz möglicherweise verursacht hat.
- Code Reviews und Merge Requests: Auch nach dem Pair Programming überprüft eine zweite Person den Code beim Merge Request. Ein weiterer Kontrollpunkt.
- Smart Pointers in C++: Da das CrowdStrike-System in C++ implementiert war, wo man das Memory Management selbst übernimmt, sind Tools wie Smart Pointers unverzichtbar, um Null-Pointer-Exceptions zu verhindern.
Continuous Integration und Testautomatisierung#
Nach dem Commit in das Repository greift das Continuous-Integration-System. Hier wird der neue Code mit dem Rest der Codebasis reintegriert. In dieser Phase kommen zum Einsatz:
- Statische Analyse (z.B. CppCheck für C++) scannt den Code auf Fehler und potenzielle Null-Pointer-Exceptions.
- Unit Tests und Integrationstests prüfen, ob die Software auf verschiedenen Windows-Versionen korrekt funktioniert, einschliesslich Reboot-Mechanismen.
- Dynamische Analyse (z.B. Valgrind für C++) führt den Code aus und erkennt Laufzeitprobleme, Speicherlecks und Exceptions.
Nach diesen Schritten hat man ein deploymenttaugliches Artefakt, das reviewt, statisch und dynamisch analysiert wurde.
Staging, Blue-Green Deployments und Rollback#
Das geprüfte Artefakt wird auf eine Staging-Umgebung deployed, wo Feature Toggles das Testen der Software ermöglichen. Blue-Green Deployments sind hier besonders wertvoll: Man betreibt zwei Umgebungen, eine aktive und eine inaktive. Man deployed auf die inaktive Umgebung, leitet den Traffic um, und falls etwas schiefgeht, schaltet man sofort zurück. Rollback-Mechanismen sind unverzichtbar, egal ob durch Blue-Green-Switching oder durch Deinstallation und Rückkehr zur vorherigen Version.
Zu diesem Zeitpunkt hat man die Software noch nicht released. Im CrowdStrike-Szenario hätte man sie deployed, aber nicht released.
Canary Releases und Dark Launches#
Hier hätte CrowdStrike meiner Meinung nach den grössten Unterschied machen können. Canary Releases bedeuten, dass man zuerst an eine kleine Nutzergruppe ausliefert, typischerweise Beta-Nutzer, die die neuesten Features haben möchten. Falls etwas schiefgeht, bleibt der Blast Radius klein. Ich bin überzeugt, dass dieses Prinzip beim CrowdStrike-Ausfall massiv geholfen hätte.
Dark Launches sind eine Variante: Man deployed kontinuierlich neue Versionen in die Produktion, aber die Feature Toggles bleiben ausgeschaltet. Man aktiviert sie nur gezielt auf Testsystemen, um zu verifizieren, dass alles funktioniert. Normale Nutzer sehen die neuen Features nie, bis man sicher ist.
A/B Testing folgt derselben Logik: Eine Gruppe (A) bekommt das neue Feature, die andere (B) nicht. Man vergleicht die Ergebnisse, bevor man breit ausrollt.
Das alles sind Release-Strategien, und die vorausschauende Planung dafür ist essenziell.
Proaktive Erkennung und Monitoring#
Man möchte nie, dass die eigenen Kunden ein Problem vor einem selbst entdecken. CrowdStrikes Kunden erfuhren vom Absturz vor CrowdStrike selbst. Um das zu verhindern, braucht man:
- Proaktive Erkennung: Bugs finden, bevor die Kunden sie finden.
- Alerting: Basierend auf der proaktiven Erkennung müssen automatisierte Alerts sofort benachrichtigen.
- Kontinuierliches Monitoring: Alle Systeme beobachten, Feedback sammeln und die proaktive Erkennung ermöglichen, damit man reagieren kann, bevor Nutzer betroffen sind.
Kernaussagen#
- Wir können nicht alle Vorfälle verhindern, aber wir können den Blast Radius reduzieren. Wir leben in einer hochvernetzten Welt, in der Software alles steuert. Wir müssen aus Fehlern lernen.
- Pair Programming und Code Reviews finden Fehler früh, einschliesslich potenzieller Null-Pointer-Exceptions.
- Statische und dynamische Analyse bieten automatisierte Sicherheitsnetze für die Code-Qualität.
- Unit- und Integrationstests sollten die Software auf verschiedenen Systemversionen verifizieren, einschliesslich Reboot-Mechanismen.
- Canary Releases sind entscheidend. Neue Versionen sollten immer zuerst an eine kleine Beta-Gruppe gehen, um die Auswirkungen potenzieller Fehler zu begrenzen.
- Resiliente Systeme bauen. Als Industrie müssen wir unbequeme Fragen stellen. Warum hat Microsoft kein resilienteres Windows-System gebaut, das nicht von einem einzigen Drittanbieter-Update komplett lahmgelegt werden kann? Wir müssen unsere Systeme konsequent für Resilienz entwickeln.
- Ein gründliches Post-Mortem durchführen. Die Root Cause analysieren, auf Basis der Erkenntnisse verbessern und DevOps-Prinzipien konsequent anwenden.