# Die unbekannten Single Points of Failure · CentOps > Ein Business-Service ist auf dem Papier redundant. In der Realität kann er jedoch von einem einzigen Switch, Storage-Array oder Hypervisor abhängig sein. URL: https://centops.app/de/blog/single-points-of-failure/ Language: de Last updated: 2026-10-30 [← Zurück zum Blog](https://centops.app/de/blog/) Resilienz18\. Juni 2026Aktualisiert 30\. Oktober 20263 Min. LesezeitEywo-Team # Die unbekannten Single Points of Failure Ein Business-Service ist auf dem Papier redundant. In der Realität kann er jedoch von einem einzigen Switch, Storage-Array oder Hypervisor abhängig sein. Hier erfahren Sie, wie Sie diese Schwachstellen finden, bevor sie zum Problem werden. Der Service verfügt über zwei Anwendungserver und eine Cluster-Datenbank, und im Architekturdiagramm sieht es sicher aus. Eines Tages fällt ein einzelnes Netzwerkgerät aus und der gesamte Service ist dunkel. Die Post-Incident-Überprüfung zeigt, dass beide Anwendungserver auf demselben Hypervisor liefen oder dass beide Datenbankinstanzen an demselben Speicherarray angeschlossen waren. Die Redundanz existierte nur in einer Schicht. Solche Entdeckungen sind für alle unangenehm. Der Service Owner glaubte, geschützt zu sein. Das Betriebsteam könnte die Schwachstelle vermutet haben, aber es hatte keine Möglichkeit, sie zu beweisen. Und die Menschen, die den Incident in der Nacht bekämpften, fragen sich, warum niemand es kommen sah. ## Warum einzelne Fehlerpunkte verborgen bleiben Ein einzelner Fehlerpunkt (SPOF) ist selten ein Designfehler. Er ist normalerweise das Ergebnis einer allmählichen Abweichung. Die Infrastruktur ändert sich, virtuelle Maschinen bewegen sich, Kapazitäten werden neu zugewiesen. Was bei der Inbetriebnahme getrennt war, kann Monate später auf demselben Hardware enden. - **Redundanz wird Schicht für Schicht bewertet.** Das Anwendungsteam sieht zwei Server, das Virtualisierungsteam sieht freie Kapazität, und niemand sieht die gesamte Kette. - **Diagramme erfassen die Absicht, nicht die Realität.** Sie zeigen, wie die Dinge gemeint waren, nicht wo Systeme seitdem bewegt wurden. - **Resilienzprüfungen sind einmalige Übungen.** Sie finden zum Zeitpunkt des Designs oder während eines Audits statt, nicht kontinuierlich. - **Wartung setzt Schwachstellen zu spät frei.** Wenn beide Knoten eines redundanten Paares gleichzeitig gepatcht werden, geht der Service down, obwohl er formal redundant ist. ## Eine bessere Art, über Resilienz nachzudenken Die Service-Resilienz ist eine Eigenschaft der gesamten Abhängigkeitskette, nicht einzelner Komponenten. Sie muss daher auf Service-Ebene bewertet werden, über alle Schichten hinweg auf einmal. Wir empfehlen: 1. **Redundanz explizit aufzeichnen.** Welche Elemente stehen füreinander ein und bilden eine redundante Gruppe. 2. **SPOFs kontinuierlich suchen, nicht einmal im Jahr.** Jede Infrastrukturänderung kann die Antwort ändern. 3. **Resilienz mit Simulation testen.** Fragen Sie, was passiert, wenn eine bestimmte Komponente ausfällt. 4. **Redundanz in die Wartung einbeziehen.** Patchen Sie redundante Knoten nacheinander, damit der Service oben bleibt. ## Wie CentOps damit umgeht CentOps arbeitet mit einer mehrschichtigen Abhängigkeitskarte, von Business Services über Anwendungen, Datenbanken und Server bis hin zu Hypervisoren, Speicher und Netzwerk. Auf dieser Grundlage kann es: - **redundante Gruppen aufzeichnen**, d.h. Elemente, die füreinander einstehen, - **einzelne Fehlerpunkte identifizieren**, die Komponenten, deren Ausfall einen Service unabhängig von der Redundanz an anderer Stelle in der Kette trifft, - **Service-Resilienz bewerten** und zeigen, wo ein Service geschützt ist und wo nicht, - **den Ausfall einer ausgewählten Komponente simulieren** und die betroffenen Services und Anwendungen anzeigen. Der Service Owner muss sich nicht mehr auf ein Diagramm verlassen. Er sieht den aktuellen Zustand, abgeleitet aus der CMDB, und weiß, worauf sein Service tatsächlich angewiesen ist. ## Fazit Einzelne Fehlerpunkte erscheinen nicht über Nacht, und eine einmalige Überprüfung wird sie nicht verschwinden lassen. Sie können nur gefunden werden, indem man einen Service als Ganzes betrachtet, über jede Schicht hinweg, mit einer aktuellen Ansicht. Unangenehme nächtliche Entdeckungen werden dann zu gewöhnlichen Posten auf dem Arbeitsplan, die ruhig und während der Geschäftszeiten behoben werden. So sieht es in der Anwendung aus **Kostenlose Beta für 6 Monate** Die Beta steht höchstens 10 Unternehmen offen. Sie erhalten die vollständige Anwendung und ein Team, das die Einführung mit Ihnen durchgeht. [An der Beta teilnehmen →](https://centops.app/de/beta/) ## Weitere Artikel [Betrieb·29\. Oktober 2026 ### Ein Switch fällt aus – der Service steht noch nicht Eine Auswirkungsanalyse, die Redundanz nicht kennt, meldet Hunderte „beeinträchtigte“ Elemente und weckt Menschen wegen Alerts, die nur eine Ursache wiederholen. CentOps berechnet Auswirkung und Ereigniskorrelation jetzt danach, was tatsächlich passieren würde. 5 Min. Lesezeit](https://centops.app/de/blog/redundancy-aware-impact/)[CMDB·25\. Oktober 2026 ### Das virtuelle Netzwerk in der CMDB: von der Portgruppe bis zum Leaf-Switch Zwischen einer virtuellen Maschine und dem physischen Netzwerk liegt eine Schicht, die die meisten CMDBs nicht sehen – virtuelle Switches, Port Groups und Host-Uplinks. Doch genau hier wird entschieden, welche Business-Services eine Netzwerk-Änderung berührt. 3 Min. Lesezeit](https://centops.app/de/blog/virtual-network-in-the-cmdb/)[Governance·25\. Oktober 2026 ### NIS2 und DORA: Was der IT-Betrieb nachweisen können muss Beide Vorschriften stellen dieselbe Frage: Wissen Sie, welche Services ein Ausfall trifft, wer dafür verantwortlich ist und was sich wann geändert hat? Ohne eine zuverlässige Abhängigkeitskarte müssen die Antworten oft unter Zeitdruck manuell zusammengestellt werden. 2 Min. Lesezeit](https://centops.app/de/blog/nis2-dora-evidence/)