Die Delivery-Engine betreiben

Die Autonomous Delivery Engine (ADR 0045) bietet zwei Operability-Oberflächen mit unterschiedlichem Scope:

• Die Operator-Konsole unter /operator ist das mandantenübergreifende Cockpit für einen Instanz-Admin: Sie zeigt den Dispatcher-Zustand über alle Workspaces hinweg, ausgelöste Circuit Breaker, ein nachvollziehbares Routing-Protokoll, die mandantenübergreifende Audit-Abfrage und die globalen Systemschalter.
• Die Operability-Konsole unter /operations ist eine mandantenbezogene, schreibgeschützte Ansicht eines einzelnen Workspaces für dessen Owner und Admins: Sie zeigt allein die Dispatch-Metriken, das Routing-Entscheidungsprotokoll und die ausgelösten Circuit Breaker dieses Workspaces – keinen anderen Mandanten und ohne jeden Schalter.

Diese Anleitung erklärt, wie du beide Oberflächen liest, und beschreibt die beiden Sicherheitskontrollen: den globalen Dispatch-Kill-Switch (Instanz-Owner) und die Pause je Workspace (Workspace-Owner).

Wer was öffnen kann

Die mandantenübergreifende Operator-Konsole richtet sich an Instanz-Admins: Der Eintrag Operator in der Seitenleiste erscheint nur für einen Admin, und die Konsole öffnet sich mit deiner normalen Anmelde-Sitzung. Die mandantenbezogene Operability-Konsole ist für die Owner und Admins eines Workspaces gedacht und zeigt nur diesen einen Workspace. Jeder mandantenübergreifende Lesezugriff und jede Schalteränderung wird als actor_type=operator auditiert.

Die Operability-Konsole deines Workspaces lesen

Als Workspace-Owner oder -Admin öffnest du /operations, um zu sehen, wie die Delivery-Engine deinen Workspace behandelt – ganz ohne Instanz-Admin-Zugriff. Die Seite folgt dem vertrauten tabbasierten Einstellungen-Layout.

Drei mandantenbezogene, schreibgeschützte Endpunkte speisen die Seite; den Workspace leitet der Server aus deiner Sitzung ab, du übergibst ihn nie als Parameter:

• GET /api/operator/v1/tenant/dispatch/metrics — Warteschlangentiefe, -alter und -durchsatz dieses Workspaces, plus seine eigene Provider-Quota-Auslastung je Anmeldedatum.
• GET /api/operator/v1/tenant/routing — das Routing-Entscheidungsprotokoll dieses Workspaces.
• GET /api/operator/v1/tenant/circuit-breakers — die ausgelösten Breaker auf Projekt-Scope dieses Workspaces.

Öffnet ein Member oder Viewer /operations per Deeplink, wird er abgewiesen – die Konsole setzt die Workspace-Rolle Owner oder Admin voraus.

Die Konsole öffnen

1. Melde dich als Instanz-Admin an und öffne /operator (der Eintrag Operator in der Seitenleiste erscheint nur für Admins).

2. Die Seite lädt die mandantenübergreifende Übersicht: das Dispatch-Metriken-Panel, das Routing-Entscheidungsprotokoll, die Audit-Abfrage und die Systemschalter. Über Aktualisieren lädst du sie jederzeit neu.

Das Dispatch-Metriken-Panel lesen

Der Abschnitt Dispatch-Metriken bündelt den Zustand des Dispatchers über alle Workspaces hinweg. Er ist eine schreibgeschützte Momentaufnahme und lädt bei jedem Klick auf Aktualisieren neu.

Warteschlangen- und Tick-Anzeigen

Die vier oberen Anzeigen geben Aufschluss über die Backlog-Warteschlange und den Zustand des Schedulers:

Anzeige	Bedeutung
Warteschlangentiefe	Backlog-Elemente, die derzeit queued sind und auf den Dispatch warten.
Ältestes in Warteschlange	Alter des ältesten wartenden Elements (Veraltung der Warteschlange). Angezeigt als Ns / Nm / Nh, oder „nie“, wenn die Warteschlange leer ist.
Kürzlich dispatcht	Backlog-Runs, die im jüngsten Fenster dispatcht wurden — der Durchsatz.
Tick-Zustand	Zeit seit dem letzten Scheduler-Tick. Ein wachsender Wert bedeutet, dass der Dispatch-Ticker hängt.

Darunter zeigt die Prioritätsverteilung als Balken, wie sich die wartenden Elemente auf die Prioritätsklassen verteilen (höchste Priorität zuerst). Ein langer Ausläufer in der niedrigsten Klasse ist normal; ein Stau in der höchsten Klasse ist es nicht.

Anzeigen zur Provider-Quota-Auslastung

Die Karte Provider-Auslastung zeigt pro Modell-Provider, wie viel der gemessenen Quota verbraucht ist (verbraucht / Limit, summiert über die Anmeldedaten des Providers):

• Oberhalb von 60 % Auslastung färbt sich eine Anzeige bernstein, oberhalb von 85 % rot – das ist die Drosselungsgrenze des Dispatchers. Eine rote Anzeige heißt, dass der Dispatcher diesen Provider zurückfährt, um das Limit nicht zu erreichen.
• Ist das Limit eines Providers in jedem gemessenen Fenster unbekannt, erscheint er als unbekannt (ohne Anzeige) – ohne bekannte Obergrenze lässt sich keine Auslastung berechnen.
• Die Zeile „kurz vor Erschöpfung“ unter einer Anzeige zählt die Fenster, die bereits über der 85-%-Grenze liegen.

Fehler-Recovery-Raten

Die Karte Fehler-Recovery zeigt pro Agent-Fehlerklasse (transient_server, usage_limit, context_degraded, auth_config, fatal), welcher Anteil der jüngsten Fehler dieser Klasse von der Recovery-Schicht als automatisch wiederholbar markiert wurde. Eine hohe Recovery-Rate bei transient_server ist gesund – Aussetzer werden dann erneut versucht. Eine niedrige Rate bei einer Klasse, die eigentlich wiederherstellbar sein sollte, ist hingegen einen genaueren Blick wert.

Das Routing-Entscheidungsprotokoll

Die Karte Routing-Protokoll ist die Nachvollziehbarkeits-Oberfläche des Dispatchers. Jeder Eintrag steht für eine Backlog-Routing-Entscheidung, die neueste zuoberst, und zeigt:

• den Elementtitel (oder die ID), für den die Entscheidung galt;
• die Routing-Quelle – classify, escalate, fallback oder manual – also den Pfad, der die Entscheidung getroffen hat;
• die Entscheidungsfaktoren im Wortlaut als JSON, geschrieben vom Klassifizierer oder von der Eskalation (warum das Element dispatcht wurde, welches Modell gewählt wurde, warum es pausiert wurde). Bewege die Maus über einen Eintrag, um das vollständige JSON im Tooltip zu lesen;
• den Zeitstempel der Entscheidung.

Mit diesem Protokoll beantwortest du Fragen wie „Warum lief dieses Element auf diesem Modell?“ oder „Warum wartet dieses Element noch?“, ohne in den Server-Logs zu suchen.

Hinweis

Diese Konsole liest mandantenübergreifend. Dasselbe Routing-Protokoll – auf einen einzelnen Workspace eingegrenzt – sieht ein Workspace-Owner oder -Admin in seiner eigenen Operability-Konsole unter GET /api/operator/v1/tenant/routing.

Den Circuit-Breaker-Zustand lesen

Ein Circuit Breaker verhindert, dass der Dispatcher einen Provider oder ein Projekt während eines anhaltenden Ausfalls weiter mit Anfragen überzieht. Jeder Breaker ist durch einen Scope (provider oder project) und eine Fehlerklasse gekennzeichnet und nimmt einen von drei Zuständen an:

• closed – Anfragen fließen normal.
• open – der Breaker hat ausgelöst; Anfragen schlagen sofort fehl oder weichen aus. Er löst nach drei aufeinanderfolgenden Fehlern desselben Scopes und derselben Klasse aus und bleibt für eine Abkühlphase von 60 Sekunden offen.
• half-open – nach der Abkühlphase lässt der Breaker eine einzelne Probe-Anfrage durch. Bei Erfolg schließt er sich; bei einem Fehler öffnet er sich erneut und die Abkühlphase beginnt von vorn.

Ein ausgelöster Provider bleibt über einen Server-Neustart hinweg ausgelöst – der Zustand ist dauerhaft. Aktuell ausgelöste Breaker listet GET /api/operator/v1/circuit-breakers auf: Der Endpunkt liefert nur die nicht geschlossenen Breaker, jeweils mit Scope, Fehlerklasse, Zustand und Auslösezahl.

Tipp

Hat ein Provider einen offenen Provider-Ausfall-Breaker (transient_server oder usage_limit), weicht der Dispatcher auf ein alternatives Anmeldedatum oder einen anderen Provider aus, statt einen Run zu starten, der ohnehin nur wieder fehlschlägt. Ein Breaker heilt sich beim nächsten Erfolg nach der Abkühlphase von selbst – von Hand zurücksetzen musst du ihn in der Regel nicht.

Den globalen Kill-Switch nutzen

Der Schalter global dispatch ist der Hauptschalter der Engine. Solange er deaktiviert ist, dispatcht der Backlog-Ticker über alle Workspaces hinweg nichts: Die Warteschlange füllt sich zwar weiter, doch es starten keine neuen autonomen Runs.

1. Scrolle in der Operator-Konsole zu Systemschalter.

2. Gib im Begründungsfeld eine Begründung ein – ohne Begründung wird eine Schalteränderung abgelehnt. Die Begründung landet im Audit-Protokoll.

3. Klicke auf die Aktionsschaltfläche in der Zeile global_dispatch, um den Schalter umzulegen. Ihre Beschriftung benennt die Aktion, die sie ausführt (Aktivieren / Deaktivieren). Der Umschalter ruft PUT /api/operator/v1/switches/{key} auf und ist dem Instanz-Owner vorbehalten.

Die übrigen Schalter in diesem Panel – task_launch, scheduler, auto_developer, webhook_automation, outbound_notifications, auto_model_selection – sind feiner gefasste globale Gates über denselben auditierten Mechanismus. Auch sie umzulegen erfordert eine Begründung.

Einen einzelnen Workspace pausieren

Der obige Kill-Switch wirkt global. Um einen Workspace zu pausieren, ohne die übrigen zu berühren, setze dessen workspace-gebundenen Schalter. Ein workspace-gebundener Schalter überschreibt den globalen Wert nur für diesen einen Workspace; ein nicht gesetzter Workspace-Schalter erbt den globalen Wert (der standardmäßig erlaubt ist). Du setzt ihn über die Einstellungen des Workspaces selbst oder die Management-API, nicht über das globale Schalter-Panel der Operator-Konsole.

Achtung

Jede Schalteränderung – global oder je Workspace – schreibt eine audit_events-Zeile mit dem Akteur, dem Zielschalter und der erforderlichen Begründung. Sieh die Begründung als die betriebliche Aufzeichnung dafür, warum der Dispatch pausiert wurde.

Siehe auch

• Der selbstlernende Governor — wie die Engine die Modellauswahl lernt und was der L3-Governor vorschlägt (nichts wird automatisch angewendet).
• Die vollständige Designbegründung findet sich in ADR 0045.