Bewertung von Failover-Lösungen für Unternehmen

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

In einem Unternehmen mit 20 bis 500 Mitarbeitern ist ein Ausfall in der ersten Minute selten auffällig. Zuerst kann jemand kein Etikett drucken. Eine Bestellung aus dem Webshop wird nicht in das Verwaltungssystem übertragen. Die für den Produktionsplan benötigten Daten befinden sich nur in einem freigegebenen Ordner, der gerade nicht zugänglich ist. Nach einigen Stunden ersetzen Telefone, E-Mails und manuell geführte Listen die Systeme. Dies führt nicht nur zu Umsatzeinbußen: Es verursacht Fehler, Verzögerungen, Überstunden und unsichere 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 Backup-Netzwerkgerät, eine Datenbank-Replikation 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 Schutzgrad. Ein mehrstündiger Ausfall eines internen Archivs kann handhabbar sein. Der Ausfall der Auftragsabwicklung, der Lagerbestandsinformationen, der Produktionssteuerung oder der Rechnungsstellung 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 eine Lieferanforderung 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 ist ratsam, mit einigen konkreten Geschäftsszenarien zu arbeiten, anstatt 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? Können die Vertriebsmitarbeiter auf Kundendaten zugreifen? 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 in eine Warteschlange gestellt, gehen sie 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 getrennt betrachtet werden:

• Umsatz und Kundenservice: Werden Bestellungen, Lieferungen oder Rechnungen versäumt;
• Betrieb: Kommt es zu einem Stillstand im Lager, in der Produktion, im Einkauf oder im Kundenservice;
• Daten und Compliance: Können Daten beschädigt werden, Transaktionen verloren gehen oder Aufzeichnungspflichten verletzt werden;
• Menschliche Belastung: Wer behebt den Fehler, wer kann einen Umgehungsprozess 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 tauchen häufig zwei Abkürzungen auf. Die RTO, die Wiederherstellungszeitvorgabe, gibt an, wie lange es dauern soll, bis ein Dienst wieder nutzbar ist. Die RPO, die Wiederherstellungspunktvorgabe, gibt an, wie viel Datenverlust akzeptabel ist.

Zahlen allein sind wenig wert. Dass die RTO eines Systems vier Stunden beträgt, 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 einen Stillstand der Lagerlieferungen bedeutet, könnte das Ziel zu locker sein. Wenn es sich um eine selten genutzte Berichtsplattform handelt, könnte es sogar gerechtfertigt sein.

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

Zu strenge Ziele haben ihren Preis. Sofortige Umschaltung, die Aufrechterhaltung von Kapazitäten an mehreren Standorten und die kontinuierliche Datensynchronisation erfordern erhebliche Investitionen und betriebliche Disziplin. Es ist nicht das Ziel, jedes System für eine Bankverfügbarkeit zu entwerfen. Das Ziel ist, dass der Schutz im Verhältnis zu den tatsächlichen geschäftlichen Folgen eines Ausfalls steht.

Ein Backup-Server allein reicht nicht aus, wenn die Abhängigkeiten an einem Ort bleiben

Viele Organisationen haben ein Backup, vielleicht auch einen sekundären Server, und dennoch bleibt ein einziger Fehlerpunkt im Betrieb. Die sekundäre Umgebung startet vergeblich, wenn sie dieselbe Internetverbindung nutzt, auf denselben Authentifizierungsdienst angewiesen ist oder derselbe Integrationsdienst die Systeme verbindet.

Die Untersuchung muss daher die gesamte Kette umfassen: Netzwerk, Stromversorgung, DNS, Identitätsmanagement, Datenbank, Anwendungen, externe Dienstleister und Integrationen. Ein Webshop kann beispielsweise erreichbar sein, während der Zahlungsdienstleister, die Bestandsinformationen oder die Speditionsverbindung 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 ein Partnersystem hochlädt, kann die Abwesenheit dieser Person und ein Fehler bei der Dateifreigabe zu einem Stillstand führen. Hier ist das Failover teilweise eine technische Frage, teilweise eine Frage der Prozessneugestaltung. Die richtige Antwort könnte nicht in einer teuren hochverfügbaren Umgebung liegen, sondern in der Abschaffung der manuellen Übergabe und der Überprüfbarkeit der Integration .

Automatische oder manuelle Umschaltung?

Automatisches Failover ist schneller, aber komplexer. Es 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 es bei einem von Kunden direkt genutzten Online-Dienst oder einer kontinuierlichen Produktionsdatenverbindung gerechtfertigt sein.

Manuelles Umschalten 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 entsprechender Dokumentation und benannten Verantwortlichen die rationale Entscheidung sein. Der Schlüssel ist, dass der Prozess auch unter Druck tatsächlich durchführbar ist und nicht nur in einer alten technischen Beschreibung existiert.

Zwischen den beiden Modellen gibt es auch hybride Lösungen. Die Internetverbindung kann automatisch auf eine Backup-Leitung umschalten, während die Wiederherstellung eines weniger kritischen Geschäftssystems weiterhin eine Genehmigung und manuelle Initiierung 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 Umschaltpläne: Die sekundäre Umgebung kann starten, aber es kann sein, dass die Benutzer sich nicht anmelden können, eine Partnerverbindung die neue IP-Adresse blockiert oder das System einen älteren Datenstand 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 die Berichterstattung wiederhergestellt wird. Die beim Test entstehenden 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 die Umschaltung 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 hindeuten, dass der Prozess durch zu viele Systeme läuft, die Integrationen nicht überwacht werden oder die Verantwortlichkeiten unklar sind. Die Bewertung des Failovers ist daher auch eine gute Gelegenheit für das Unternehmen, erneut zu prü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 Arbeiten und das gegenüber den 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, solange noch Zeit ist, um zu fragen: Was fällt aus, wer ist betroffen, was kann ersetzt werden und wofür gibt es keine akzeptable Umgehungslösung.