Wie können Netzwerktopologie und Anwendungstopologie helfen, die Geschäftsauswirkungen von Infrastrukturausfällen zu erkennen?

Netzwerktopologie und Anwendungstopologie machen Geschäftsauswirkungen sichtbar, weil sie zeigen, wie eine ausgefallene Infrastrukturkomponente mit Workloads, Anwendungen und Geschäftsdiensten verbunden ist. Administratoren müssen einen Alarm dann nicht als isoliertes Geräteereignis behandeln. Sie können der Abhängigkeitskette folgen und ermitteln, was betroffen ist, was das Problem wahrscheinlich verursacht und wem der betroffene Service gehört.

Das zugrunde liegende Data-Foundation-Modell beschreibt drei Analyserichtungen: nach oben, um den betroffenen Geschäftsbereich zu finden, nach unten, um die Hardware-Ursache zu lokalisieren, und horizontal, um Verantwortlichkeit und Prozesszuständigkeit zu klären. Die Topologie liefert die Beziehungsdaten, ohne die keine dieser drei Sichten möglich wäre.

Was ist Netzwerktopologie im Betrieb?

Netzwerktopologie ist die operative Landkarte der Netzwerkgeräte, Schnittstellen, Links und Verbindungen und ihrer Beziehungen zueinander. Dazu können Switches, Router, Netzwerkschnittstellen, physische und logische Links, Primär- und Backup-Pfade, dedizierte Leitungen, Storage-Netzwerke, Trainings-Fabrics und Management-Netzwerke gehören.

Die Topologie sollte beantworten, welche Wege der Traffic nehmen kann und welche Infrastrukturkomponenten vom Netzwerkpfad abhängen. Eine vor sechs Monaten erstellte Zeichnung ist nützliche Dokumentation, doch eine operative Topologie muss an das aktuelle Inventar und das Monitoring gekoppelt sein. Wird ein Switch ausgetauscht, ändert sich ein Link oder wechselt eine Leitung auf den Backup-Pfad, sollte die Topologie den neuen Zustand zeigen. Deshalb gehört sie in die Data Foundation und nicht nur in Architekturdiagramme.

Was ist Anwendungstopologie?

Anwendungstopologie bildet die technischen Komponenten ab, die gemeinsam eine Anwendung oder einen Service bereitstellen. Dazu können gehören:

• Business-Anwendung
• Anwendungs-Service
• API
• Modell-Service
• Container
• virtuelle Maschine
• Datenbank
• Middleware
• Storage
• Server
• Netzwerkabhängigkeit

Das zugrunde liegende Beziehungsmodell reicht von Business-Anwendungen bis hinunter zu Racks. Diese Tiefe braucht es, weil moderne Services über viele Schichten verteilt sein können. Der Nutzer sieht einen einzigen Service. Der Betrieb muss unter Umständen ein Gateway, eine Modellinstanz, einen Container, einen Cluster-Node, einen physischen Server, einen Beschleuniger, ein Rack, ein Netzwerk und Storage durchgehen, bevor er bei der physischen Ursache ankommt. Die Anwendungstopologie gibt diesem Pfad eine Struktur.

Wie macht Topologie aus einem Alarm eine Geschäftsauswirkung?

Mit der Topologie kann die Plattform fragen, was vom ausgefallenen Objekt abhängt. Angenommen, ein Switch fällt aus. Das Netzwerk-Monitoring weiß, welcher Switch down ist, und die Topologie, welche Server darüber angebunden sind. Die Compute-Ebene kennt die Workloads auf diesen Servern, die Anwendungstopologie die Services, die diese Workloads tragen, und die Geschäftsbeziehung die Projekte oder Abteilungen, denen diese Services gehören. Damit lässt sich der Vorfall in geschäftlichen Begriffen beschreiben.

Ohne Topologie bekommt der Administrator einen Gerätealarm und muss bei mehreren Teams nachfragen, was an dem Gerät hängt, und diese manuelle Suche verlängert die Reaktionszeit. Das zugrunde liegende Modell nutzt Beziehungsdaten ausdrücklich dafür, Ressourcenlisten und Alarme mit dem Gesundheitszustand von Geschäftssystemen zu verknüpfen.

Was bedeutet Aufwärts-Impact-Analyse?

Die Aufwärts-Impact-Analyse beginnt bei einem Fehler auf niedriger Ebene und folgt den Abhängigkeiten in Richtung Geschäftsservice. Eine solche Kette kann von der GPU-Karte über Server, Cluster-Node, Container, Inferenz-Instanz, Modell-Service und Business-Anwendung bis zum Projekt reichen.

Fällt die GPU aus, verfolgt die Plattform diese Kette nach oben. Sie kann feststellen, ob die Karte eine redundante Instanz trägt oder ob der Ausfall die Service-Kapazität direkt verringert. So wird nicht jeder Hardware-Alarm als gleich schwer behandelt.

Zwei identische Server können sehr unterschiedliche Geschäftsauswirkungen haben. Auf dem einen läuft vielleicht eine Entwicklungsaufgabe, der andere bedient womöglich einen produktiven Inferenz-Endpunkt. Auf Hardware-Ebene ist der Schweregrad ähnlich, geschäftlich unterscheidet er sich deutlich.

Was bedeutet Abwärts-Root-Cause-Analyse?

Die Abwärts-Analyse beginnt bei einem Service-Symptom und folgt den Abhängigkeiten zur Infrastruktur, die es verursachen könnte. Angenommen, eine Anwendung meldet langsame Antwortzeiten. Die Anwendungstopologie zeigt, dass sie von einem API-Gateway, einem Inferenz-Service, einer Modell-Instanz, einem GPU-Node, einem Storage-Service und einem Netzwerkpfad abhängt, und der Administrator kann jede dieser Abhängigkeiten prüfen.

Ist der Inferenz-Service gesund, die Storage-Latenz aber auffällig, verlagert sich die Untersuchung zum Storage. Fallen mehrere Services auf demselben physischen Server gemeinsam aus, rückt der Server als Kandidat nach vorn. Die zugrunde liegende Data Foundation beschreibt diese Abwärtsrichtung ausdrücklich als Lokalisierung der Hardware-Ursache.

Einen Beweis für die Ursache liefert die Topologie allein nicht. Sie grenzt den Suchraum ein und liefert Belege über Abhängigkeiten.

Was bedeutet horizontale Analyse?

Die horizontale Analyse klärt Verantwortlichkeit und operative Zuständigkeit. Sobald die Plattform weiß, welcher Service oder welche Ressource betroffen ist, kann sie diese mit Service-Owner, Anwendungsteam, Infrastrukturteam, Hersteller, Mandant, Projekt, Arbeitsauftrag und Bereitschaftsdienst verknüpfen. Das zugrunde liegende Modell nennt das die Bestimmung von Verantwortlichkeit und Prozesszuständigkeit.

Für den Betrieb ist das wichtig, denn auch eine gefundene Ursache ohne Verantwortlichen kostet Zeit. Die Topologie sollte deshalb technische Objekte mit Personen- und Workflow-Daten verbinden. Aus diesem Grund führt das zugrunde liegende Konfigurationsinventar Personen, Assets, Aktivitäten, Compute und Geschäftsobjekte in einem einzigen Modell.

Wie verbessert Netzwerktopologie die Impact-Analyse?

Netzwerktopologie zeigt gemeinsame Abhängigkeiten, die reines Anwendungs-Monitoring übersehen kann. Mehrere Anwendungen können gleichzeitig ausfallen, weil sie sich einen Switch, eine Leitung, einen Netzwerkpfad, eine Firewall, einen Inter-Data-Center-Link oder eine Trainings-Fabric-Domain teilen. Untersuchen die Anwendungsteams jeweils für sich, sehen sie möglicherweise getrennte Symptome, während die Netzwerktopologie die gemeinsame Abhängigkeit zeigt.

Bei Redundanz gilt dasselbe. Fällt die primäre Leitung aus und trägt eine gesunde Backup-Leitung den Traffic, bleibt die Geschäftsauswirkung womöglich begrenzt. Hängen beide Pfade aber an derselben vorgelagerten Abhängigkeit, ist das Risiko höher.

Für den Betrieb dedizierter Leitungen behandelt wie Organisationen dedizierte Leitungen und private Netzwerkverbindungen zwischen Rechenzentren verwalten können, wie Primär- und Backup-Pfade abgebildet werden sollten.

Wie kann Topologie automatisch entdeckt werden?

Ein Teil der Topologie lässt sich aus Infrastruktur-APIs, Neighbor-Protokollen, Cloud-APIs, Cluster-APIs, Service-Traffic, Traces und Konfigurationsdaten ermitteln. Netzwerkgeräte können Adjacency- und Schnittstellenbeziehungen melden, und Kubernetes gibt die Beziehungen zwischen Services, Pods und Nodes preis. Anwendungs-Traces können übergeordnete und untergeordnete Request-Pfade zeigen. OpenTelemetry definiert Traces als Graphen aus Spans mit Eltern-Kind-Beziehungen, die bei vorhandener Instrumentierung Belege für Aufrufabhängigkeiten zwischen Anwendungen liefern können. Service-Mapping-Systeme kombinieren Discovery- und Beziehungsdaten zu Landkarten der Anwendungs-Services.

Nicht jede Beziehung lässt sich automatisch entdecken. Geschäftliche Verantwortlichkeit und Service-Kritikalität brauchen unter Umständen explizite Metadaten, und für physische Carrier-Diversität sind eventuell Design- oder Carrier-Informationen nötig. Die Plattform sollte deshalb automatische Discovery ebenso unterstützen wie kontrolliert gepflegte manuelle Beziehungen mit vollständiger Nachvollziehbarkeit.

Wie sollten Topologie-Änderungen gehandhabt werden?

Behandeln Sie Topologie als dynamische Daten. Container wandern, virtuelle Maschinen migrieren, Netzwerkpfade ändern sich, und ein Server wird ausgetauscht. Eine neue Anwendungsversion bringt eine neue Abhängigkeit mit, oder eine dedizierte Leitung schaltet auf Backup. Die Plattform muss die Beziehungen aktualisieren, sobald so etwas passiert.

Die zugrunde liegende Data Foundation unterstützt automatische Discovery, manuelle Pflege und Point-in-Time-Snapshots, und das gilt auch für die Topologie. Bei der Nachbereitung eines Vorfalls brauchen Administratoren unter Umständen die Topologie zum Zeitpunkt des Vorfalls und nicht die von heute, und historische Beziehungs-Snapshots machen genau das möglich.

Warum ist die Genauigkeit der Topologie für AIOps wichtig?

AIOps entscheidet anhand der Topologie, welche Alarme eine gemeinsame Ursache haben könnten und welche Services betroffen sein könnten. Stimmen die Beziehungen nicht, stimmt auch die Analyse nicht. Das Ausgangsmaterial sagt das direkt: Alarm-Konsolidierung, fehlerbewusstes Scheduling und Kostenzuordnung hängen alle von denselben Beziehungsdaten ab und fallen auf isolierte Monitoring-Funktionen zurück, sobald die Daten ungültig werden.

Für AIOps kann die Topologie helfen zu klären, ob sich Alarme eine vorgelagerte Abhängigkeit teilen, ob das Infrastrukturereignis vor dem Anwendungssymptom auftrat, welche Services von einer Komponente abhängen und welcher Verantwortliche den Vorfall bekommen sollte.

Für den vollständigen Vorfallsablauf erklärt wie AIOps Alarmrauschen reduziert, Ursachen identifiziert und Geschäftsauswirkungen bestimmt, wie Topologie mit Zeitreihen- und Ereignisdaten kombiniert wird.

Wie sollte der Gesundheitszustand von Geschäftsservices berechnet werden?

Der Gesundheitszustand eines Geschäftsservices sollte den Zustand der technischen Komponenten zusammenfassen, die den Service tatsächlich tragen, und dabei den Drill-down erhalten. Das zugrunde liegende Business-Topologie-Modell umfasst einen Gesundheits-Score für Geschäftssysteme, eine vierschichtige Topologie sowie verknüpfte Ressourcen- und Alarmansichten.

Die Bewertungsformel sollte transparent sein, und ein komplexer Service sollte nicht auf einen einzigen undurchsichtigen Score schrumpfen. Eine nützliche Gesundheitsansicht kann die Verfügbarkeit kritischer Komponenten, aktuelle Alarme, den SLO-Status, Redundanz, betroffene Transaktionen und verminderte Kapazität berücksichtigen. Von dort aus sollte der Nutzer zu den zugrunde liegenden Ressourcen und Ereignissen durchklicken können. Der Score hilft bei der Navigation, handeln sollten Administratoren auf Basis der Belege.

Wie kann Topologie den Blast Radius vor einer Änderung zeigen?

Das Beziehungsmodell, mit dem sich Vorfallsauswirkungen bestimmen lassen, funktioniert auch vor geplanten Änderungen. Angenommen, ein Netzwerktechniker möchte einen Switch aktualisieren. Die Topologie kann die angebundenen Server zeigen, die Anwendungen auf diesen Servern, die Geschäftsservices, redundante Pfade, aktuelle Wartungsfenster und die Verantwortlichen. Damit lässt sich der Blast Radius vor der Ausführung abschätzen.

Eine CMDB oder Service-Map sollte deshalb sowohl die Auswirkungen von Vorfällen als auch die von Änderungen abbilden können. Je genauer die Beziehungskette, desto nützlicher die Einschätzung vor der Änderung.

Wie sollten Anwendungs- und Infrastruktur-Topologie verknüpft werden?

Verwenden Sie gemeinsame Objektidentitäten. Die Anwendungsebene sollte nicht von „server-prod-17" sprechen, während die Infrastrukturebene dieselbe Maschine ohne jede Zuordnung nur über die Seriennummer kennt. Die Beziehungskette braucht ein stabiles Identitätsmodell, zum Beispiel:

• Rack R12 enthält Server S17.
• Server S17 hostet den Kubernetes-Node N17.
• Node N17 führt Pod P202 aus.
• Pod P202 ist Teil des Inference Service IS4.
• IS4 unterstützt den Business Service BS1.

Sind diese Beziehungen explizit hinterlegt, kann die Plattform sie in beide Richtungen durchlaufen.

Für den Mapping-Prozess dahinter erklärt wie Organisationen Business-Anwendungen auf Server, Container, Datenbanken, Netzwerkgeräte und Storage abbilden können, wie sich der Graph aufbauen lässt.

Was sollte eine Topologie-Ansicht während eines Vorfalls zeigen?

Die erste Ansicht sollte das vermutete Problem und den betroffenen Bereich zeigen, ohne den Administrator zu überfordern. Nützlich sind:

• das primär ausgefallene Objekt
• vor- und nachgelagerte Beziehungen
• betroffene Anwendungen
• betroffene Geschäftsservices
• aktuelle Alarme
• redundante Pfade
• der Verantwortliche
• ein offener Arbeitsauftrag
• kürzliche Änderungen

Von dort aus sollte ein tieferer Drill-down möglich sein. Die zugrunde liegende Business-Topologie beschränkt sich bewusst auf eine vierschichtige Ansicht, damit die Landkarte benutzbar bleibt. Ein unbegrenzter Graph kann unlesbar werden, auch wenn das Datenmodell beliebige Tiefe erlaubt, deshalb sollte die Oberfläche zuerst den relevanten Pfad zeigen.

Was ist der praktische Unterschied zwischen Topologie und Monitoring?

Monitoring zeigt den Zustand einzelner Objekte, Topologie zeigt, wie diese Objekte zusammenhängen. Der Netzwerk-Monitor meldet, dass Switch 12 down ist, und der Anwendungs-Monitor, dass die Checkout-Latenz hoch ist. Ob beide Ereignisse zusammengehören, erklärt erst die Topologie. Monitoring allein kann deshalb kein vollständiges Bild der Geschäftsauswirkung liefern.

Ein Plattformbeispiel, das Beziehungsgraphen, Impact-Analyse und Business-Topologie kombiniert, ist Sensaka.

Wenn ich Topologie für den Betrieb bewerten sollte, würde ich einen echten Fehlerpfad testen. Beginnen Sie bei einem physischen Gerät und arbeiten Sie sich nach oben zum Geschäftsservice vor, dann gehen Sie von diesem Service wieder nach unten zum Gerät. Funktionieren beide Richtungen und sind der Verantwortliche und die aktiven Alarme sichtbar, ist die Topologie im Betrieb brauchbar.