De upgrade die al drie versies wacht

In veel backlogs staat een ticket dat binnenkort jarig is. Het heet “mesh-upgrade” en schuift al maanden van sprint naar sprint.

Het patroon erachter zie ik in veel setups. Niemand durft aan het datapad te komen: een mesh-upgrade raakt potentieel elke sidecar, en daarmee elke service in het cluster. Tegelijk is niemand verantwoordelijk. De mesh is van “het platform”, de upgrade is van niemand. Dus wacht hij.

Terwijl hij wacht, stapelen buiten de releases zich op en schuift het supportvenster verder. De afstand tussen “waar we staan” en “waar we zouden moeten zijn” groeit. Hoe groter de afstand, hoe groter de sprong. Hoe groter de sprong, hoe groter de testinspanning, hoe groter de angst, hoe langer het wachten. De cirkel versterkt zichzelf. De angst is het enige deel van het systeem dat automatisch schaalt.

Hoe dit verhaal eindigt, stond al in report #2: als de CVE komt, is het te laat. Patches richten zich op actuele releases. Wie ver achterloopt, kan in een noodgeval niet zomaar patchen. Die springt over meerdere versies heen, onder tijdsdruk.

Voor beslissers is upgrade-schuld daarom een dubbel risico. Een veiligheidsrisico, omdat het noodgeval geen uitstel kent. En een personeelsrisico, omdat de grote sprong precies de specialistische kennis vraagt die in een noodgeval het moeilijkst te krijgen is. Beide duiken in geen enkel risk register op zolang het ticket braaf blijft doorschuiven.

Een upgrade die drie versies wacht, is geen upgrade meer. Het is een migratie die haar moment niet meer zelf mag kiezen.

Toch is de uitweg geen kwestie van moed. Er bestaat een upgradepatroon waarbij de weg terug er vanaf het begin in zit. Twee control planes, één label, geen drama. Volgende week hier.