CrowdStrike hat am Freitag einen relativ kleinen Patch veröffentlicht, der in weiten Teilen der IT-Welt, auf denen Microsoft Windows läuft, Chaos anrichtete und Flughäfen, Gesundheitseinrichtungen und Notrufzentralen lahmlegte. Wir wissen zwar, dass ein fehlerhaftes Update das Problem verursacht hat, aber wir wissen nicht, wie es überhaupt veröffentlicht wurde. Ein Unternehmen wie CrowdStrike verfügt höchstwahrscheinlich über eine ausgeklügelte DevOps-Pipeline mit entsprechenden Veröffentlichungsrichtlinien, aber selbst damit ist der fehlerhafte Code irgendwie durchgerutscht.
In diesem Fall war es vielleicht die Mutter aller fehlerhaften Codes. Der Ruf des Unternehmens wurde stark geschädigt und der Aktienkurs stürzte von 345,10 Dollar am Donnerstagabend auf 263,10 Dollar am Montagnachmittag. Seitdem hat er sich wieder leicht erholt.
In einer Erklärung vom Freitag räumte das Unternehmen die Folgen des fehlerhaften Updates ein: „CrowdStrike ist sich der Schwere und der Auswirkungen der Situation bewusst. Wir haben das Problem schnell identifiziert und einen Fix bereitgestellt, sodass wir uns mit höchster Priorität auf die Wiederherstellung der Kundensysteme konzentrieren können.“
Außerdem wurde die Grundursache des Ausfalls erklärt, allerdings nicht, wie es dazu kam. Dies ist ein Post-mortem-Prozess, der vermutlich noch einige Zeit im Unternehmen andauern wird, um zu verhindern, dass so etwas noch einmal passiert.
Dan Rogers, CEO von LaunchDarkly, einem Unternehmen, das ein Konzept namens „Feature Flags“ verwendet, um Software auf streng kontrollierte Weise bereitzustellen, konnte nicht direkt zum Bereitstellungsproblem von CrowdStrike sprechen, er konnte jedoch allgemeiner zu Problemen bei der Softwarebereitstellung sprechen.
„Softwarefehler kommen vor, aber die meisten Softwareprobleme, die jemand erlebt, sind nicht auf Infrastrukturprobleme zurückzuführen“, sagte er gegenüber TechCrunch. „Sie entstehen, weil jemand eine Software herausgebracht hat, die nicht funktioniert, und diese sind im Allgemeinen sehr kontrollierbar.“ Mit Feature-Flags können Sie die Geschwindigkeit der Bereitstellung neuer Funktionen steuern und eine Funktion deaktivieren, wenn etwas schief geht, um zu verhindern, dass sich das Problem weit verbreitet.
Es ist jedoch wichtig zu beachten, dass das Problem in diesem Fall auf der Ebene des Betriebssystemkernels lag und wenn dieser einmal außer Kontrolle geraten ist, ist es schwieriger zu beheben als beispielsweise eine Webanwendung. Eine langsamere Bereitstellung hätte das Unternehmen jedoch viel früher auf das Problem aufmerksam machen können.
Was bei CrowdStrike passiert ist, könnte potenziell jedem Softwareunternehmen passieren, selbst einem, das gute Software-Release-Praktiken anwendet, sagte Jyoti Bansal, Gründer und CEO von Harness Labs, einem Hersteller von DevOps-Pipeline-Entwicklertools. Auch er konnte nicht genau sagen, was bei CrowdStrike passiert ist, sprach aber allgemein darüber, wie fehlerhafter Code durch die Maschen schlüpfen kann.
Normalerweise gibt es einen Prozess, bei dem Code gründlich getestet wird, bevor er bereitgestellt wird, aber manchmal kann ein Entwicklungsteam, insbesondere in einer großen Entwicklungsgruppe, Abstriche machen. „So etwas kann passieren, wenn Sie die DevOps-Testpipeline überspringen, was bei kleineren Updates ziemlich häufig vorkommt“, sagte Bansal gegenüber TechCrunch.
Er sagt, dass dies häufig in größeren Organisationen passiert, in denen es keinen einheitlichen Ansatz für Software-Releases gibt. „Nehmen wir an, Sie haben 5.000 Ingenieure, die wahrscheinlich in 100 Teams mit jeweils etwa 50 verschiedenen Entwicklern aufgeteilt sind. Diese Teams wenden unterschiedliche Vorgehensweisen an“, sagte er. Und ohne Standardisierung kann schlechter Code leichter durch die Maschen schlüpfen.
So verhindern Sie, dass Fehler durchrutschen
Beide CEOs geben zu, dass manchmal Fehler durchkommen, aber es gibt Möglichkeiten, das Risiko zu minimieren. Die offensichtlichste davon ist, die Standardhygiene für Software-Releases einzuhalten. Dazu gehört, vor der Bereitstellung Tests durchzuführen und die Software dann kontrolliert bereitzustellen.
Rogers verweist auf die Software seines Unternehmens und merkt an, dass schrittweise Rollouts der richtige Ausgangspunkt sind. Anstatt die Änderung auf einmal an alle Benutzer zu übermitteln, gibt man sie stattdessen an eine kleine Teilmenge weiter und sieht, was passiert, bevor man den Rollout ausweitet. In ähnlicher Weise kann man, wenn man kontrollierte Rollouts hat und etwas schief geht, ein Rollback durchführen. „Mit dieser Idee der Funktionsverwaltung oder -kontrolle können Sie Funktionen, die nicht funktionieren, zurücksetzen und die Benutzer zur vorherigen Version zurückbringen, wenn etwas nicht funktioniert.“
Bansal, dessen Unternehmen im Mai gerade das Feature-Flag-Startup Split.io gekauft hat, empfiehlt auch das, was er „Canary Deployments“ nennt, kleine kontrollierte Test-Deployments. Der Name geht auf die Kanarienvögel zurück, die in Kohlebergwerke geschickt wurden, um auf Kohlenmonoxid-Lecks zu testen. Sobald Sie beweisen, dass der Test-Rollout gut aussieht, können Sie mit dem schrittweisen Rollout fortfahren, auf den Rogers anspielte.
Wie Bansal sagt, kann es beim Testen gut aussehen, aber ein Labortest erfasst nicht immer alles. Deshalb müssen Sie gute DevOps-Tests mit kontrollierter Bereitstellung kombinieren, um Dinge zu erfassen, die bei Labortests übersehen werden.
Rogers schlägt vor, bei der Analyse Ihres Softwaretestprogramms drei Schlüsselbereiche zu berücksichtigen – Plattform, Menschen und Prozesse – und sie alle arbeiten seiner Ansicht nach zusammen. „Es reicht nicht aus, nur eine großartige Softwareplattform zu haben. Es reicht nicht aus, hochqualifizierte Entwickler zu haben. Es reicht auch nicht aus, nur vordefinierte Arbeitsabläufe und Governance zu haben. Alle drei müssen zusammenkommen“, sagte er.
Eine Möglichkeit, einzelne Ingenieure oder Teams daran zu hindern, die Pipeline zu umgehen, besteht darin, allen den gleichen Ansatz aufzuerlegen, aber auf eine Weise, die die Teams nicht ausbremst. „Wenn Sie eine Pipeline bauen, die die Entwickler ausbremst, werden sie irgendwann Wege finden, ihre Arbeit außerhalb dieser Pipeline zu erledigen, weil sie denken, dass der Prozess weitere zwei Wochen oder einen Monat in Anspruch nimmt, bevor wir den Code ausliefern können, den wir geschrieben haben“, sagte Bansal.
Rogers stimmt zu, dass es wichtig ist, nicht als Reaktion auf einen einzigen Vorfall starre Systeme einzuführen. „Man möchte nicht, dass man sich so viele Gedanken über Softwareänderungen macht, dass man einen sehr langen und langwierigen Testzyklus hat und am Ende die Softwareinnovation erstickt“, sagte er.
Bansal sagt, dass ein durchdachter automatisierter Ansatz tatsächlich hilfreich sein kann, insbesondere bei größeren Entwicklungsgruppen. Aber es wird immer eine gewisse Spannung zwischen Sicherheit und Governance und der Notwendigkeit einer schnellen Veröffentlichung geben, und es ist schwer, die richtige Balance zu finden.
Was bei CrowdStrike passiert ist, wissen wir vielleicht noch eine Weile nicht, aber wir wissen, dass bestimmte Ansätze dabei helfen, die Risiken bei der Softwarebereitstellung zu minimieren. Von Zeit zu Zeit schlüpft fehlerhafter Code durch, aber wenn Sie bewährte Methoden befolgen, wird es wahrscheinlich nicht so katastrophal sein wie das, was letzte Woche passiert ist.
