Von der Verfügbarkeit zur Erfahrung: Der KI-gesteuerte Wandel in der modernen Observierbarkeit

Im Jahr 2001 veröffentlichte IBM ein autonomes IT‑Manifest. Die Vision des autonomen Rechnens zerlegte die Selbstverwaltung in vier Säulen: Selbstoptimierung, Selbstheilung, Selbstkonfiguration und Selbstschutz. Ich war bei Microsoft, als IBM diese IT‑Vision präsentierte. Wir reagierten, indem wir technologische Ideen wie das autonome Rechenzentrum vorschlugen, doch letztlich war es ein Traum, der seiner Zeit weit voraus war. Es gab keinen praktischen Weg, diese Vision in die Realität umzusetzen.

Während meiner Zeit bei Microsoft war ich im Team hinter Clippy. Obwohl der animierte Büroklammer‑Assistent berüchtigt aufdringlich war, war die dahinterstehende Idee solide: Computer sollten Menschen aktiv bei ihrer Arbeit unterstützen. Wir hatten einfach nicht die nötige Rechenleistung und KI, um das zu ermöglichen. 25 Jahre später ist das endlich möglich.

Vom Service‑Level zum Erfahrungs‑Level

Das Konzept der Observierbarkeit stammt nicht aus der IT. 1960 prägte der ungarisch‑amerikanische Ingenieur und Mathematiker Rudolf E. Kálmán den Begriff „Observierbarkeit“, um zu beschreiben, wie gut ein System anhand seiner Ausgaben gemessen werden kann. Dann übernahm den Begriff Twitter 2013 in einer Reihe von Blog‑Posts und machte damit deutlich, dass herkömmliches Monitoring mit allen verfügbaren kommerziellen Standard‑Tools für eine andere Technologiegeneration konzipiert war und in Architekturen im Mikroservice‑Maßstab nicht funktionierte.

Stellen Sie es sich vor wie einen Arzt, der einen Patienten untersucht. Er kann den Puls prüfen, den Blutdruck messen und weitere äußere Merkmale beobachten, um indirekt die innere Gesundheit des Patienten zu beurteilen. In der IT müssen wir dasselbe tun. Wenn der Puls des Patienten flackert, müssen wir wissen, ob das auf Probleme mit der Niere oder der Leber hindeutet. Bei dem Umfang und der Komplexität der Operationen, mit denen Twitter vor 20 Jahren zu kämpfen hatte (das Unternehmen bediente damals nur 100 Millionen Nutzer mit Echtzeit‑Tweets und Feeds), erforderte die Observierbarkeit ein anderes Tooling‑ und Monitoring‑Konzept.

Heutige Systeme sind noch größer und komplexer geworden, mit Abhängigkeiten von Content‑Delivery‑Netzwerken, dem Caching und der Verteilung von Bitmaps, Schriftarten, JavaScript‑Dateien und so weiter rund um den Globus. Die tatsächliche Leistungsfähigkeit von realen Anwendungen zu verstehen, ist keine leichte Aufgabe.

Wenn die IT um 4 Uhr morgens einen Alarm erhält, muss jemand aus dem Bett steigen und herausfinden, ob das Problem durch einen fehlerhaften Sektor auf einer Festplatte oder durch einen Angreifer verursacht wird, der in die Infrastruktur eindringen und Chaos anrichten will. Es spielt letztlich keine Rolle, welcher Fall zutrifft: Am Ende ist es ihre Aufgabe, alle Systeme am Laufen zu halten. Glücklicherweise können wir zur Bewertung der Anwendungs­gesundheit heute sämtliche verfügbare Telemetrie einbeziehen: jedes Netzwerkgerät, jede Anwendung, tausende vorgefertigte Integrationen, Ticket‑Flows über JIRA oder Atlassian und zahlreiche weitere Signale.

Hier kommen Experience‑Level‑Objectives (XLOs) ins Spiel. Sie haben wahrscheinlich schon von Service‑Level‑Agreements (SLAs) und Service‑Level‑Objectives (SLOs) gehört, aber XLOs gehen einen Schritt weiter, indem sie messen, ob Ihre Kunden und Mitarbeitenden das gewünschte Erfahrungsniveau erhalten. Es geht um Qualität, nicht nur um Verfügbarkeit. Aus technischer Sicht ist die einzige Möglichkeit, XLOs zu erreichen, Sichtbarkeit vom NIC bis zum Endgerät des Nutzers zu haben.

Im letzten Oktober fiel AWS US‑EAST‑1 fiel aus. Catchpoint erkannte das Problem 16 Minuten, bevor Amazon es öffentlich bestätigte. Kunden mit dieser Sichtbarkeit konnten reagieren, bevor ihre Nutzer die Folgen des Ausfalls spürten.

Das Versprechen der Observierbarkeit ist vergleichbar mit Smokey Bear: Rauch erkennen, bevor ein Feuer entsteht. Richtig eingesetzt ermöglicht die Observierbarkeit, ein Prärie‑Feuer zu löschen, bevor es zu einer Flammenlawine wird, die die Palisades in Kalifornien zerstört. Smokey ist das Frühwarnsystem, das kleine Rauchschwaden erkennt, egal woher sie stammen: ein AWS‑Problem, ein Oracle‑Problem, ein GCP‑Problem, ein Microsoft‑Azure‑Problem oder ein Fehlfunktion in Ihrer Infrastruktur.

KI skaliert Sicherheitssysteme

Kein menschlicher Betreiber kann die heutigen Infrastruktursysteme im Blick behalten. Der einzige Weg, Systeme in großem Maßstab zu überwachen und dabei Petabytes an Log‑Daten sowie Billionen von Metriken pro Tag zu verarbeiten, besteht darin, KI einzusetzen.

Angenommen, Sie möchten die Lese‑/Schreib‑Leistung einer Festplatte oder Ein‑/Ausgabe‑ bzw. Paketpuffer‑Überläufe in Ihrer Netzwerkumgebung verfolgen. Sie können einen dynamischen Schwellenwert verwenden, um zu definieren, wie Normal aussieht, oder einen deterministischen Ansatz, um Zeitreihendaten der letzten Woche, des Monats, Jahres oder eines beliebigen Zeitraums zu analysieren und normale Leistungsgrenzen festzulegen. Sobald Sie diese statistische Analyse haben, können Sie Werte für zwei Standardabweichungen vom Mittelwert setzen, sodass Sie bei Ereignissen außerhalb dieses Bereichs eine Warnung erhalten, dass die Leistung möglicherweise abnormal ist.

Hochkomplexe Systeme können jedoch Tausende von Alarmen pro Tag erhalten. Dashboards beginnen zu blinken, und Menschen werden paginiert. Das Durchsuchen all dieser Alarme ist keine sinnvolle Nutzung der Zeit von Menschen. Tatsächlich schätzt Vectra, dass Organisationen durchschnittlich 2,992 Sicherheitsalarme pro Tag erhalten, 63 % davon unbehandelt bleiben.

KI‑Tools können diese tausenden von Alarmen pro Tag auf nur ein paar Dutzend reduzieren. Ich erinnere mich an einen Fall, bei dem ein einziges Problem an einer einzigen Netzwerkschnittstelle einer einzigen Maschine 2.000 nachgelagerte Alarme auslöste. Dank KI konnte der Kunde die Alarme korrelieren und zu einer viel schnelleren Ursachenanalyse gelangen, die wiederum ergab, dass ein einzelnes Problem zu diesem Zeitpunkt das gesamte Dashboard des Unternehmens rot werden ließ.

KI macht IT wieder spannend

Ich habe mir nach der Übernahme von Splunk durch Cisco im Jahr 2023 eine Auszeit genommen. In den folgenden zwei Jahren beobachtete ich, wie meine Freunde und ehemaligen Kolleg*innen Unternehmen gründeten, um KI auf Arten zu nutzen, die vor fünf Jahren noch nicht möglich waren. (Zur Erinnerung: Wenn ChatGPT ein menschliches Kind wäre, wäre es drei Jahre alt.)

IT‑Teams benötigen Hilfe, um den Rauch zu erkennen, bevor der Alarm losgeht, nicht mehr Dashboards, in die sie starren müssen. Sie. In gewisser Weise ist das dasselbe Problem, das IBM, Twitter und sogar Microsoft mit Clippy zu lösen versuchen.

Das ist der Grund, warum ich beschlossen habe, wieder einzusteigen. Die Technologie hat endlich einen Punkt erreicht, an dem wir das ursprüngliche Versprechen von Observability und autonomer IT einlösen können.