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

Netzwerktopologie und Anwendungstopologie helfen dabei, Geschäftsauswirkungen zu erkennen, indem sie zeigen, wie eine ausgefallene Infrastrukturkomponente mit Workloads, Anwendungen und Geschäftsdiensten verbunden ist. Statt einen Alarm als isoliertes Geräteereignis zu behandeln, können Administratoren 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 identifizieren, nach unten, um die Hardware-Ursache zu lokalisieren, und horizontal, um Verantwortlichkeit und Prozesszuständigkeit zu identifizieren. Topologie ist die Beziehungsdaten, die diese drei Sichten erst möglich machen.

Was ist Netzwerktopologie im Betrieb?

Netzwerktopologie ist die operative Landkarte von Netzwerkgeräten, Schnittstellen, Links, Verbindungen und ihren Beziehungen.

Dazu kann gehören:

Switches
Router
Netzwerkschnittstellen
Physische und logische Links
Primär- und Backup-Pfade
Dedizierte Leitungen
Storage-Netzwerke
Trainings-Fabrics
Management-Netzwerke

Die Topologie sollte beantworten, wie sich Traffic bewegen kann und welche Infrastrukturkomponenten vom Netzwerkpfad abhängen.

Eine vor sechs Monaten erstellte Zeichnung ist nützliche Dokumentation.

Eine operative Topologie sollte an aktuelles Inventar und Monitoring gekoppelt sein.

Wenn ein Switch ausgetauscht wird, sich ein Link ändert oder eine Leitung auf einen Backup-Pfad wechselt, sollte die Topologie den neuen Zustand widerspiegeln.

Deshalb gehört Topologie 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 kann gehören:

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

Das zugrunde liegende Beziehungsmodell verbindet Business-Anwendungen bis hinunter zu Racks.

Diese Tiefe ist wichtig, weil moderne Services mehrere Schichten umspannen können.

Ein Nutzer sieht einen Service.

Der Betrieb muss möglicherweise ein Gateway, eine Modellinstanz, einen Container, einen Cluster-Node, einen physischen Server, einen Beschleuniger, ein Rack, ein Netzwerk und Storage durchqueren, bevor die physische Ursache eines Problems erreicht wird.

Anwendungstopologie gibt diesem Pfad Struktur.

Wie macht Topologie aus einem Alarm eine Geschäftsauswirkung?

Topologie erlaubt es der Plattform zu fragen, was von dem ausgefallenen Objekt abhängt.

Angenommen, ein Switch fällt aus.

Das Netzwerk-Monitoring weiß, welcher Switch down ist.

Die Topologie weiß, welche Server darüber verbunden sind.

Die Compute-Ebene weiß, welche Workloads auf diesen Servern laufen.

Die Anwendungstopologie weiß, welche Services diese Workloads unterstützen.

Die Geschäftsbeziehung weiß, welche Projekte oder Abteilungen diese Services verantworten.

Jetzt lässt sich der Vorfall in Geschäftsbegriffen ausdrücken.

Ohne Topologie erhält der Administrator einen Gerätealarm und muss mehrere Teams fragen, was das Gerät unterstützt.

Diese manuelle Ermittlung verlängert die Reaktionszeit.

Das zugrunde liegende Modell nutzt Beziehungsdaten ausdrücklich, damit Ressourcenlisten und Alarme mit dem Gesundheitszustand von Geschäftssystemen verknüpft werden können.

Was bedeutet Aufwärts-Impact-Analyse?

Aufwärts-Impact-Analyse beginnt bei einem Fehler auf niedriger Ebene und folgt den Abhängigkeiten in Richtung Geschäftsservice.

Beispiel:

GPU-Karte
Server
Cluster-Node
Container
Inferenz-Instanz
Modell-Service
Business-Anwendung
Projekt

Fällt die GPU aus, folgt die Plattform dieser Kette nach oben.

Sie kann feststellen, ob die Karte eine redundante Instanz unterstützt oder ob der Ausfall die Service-Kapazität direkt verringert.

Das verhindert, dass jeder Hardware-Alarm als gleich schwerwiegend behandelt wird.

Zwei identische Server können sehr unterschiedliche Geschäftsauswirkungen haben.

Der eine führt vielleicht eine Entwicklungsaufgabe aus.

Der andere unterstützt vielleicht einen produktiven Inferenz-Endpunkt.

Der Schweregrad auf Hardware-Ebene ist ähnlich.

Der geschäftliche Schweregrad ist es nicht.

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

Abwärts-Analyse beginnt bei einem Service-Symptom und folgt den Abhängigkeiten in Richtung der Infrastruktur, die es verursachen könnte.

Angenommen, eine Anwendung meldet langsame Antwortzeiten.

Die Anwendungstopologie zeigt, dass sie abhängt von:

API-Gateway
Inferenz-Service
Modell-Instanz
GPU-Node
Storage-Service
Netzwerkpfad

Der Administrator kann jede Abhängigkeit prüfen.

Ist der Inferenz-Service gesund, aber die Storage-Latenz auffällig, verlagert sich die Untersuchung in Richtung Storage.

Fallen mehrere Services auf einem physischen Server gemeinsam aus, wird der Server zum wahrscheinlicheren Kandidaten.

Die zugrunde liegende Data Foundation beschreibt diese Abwärtsrichtung ausdrücklich als das Lokalisieren der Hardware-Ursache.

Topologie beweist die Ursache nicht von allein.

Sie grenzt den Suchraum ein und liefert Belege zu Abhängigkeiten.

Was bedeutet horizontale Analyse?

Horizontale Analyse identifiziert Verantwortlichkeit und operative Zuständigkeit.

Sobald die Plattform weiß, welcher Service oder welche Ressource betroffen ist, kann sie verknüpfen mit:

Service-Owner
Anwendungsteam
Infrastrukturteam
Hersteller
Mandant
Projekt
Arbeitsauftrag
Bereitschaftsdienst

Das zugrunde liegende Modell beschreibt dies als das Bestimmen von Verantwortlichkeit und Prozesszuständigkeit.

Das ist operativ wichtig.

Eine Ursache ohne Verantwortlichen erzeugt trotzdem Verzögerung.

Topologie sollte deshalb technische Objekte mit Personen- und Workflow-Daten verknüpfen.

Deshalb umfasst 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 Folgendes teilen:

Einen Switch
Eine Leitung
Einen Netzwerkpfad
Eine Firewall
Einen Inter-Data-Center-Link
Eine Trainings-Fabric-Domain

Untersuchen Anwendungsteams unabhängig voneinander, sehen sie möglicherweise getrennte Symptome.

Die Netzwerktopologie zeigt die gemeinsame Abhängigkeit.

Dieselbe Idee gilt für Redundanz.

Fällt die primäre Leitung aus, ist die Backup-Leitung aber gesund und trägt Traffic, kann die Geschäftsauswirkung begrenzt sein.

Teilen sich beide Pfade dieselbe vorgelagerte 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 offenlegen.

Kubernetes legt Beziehungen zwischen Services, Pods und Nodes offen.

Anwendungs-Traces können übergeordnete und untergeordnete Request-Pfade zeigen.

OpenTelemetry definiert Traces als einen Graphen aus Spans mit übergeordneten und untergeordneten Beziehungen, der bei vorhandener Instrumentierung Belege für Aufrufabhängigkeiten von Anwendungen liefern kann.

Service-Mapping-Systeme können Discovery- und Beziehungsdaten kombinieren, um Anwendungs-Service-Landkarten zu erstellen.

Allerdings lässt sich nicht jede Beziehung automatisch entdecken.

Geschäftliche Verantwortlichkeit und Service-Kritikalität erfordern möglicherweise explizite Metadaten.

Physische Carrier-Diversität benötigt möglicherweise Design- oder Carrier-Informationen.

Die Plattform sollte deshalb automatische Discovery und kontrollierte manuelle Beziehungen mit vollständiger Nachvollziehbarkeit unterstützen.

Wie sollten Topologie-Änderungen gehandhabt werden?

Topologie sollte als dynamische Daten behandelt werden.

Container bewegen sich.

Virtuelle Maschinen migrieren.

Netzwerkpfade ändern sich.

Ein Server wird ausgetauscht.

Eine Anwendungsversion führt eine neue Abhängigkeit ein.

Eine dedizierte Leitung wechselt auf Backup.

Die Plattform muss Beziehungen aktualisieren, sobald diese Änderungen eintreten.

Die zugrunde liegende Data Foundation unterstützt automatische Discovery, manuelle Pflege und Point-in-Time-Snapshots.

Das gilt auch für Topologie.

Bei der Vorfallsnachbereitung benötigen Administratoren möglicherweise die Topologie, die zum Zeitpunkt des Vorfalls bestand, statt der heute bestehenden Topologie.

Historische Beziehungs-Snapshots machen das möglich.

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

AIOps nutzt Topologie, um zu entscheiden, welche Alarme möglicherweise eine gemeinsame Ursache haben und welche Services betroffen sein könnten.

Sind die Beziehungen falsch, ist die Analyse falsch.

Das Ausgangsmaterial macht diesen Punkt direkt deutlich: Alarm-Konsolidierung, fehlerbewusstes Scheduling und Kostenzuordnung hängen alle von denselben Beziehungsdaten ab und degradieren zu isolierten Monitoring-Funktionen, sobald die Daten ungültig werden.

Für AIOps kann Topologie helfen, Folgendes zu beantworten:

Teilen sich diese Alarme eine vorgelagerte Abhängigkeit?

Trat das Infrastrukturereignis vor dem Anwendungssymptom auf?

Welche Services hängen von dieser Komponente ab?

Welcher Verantwortliche sollte den Vorfall erhalten?

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 aggregieren, die den Service tatsächlich unterstützen, und dabei 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 genaue Bewertungsformel sollte transparent sein.

Reduzieren Sie einen komplexen Service nicht auf einen einzigen undurchsichtigen Score.

Eine nützliche Gesundheitsansicht kann berücksichtigen:

Verfügbarkeit kritischer Komponenten
Aktuelle Alarme
SLO-Status
Redundanz
Betroffene Transaktionen
Verminderte Kapazität

Erlauben Sie dem Nutzer anschließend, zu den zugrunde liegenden Ressourcen und Ereignissen durchzuklicken.

Der Score ist eine Navigationshilfe.

Die Belege sind das, worauf Administratoren ihre Handlungen stützen.

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

Dasselbe Beziehungsmodell, das für Vorfallsauswirkungen genutzt wird, lässt sich auch vor geplanten Änderungen einsetzen.

Angenommen, ein Netzwerktechniker möchte einen Switch aktualisieren.

Die Topologie kann identifizieren:

Verbundene Server
Anwendungen, die diese Server nutzen
Geschäftsservices
Redundante Pfade
Aktuelle Wartungsfenster
Verantwortliche

Das hilft, den Blast Radius vor der Ausführung abzuschätzen.

Eine CMDB oder Service-Map sollte deshalb sowohl Vorfallsauswirkungen als auch Änderungsauswirkungen unterstützen.

Je genauer die Beziehungskette, desto nützlicher wird 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 referenziert.

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.

Sobald diese Beziehungen explizit sind, kann die Plattform sie in beide Richtungen durchlaufen.

Für den zugrunde liegenden Mapping-Prozess 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.

Zu den nützlichen Elementen gehören:

Primäres ausgefallenes Objekt
Vor- und nachgelagerte Beziehungen
Betroffene Anwendungen
Betroffene Geschäftsservices
Aktuelle Alarme
Redundante Pfade
Verantwortlicher
Offener Arbeitsauftrag
Kürzliche Änderungen

Erlauben Sie anschließend tieferen Drill-down.

Die zugrunde liegende Business-Topologie nutzt gezielt eine vierschichtige Ansicht, damit die Landkarte nutzbar bleibt.

Ein unbegrenzter Graph kann visuell unlesbar werden, selbst wenn das Datenmodell beliebige Tiefe unterstützt.

Die UI sollte zuerst den relevanten Pfad zeigen.

Was ist der praktische Unterschied zwischen Topologie und Monitoring?

Monitoring sagt Ihnen den Zustand einzelner Objekte.

Topologie sagt Ihnen, wie diese Objekte zusammenhängen.

Ein Netzwerk-Monitor sagt, dass Switch 12 down ist.

Ein Anwendungs-Monitor sagt, dass die Checkout-Latenz hoch ist.

Topologie erklärt, ob die beiden Ereignisse zusammenhängen.

Deshalb kann Monitoring allein keine vollständige Geschäftsauswirkung liefern.

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

Wenn ich Topologie für den Betrieb bewerten würde, 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 beginnen Sie bei diesem Service und arbeiten sich nach unten zum Gerät vor. Funktionieren beide Richtungen und sind der Verantwortliche sowie aktive Alarme sichtbar, ist die Topologie operativ nützlich.