Bewertung von Unternehmens-Failover-Lösungen

Die Abrechnung funktioniert, die Auftragsverwaltung funktioniert, das Lager läuft – bis ein zentraler Server, eine Internetverbindung oder eine Anwendung ausfällt. Dann zeigt sich, wer noch arbeiten kann, welche Daten zugänglich sind und welche Prozesse vollständig zum Erliegen kommen. Die Bewertung von Unternehmens-Failover-Lösungen ist daher nicht in erster Linie eine Infrastruktur-Kaufentscheidung. Es geht darum zu prüfen, wie schnell ein technischer Fehler zu einem geschäftlichen Problem wird.

Bei einem Unternehmen mit 20 bis 500 Mitarbeitern ist der Ausfall selten in der ersten Minute sichtbar. Zuerst kann jemand kein Etikett drucken. Eine Bestellung aus dem Webshop wird nicht in das Verwaltungssystem übertragen. Die für den Produktionsplan erforderlichen Daten befinden sich nur in einem freigegebenen Ordner, der gerade nicht verfügbar ist. Nach einigen Stunden ersetzen Telefone, E-Mails und manuell geführte Listen die Systeme. Dies führt nicht nur zu Einnahmeverlusten, sondern auch zu Fehlern, Verzögerungen, Überstunden und unsicheren Managemententscheidungen.

Was muss tatsächlich bewertet werden?

Failover ist ein Backup-Betriebsmechanismus, der eine ausgefallene Komponente durch eine andere Ressource ersetzt. Dies kann ein sekundärer Server, eine alternative Internetverbindung, ein Ersatznetzwerkgerät, eine Datenbankreplik oder eine in der Cloud laufende Umgebung sein. Die technische Definition ist jedoch nur der Ausgangspunkt.

Die Führungsfrage lautet eher: Wenn dieses System nicht verfügbar ist, was genau kann im Unternehmen nicht passieren? Nicht jedes System verdient denselben Schutz. Ein mehrstündiger Ausfall eines internen Archivs kann handhabbar sein. Der Ausfall der Auftragsabwicklung, der Lagerbestandsinformationen, der Produktionssteuerung oder der Abrechnungsverbindung kann jedoch schnell zu einem direkten Geschäftsrisiko werden.

Eine gute Bewertung beginnt also nicht mit der Frage, ob zwei Server benötigt werden. Zuerst muss aufgezeigt werden, wie eine Bestellung, ein Arbeitsblatt oder ein Lieferbedarf durch die Systeme und die Menschen fließt. Oft zeigt sich hier, dass die größte Abhängigkeit nicht die Anwendung ist, sondern eine einzige Integration, eine gemeinsame Dateifreigabe oder ein von einem Mitarbeiter bekannter manueller Umweg.

Der erste Schritt bei der Bewertung von Unternehmens-Failover-Lösungen: Geschäftsauswirkungen

Es lohnt sich, mit einigen konkreten Geschäftsszenarien zu arbeiten, nicht mit allgemeinen Fragen. Was passiert zum Beispiel, wenn das Unternehmensinternet an einem Montagmorgen für vier Stunden ausfällt? Kann das Lager kommissionieren? Kommen die Webshop-Bestellungen an? Haben die Vertriebsmitarbeiter Zugriff auf Kundendaten? Kann die Finanzabteilung Rechnungen ausstellen oder Bankdaten überprüfen?

Ebenso wichtig ist die Untersuchung von Anwendungsfehlern. Wenn das ERP verfügbar ist, aber die Verbindung zwischen dem Webshop und dem ERP ausfällt, bemerkt das Team dies sofort? Werden die Bestellungen aufgereiht, gehen verloren oder beginnen die Kollegen, sie manuell neu zu erfassen? Die manuelle Erfassung mag kurzfristig hilfreich erscheinen, führt jedoch später zu Duplikationen, fehlerhaften Beständen und Abstimmungsarbeiten.

Bei der Bewertung der Auswirkungen sollten vier Perspektiven separat behandelt werden:

• Einnahmen und Kundenservice: Werden Bestellungen, Lieferungen oder Abrechnungen verpasst;
• Betrieb: Stoppt das Lager, die Produktion, der Einkauf oder der Kundenservice;
• Daten und Compliance: Können Daten beschädigt werden, Transaktionen verloren gehen oder Aufzeichnungspflichten verletzt werden;
• Menschliche Belastung: Wer behandelt den Fehler, wer kann Umgehungsprozesse anwenden und wie lange kann dieser Zustand aufrechterhalten werden.

Auf dieser Grundlage kann bereits zwischen unangenehmen und inakzeptablen Ausfällen unterschieden werden. Dieser Unterschied bestimmt, ob für ein System eine dokumentierte Wiederherstellung ausreicht oder ein automatischer Failover erforderlich ist.

RTO und RPO: Zwei Werte, die in Geschäftssprache übersetzt werden müssen

In der Failover-Planung werden häufig zwei Abkürzungen verwendet. Das RTO, oder Recovery Time Objective, gibt an, wie lange es dauern sollte, bis ein Dienst wieder nutzbar ist. Das RPO, oder Recovery Point Objective, gibt an, wie viel Datenverlust akzeptabel ist.

Die Zahlen sind für sich genommen wenig wert. Dass ein System ein RTO von vier Stunden hat, ist nur dann sinnvoll, wenn das Unternehmen weiß, was in diesen vier Stunden passiert. Wenn dies zwischen acht Uhr morgens und zwölf Uhr mittags den Stillstand der Lagerauslieferung bedeutet, könnte das Ziel zu locker sein. Wenn es sich um eine selten genutzte Berichtsumgebung handelt, könnte es sogar gerechtfertigt sein.

Beim RPO ist es dasselbe. Ein einstündiger Datenverlust kann bei bestimmten Dokumentenarchiven akzeptabel sein, jedoch nicht in einem Bestell- oder Produktionssystem, in dem jede Minute neue Transaktionen entstehen. In solchen Fällen reicht eine nächtliche Sicherung nicht aus. Es kann Replikation, häufigere Sicherungen oder eine Anwendungslogik erforderlich sein, die die Wiederherstellbarkeit der Transaktionen gewährleistet.

Zu strenge Ziele haben ihren Preis. Sofortiger Failover, aufrechterhaltene Kapazität an mehreren Standorten und kontinuierliche Datensynchronisation erfordern erhebliche Investitionen und Betriebskontrolle. Es ist nicht das Ziel, jedes System für eine bankähnliche Verfügbarkeit zu konzipieren. Das Ziel ist, dass der Schutz im Verhältnis zu den tatsächlichen geschäftlichen Folgen eines Ausfalls steht.

Ein Ersatzserver reicht nicht aus, wenn die Abhängigkeiten an einem Ort bleiben

Viele Organisationen haben Backups, möglicherweise auch sekundäre Server, aber dennoch bleibt ein einziger Fehlerpunkt im Betrieb. Die sekundäre Umgebung kann starten, aber wenn sie dieselbe Internetverbindung nutzt, auf denselben Authentifizierungsdienst angewiesen ist oder derselbe Integrationsdienst die Systeme verbindet, ist das Problem nicht gelöst.

Die Untersuchung muss daher die gesamte Kette umfassen: Netzwerk, Stromversorgung, DNS, Identitätsmanagement, Datenbank, Anwendungen, externe Dienstleister und Integrationen. Ein Webshop kann beispielsweise verfügbar sein, während der Zahlungsdienstleister, die Bestandsinformationen oder die Transportverbindung nicht funktionieren. Aus geschäftlicher Sicht ist dies ein teilweiser, aber sehr realer Ausfall.

Manuelle Prozesse stellen ebenfalls eine Abhängigkeit dar. Wenn ein Mitarbeiter jeden Nachmittag eine Datei exportiert und dann in das System eines Partners hochlädt, kann die Abwesenheit dieser Person und der Fehler bei der Dateifreigabe einen Stillstand verursachen. Hier ist Failover teilweise eine technische Frage, teilweise eine Frage der Prozessneugestaltung. Möglicherweise ist die richtige Antwort nicht eine teure hochverfügbare Umgebung, sondern die Beseitigung der manuellen Übergabe und die Überprüfbarkeit der Integration .

Automatischer oder manueller Failover?

Automatischer Failover ist schneller, aber komplexer. Er ist nützlich, wenn der Ausfall innerhalb von Minuten messbaren geschäftlichen Schaden verursacht und der Zustand des Dienstes sicher überprüft werden kann. Zum Beispiel kann er bei einem von Kunden direkt genutzten Online-Dienst oder bei einer kontinuierlichen Produktionsdatenverbindung gerechtfertigt sein.

Manueller Failover ist langsamer, aber in vielen Fällen einfacher, kostengünstiger und besser kontrollierbar. Bei einer internen Geschäftsanwendung, deren Wiederherstellung innerhalb weniger Stunden akzeptabel ist, kann dies mit geeigneter Dokumentation und benannten Verantwortlichen die rationale Entscheidung sein. Der Schlüssel ist, dass der Prozess auch unter Druck durchführbar ist und nicht nur in einer alten technischen Beschreibung existiert.

Zwischen den beiden Modellen gibt es hybride Lösungen. Die Internetverbindung kann automatisch auf eine Ersatzleitung umschalten, während die Wiederherstellung eines weniger kritischen Geschäftssystems weiterhin eine Genehmigung und manuelle Auslösung erfordert. Dies passt oft besser zu den tatsächlichen Risiken als das Erzwingen eines automatischen Failovers überall.

Der Test ist der wichtigste Teil der Bewertung

Ein nicht getestetes Failover ist eher eine Annahme als eine Funktionsfähigkeit. Auch bei einem Backup zeigt sich erst, dass es nutzbar ist, wenn tatsächlich Daten daraus wiederhergestellt werden. Dasselbe gilt für die Failover-Pläne: Die sekundäre Umgebung kann starten, aber es kann sein, dass Benutzer sich nicht anmelden können, eine Partnerverbindung die neue IP-Adresse blockiert oder das System einen älteren Datenzustand anzeigt.

Der Test sollte einem Geschäftsszenario folgen. Es reicht nicht aus zu bestätigen, dass eine virtuelle Maschine gestartet wurde. Es muss überprüft werden, ob die Bestellung erstellt wird, in das nächste System übertragen wird, im Lager erscheint, der Beleg erstellt wird und das Reporting wiederhergestellt wird. Die beim Test auftretenden Abweichungen sind besonders wertvoll, da sie versteckte Abhängigkeiten aufzeigen, die in Systemdiagrammen oft nicht enthalten sind.

Der Test sollte einen Verantwortlichen, ein Protokoll und eine Liste von Korrekturmaßnahmen haben. Wenn ein kritischer Schritt nur im Kopf eines externen Experten existiert oder der Zugriff an einen einzigen Mitarbeiter gebunden ist, dann hat sich keine echte Geschäftskontinuitätentwickelt.

Was bedeutet es, wenn der Failover zu kompliziert ist?

Wenn zur Wiederherstellung eines Dienstes viele Tabellen, Telefonate und Improvisationen erforderlich sind, ist dies oft nicht nur ein Infrastrukturproblem. Es kann darauf hinweisen, dass der Prozess über zu viele Systeme läuft, die Integrationen nicht überwacht werden oder die Verantwortlichkeiten nicht klar sind. Die Bewertung des Failovers ist daher auch eine gute Gelegenheit für das Unternehmen, zu überprüfen, warum die Informationen auf diesem Weg fließen.

Eine gut durchdachte Lösung ist nicht unbedingt spektakulär. Oft zeigt sie sich darin, dass die Mitarbeiter im Falle eines Fehlers wissen, was passiert, was zu tun ist und welche Daten als zuverlässig gelten. Diese Kontrolle reduziert Panik, unnötige manuelle Arbeit und das gegenüber Kunden eingegangene Risiko.

Der nächste Ausfall ist kein guter Zeitpunkt, um herauszufinden, ob die Backup-Lösung tatsächlich funktioniert. Es ist ratsam, die kritischen Prozesse durchzugehen, wenn noch Zeit ist, um zu fragen: Was fällt aus, wer ist betroffen, was kann ersetzt werden und wofür gibt es keinen akzeptablen Umweg.