Verfügbarkeit kritischer Systeme

Ein Webshop-Ausfall ist nicht nur ein IT-Vorfall: Bestellungen werden unterbrochen, das Lager erhält keine Aufgaben, der Kundendienst hat keine Daten und die Finanzprozesse stehen später vor fehlerhaften Abstimmungen. Die Verfügbarkeit kritischer Systeme ist daher eine Frage der Geschäftskontinuität. Es geht nicht um den Zustand eines einzelnen Servers, Cloud-Dienstes oder einer Anwendung, sondern darum, ob der gesamte Prozess den Unternehmensanforderungen entsprechend funktionieren kann.

In mittelgroßen Unternehmensumgebungen beginnt das Problem oft nicht mit einem auffälligen Fehler. Zunächst verzögern sich Bestandsaktualisierungen, eine Rechnungsintegration bleibt gelegentlich hängen oder das Fertigungssystem startet zu Beginn der Schicht langsamer. Diese Anzeichen können darauf hindeuten, dass das System seine Kapazitäts-, Architektur- oder Betriebsgrenzen erreicht hat. Wenn die Funktionsweise der verbundenen Systeme nicht als Ganzes betrachtet wird, können kleinere Störungen leicht zu Geschäftsausfällen werden.

Was bedeutet Verfügbarkeit wirklich?

Die Verfügbarkeit zeigt einfach, wie lange ein Dienst in einem bestimmten Zeitraum genutzt werden kann. Dies allein reicht jedoch nicht für die Entscheidungsfindung des Managements aus. Ein ERP kann technisch verfügbar sein, während der Webshop die Bestellungen nicht weiterleiten kann . Ein Lagerterminal kann funktionieren, aber wenn die Artikelstammdaten den Stand von vor Stunden anzeigen, kann der Dienst aus Betriebssicht nicht als vollständig funktionsfähig angesehen werden.

Daher muss die Verfügbarkeit pro Geschäftsdienst interpretiert werden. Unterschiedliche Erwartungen gelten für eine interne Berichtsschnittstelle als für einen Bestellverwaltungs-, Logistik- oder Fertigungssteuerungsprozess. Im ersten Fall kann ein kurzes, vorher abgestimmtes Wartungsfenster akzeptabel sein. Im zweiten Fall kann bereits ein Ausfall von wenigen Minuten zu Staus, manuellen Lösungen und Kommunikationsbelastungen mit Kunden führen.

Verfügbarkeit ist nicht gleich Benutzbarkeit

Technische Überprüfungen konzentrieren sich oft darauf, ob ein Server antwortet oder eine Webseite geladen wird. Dies ist ein nützlicher Grundindikator, beweist jedoch nicht, dass die Geschäftsprozesse funktionieren. Ein ausgereifter Überwachungsansatz untersucht beispielsweise auch, ob eine Bestellung erstellt wird, in das ERP übertragen wird, die Rechnung erstellt wird und das Lager die Kommissionieraufgabe erhält.

Benutzerorientierte Überprüfungen erfordern mehr Planung, zeigen jedoch im Gegenzug früher Integrations-, Berechtigungs- oder Datenqualitätsfehler an. Sie sind besonders wichtig dort, wo mehrere externe Dienstleister, APIs, logistische und Lieferantendatenquellen oder Altsysteme verbunden sind.

Grundlagen der Verfügbarkeit kritischer Systeme

Höhere Verfügbarkeit ist nicht das Ergebnis eines einzelnen Produkts oder Infrastrukturelements. Es ist eine Kombination aus Architektur, Betriebssdisziplin und Geschäftsprioritäten. Die richtige Konfiguration hängt davon ab, welche Prozesse kritisch sind, welcher Ausfall akzeptabel ist und welche Kosten zur Risikobewältigung gerechtfertigt sind.

Vier Bereiche, die gemeinsam betrachtet werden sollten:

• Abhängigkeiten kartieren: Welche Datenbanken, Integrationen, Netzwerkelemente, Zertifikate und externen Dienste sind für den Betrieb eines Geschäftsprozesses erforderlich.
• Fehlertolerantes Design: Wo es gerechtfertigt ist, sollten redundante Komponenten, Lastverteilungvorhanden sein, isolierte Infrastruktur oder automatische Übernahme bei Ausfall.
• Beobachtbarkeit: Welche geschäftlichen und technischen Signale müssen kontinuierlich gemessen werden, wer erhält Benachrichtigungen und welches Eskalationsprotokoll wird für Eingriffe befolgt.
• Wiederherstellungsfähigkeit: Sind Backups, Konfigurationen, Zugriffe und dokumentierte Schritte verfügbar, um den Dienst innerhalb der erforderlichen Zeit wiederherzustellen.

Von der Liste erhält die Redundanz normalerweise die meiste Aufmerksamkeit, löst jedoch nicht alles allein. Zwei Anwendungsserver helfen nicht, wenn sie mit derselben einzigen Datenbank verbunden sind oder wenn ein abgelaufenes Zertifikat beide unbrauchbar macht. Die echten Risiken müssen über die gesamte Länge der Abhängigkeitskette betrachtet werden.

RTO und RPO: die zwei Fragen, die die Erwartungen klären

Das Wiederherstellungszeit-Ziel, das RTO, beantwortet, wie schnell ein Dienst wieder nutzbar werden soll. Das Wiederherstellungspunkt-Ziel, das RPO, legt fest, wie viel Datenverlust akzeptabel ist. Zum Beispiel können die Erwartungen an ein Bestellverwaltungssystem völlig anders sein als an ein Dokumentenarchiv.

Diese Werte sollten nicht ausschließlich auf der IT-Seite festgelegt werden. Die Geschäftsleitung muss entscheiden, welcher Ausfall und Datenverlust noch ein handhabbares Betriebslast darstellt, und das IT-Team muss dafür realistische technische und betriebliche Lösungen planen. Zu strenge Ziele können unnötig teure Systeme zur Folge haben, während zu lockere Erwartungen nur während eines laufenden Vorfalls die Mängel aufdecken.

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

Viele Organisationen haben Backup-Aufgaben, aber nur wenige können nachweisen, dass ein kritischer Dienst tatsächlich innerhalb der erforderlichen Zeit wiederhergestellt werden kann. Ein Datenbank-Backup kann fehlerhaft sein, Verschlüsselungsschlüssel können fehlen oder die für die Wiederherstellung erforderlichen Anwendungskonfigurationen und Infrastrukturbeschreibungen sind nicht verfügbar.

Daher endet die Backup-Strategie nicht mit dem Kopieren von Dateien. Sie muss Datenbanken, Anwendungscodes, Konfigurationen, Beschreibungen von virtuellen Maschinen oder Containern, Berechtigungsmodelle und die Dokumentation der erforderlichen externen Verbindungen abdecken. Bei einem Wiederherstellungstest muss nicht nur überprüft werden, ob das System startet, sondern auch, ob der Geschäftsprozess durchläuft.

Regelmäßige Tests sind mit Kosten und organisatorischen Anforderungen verbunden. Hier wird der auf Papier stehende Kontinuitätsplan jedoch zur operativen Fähigkeit. Die Testergebnisse decken oft versteckte Abhängigkeiten auf, die im normalen Betrieb nicht sichtbar sind.

Überwachung: nicht nur Alarme, sondern Grundlage für Entscheidungen

Zu viele Alarme verlieren schnell an Bedeutung. Wenn ein Operator täglich dutzende nicht dringende Benachrichtigungen erhält, kann er leicht über das eigentliche Problem hinwegsehen. Daher sollte die Überwachung nach Prioritäten, geschäftlichen Auswirkungen und klaren Verantwortlichkeiten entwickelt werden.

Ein nützliches System überwacht die Verfügbarkeit, Antwortzeiten, Ressourcenauslastung, Fehlerraten, Abschluss von Backups und den Status der Integrationswarteschlangen. Es zeigt auch Trends. Eine allmählich steigende Datenbank-Antwortzeit oder Speicherplatznutzung ist nicht unbedingt ein sofortiger Vorfall, kann jedoch ohne angemessene Kapazitätsplanung später zu einem werden.

Die Führungsebene muss nicht jede technische Kennzahl enthalten. Viel nützlicher ist es, zu zeigen, welche Dienste betroffen sind, welche Geschäftsprozesse von dem Fehler betroffen sind, welcher Wiederherstellungsweg erwartet wird und ob eine betriebliche Entscheidung erforderlich ist. Dieser Ansatz reduziert Missverständnisse zwischen IT und Geschäftsbereichen.

Änderungsmanagement ist Teil der Verfügbarkeit

Die meisten Umgebungen sind nicht statisch. Neue Webshop-Funktionen, ERP-Updates, API-Verbindungen, Infrastruktur-Migrationen oder Berechtigungsänderungen gestalten ständig die Risikolandschaft. Unkontrollierte Änderungen sind häufige Ursachen für unerwartete Dienstunterbrechungen, auch wenn die Änderung selbst zunächst unbedeutend erscheint.

Änderungsmanagement muss keine schwerfällige Bürokratie sein. Bei kritischen Systemen sind jedoch Auswirkungen, Wiederherstellungsplanung, Tests und klare Genehmigungen erforderlich. Besonders bei Integrationen ist es wichtig zu wissen, welche weiteren Systeme durch eine Änderung eines Feldes, einer Zeitplanung oder einer Authentifizierungsmethode betroffen sein könnten.

Wartungsfenster sind ebenfalls Teil der bewussten Verfügbarkeit. Ein im Voraus kommuniziertes, kontrolliertes Update birgt oft ein geringeres Geschäftsrisiko als ein dringender Eingriff aufgrund einer aufgeschobenen Reparatur. Das Ziel ist, dass die Änderung vorhersehbar ist und im Fehlerfall eine Rückfalloption besteht.

Systemverantwortung in komplexen Umgebungen

Webshop, ERP, WMS, Abrechnungs-, Fertigungssystem und Logistikpartner haben selten eine einzige Fehlerquelle oder ein einziges verantwortliches Team. Daher ist es unerlässlich, Systemgrenzen, Dienstverantwortlichkeiten und Eskalationswege klar zu definieren. Während eines Vorfalls sollte nicht erst herausgefunden werden, wer Zugriff auf die Protokolle hat, wer Konfigurationen ändern kann oder wer mit dem externen Dienstleister koordiniert.

Im CGAT-Ansatz können Anwendungsentwicklung, Integration und Infrastrukturmanagement nicht künstlich getrennt werden, wenn sie denselben Geschäftsprozess bedienen. Die Verfügbarkeit verbessert sich erheblich, wenn Fehler nicht als isolierte Symptome, sondern als Teil des gesamten Systembetriebs betrachtet werden.

Es lohnt sich, damit zu beginnen, die drei bis fünf Geschäftsprozesse zu identifizieren, deren Ausfall am schnellsten zu Betriebsstörungen führt. Für diese können realistische Verfügbarkeitsziele, Wiederherstellungserwartungen und messbare Betriebskontrollen festgelegt werden. Dies ist ein viel brauchbarerer Ausgangspunkt als ein allgemeines Versprechen, dass alle Systeme immer funktionieren müssen.