Einleitung
Der Satz "Never change a running system" ist eine IT-Weisheit, die ich oft in meinem IT Umfeld höre. Kleiner Fun fact: Im englischsprachigen Raum kennt den Spruch kaum jemand. Dort heißt es eher: “If it ain’t broke, don’t fix it.” Klingt ähnlich, meint aber eigentlich auch nicht das, was viele daraus interpretieren.
In der Praxis wird damit oft begründet, warum Systeme keine Patches oder Updates bekommen sollten: "Läuft doch alles". Oder?
Klar - bis zur nächsten Sicherheitslücke, die gerade aktiv ausgenutzt wird. Denn genau dafür gibt’s Patches: weil im Code Fehler oder gefährliche Sicherheitslücken gefunden wurden. Und die sind dann vorhanden, ob du sie schon bemerkt hast oder nicht.
Was wirklich gemeint ist
Wenn überhaupt, dann sollte der Spruch heißen: "Verändere ein System nicht genau dann, wenn’s gerade kritisch gebraucht wird." oder wenn es aus Sicherheitsgründen nicht notwendig ist. Und das ergibt auch Sinn. Wer mitten im Livebetrieb Updates einspielt - ohne Tests, Backup oder Plan - riskiert nicht nur das System, sondern auch den Geschäftsbetrieb.
Also lieber: Wartungsfenster festlegen, Updates vorher testen, idealweise in einer Sandbox wie in einer VM, eigene Container oder Testumgebungen. Und dann sauber einspielen. So einfach ist das.
Es gibt Ausnahmen - zum Beispiel in der Musikproduktion
Besonders vorsichtig sollte man sein, wenn man mit Musiksoftware, Audio-Interfaces oder Plugins arbeitet. Da kann ein Update - vor allem ein neues Betriebssystem - ziemlich schnell das komplette Setup zerschießen. Viele Hersteller brauchen Monate, bis sie Kompatibilität mit neuen macOS- oder Windows-Versionen garantieren können.
Wer professionell Musik produziert, kennt das: Lieber mal ein halbes Jahr beim alten OS bleiben, statt nach dem Update plötzlich ohne funktionierende Plugins dazustehen und damit die eigene, vielleicht sogar terminierte, Produktion zu gefährden.
So handhabe ich es auch: Updates von zum Beispiel macOS spiele ich oft erst nach einem halben Jahr ein. Manchmal schon etwas früher, wenn ich zum Beispiel für ein großes Software Unternehmen im Musikbereich deren Beta-Version deren Musiksoftware auf dem neuen OS teste. Dann allerdings nicht auf meinem Produktivsystem, sondern ich installiere das neue OS auf einer externen Festplatte. An der Stelle ist eine VM kontraproduktiv, da es bei einer derartigen Software auf jede ms an Latenzreduktion ankommt und somit nur eine Bare-Metal Installation in Frage kommt.
Auch Entwickler müssen abwägen
In der Softwareentwicklung ist Patchmanagement zwar wichtig - aber auch hier gilt: Nicht jedes Update ist gleich ein Gewinn. Neue Versionen von Libraries, Frameworks oder Toolchains können Abhängigkeiten zerschießen, zu Inkompatibilitäten führen oder einfach mehr Probleme schaffen, als sie lösen.
Das heißt nicht, dass man gar nicht updaten sollte - im Gegenteil. Aber: Testen, testen, testen. Automatisierte Tests, CI/CD-Pipelines, Tools wie Renovate helfen dabei, verfügbare Updates für Abhängigkeiten automatisch zu erkennen und in Form von Pull/Merge Requests bereitzustellen, Docker-Container oder VMs sind da die besten Freunde. Wer das sauber aufsetzt, kann auch Updates zügig, aber mit Plan einführen. Beim Einsatz von Renovate in Kombination mit einem CI/CD System wie Gitlab oder Github erstellt Renovate Merge-Requests / Pull-Requessts, womit man gezielt die Changelogs der Abhängigkeiten auf zum Beispiel "Breaking Changes" vorab prüfen und entscheiden kann, ob hier eine Aktualisierung problemlos möglich ist.
Fazit
„Never change a running system“ ist kein Freifahrtschein für Stillstand. Systeme müssen gepflegt werden - und dazu gehören Updates nun mal dazu. Nur eben nicht kopflos. Die richtige Devise lautet also eher:
"Change it - but test it first."
Ich freue mich auf eure Rückmeldungen und gerne auch auf eine konstruktive Diskussion.
Sprich: ich oder mein Unternehmen soll für den Schutz sorgen - und der Schutz fängt beim Endanwender und dessen Verständnis / Verhalten am Rechner an.
