Agenten im Cloud-Betrieb, beginnend mit dem langweiligen Ende

Der Cloud-Betrieb scheint wie geschaffen für Automatisierung: riesiges Ereignisaufkommen, sich wiederholende Untersuchungen, auf wenige Personen konzentriertes Fachwissen und ein Rückstand an Verbesserungen, die niemand erreichen kann.

Der Instinkt besteht darin, einen Agenten auf den Alarmstrom zu richten und ihn entscheiden zu lassen. Dies ist die Anwendung, die am wahrscheinlichsten scheitert, und zwar aus einem Grund, der vor allem erwähnt werden sollte.

Warum automatisierte Entscheidungen hier zunächst scheitern

Eine Warnung bedeutet unterschiedliche Bedeutungen, je nachdem, was vorab passiert ist, was bereitgestellt wird, welche Wartung geplant ist und ob dieses Muster etwas ähnelt, das sich im letzten Quartal als nichts herausstellte.

Der Großteil dieses Kontexts ist nicht in der Warnung enthalten. Es steckt in anderen Systemen und in den Köpfen der Ingenieure. Ein Agent, der ohne diese Entscheidung entscheidet, wird getrost falsch liegen, und zwei getroste Fehler reichen aus, um das Vertrauen zu zerstören, das das Projekt ermöglicht hat.

Es gibt auch keinen natürlichen Überprüfungsschritt. Bis eine Entscheidung überprüft werden konnte, hatte sie bereits Konsequenzen.

Wo es funktioniert

Kontextzusammenstellung, bevor ein Mensch entscheidet. Aktuelle Änderungen am betroffenen Pfad, zugehörige frühere Vorfälle, der aktuelle Bereitstellungsstatus, der relevante Runbook-Abschnitt. Dadurch entfallen die zehn Minuten der Suche, die jeder echten Diagnose, jedem Vorfall und für immer vorausgehen.

Zeitpläne nach einem Vorfall, die über mehrere Systeme hinweg existieren und spät und schlecht geschrieben werden.

Kosten- und Kapazitätsüberprüfung, die mechanisch, kontinuierlich und dauerhaft nachrangig ist.

Änderungsvalidierung anhand von Richtlinien und früheren Vorfällen, Kennzeichnung statt Blockierung.

Die Zugriffsgrenze

Ein Agent, der den Infrastrukturstatus lesen und ihn nicht ändern kann, stellt ein grundlegend anderes Risiko dar als ein Agent, der beides kann. Diese Grenze gehört an den Punkt, an dem die Aktion stattfindet, nicht an die Eingabeaufforderung.

Anmeldeinformationen werden zur Laufzeit aus dem Organisationstresor aufgelöst, sodass keine Infrastrukturanmeldeinformationen in der Konfiguration eines Agenten verbleiben und der Widerruf eine einzige Aktion ist.

Instrumentieren Sie den Agenten so, wie Sie alles andere instrumentieren

Cloud-Teams sind in der Regel gut darin und vergessen, es auf den Agenten selbst anzuwenden. Pro Agent zugeordnete Kosten. Latenzperzentile statt Mittelwerte, da Agentenausführungen stark verzerrt sind. Wiederholungsversuche werden getrennt von Erfolgen gezählt, da es sich um dieselbe Arbeit handelt, die zweimal in Rechnung gestellt wird.

Evaluiert bei jedem Durchlauf statt einer regelmäßigen Prüfung, da der Fehler, der Sie interessiert, derjenige ist, der nach und nach auftritt.

Ausgangsform

Kontextzusammenstellung für eine Klasse von Vorfällen. Benannter Eigentümer auf der Betriebsseite. Bewertungskriterien, die auf den realen Vorfällen des letzten Quartals basieren. Zunächst schreibgeschützt und ein Budget, das blockiert.

Erweitern Sie, wenn die Ergebnisse langweilig sind, nicht, wenn die Demo beeindruckend ist.

Als nächstes

Auf den Seiten „KI-Beobachtbarkeit“ und „Token-Überwachung“ wird die Instrumentierung behandelt. Die Seiten zum Agent Orchestration System behandeln Richtlinien, Anmeldeinformationen und Bewertung.