Software-Update
Na, toll. [Update]
Kam vorhin im Radio, blubbert gerade so durch die Presse: Etliche Flüge sind heute morgen ausgefallen (Ferienzeit…) und irgendwo im deutschen Luftraum musste die Verkehrsmenge auf die Hälfte reduziert werden, weil bei der Flugsicherung ein Software-Update in die Hose gegangen war und sie die Systeme erst wieder zum Laufen bringen mussten.
Oder wie die WAZ es ausdrückt:
Beim Einspielen eines Updates bei der Flugsicherung gab es technische Probleme.
[…]Technische Probleme bei der Deutschen Flugsicherung haben am frühen Mittwochmorgen den Flugverkehr über weiten Teilen Deutschlands vorübergehend eingeschränkt. Die Störung konnte am Morgen wieder behoben werden, ab 9 Uhr sollte wieder der normale Betrieb möglich sein, sagte eine Sprecherin der bundeseigenen Einrichtung.
Grund war ein Softwareproblem beim Aufspielen eines Updates im Kontrollcenter Langen, wie eine Sprecherin der bundeseigenen Einrichtung erklärte.
Wenn ich sowas schon höre: „Aufspielen eines Updates“.
Kann man machen, ja. Wenn es nicht mit den Verfügbarkeitsanforderungen kollidiert. Auf meinem PC kann ich Updates „aufspielen“. Auch bei meinem Blog. Weil da kein nennenswerter Schaden entsteht, wenn das mal einen halben Tag nicht funktioniert, man kann die Blogartikel auch ein paar Stunden später schreiben oder lesen.
Aber nicht bei etwas wie der Flugsicherung.
Eigentlich gibt es dafür schon lange geeignete Technik, um so etwas zu verhindern.
Schon lange ist es üblich, Systeme so zu bauen, dass sie zwei Installation fahren, immer nur eine davon aktiv betrieben und die andere aktualisiert wird, und man erst umschaltet, wenn die Aktualisierung sauber durchgelaufen ist. Und gibt es dann Probleme, kann man wieder zurückschalten. Gibt es eigentlich schon ewig, meist ohne Namen, neulich habe ich dann auch endlich mal einen Fachbegriff dafür gefunden, ich glaube, sie nannten das A-B-Betrieb. Sowas ähnliches habe ich um 2004 herum schon mal aufgesetzt, hatte das Ding damals „Boot-Oszillator“ genannt, weil das System so gebaut war, dass es selbsttätig immer abwechselnd die eine und die andere Installation bootete.
Eine andere Herangehensweise ist, Systeme gar nicht mehr zu aktualisieren, sondern über Software-Container zu betreiben. Man baut sich also erst den neuen Container mit der aktualisierten Software. Dann testet man ihn, ob der auch funktioniert und alles sauber läuft. Und dann kopiert man ihn auf das Produktiv-System, hält dort den alten Container an und startet sofort den neuen. Sowas geht im Sekundenbereich. Je nach Anwendung, etwa bei Client-Server-Architekturen, sogar überlappend, also so, dass der neue Container schon neue Anfragen annimmt, während der alte noch arbeitet und seine Anfragen abzuarbeiten. Wird in der IT auch als Eigenschaft beworben unter dem etwas schreierischen, aber nicht unberechtigten Begriff „Zero Downtime“.
Gut, das sagt sich jetzt leicht, wenn man nicht weiß, was dort überhaupt schief gelaufen ist. Aber grundsätzlich gibt es Techniken, um Systeme zu aktualisieren, ohne „Updates aufzuspielen“.
Update: Ah, ja. Ein Leser schreibt, der Fachbegriff für diesen Ansatz mit zwei abwechselnd verwendeten Installationen ist „Blue-Green-Deployment“.
Stimmt. Mir war es nicht mehr eingefallen. Die Technik an sich kenne ich seit über 10 Jahren, wird beispielsweise auch bei Ubuntu Core und Fedora CoreOS eingesetzt, aber dass sich dafür ein Fachbegriff etabliert hatte, habe ich neulich erst gelesen und der war mir wieder entfallen.
Dabei hätte ich durchaus drauf kommen können, denn das macht man ja – spätestens seit COVID-19 und Pandemie – auch mit Teams, die sich abwechseln, Team blau und Team grün. Sowas hatte ich so um 2010 schon mal für irgendeine Grippewelle (Schweine- oder was) entworfen, aber mit drei Teams. Ein Team aus denen, die sich impfen lassen wollten. Eins aus denen, die sich nicht impfen lassen wollen. Und beide nur abwechselnd in der Firma. Ein drittes Team ausschließlich aus dem Home-Office. Und jedes Team muss für sich alleine den Notbetrieb aufrecht erhalten können.