DevOps-Erkenntnisse aus dem CrowdStrike-Ausfall: Stärkung der Software-Resilienz
In sozialen Netzwerken teilen
DevOps-Erkenntnisse aus dem CrowdStrike-Ausfall: Stärkung der Software-Resilienz
Matt Saunders
26. November 2024
5 Min. Lesezeit
Matt Saunders
26. November 2024
5 Min. Lesezeit
In diesem Beitrag beleuchten wir die Erkenntnisse aus dem CrowdStrike-Ausfall und gehen auf die Bedeutung von DevOps-Praktiken, strategischen Tests und automatisierter Infrastruktur ein.
Unternehmen können aus dem Ausfall von CrowdStrike viel lernen, und zwar in Bezug auf die Prinzipien und die praktische Umsetzung der DevOps-Bewegung.
Eine oft wiederholte Beobachtung des CrowdStrike-Vorfalls lautet: „Warum wurde dies nicht richtig getestet?“ – DevOps bietet viele Antworten darauf. Ein zentraler Grundsatz von DevOps ist die Konzentration auf Feedbackschleifen, in denen iterative Verbesserungen der Software gemessen, getestet und an die Entwickler zurückgemeldet werden. Die Kurzschlussreaktion auf den CrowdStrike-Vorfall deutet darauf hin, dass dies nicht geschehen ist. Eine detaillierte Analyse der Grundursache des Vorfalls spricht jedoch nicht dafür, sondern deutet darauf hin, dass eine Reihe schwer zu testender und schwer vorhersehbarer Umstände den Ausfall verursacht haben.
Die überwiegende Mehrheit unserer Umfrageteilnehmer gibt an, dass sie ihre technischen Teams erweitern und sich dabei auf DevOps und Tests konzentrieren werden. Dadurch bietet sich allen Organisationen die Möglichkeit, in beiden Bereichen Fortschritte zu erzielen. Organisationen dürfen jedoch nicht in die Falle tappen, einfach immer mehr Tests hinzuzufügen, da diese die Zeit für den Build- und Testzyklus verlängern und zu einer Verlängerung der Feedbackschleife führen können, was das Gegenteil von dem ist, was wir wollen. Stattdessen sollten Organisationen einen strategischeren DevOps-Ansatz verfolgen, der weniger auf Modultests setzt und die Möglichkeiten von Integrations- und Abnahmetests erweitert. Dies wiederum trägt dazu bei, dass diese Feedbackschleifen realitätsnah und schnell genug sind, um in einen hochgradig iterativen Entwicklungsprozess zu passen.
There is almost no human action or decision that cannot be made to look flawed and less sensible in the misleading light of hindsight.
Sidney Dekker
Just Culture: Balancing Safety and Accountability
Analysen von Katastrophen und Ausfällen in Nicht-IT-Branchen, wie die von Sidney Dekker und Steven J. Spear, zeigen, dass man sich mit der Erklärung von Vorfällen als Pech oder Ausnahmesituation die Chance auf Verbesserungen verbaut. Technische Teams können aus diesem Ansatz viel lernen. Jeder Vorfall bietet die Möglichkeit zu lernen und Feedback zu neuen Wegen des Testens von Software im Software-Lieferzyklus zu geben.
Nicht viele Organisationen sind in der Lage, Software zu schreiben, die direkt mit dem Windows-Kernel interagiert – die meisten Anwendungen werden für die Sandbox erstellt, in der eine Webanwendung ausgeführt wird. Wir können jedoch von den Bemühungen lernen, das Testen mobiler Anwendungen zu verbessern – indem wir erheblich in die Infrastruktur investieren, um Anwendungen bei Bedarf automatisch mit echten Hardwaregeräten zu testen. Für die meisten Organisationen ist dies eine Fähigkeit, die eingekauft werden kann. Um die Frequenz einer Feedbackschleife aufrechtzuerhalten, ist es entscheidend, Entwicklern Zugang zu einer automatisierten Infrastruktur zu verschaffen, mithilfe derer sie diese bereitstellen und ausführen können.
Viele begrüßen eine verstärkte Regulierung bei der Bereitstellung von Software. Insider sind jedoch besorgt über die zunehmende Belastung der Entwicklungsteams, die die Zuverlässigkeit und Sicherheit der Software gewährleisten sollen. Gute DevOps-Praktiken wie Repetition und Automatisierung können hier Abhilfe schaffen und Unternehmen die Möglichkeit bieten, Vorschriften und Sicherheitsanforderungen automatisiert und kontinuierlich zu interpretieren.
Wir sind darauf spezialisiert, eine effektive Infrastruktur für automatisierte Tests (CI/CD) in öffentlichen und privaten Clouds mit Tools wie Terraform und Kubernetes aufzubauen. Unsere Teams sind bestrebt, diese Probleme sorgfältig und pragmatisch zu lösen, indem sie ein kombiniertes Ergebnis liefern, das für alle zugänglich ist. Und vor allem sollen Probleme schnell und kohärent aufgedeckt werden, damit sich die Entwickler auf das konzentrieren können, worin sie am besten sind.
Weitere Informationen zu unseren Forschungsergebnissen und dazu, wie Adaptavist eure Organisation bei der Navigation durch diese neue Landschaft mit unseren DevOps-Diensten unterstützen kann, findet ihr in unserer Pressemitteilung. Gestaltet gemeinsam mit uns die Zukunft der Softwareentwicklung, in der Resilienz und Innovation Hand in Hand gehen.
Weitere Informationen zu unseren DevOps-Services und -Ressourcen findet ihr hier in unserem DevOps Resource Hub.
Verfasst von
DevOps Lead
Mit seinem Hintergrund als Linux-Systemadministrator ist Matt eine Autorität in Sachen DevOps. Bei Adaptavist und darüber hinaus setzt er sich für DevOps-Arbeitsweisen ein und hilft Teams dabei, die Leistung von Menschen, Prozessen und Technologien zu optimieren, um Software effizient und sicher zu liefern.
DevOps