Cross-Project Flakiness: A Case Study of the OpenStack Ecosystem

Stellen Sie sich vor, Sie sind Teil einer riesigen, globalen Baucrew, die eine gigantische, komplexe Wolkenstadt namens OpenStack errichtet. Diese Stadt wird nicht von einer einzigen Person gebaut; sie wird von Tausenden von Arbeitern (Entwicklern) errichtet, die an Hunderten verschiedener Stadtviertel (Projekte) wie Cinder, Glance und Nova arbeiten. Um sicherzustellen, dass die Stadt nicht einstürzt, führt jeder, der einen neuen Ziegel hinzufügt oder ein Rohr verändert, eine Reihe automatisierter „Sicherheitschecks" (Tests) durch.

Im Idealfall sollten diese Sicherheitschecks wie eine perfekte Ampel funktionieren: Grün bedeutet „Los, die Änderung ist sicher", und Rot bedeutet „Stopp, es gibt ein Problem".

Doch manchmal flackert die Ampel. Sie wird ohne triftigen Grund Rot, dann wieder Grün, wenn Sie nachschauen, und dann wieder Rot. In der Softwarewelt nennt man dies „Flakiness" (Unzuverlässigkeit). Es ist wie ein Test, der einfach „stimmungslabil" ist – er weiß nicht, ob er besteht oder durchfällt, obwohl sich im Code nichts geändert hat.

Dieser Artikel ist eine Detektivgeschichte darüber, wie sich dieses „stimmungslabile" Verhalten über die gesamte OpenStack-Stadt ausbreitet, nicht nur in einem einzigen Viertel.

Die zwei großen Probleme, die sie entdeckten

Die Forscher entdeckten zwei spezifische Wege, auf denen dieses „stimmungslabile" Verhalten Ärger verursacht:

1. Der „ansteckende" Defekt (Cross-Project Flakiness)
Stellen Sie sich einen bestimmten Sicherheitscheck (einen Test) vor, der überprüfen soll, ob ein Türschloss funktioniert. In dieser Stadt wird derselbe Schloss-Check im Cinder-Viertel, im Glance-Viertel und im Nova-Viertel verwendet.

• Das Problem: Der Schloss-Check ist „stimmungslabil". Er fällt in allen drei Vierteln zufällig durch.
• Die Auswirkung: Da die Viertel diesen einen Test teilen, stoppt ein einziger fehlerhafter Test den Fortschritt an mehreren Stellen gleichzeitig. Die Forscher stellten fest, dass 55 % aller Viertel in OpenStack von diesen ansteckenden Defekten betroffen sind. Es ist wie ein einziger fauler Apfel, der das ganze Fass verdirbt, wobei der Apfel eigentlich ein Test ist, den alle verwenden.

2. Der „auswählende" Defekt (Inconsistent Flakiness)
Stellen Sie sich nun vor, derselbe Schloss-Check wird im Cinder-Viertel und im Nova-Viertel verwendet.

• Das Problem: In Cinder ist der Test absolut zuverlässig (immer Grün). Aber in Nova ist derselbe Test genau genommen „stimmungslabil" (flackert zwischen Rot und Grün).
• Die Auswirkung: Das ist verwirrend! Es bedeutet, dass der Test selbst nicht defekt ist; etwas in der Umgebung in Nova verursacht den Ärger. Es ist wie ein Auto, das in Ihrer Einfahrt perfekt startet, aber jedes Mal stottert, wenn Sie versuchen, es beim Freund zu starten. Die Forscher entdeckten über 1.100 dieser „auswählenden" Defekte.

Die große Überraschung: Selbst „Unit"-Tests werden krank

Normalerweise betrachten Entwickler Unit-Tests als die „Mikroskope" der Softwarewelt. Sie betrachten winzige, isolierte Code-Stücke (wie eine einzelne Funktion) im Vakuum. Sie sollen die stabilsten, vorhersehbarsten Tests sein, da sie nicht mit der Außenwelt kommunizieren.

Die schockierende Erkenntnis des Artikels:
Die Forscher stellten fest, dass 70 % dieser „Mikroskop"-Tests tatsächlich an den „ansteckenden" Defekten beteiligt sind.

• Analogie: Es ist, als würde man herausfinden, dass die winzigen, isolierten Schrauben, die Ihren Toaster zusammenhalten, dieselben Schrauben sind, die den gesamten elektrischen Stromkreis der Küche zum Kurzschluss bringen. Wir gingen davon aus, dass diese kleinen Tests sicher und isoliert waren, aber in einem riesigen Ökosystem sind sie tief miteinander verbunden und können Instabilität überallhin verbreiten.

Warum passiert das? (Die Ursachen)

Das Team grub in den Protokollen, um herauszufinden, warum die Tests an manchen Orten versagten und an anderen nicht. Sie identifizierten drei Hauptschuldige:

1. Die „Race Condition" (Der 89 %-Killer): Dies ist die häufigste Ursache. Stellen Sie sich zwei Arbeiter vor, die versuchen, exakt im selben Millisekunden denselben Werkzeuggriff zu ergreifen. Manchmal bekommt Arbeiter A ihn; manchmal Arbeiter B. Wenn der Test versucht, eine Ressource (wie einen Server oder eine Datei) zu ergreifen, die bereits von etwas anderem verwendet wird, schlägt er fehl. Wenn er sie bekommt, besteht er. Diese Zufälligkeit wird „Race Condition" genannt.
2. Nicht übereinstimmende Konfigurationen: Es ist, als würde man versuchen, einen Kuchen nach einem Rezept aus einem Land zu backen, aber mit Zutaten aus einem anderen Land. Der Test erwartet ein spezifisches Setup (wie eine bestimmte Version einer Bibliothek oder eine bestimmte Servergeschwindigkeit), aber die Umgebung passt nicht.
3. Abhängigkeitsprobleme: Ein Viertel hat möglicherweise sein „Stromnetz" (eine Softwarebibliothek) aktualisiert, während die benachbarte Stadt dies noch nicht getan hat. Der Test funktioniert in der aktualisierten Stadt, schlägt aber in der alten fehl.

Die Kosten des „Warten und Sehen"-Ansatzes

Wenn ein Test fehlschlägt, lautet die Standardreaktion in OpenStack: „Oh, es muss ein Defekt sein. Lassen Sie uns ihn einfach erneut ausführen (recheck) und warten."

• Die Kosten: Die Forscher berechneten, dass diese Gewohnheit des „erneuten Ausführens und Wartens" 1.156 Tage an Rechenzeit und Geld verschwendet hat.
• Die Analogie: Es ist, als würde ein Verkehrspolizist eine rote Ampel sehen, davon ausgehen, dass der Sensor defekt ist, und Autos durchwinken, dann erneut prüfen und sie wieder durchwinken. Dies verschwendet Kraftstoff (Rechenressourcen) und verzögert den Pendelverkehr aller (Code-Reviews).

Was sagen die Arbeiter? (Feedback der Entwickler)

Die Forscher fragten die eigentlichen Bauarbeiter (Entwickler) dazu.

• Die Frustration: Viele Entwickler fühlen sich hilflos. Sie sagen: „Ich bin neu, ich weiß nicht, wen ich fragen soll, also klicke ich einfach weiter auf 'erneut ausführen', bis es besteht."
• Die Realität: Sie geben zu, dass die Behebung dieser Probleme schwierig ist, da sie die Kommunikation mit mehreren Teams erfordert. Wenn ein Test in Nova wegen eines Problems in Cinder fehlschlägt, muss der Nova-Entwickler warten, bis das Cinder-Team es behebt.
• Die Werkzeuglücke: Sie erwähnten, dass zwar Werkzeuge existieren, um zu helfen, diese aber oft kaputtgehen oder aufgegeben werden, weil niemand Zeit hat, sie zu warten. Sie benötigen einen dedizierten „Mechaniker" für das CI-System, nicht nur Freiwillige, die es nebenbei machen.

Das Fazit

Der Artikel kommt zu dem Schluss, dass man in einem riesigen, vernetzten Software-Ökosystem Tests nicht als isolierte Inseln behandeln kann.

• Für Entwickler: Hören Sie auf, einfach nur „erneut auszuführen" und zu warten. Untersuchen Sie, warum ein Test fehlgeschlagen ist, auch wenn er nichts mit Ihrem Code zu tun zu haben scheint.
• Für Teamleiter: Sie müssen standardisieren, wie Tests in allen Vierteln ausgeführt werden. Wenn eine Stadt ein bestimmtes Werkzeug verwendet, sollten alle dasselbe tun. Sie müssen auch die Verfolgung dieser Defekte zentralisieren, damit jeder weiß, welche „Schrauben" locker sind.
• Für die Zukunft: Wir benötigen bessere Werkzeuge, die uns automatisch sagen, warum ein Test unzuverlässig ist (z. B. „Er ist fehlgeschlagen, weil der Server down war", nicht nur „Er ist fehlgeschlagen").

Kurz gesagt argumentiert der Artikel, dass wir, um die OpenStack-Stadt reibungslos laufen zu lassen, aufhören müssen, Testfehler als zufälliges Pech zu behandeln und anfangen müssen, sie als ein systemisches Koordinationsproblem zu betrachten, das die gesamte Stadt betrifft.