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

Stel je voor dat je deel uitmaakt van een enorm, wereldwijd bouwteam dat een gigantische, complexe wolkenstad genaamd OpenStack bouwt. Deze stad wordt niet door één persoon gebouwd; het wordt gebouwd door duizenden arbeiders (ontwikkelaars) die werken aan honderden verschillende wijken (projecten) zoals Cinder, Glance en Nova. Om ervoor te zorgen dat de stad niet instort, voert iedereen, elke keer als ze een nieuwe baksteen toevoegen of een pijp veranderen, een reeks geautomatiseerde "veiligheidscontroles" (tests) uit.

Ideaal gezien zouden deze veiligheidscontroles moeten werken als een perfect verkeerslicht: Groen betekent "Ga, de wijziging is veilig", en Rood betekent "Stop, er is een probleem".

Maar soms flikkert het verkeerslicht. Het wordt Rood zonder goede reden, dan Groen als je het opnieuw controleert, en daarna weer Rood. In de softwarewereld heet dit "Flakiness" (onbetrouwbaarheid). Het is als een test die gewoon "stemmingswisselingen" heeft – hij weet niet of hij slaagt of faalt, zelfs al is er niets veranderd in de code.

Dit artikel is een detectiveverhaal over hoe dit "stemmingswisselende" gedrag zich verspreidt over de hele OpenStack-stad, niet alleen in één wijk.

De twee grote problemen die ze ontdekten

De onderzoekers ontdekten twee specifieke manieren waarop dit "stemmingswisselende" gedrag voor problemen zorgt:

1. De "aanstekelijke" storing (Cross-Project Flakiness)
Stel je een specifieke veiligheidscontrole (een test) voor die moet verifiëren of een deurslot werkt. In deze stad wordt datzelfde slotcontrole gebruikt in de Cinder-wijk, de Glance-wijk en de Nova-wijk.

• Het probleem: De slotcontrole is "stemmingswisselend". Hij faalt willekeurig in alle drie de wijken.
• De impact: Omdat de wijken deze ene test delen, stopt één enkele defecte test de voortgang op meerdere plaatsen tegelijk. De onderzoekers ontdekten dat 55% van alle wijken in OpenStack wordt getroffen door deze aanstekelijke storingen. Het is als één slechte appel die het hele vat laat rotten, maar de appel is eigenlijk een test die iedereen gebruikt.

2. De "kies-en-kijs" storing (Inconsistent Flakiness)
Stel je nu voor dat diezelfde slotcontrole wordt gebruikt in de Cinder-wijk en de Nova-wijk.

• Het probleem: In Cinder is de test perfect betrouwbaar (altijd Groen). Maar in Nova is die exacte test "stemmingswisselend" (flikkerend tussen Rood en Groen).
• De impact: Dit is verwarrend! Het betekent dat de test zelf niet kapot is; iets in de omgeving in Nova veroorzaakt de problemen. Het is als een auto die perfect start in je oprit, maar elke keer stottert als je probeert te starten bij een vriend thuis. De onderzoekers vonden meer dan 1.100 van deze "kies-en-kijs" storingen.

De grote verrassing: Zelfs "Unit"-tests worden ziek

Meestal denken ontwikkelaars aan Unit-tests als de "microscopen" van de softwarewereld. Ze kijken naar kleine, geïsoleerde stukjes code (zoals een enkele functie) in een vacuüm. Ze zouden de meest stabiele, voorspelbare tests moeten zijn omdat ze niet met de buitenwereld communiceren.

De schokkende bevinding van het artikel:
De onderzoekers ontdekten dat 70% van deze "microscoop"-tests eigenlijk betrokken is bij de "aanstekelijke" storingen.

• Analogie: Het is als het ontdekken dat de kleine, geïsoleerde schroeven die je broodrooster bij elkaar houden, dezelfde schroeven zijn die ervoor zorgen dat het hele elektrische systeem van de keuken kortsluiting krijgt. We namen aan dat deze kleine tests veilig en geïsoleerd waren, maar in een enorm ecosysteem zijn ze diep verbonden en kunnen ze overal instabiliteit verspreiden.

Waarom gebeurt dit? (De oorzaken)

Het team duikte in de logs om uit te vinden waarom de tests op sommige plaatsen wel en op andere plaatsen niet op hol sloegen. Ze vonden drie hoofdschuldigen:

1. De "Race Condition" (De 89%-doder): Dit is de meest voorkomende oorzaak. Stel je twee arbeiders voor die op exact hetzelfde milliseconde proberen dezelfde tool te grijpen. Soms krijgt Arbeider A hem; soms krijgt Arbeider B hem. Als de test probeert een bron (zoals een server of een bestand) te grijpen die al door iets anders wordt gebruikt, faalt hij. Als hij hem krijgt, slaagt hij. Deze willekeur heet een "race condition".
2. Niet-overeenkomende configuraties: Het is als proberen een cake te bakken met een recept uit het ene land, maar ingrediënten uit een ander land. De test verwacht een specifieke opstelling (zoals een specifieke versie van een bibliotheek of een specifieke serversnelheid), maar de omgeving komt niet overeen.
3. Afhankelijkheidsproblemen: Een wijk heeft misschien hun "stroomnet" (een softwarebibliotheek) bijgewerkt, terwijl de buurstad dat nog niet heeft. De test werkt in de bijgewerkte stad, maar faalt in de oude.

De kosten van de "wachten en zien"-aanpak

Wanneer een test faalt, is de standaardreactie in OpenStack om te zeggen: "Oh, het moet wel een storing zijn. Laten we het gewoon opnieuw uitvoeren (recheck) en wachten."

• De kosten: De onderzoekers berekenden dat deze "opnieuw uitvoeren en wachten"-gewoonte 1.156 dagen aan rekentijd en geld heeft verspild.
• De analogie: Het is als een verkeersagent die een rood licht ziet, ervan uitgaat dat de sensor kapot is, en auto's doorwaakt, dan opnieuw controleert, en ze dan weer doorwaakt. Dit verspilt brandstof (rekenresources) en vertraagt ieders woon-werkverkeer (codebeoordelingen).

Wat zeggen de arbeiders? (Feedback van ontwikkelaars)

De onderzoekers vroegen de echte bouwers (ontwikkelaars) hierover.

• De frustratie: Veel ontwikkelaars voelen zich hulpeloos. Ze zeggen: "Ik ben nieuw, ik weet niet wie ik moet vragen, dus ik blijf gewoon op 'recheck' drukken tot het slaagt."
• De realiteit: Ze geven toe dat het oplossen van deze problemen moeilijk is omdat het vereist dat je met meerdere teams praat. Als een test faalt in Nova vanwege een probleem in Cinder, moet de Nova-ontwikkelaar wachten tot het Cinder-team het oplost.
• Het gat in de tools: Ze noemden dat hoewel er tools bestaan om te helpen, deze vaak kapot gaan of worden verlaten omdat niemand de tijd heeft om ze te onderhouden. Ze hebben een toegewijde "monteur" nodig voor het CI-systeem, niet alleen vrijwilligers die het erbij doen.

De les

Het artikel concludeert dat je in een enorm, verbonden software-ecosysteem tests niet als geïsoleerde eilanden kunt behandelen.

• Voor ontwikkelaars: Stop met gewoon "rechecken" en wachten. Onderzoek waarom een test faalde, zelfs als het lijkt alsof het niets met je code te maken heeft.
• Voor teamleiders: Je moet standaardiseren hoe tests worden uitgevoerd in alle wijken. Als één stad een specifieke tool gebruikt, moet iedereen dat doen. Je moet ook de tracking van deze storingen centraliseren, zodat iedereen weet welke "schroeven" loszitten.
• Voor de toekomst: We hebben betere tools nodig om ons automatisch te vertellen waarom een test onbetrouwbaar is (bijvoorbeeld: "Het faalde omdat de server offline was", niet alleen "Het faalde").

Kortom, het artikel stelt dat we, om de OpenStack-stad soepel te laten draaien, moeten stoppen met het behandelen van testmislukkingen als willekeurig ongeluk en moeten beginnen met het behandelen ervan als een systemisch coördinatieprobleem dat de hele stad beïnvloedt.