Wie stabilisiert man eine geerbte Infrastruktur?

Am Montagmorgen reagiert ein alter Server erneut nicht. Das Lager kann die Bestellungen nicht sehen, die Rechnungsstellung wartet, und der Kundenservice versucht telefonisch herauszufinden, was passiert ist. In solchen Fällen stellt sich nicht die Frage, ob das System alt ist, sondern wie wir eine veraltete Infrastruktur stabilisieren können, ohne dass das Geschäft zum Stillstand kommt und ohne dass eine weitere Notfallreparatur die einzige Antwort ist.

Eine veraltete Infrastruktur ist oft über Jahre hinweg kritisch geworden. 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 danach kann verantwortungsbewusst über das Tempo der Modernisierung entschieden werden.

Wie stabilisiert man eine veraltete Infrastruktur aus geschäftlicher Sicht?

Der Ausgangspunkt ist nicht die Liste der Server, sondern die Kartierung kritischer Geschäftsprozesse. Welche Systeme sind unerlässlich, 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? Eine zweistündige Berichtsverzögerung 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äftsapplikation fällt selten allein 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 heraus.

Die Bewertung muss daher auch zeigen, wo es versteckte individuelle Lösungen gibt. Beispielsweise wird eine vermeintlich automatische Datenübertragung 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 keine einfachen IT-Risiken, sondern betriebliche Risiken, die von Personen abhängen.

Es ist ratsam, bei jedem kritischen Dienst festzuhalten, welche Rolle er spielt, wo er läuft, mit welchen Daten er arbeitet, woran er angeschlossen 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 schiefgeht. Es bedeutet, dass Fehler rechtzeitig erkannt werden, ihre Auswirkungen begrenzt werden können und die Wiederherstellung nicht aus Improvisation besteht.

Das erste Element ist die Beobachtbarkeit. Wenn Speicherplatz, Speicher, Netzwerkverbindung, Dienststatus oder Backup-Prozess erst sichtbar werden, wenn bereits eine Beschwerde vorliegt, ist das Unternehmen ständig im Rückstand. Die richtige Überwachung ist keine technische Dekoration. 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 veraltete Umgebungen werden nicht durch einen großen Fehler anfällig, sondern durch viele kleine, nicht nachverfolgbare Änderungen. Neuer Benutzer, manuell geänderte Berechtigung, 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 früherer Mitarbeiter sind sowohl Sicherheits- als auch Betriebsprobleme. Bei der Untersuchung eines Fehlers kann nicht einmal festgestellt werden, wer was getan hat. Die Berechtigungen müssen an die Aufgaben und Verantwortlichkeiten gekoppelt sein, und kritische Zugriffe sollten regelmäßig überprüft werden.

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

Viele Organisationen beruhigen sich damit, dass das Backup täglich läuft. Das ist nicht genug. Die eigentlichen Fragen sind andere: Ist das Backup intakt, ist es von der Produktionsumgebung getrennt, wie viele Daten würden bei einer Wiederherstellung verloren gehen, und wie lange dauert es, bis der kritische Prozess wieder startet?

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

Ein regelmäßiger Wiederherstellungstest bringt in der Regel schnell versteckte Mängel ans Licht: fehlender Verschlüsselungsschlüssel, nicht dokumentierte Konfiguration, erschöpfter Speicherplatz oder eine Abhängigkeit, von der 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 einer veralteten Infrastruktur ist „alles ersetzen“ oft eine verständliche Reaktion, aber selten der richtige erste 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 werden, das Backup und der Zugriff können geregelt, die Konfiguration dokumentiert und dann die veralteten Elemente in einem separaten Tempo modernisiert werden. Dies kann Servervirtualisierung, Netzwerksegmentierung, Umzug auf ein unterstütztes Betriebssystem, Einführung von Cloud-Diensten oder der 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.

Es gibt Zeiten, in denen es gerechtfertigt ist, 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 reguliert und ein späterer Ersatzplan erstellt werden. Manchmal stellt gerade 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 eine menschliche Verantwortung

Wenn nur eine Person weiß, wie das Unternehmenssystem neu gestartet wird, gibt es keinen stabilen Betrieb. Wenn die Finanzabteilung ihre 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 ist ein einfacher, nutzbarer Betriebsablauf Teil der Stabilisierung: 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-internen 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 vom Gedächtnis eines einzigen Kollegen ab. Von hier aus kann nicht aus Zwang, sondern nach Plan weiterentwickelt werden.