Wie stabilisiert man eine geerbte Infrastruktur?

Am Montagmorgen reagiert ein alter Server erneut nicht. Das Lager sieht die Bestellungen nicht, die Rechnungsstellung wartet, und der Kundenservice versucht telefonisch herauszufinden, was passiert ist. In solchen Momenten stellt sich nicht die Frage, ob das System alt ist, sondern wie man eine geerbte Infrastruktur stabilisiert, ohne dass das Geschäft zum Stillstand kommt und ohne dass eine weitere Notfallreparatur die einzige Antwort ist.

Eine geerbte Infrastruktur wird oft über Jahre hinweg kritisch. Eine frühere Anwendung läuft nur auf einem bestimmten Server, Netzwerkerweiterungen sind undokumentiert, das Backup existiert, aber die Wiederherstellung wurde lange nicht getestet. In der Zwischenzeit ist das Unternehmen gewachsen: mehr Bestellungen, mehr Benutzer, mehr Integrationen und höhere Erwartungen auf derselben technischen Basis.

Stabilisierung bedeutet nicht, dass alles sofort ersetzt werden muss. In vielen Fällen birgt ein vollständiger Austausch das größte Geschäftsrisiko. Das Ziel ist zunächst, dass der grundlegende Betrieb vorhersehbar, kontrollierbar und wiederherstellbar wird. Erst dann kann verantwortungsbewusst über das Tempo der Modernisierung entschieden werden.

Wie stabilisiert man geerbte Infrastruktur aus geschäftlicher Sicht?

Der Ausgangspunkt ist nicht die Liste der Server, sondern die Kartierung kritischer Geschäftsprozesse. Welche Systeme sind unverzichtbar, um Bestellungen anzunehmen, die Produktion zu starten, Waren auszugeben, Rechnungen zu stellen oder Kunden zu bedienen? Wie lange kann ein Ausfall in den einzelnen Bereichen toleriert werden? Ein zweistündiger Berichtverzug kann unangenehm sein, aber ein zweistündiger Lagerstillstand kann bereits direkten Umsatz- und Vertrauensverlust verursachen.

Dieser Unterschied bestimmt die Prioritäten. Ein häufiger Fehler ist, dass das technische Team mit dem beginnt, was am ältesten oder am schwierigsten zu handhaben ist. Aus geschäftlicher Sicht muss jedoch zuerst das geschützt werden, dessen Ausfall die größten betrieblichen Konsequenzen hat.

Kartieren Sie nicht nur Systeme, sondern auch Abhängigkeiten

Eine Geschäftsanwendung fällt selten alleine aus. Sie kann von einer Datenbank, einem Dateiserver, einer Netzwerkverbindung, einem Lizenzserver, einer externen Partnerverbindung oder einem einzigen, nicht mehr unterstützten Client abhängen. Der Webshop kann funktionieren, aber wenn die Bestandsinformationen nicht ins ERP gelangen, arbeiten Vertrieb und Lager aus unterschiedlichen Realitäten.

Die Bewertung muss daher auch zeigen, wo versteckte individuelle Lösungen existieren. Beispielsweise wird ein automatisierter Datentransfer tatsächlich jeden Morgen von einem Kollegen gestartet. Oder eine alte Anwendung funktioniert nur, weil jemand weiß, welchen Dienst er neu starten muss. Dies sind nicht nur IT-Risiken, sondern betriebliche Risiken, die von Personen abhängen.

Es ist sinnvoll, bei jedem kritischen Dienst festzuhalten, welche Rolle er spielt, wo er läuft, mit welchen Daten er arbeitet, womit er verbunden ist, wer dafür verantwortlich ist und was bei einem Ausfall passiert. Es muss kein monatelanges Dokumentationsprojekt gestartet werden. Aber für Entscheidungen ist ein realistisches, gemeinsam akzeptiertes Bild des aktuellen Zustands erforderlich.

Stellen Sie zuerst die Betriebskontrolle wieder her

Eine stabile Infrastruktur bedeutet nicht, dass nie etwas ausfällt. Es bedeutet, dass Fehler rechtzeitig erkannt werden, ihre Auswirkungen begrenzt werden können und die Wiederherstellung nicht improvisiert wird.

Das erste Element ist die Beobachtbarkeit. Wenn Speicherplatz, Speicher, Netzwerkverbindung, Dienststatus oder Backup-Prozess erst sichtbar werden, wenn bereits eine Beschwerde eingegangen ist, ist das Unternehmen ständig im Rückstand. Die richtige Überwachung ist kein technisches Beiwerk. Sie hilft, ein langsamer werdendes, gesättigtes System von einem unerwarteten Ausfall zu unterscheiden und bildet die Grundlage für die Kapazitätsplanung.

Das zweite Element ist das Änderungsmanagement. Viele geerbte Umgebungen werden nicht durch einen großen Fehler fragil, sondern durch viele kleine, nicht nachverfolgbare Änderungen. Neuer Benutzer, manuell geänderte Berechtigungen, dringendes Update, temporäre Firewall-Regel und dann eine vergessene Ausnahme. Wenn nicht klar ist, was sich geändert hat, wer es genehmigt hat und wie man zurückkehren kann, erhöht jede Intervention das Risiko.

Das dritte Element ist die Bereinigung der Zugriffe. Allgemeine Administratorkonten, geteilte Passwörter und aktive Berechtigungen ehemaliger Mitarbeiter sind gleichzeitig Sicherheits- und Betriebsprobleme. Bei der Untersuchung eines Fehlers kann nicht einmal festgestellt werden, wer was getan hat. Die Berechtigungen müssen an die Aufgaben und Verantwortlichkeiten gebunden sein, und kritische Zugriffe müssen regelmäßig überprüft werden.

Ein Backup ist nur dann wertvoll, wenn es auch wiederhergestellt werden kann

Viele Organisationen beruhigen sich, wenn das Backup täglich läuft. Das ist nicht genug. Die eigentlichen Fragen sind andere: Ist das Backup intakt, ist es vom Live-System getrennt, wie viele Daten würden bei einer Wiederherstellung verloren gehen, und wie schnell können die kritischen Prozesse wieder anlaufen?

Für ein Produktions- oder Handelsunternehmen macht es einen Unterschied, ob die Wiederherstellung einer Datenbank drei Stunden oder drei Tage dauert. Ebenso, ob die mit dem wiederhergestellten System verbundenen Integrationen, Berechtigungen und Dateifreigaben funktionieren. Der Backup-Plan sollte daher nicht als administrative Compliance, sondern als Werkzeug zur Geschäftskontinuität behandelt werden.

Regelmäßige Wiederherstellungstests bringen in der Regel schnell versteckte Mängel ans Licht: fehlende Verschlüsselungsschlüssel, nicht dokumentierte Konfigurationen, erschöpfter Speicherplatz oder Abhängigkeiten, von denen niemand wusste. Diese Entdeckung ist unangenehm, aber in einer kontrollierten Situation viel günstiger als während eines echten Vorfalls.

Machen Sie den vollständigen Austausch nicht zum ersten Projekt

Bei der Modernisierung geerbter Infrastrukturen ist „alles ersetzen“ oft eine verständliche Reaktion, aber selten ein guter erster Schritt. Eine große Umstellung betrifft gleichzeitig Anwendungen, Daten, Integrationen, Benutzergewohnheiten und Betriebsprozesse. Wenn diese nicht aufgedeckt sind, verlagert das Projekt nur die Unsicherheit auf eine neue Plattform.

Ein schrittweiser Ansatz birgt in der Regel ein geringeres Risiko. Zuerst kann die kritischste Komponente abgetrennt oder geschützt, das Backup und der Zugriff geregelt, die Konfiguration dokumentiert und dann die veralteten Elemente in separaten Phasen modernisiert werden. Dies kann Servervirtualisierung, Netzwerksegmentierung, Umzug auf ein unterstütztes Betriebssystem, Einführung von Cloud-Diensten oder Ersatz einer Anwendung sein. Der richtige Weg hängt davon ab, welchen Geschäftsprozess das jeweilige Element unterstützt und wie stark es mit anderen Systemen verbunden ist.

Manchmal ist es gerechtfertigt, eine alte, aber stabile Anwendung beizubehalten, weil ihr Austausch zu großen Prozessänderungen führen würde. In diesem Fall muss ihre Umgebung sicherer gemacht, ihre Verbindungen geregelt und ein späterer Ersatzplan erstellt werden. In anderen Fällen stellt eine für ein altes System erstellte temporäre Schnittstelle oder ein manueller Export ein größeres Risiko dar als die Anwendung selbst.

Technische Stabilität ist auch menschliche Verantwortung

Wenn nur eine Person weiß, wie das Unternehmenssystem neu gestartet wird, gibt es keinen stabilen Betrieb. Wenn die Finanzabteilung Daten in einer eigenen Tabelle korrigiert, weil sie dem zentralen System nicht vertraut, betrifft das Infrastrukturproblem bereits die Entscheidungsunterstützung. Technische Unsicherheit führt schnell zu manuellen Umgehungen, parallelen Aufzeichnungen und Frustration.

Daher gehört zur Stabilisierung ein einfaches, nutzbares Betriebsregime: Wer nimmt den Alarm entgegen, wer entscheidet im Falle eines Vorfalls, wo ist die Dokumentation, wie erfolgt die Eskalation und wann werden die Risiken überprüft. Nicht jedes Unternehmen benötigt einen 24-Stunden-Bereitschaftsdienst oder ein komplexes Unternehmensregelwerk. Aber für jeden kritischen Betrieb muss es eine zugewiesene Verantwortung und ein erprobtes Verfahren geben.

Am Ende eines guten Stabilisationsprogramms ist die Technologie nicht unbedingt spektakulär neu. Vielmehr ist der Betrieb ruhiger: weniger unerwartete Ausfälle, schnellere Fehlerbehebung, zuverlässigere Daten, und der Betrieb hängt nicht von der Erinnerung eines einzelnen Kollegen ab. Von hier aus kann man nicht aus Zwang, sondern nach Plan weiterentwickeln.