Resilienz statt Verfügbarkeit: Was Führungskräfte über moderne Netzwerke wissen müssen

Verfügbarkeit misst die falsche Störung

Verfügbarkeitskennzahlen wie 99,9 Prozent oder MTBF-Werte beantworten eine bestimmte Frage: Wie wahrscheinlich ist es, dass eine einzelne Komponente in einem definierten Zeitraum funktioniert? Die dahinterliegende Annahme ist der zufällige, voneinander unabhängige Ausfall: ein defektes Netzteil, eine gestörte Leitung, ein abgestürztes Gerät. Gegen genau diese Fehlerklasse hilft Redundanz: Fällt eine Komponente aus, übernimmt die zweite.

Die Ausfälle, die Unternehmen heute tatsächlich stilllegen, folgen dieser Annahme nicht. Ein Ransomware-Vorfall, ein fehlerhaftes Firmware-Update, eine defekte Konfigurationsänderung, die zentral ausgerollt wird, oder der Ausfall eines zentralen Dienstes wie Verzeichnisdienst, DNS oder DHCP treffen beide redundanten Pfade gleichzeitig weil beide Pfade dieselbe Software, dieselbe Konfiguration und dieselben Abhängigkeiten teilen. Zwei Core-Switches im Cluster sind gegen einen Hardwaredefekt doppelt abgesichert, gegen einen Konfigurationsfehler oder eine kompromittierte Management-Ebene aber exakt einfach: Der Fehler repliziert sich mit.

In der Praxis heißt das: Ein Netz kann auf dem Papier hochverfügbar sein und trotzdem in einem einzigen Ereignis vollständig ausfallen. Verfügbarkeit beschreibt die Abwesenheit kleiner Störungen. Sie sagt nichts darüber aus, wie das Unternehmen ein großes Ereignis übersteht.

Was Resilienz im Netz konkret bedeutet

Resilienz ist kein weicher Begriff und keine Umbenennung von Hochverfügbarkeit. Aus Sicht der Netzarchitektur besteht sie aus drei überprüfbaren Eigenschaften: begrenzte Ausfalldomänen, definierter Notbetrieb und geplanter Wiederanlauf.

Ausfalldomänen begrenzen

Die zentrale Frage lautet nicht „Wie verhindern wir den Ausfall?", sondern „Wie weit darf sich ein Ausfall ausbreiten?". Ein flaches, durchgängig geroutetes Netz hat genau eine Ausfalldomäne: das gesamte Unternehmen. Segmentierung nach Standorten, Funktionsbereichen und in der Produktion nach Zonen und Zellen zieht Grenzen ein, an denen eine Störung stoppt. Das betrifft nicht nur Firewalls zwischen Office und Fertigung, sondern auch weniger sichtbare Ebenen. Getrennte Broadcast-Domänen, eigenständige Layer-2-Bereiche pro Zelle, kontrollierte Routing-Übergänge und eine Management-Ebene, die nicht am selben Faden hängt wie das Produktivnetz.

Für die Führungsebene ist die relevante Kennzahl der sogenannte Blast Radius: Welcher Anteil des Betriebs steht still, wenn ein beliebiges einzelnes Segment kompromittiert oder abgeschaltet wird? In einem resilienten Netz ist die Antwort „ein Segment". In vielen gewachsenen Netzen ist die ehrliche Antwort „alles".

Weiterlaufen im degradierten Zustand

Die zweite Eigenschaft ist die Fähigkeit einzelner Bereiche, ohne zentrale Dienste weiterzuarbeiten. Gerade in der Produktion ist das entscheidend: Eine Fertigungszelle, die für jeden Arbeitsschritt eine Verbindung zum zentralen Rechenzentrum oder in die Cloud benötigt, fällt mit jeder Störung dieser Verbindung, unabhängig davon, wie redundant die Zelle selbst gebaut ist, mit aus. Resiliente Architekturen halten die Dienste, die für den unmittelbaren Betrieb nötig sind: Zeitserver, Namensauflösung, lokale Steuerungs- und Visualisierungssysteme, gegebenenfalls lokale Authentifizierung, in der jeweiligen Zone vor. Das Ziel ist ein definierter Notbetrieb: Was muss lokal funktionieren, damit die Anlage produziert, auch wenn das Firmennetz dunkel ist? Diese Frage lässt sich nicht nachträglich im Krisenstab beantworten. Sie ist eine Architekturentscheidung.

Wiederanlauf als Designziel

Die dritte Eigenschaft wird am häufigsten übersehen: die Fähigkeit, das Netz aus einem schlechten Zustand heraus kontrolliert wieder aufzubauen. Dazu gehören eine Out-of-Band-Management-Ebene, über die Netzkomponenten auch dann erreichbar sind, wenn das Produktivnetz nicht mehr vertrauenswürdig ist. Ebenso offline gesicherte, versionierte Konfigurationen aller Netzkomponenten, ein dokumentierter „Known-Good"-Zustand und eine festgelegte Wiederanlaufreihenfolge, die Abhängigkeiten berücksichtigt. Erst Netz-Kerndienste, dann Infrastrukturdienste, dann Applikationen, dann Produktion. Wer nach einem Vorfall erst herausfinden muss, welche VLANs, Routen und Firewall-Regeln der letzte funktionierende Stand waren, verliert Tage statt Stunden. Die Wiederanlaufzeit ist in der Praxis fast nie durch Hardware begrenzt, sondern durch fehlende Dokumentation, fehlende Übung und ungeklärte Reihenfolgen.

Der Gesetzgeber hat die Perspektive bereits gewechselt

Dass Resilienz mehr ist als Verfügbarkeit, ist inzwischen auch regulatorisch festgeschrieben. Seit dem 6. Dezember 2025 gilt in Deutschland das NIS2-Umsetzungsgesetz ohne Übergangsfrist. Es verpflichtet betroffene Einrichtungen unter anderem zu Risikomanagement, Backup- und Krisenmanagement, Lieferkettensicherheit und einem gestuften Meldeverfahren bei erheblichen Sicherheitsvorfällen. Die Registrierungsfrist beim BSI ist bereits im März 2026 abgelaufen. Seit dem 17. März 2026 ergänzt das KRITIS-Dachgesetz diese Pflichten für Betreiber kritischer Anlagen ausdrücklich um die physische Resilienz. Sprich: die Widerstandsfähigkeit gegen Sabotage, Naturereignisse und Infrastrukturausfälle.

Bemerkenswert ist die Stoßrichtung beider Gesetze: Verlangt wird nicht der Nachweis, dass nichts ausfällt, sondern der Nachweis, dass der Betrieb Vorfälle bewältigen kann. Dies geschieht unter Zuhilfenahme von Erkennung, Reaktion, Meldung, Wiederherstellung. Das ist exakt der Unterschied zwischen Verfügbarkeits- und Resilienzdenken. Hinzu kommt die persönliche Dimension: Die Geschäftsleitung ist gesetzlich verpflichtet, die Risikomanagementmaßnahmen zu billigen und ihre Umsetzung zu überwachen. Die Frage, ob das eigene Netz einen Großvorfall übersteht, ist damit keine rein technische mehr, sondern eine Governance-Frage mit Haftungsrelevanz.

Fünf Fragen, an denen sich der Reifegrad zeigt

Führungskräfte müssen keine Netzpläne lesen können, um den Zustand ihrer Infrastruktur zu beurteilen. Fünf Fragen an die eigene IT- und OT-Organisation genügen – entscheidend ist, ob die Antworten konkret und belegt sind:

• Was genau steht still, wenn unser zentrales Rechenzentrum, der Verzeichnisdienst oder die Internetanbindung ausfällt und was läuft nachweislich weiter?
• Wie viele voneinander getrennte Ausfalldomänen hat unser Netz, und wo verläuft die Grenze zwischen Büro-IT und Produktion?
• Können unsere Standorte und Produktionsbereiche für einen definierten Zeitraum autark arbeiten, und wurde das jemals real getestet?
• Wie lange dauert der vollständige Wiederanlauf des Netzes aus gesicherten Konfigurationen, und wann wurde er zuletzt geübt?
• Erreichen wir unsere Netzkomponenten auch dann noch, wenn das Produktivnetz kompromittiert ist?

Antworten wie „das ist redundant ausgelegt" oder „dafür haben wir ein Konzept" sind Warnsignale. Belastbar sind nur Antworten mit Zahlen, Testdaten und dokumentierten Übungen. Ein Wiederanlauf, der nie geprobt wurde, existiert im Ernstfall nicht.

Konsequenzen für Investitionsentscheidungen

Der Wechsel von Verfügbarkeits- zu Resilienzdenken verändert, wohin Budget fließt. Verfügbarkeit wird typischerweise über Hardware gekauft: zweites Gerät, zweite Leitung, zweites Netzteil. Das ist sichtbar, leicht zu beschaffen und in vielen Fällen weiterhin sinnvoll. Dennoch adressiert es nur die kleinste Fehlerklasse. Resilienz entsteht dagegen überwiegend aus Architektur und Betrieb: aus Segmentierung, aus lokal vorgehaltenen Kerndiensten, aus einer sauberen Management-Ebene, aus gepflegter Konfigurationssicherung und aus regelmäßig geübtem Wiederanlauf. Diese Posten sind unscheinbarer als ein redundantes Core-Paar, bestimmen im Ernstfall aber allein darüber, ob der Stillstand Stunden oder Wochen dauert.

Sinnvolle Steuerungsgrößen auf Führungsebene sind entsprechend nicht Verfügbarkeitsprozente, sondern: der maximale Blast Radius eines Einzelereignisses, die nachgewiesene Autarkiezeit kritischer Bereiche und die zuletzt gemessene und nicht geschätzte Wiederanlaufzeit je Geschäftsprozess. Wer diese drei Werte kennt und regelmäßig überprüfen lässt, hat die Resilienz seines Netzes im Griff. Wer nur eine Verfügbarkeitszahl im Reporting hat, kennt lediglich die Wahrscheinlichkeit kleiner Störungen und weiß über den Fall, der das Unternehmen wirklich trifft, nichts.