Das Upgrade, das seit drei Versionen wartet

In vielen Backlogs gibt es ein Ticket, das bald Geburtstag feiert. Es heißt “Mesh-Upgrade” und wandert seit Monaten von Sprint zu Sprint.

Das Muster dahinter sehe ich in vielen Setups. Niemand traut sich an den Datenpfad: Ein Mesh-Upgrade fasst potenziell jeden Sidecar an, und damit jeden Service im Cluster. Gleichzeitig ist niemand zuständig. Das Mesh gehört “der Plattform”, das Upgrade gehört niemandem. Also wartet es.

Während es wartet, stapeln sich draußen die Releases, und das Support-Fenster wandert weiter. Der Abstand zwischen “wo wir stehen” und “wo wir sein müssten” wächst. Je größer der Abstand, desto größer der Sprung. Je größer der Sprung, desto größer der Testaufwand, desto größer die Angst, desto länger das Warten. Der Kreislauf verstärkt sich selbst. Die Angst ist der einzige Teil des Systems, der automatisch skaliert.

Wie diese Geschichte endet, stand schon in Post 2: Wenn das CVE kommt, ist es zu spät. Patches zielen auf aktuelle Releases. Wer weit zurückliegt, kann im Ernstfall nicht einfach patchen. Er springt über mehrere Versionen, unter Zeitdruck.

Für Entscheider sind Upgrade-Schulden deshalb ein doppeltes Risiko. Ein Sicherheitsrisiko, weil der Ernstfall keinen Aufschub kennt. Und ein Personalrisiko, weil der große Sprung genau das Spezialwissen braucht, das im Notfall am schwersten zu beschaffen ist. Beides taucht in keinem Risk Register auf, solange das Ticket brav weiterwandert.

Ein Upgrade, das drei Versionen wartet, ist kein Upgrade mehr. Es ist eine Migration, die sich ihren Zeitpunkt nicht mehr aussuchen darf.

Dabei ist der Ausweg keine Frage von Mut. Es gibt ein Upgrade-Muster, bei dem der Rückweg von Anfang an eingebaut ist. Zwei Control Planes, ein Label, kein Drama. Nächste Woche hier.