Hochverfügbarkeit: Beispiel für Unternehmen

Ein ausgefallener Checkout, ein nicht erreichbares Kundenportal oder eine API-Störung zur falschen Uhrzeit kostet mehr als Umsatz. Vertrieb, Service und interne Prozesse geraten ins Stocken, während IT-Teams unter Zeitdruck Ursachen suchen. Ein Hochverfügbarkeits-Beispiel für Unternehmen zeigt deshalb nicht nur, wie mehrere Server verteilt werden. Es zeigt, wie Architektur, Betriebsprozesse und geschäftliche Prioritäten zusammenspielen.

Für mittelständische Unternehmen ist dabei eine Frage entscheidend: Welche Teile einer digitalen Plattform müssen tatsächlich jederzeit verfügbar sein - und wie viel Aufwand ist dafür wirtschaftlich sinnvoll? Hochverfügbarkeit ist kein pauschales Infrastrukturprodukt. Sie ist eine bewusst getroffene Betriebsentscheidung.

Was Hochverfügbarkeit im Unternehmensalltag bedeutet

Hochverfügbarkeit bedeutet, dass ein Dienst trotz einzelner technischer Störungen weiter genutzt werden kann. Fällt eine virtuelle Maschine, eine Datenbankinstanz oder eine Netzwerkverbindung aus, übernimmt eine vorbereitete Komponente. Nutzer bemerken den Fehler idealerweise nicht oder nur durch eine kurze Verzögerung.

Entscheidend ist die Abgrenzung zu Backup und Disaster Recovery. Ein Backup schützt Daten vor Verlust und ermöglicht die Wiederherstellung nach einem Schaden. Es verhindert aber nicht, dass ein Portal während der Wiederherstellung stundenlang ausfällt. Disaster Recovery sichert den Betrieb nach schwerwiegenden Ereignissen wie einem kompletten Standortausfall. Hochverfügbarkeit reduziert dagegen den Ausfall einzelner Komponenten im laufenden Betrieb.

Wie hoch die Anforderungen sein müssen, ergibt sich aus zwei Kennzahlen. Das Recovery Time Objective, kurz RTO, beschreibt die maximal akzeptable Dauer eines Ausfalls. Das Recovery Point Objective, RPO, legt fest, wie viele Daten im schlimmsten Fall verloren gehen dürfen. Für eine Produktwebsite können einige Stunden vertretbar sein. Bei einer Bestellplattform, einer B2B-Schnittstelle oder einer Produktionssteuerung sind wenige Minuten oder gar kein Datenverlust oft die realistische Vorgabe.

Hochverfügbarkeits-Beispiel für Unternehmen: B2B-Bestellplattform

Ein Maschinenbauunternehmen betreibt eine digitale Ersatzteilplattform. Kunden bestellen darüber rund um die Uhr Komponenten, rufen technische Dokumente ab und prüfen Liefertermine. Die Plattform ist an ERP, Lagerverwaltung, Zahlungsdienstleister und ein Kundenverwaltungssystem angebunden. Fällt sie aus, entstehen nicht nur entgangene Bestellungen. Vertriebsmitarbeitende wechseln auf manuelle Prozesse, Kunden weichen möglicherweise auf andere Anbieter aus und Serviceanfragen steigen.

Das Unternehmen definiert für den Bestellprozess ein RTO von 15 Minuten und ein RPO nahe null. Produktkatalog und Dokumentenbereich dürfen im Notfall etwas später aktualisiert sein. Diese Differenzierung ist zentral: Nicht jede Funktion braucht dieselbe Verfügbarkeitsklasse.

Die Architektur verteilt gezielt kritische Komponenten

Die Web-Anwendung läuft containerisiert in einem Kubernetes-Cluster über mindestens zwei getrennte Verfügbarkeitszonen. Ein Load Balancer verteilt Anfragen auf mehrere Instanzen. Fällt ein Knoten aus, entfernt die Plattform ihn aus dem Datenverkehr und startet die Anwendung auf einem verfügbaren Knoten neu. Health Checks prüfen nicht nur, ob ein Prozess läuft, sondern ob die Anwendung tatsächlich Datenbank und benötigte Dienste erreichen kann.

Für statische Inhalte wie Bilder, Datenblätter und JavaScript-Dateien übernimmt ein CDN die Auslieferung. Das entlastet die Anwendung und reduziert die Abhängigkeit vom Kernsystem. Ein Cache beschleunigt häufige Lesezugriffe auf Katalogdaten. Wichtig ist dabei eine klare Cache-Strategie: Veraltete Preise oder Lagerbestände sind im Checkout nicht akzeptabel, bei einem technischen PDF dagegen meist unkritisch.

Die Datenbank ist als verwalteter Dienst mit synchroner Replikation innerhalb einer Region ausgelegt. Beim Ausfall der primären Instanz erfolgt ein automatisches Failover auf ein Replikat. Zusätzlich werden verschlüsselte Sicherungen in einer getrennten Umgebung abgelegt. Die Replikation schützt vor Infrastrukturfehlern, das Backup vor fehlerhaften Datenänderungen, Softwarefehlern oder versehentlichem Löschen.

Externe Abhängigkeiten werden nicht ignoriert. Ist der Zahlungsdienstleister kurzfristig nicht erreichbar, darf das System keine Bestellung verlieren. Stattdessen wird der Auftrag nach einer klaren fachlichen Regel als offen gespeichert und die Zahlungsabwicklung später erneut angestoßen. Bei der ERP-Anbindung puffert eine Warteschlange Ereignisse, bis das Zielsystem wieder verfügbar ist. So wird aus einer externen Störung nicht automatisch ein Totalausfall der eigenen Plattform.

Betrieb entscheidet, ob die Architektur wirkt

Mehrere Instanzen allein schaffen noch keine hohe Verfügbarkeit. Wenn ein fehlerhaftes Release gleichzeitig auf alle Instanzen gelangt, fällt die Plattform trotz Redundanz aus. Deshalb werden Änderungen automatisiert und schrittweise ausgerollt. Bei einem Canary Deployment erhält zunächst nur ein kleiner Teil des Traffics die neue Version. Verschlechtern sich Fehlerrate, Antwortzeit oder Conversion, wird die Version zurückgenommen.

Observability macht Fehler früh sichtbar. Metriken überwachen etwa Verfügbarkeit, Latenz, Auslastung und Fehlerquoten. Zentrales Logging ermöglicht die Ursachenanalyse über Anwendung, Infrastruktur und Schnittstellen hinweg. Tracing zeigt bei komplexen Transaktionen, an welcher Station eine Bestellung Zeit verliert. Entscheidend sind alarmfähige Schwellenwerte und klare Zuständigkeiten. Ein Alarm ohne Bereitschaftsprozess löst kein Betriebsproblem.

Warum Multi-Cloud nicht automatisch die bessere Antwort ist

Bei hohen Verfügbarkeitsanforderungen wird oft sofort über zwei Cloud-Anbieter gesprochen. Das kann sinnvoll sein, etwa bei regulatorischen Vorgaben oder wenn ein kompletter Ausfall eines Providers wirtschaftlich nicht tragbar ist. Für viele mittelständische Plattformen erhöht Multi-Cloud jedoch zunächst Komplexität, Kosten und Betriebsaufwand.

Datenbanken über mehrere Anbieter konsistent zu halten, ist technisch und fachlich anspruchsvoll. Deployment-Pipelines, Sicherheitskonzepte, Monitoring und Incident-Prozesse müssen doppelt gedacht werden. Häufig erreicht eine sauber konfigurierte Architektur über mehrere Verfügbarkeitszonen innerhalb eines Cloud-Anbieters den besseren Kosten-Nutzen-Effekt. Erst wenn Anforderungen, Schadenspotenzial und Betriebsreife es rechtfertigen, ist eine zweite Region oder ein zweiter Anbieter sinnvoll.

Das gleiche Prinzip gilt für aktive und passive Redundanz. Aktiv-aktiv verteilt produktiven Verkehr gleichzeitig auf mehrere Standorte und verkürzt Umschaltzeiten. Es verlangt aber sorgfältiges Daten- und Konfliktmanagement. Aktiv-passiv hält eine Reserveumgebung bereit, die erst im Störungsfall übernimmt. Diese Variante ist oft einfacher zu betreiben, kann jedoch längere Wiederanlaufzeiten verursachen.

So wird Hochverfügbarkeit planbar umgesetzt

Der Startpunkt ist keine Produktentscheidung, sondern eine Business-Impact-Analyse. Fachbereiche und IT bewerten gemeinsam, welche Prozesse bei Ausfall welchen Schaden verursachen. Daraus entstehen abgestufte Ziele für Verfügbarkeit, RTO und RPO. Diese Ziele müssen messbar sein. Eine allgemeine Vorgabe wie „nahezu immer verfügbar“ hilft weder der Architektur noch dem Betrieb.

Danach werden Abhängigkeiten sichtbar gemacht: Welche Datenbanken, APIs, Identitätsdienste, DNS-Einträge, Zertifikate und Drittanbieter braucht ein kritischer Ablauf? Gerade versteckte Einzelpunkte des Ausfalls werden oft übersehen. Eine redundant betriebene Anwendung hilft nicht, wenn nur ein einzelner DNS-Provider, ein ablaufendes Zertifikat oder eine nicht überwachte ERP-Schnittstelle den Zugriff blockiert.

Infrastructure as Code sorgt anschließend dafür, dass Umgebungen reproduzierbar aufgebaut und geprüft werden können. Konfigurationen gehören versioniert, überprüft und automatisiert ausgerollt. Manuelle Änderungen unter Zeitdruck sind eine häufige Quelle für Abweichungen zwischen Test- und Produktionsumgebung.

Schließlich braucht es regelmäßige Nachweise. Failover, Wiederherstellung aus Backups und der Ausfall externer Schnittstellen werden geplant getestet. Ein jährlicher Notfalltest ist besser als keiner, für geschäftskritische Plattformen aber häufig zu selten. Sinnvoll sind kontrollierte Übungen nach wesentlichen Architekturänderungen und wiederkehrende Tests der wichtigsten Störungsszenarien.

Verfügbarkeit braucht ein wirtschaftliches Betriebsmodell

99,9 Prozent Verfügbarkeit erlauben rechnerisch rund 8 Stunden und 46 Minuten Ausfall pro Jahr. Bei 99,99 Prozent sind es nur noch etwa 53 Minuten. Der Unterschied von einer zusätzlichen Neun bedeutet nicht nur bessere Technik. Er bedeutet mehr Redundanz, engere Überwachung, strengere Change-Prozesse, regelmäßige Übungen und oft auch höhere Bereitschaftskosten.

Deshalb sollte Verfügbarkeit dort investiert werden, wo sie Geschäftsvorgänge schützt. Ein Kundenlogin, Checkout oder Partner-API kann eine höhere Klasse benötigen als ein internes Reporting-System. Auch innerhalb einer Plattform lohnt sich die Trennung: Bestellannahme und Zahlungsstatus können weiterlaufen, während ein weniger kritisches Empfehlungsmodul vorübergehend abgeschaltet wird.

Eine belastbare Lösung entsteht, wenn Teams diese Prioritäten vor dem Incident festlegen und technisch umsetzen. Dann wird Hochverfügbarkeit nicht zum kostspieligen Versprechen, sondern zu einem nachvollziehbaren Beitrag für Umsatz, Kundenvertrauen und handlungsfähige Teams.