Never change a running system? Bullshit!

Der Leitsatz "Never change a running system" ist eine der am häufigsten missverstandenen IT-Empfehlungen überhaupt. Abgesehen davon, dass es sich um einen deutschen Pseudo-Anglizismus handelt (im angloamerikanischen Sprachraum nutzt man diesen Spruch nicht, sondern nur in Deutschland – ähnlich wie das Wort "Handy"), dient dieser Satz in der Regel dazu, ein fehlendes Patchmanagement für Betriebssysteme und Applikationen zu rechtfertigen. Berechtigt ist das praktisch nie.

Der Spruch leitet sich von der Sportweisheit "never change a winning team" ab. Jeder halbwegs fähige Trainer weiß aber, dass selbst das nur für sehr begrenzte Zeit gut geht, weil das Team dann eben nicht mehr gewinnt. Die Aufgabe eines guten Teamchefs besteht darin, sein Team weiterzuentwickeln, damit es besser wird oder zumindest seinen Status nicht verliert. Selbst die Mannschaft von Bayern München wird ständig umbesetzt, obwohl es mehr als den Meistertitel in der Bundesliga kaum zu gewinnen gibt.

Bei dieser falsch verstandenen und falsch angewandten Binsenweisheit geht es nicht darum, ein System nie zu patchen, weil es grundsätzlich läuft, also in Betrieb ist. Im Gegenteil geht es nur darum, ein System nicht in genau dem Moment in seiner Funktion zu verändern, in dem kritische Prozesse darauf von den Anwendern aktiv benötigt werden! Heißt also: Wartungsfenster definieren, statt einfach die Maschine zu patchen.

Aus Sicht der Sicherheit und Stabilität eines Systems kann es nur lauten: Patch your stuff! Nicht umsonst lautet die idiomatische Entsprechung zu unserem nicht so richtig englischen Sprichwort "if it ain’t broke don’t fix it" – wenn es nicht kaputt ist, dann repariere es nicht. Warum aber erscheinen Patches und Service Packs? Nur deshalb, weil im Herstellersupport festgestellt wurde, dass der ursprüngliche Code fehlerhaft ist. Das System ist also bereits kaputt – und daher muss es repariert werden!

Die richtige Einstellung ist also, ein aktives Patch- und Updatemanagement zu betreiben. Die technische Infrastruktur dafür existiert seit Jahren. Ein professionelles Patchmanagement in einem kleineren oder mittleren Unternehmen muss auch nicht ständig Arbeitskraft binden: Mit Virtualisierungs-Laboren lassen sich die kritischen Systeme schnell simulieren und die Auswirkungen von Patches und Service Packs prüfen. Läuft das Testsystem danach noch, kann der Patch produktiv eingesetzt werden. Da die meisten Patches deinstallierbar sind (bei den Ausnahmen ist dies in der Regel dokumentiert), ist auch das Fallback-Verfahren bekannt, es braucht nur eine gewisse Aufmerksamkeit.