Selbstreparierende Automatisierung ohne Klick-Generator: Türen, die um 3 Uhr morgens funktionieren
Entwurf einer unüberwachten automatischen Reparatur für geplante Agenten-Routinen: ein externer Überwachungsmechanismus, durch Umkehrbarkeit definierte Aktionen, Canary-Rollouts sowie Statusberichte, die durch Belege untermauert werden.
Quellen: Routines That Repair Themselves
Sobald ein Team Dutzende von geplanten Abläufen sowie Agentensitzungen durchführt, ist das nächste Ziel offensichtlich: Wenn ein Ablauf auf einen Fehler in sich selbst oder in seiner Umgebung stößt, sollte er die Ursache eigenständig beheben oder eine separate Sitzung erstellen, die dies tut – ohne dass jemand mitten in der Nacht jede einzelne Schritt genehmigen muss. Das Ziel ist vernünftig. Die Gefahr besteht jedoch darin, dass der schnellste Weg dorthin, nämlich die Genehmigungsmechanismen zu entfernen oder Klickvorgänge zu automatisieren, einen kleinen Fehler in ein flächendeckendes Problem für die gesamte Infrastruktur verwandelt, zu dem noch eine falsche Entwarnung hinzukommt. Diese Anleitung zeigt, wie echte, unüberwachte Reparaturen möglich sind, wobei stets die entscheidende Unterscheidung berücksichtigt wird: Ob eine Aktion rückgängig gemacht werden kann.
Was schiefgeht, wenn die Genehmigungsmechanismen verschwinden
Zwei Fehlermuster tauchen immer wieder in automatisierten Prozessen auf, und beide lohnen es, sie vor dem Aufbau jeglicher Systeme zu untersuchen.
Ein korrekter Befehl, in großem Maßstab ausgeführt
Stellen Sie sich eine Stimme oder einen Chat-Befehl vor, der leicht falsch transkribiert wird und zu einem Automatisierungsablauf gelangt, der über die Steuerung des Schedulers verfügt. Innerhalb von etwa fünf Sekunden deaktiviert dieser 146 geplante Aufgaben, einschließlich aller Überwachungsmechanismen, die dies sonst bemerkt hätten. Es gab keinen Defekt – das System hat genau das getan, was ihm befohlen wurde, sofort und in großem Umfang.
Die Lösung besteht darin, eine kurze Regel einzuführen, die leicht im Gedächtnis zu behalten ist: Jeder Befehl, der in Massen ausgeführt wird, eine ganze Kategorie von Elementen deaktiviert oder nicht rückgängig gemacht werden kann, erhält vor seiner Ausführung eine einzige Bestätigungsmeldung. In dieser Meldung werden angegeben, was beeinflusst wird und welche Folgen ein Rückschritt haben würde. Das Lesen dieser Meldung dauert eine Sekunde; ohne sie dauert es eine Stunde oder länger, sich von dem Vorfall zu erholen.
Ein Wiederherstellungsbericht, der aus Absicht erstellt wird
Der zweite Fehler ist subtiler. Nach einem solchen Vorfall besagen die Wiederherstellungsnotizen etwas wie „30 von 30 wiederhergestellt“. Tage später zeigt eine Überprüfung des laufenden Schedulers, dass 27 Aufgaben weiterhin deaktiviert sind, darunter die Konfigurations-Backup-Funktion, der Synchronisierungsmonitor sowie der Session-Watchdog. Die Statuszeile wurde auf Grundlage dessen erstellt, was der Operator tun wollte, und nicht auf Grundlage dessen, was das System tatsächlich anzeigte.
Dies führt zu einer strengen Berichterstattungsregel: Ein Satz wie „N von N wiederhergestellt“ ist nur neben dem Befehlsausgabe-Teil zulässig, der diesen Zustand zurückgibt. Ohne diesen Beleg ist die ehrliche Formulierung „Der Wiederherstellungsbefehl wurde gesendet“.
Dies ist das zentrale Risiko der automatischen Reparatur: Ein Reparateur, der Erfolg behauptet, ohne das Ergebnis zu prüfen, ist schlimmer als gar kein Reparateur, denn dadurch wird ein Ausfall in einen Ausfall plus eine zuversichtliche Meldung, dass alles in Ordnung sei, verwandelt.
Fünf Regeln für unbemannte Reparaturen
1. Eine Routine kann nicht ihr eigener Reparator sein
Falls eine Routine fehlerhaft ist, ist in der Regel auch ihre eingebaute Selbstreparaturlogik beschädigt, wodurch beide stillschweigend zusammen versagen. Die Reparatur muss auf einer Ebene darüber stattfinden: ein separater Prozess, idealerweise auf einem anderen Rechner, der die Routine von außen überwacht.
Überwacht werden sollte das Alter der Ausgabe der Routine und nicht ihr Abbruchcode. Eine Aufgabe, die mit Status 0 beendet wird und nichts schreibt, erscheint bei jeder Überprüfung des Abbruchcodes völlig intakt. Es ist durchaus möglich, dass eine solche Aufgabe wochenlang unentdeckt bleibt. Eine Frischheitsprüfung („Die Berichtsdatei ist jünger als 26 Stunden“, „Die letzte Zeile in der Tabelle stammt vom heutigen Tag“) erkennt genau die Fehler, die Abbruchcodes verbergen.
2. Klassifizieren Sie Aktionen, nicht Genehmigungen
Der Antrag hinter „Niemand darf nachts ‚Allow‘ klicken“ ist vernünftig, doch ein Bot, der automatisch auf ‚Allow‘ klickt, ist die falsche Lösung. Er löscht die einzige Zeile, die wirklich wichtig ist – jene, die Handlungen, die rückgängig gemacht werden können, von solchen unterscheidet, die es nicht können – und tut dies am schnellsten gerade dann, wenn kein Mensch zusieht. Zudem wird eine Entscheidung verdeckt: Jemand hat trotzdem entschieden, dass diese Handlungen sicher sind, und der Klicker verschleiert lediglich, wer diese Entscheidung getroffen hat und wann.
Die praktikable Alternative besteht darin, die Handlung selbst in verschiedene Kategorien einzuteilen:
- Automatisch, ohne Mensch, zu jeder Tageszeit: Neustart eines hängengebliebenen Services, Neuregistrierung einer fehlgeschlagenen Planungsaufgabe, Lösen eines veralteten Schlosses, erneute Ausführung einer idempotenten Importoperation, Neubau eines Indexes. Diese Handlungen sind begrenzt, rückgängig machbar und sicher zum Wiederholen.
Dadurch läuft die erste Ebene über Nacht vollständig autonom, die dritte Ebene wartet auf einen Morgenbericht, und um 3 Uhr morgens klickt niemand etwas an. Ebenso wichtig ist, dass um 3 Uhr morgens nichts Unumkehrbares geschieht.
Durch das Aufschreiben der Klassifizierung wird die Entscheidung bezüglich des Vertrauens klar, überprüfbar und in einer einzigen Datei änderbar. Es handelt sich dabei um denselben Grad an Vertrauen wie bei einem Allow-Clicker, der an einer Stelle gespeichert ist, die überprüft und getestet werden kann. Für eine ausführlichere Behandlung der Risikostufen sowie Genehmigungsmechanismen für Agenten im Allgemeinen siehe unseren Leitfaden zu Genehmigungen, Genehmigungsmechanismen und Risikostufen.
3. Zuerst Canary, dann die gesamte Flotte
Eine gleichzeitige Bereitstellung einer Korrektur auf allen Knoten stellt an sich bereits einen einzigen Ausfallpunkt dar: Wenn die Korrektur fehlerhaft ist, gilt sie sofort überall als fehlerhaft. Implementieren Sie sie stattdessen schrittweise:
- wenden Sie die Änderung auf einen Knoten an
- überprüfen Sie dies durch das Lesen des resultierenden Zustands, nicht durch das Vertrauen auf einen Rückgabecode
- wenden Sie sie auf einen zweiten Knoten eines anderen Typs an
- nur danach können Sie sie allen zur Verfügung stellen
Nennen Sie den Rollback vor Beginn, damit die Rücksetzung ein bekanntes Verfahren ist und nicht eine Improvisation unter Druck.
4. Erstellen Sie keinen Reparaturroboter für den ersten Fehler
Automatische Reparaturmaschinen vermehren sich leicht, denn jeder einmalige Fehler scheint seinen eigenen Roboter zu verdienen. Ein Schwellenwert hält das in Schach. Das erste Auftreten eines Problems führt zu einer einzigen, datierten Zeile in einem Protokoll. Ein Mechanismus wird erst dann entwickelt, wenn derselbe Fehlertyp zum dritten Mal auftritt – und zwar nur bei einem benannten Nutzer, der ihn benötigt.
Ohne eine solche Regel kann die Überlastung alarmierend ansteigen. Ein Team, das seine eigene Arbeit gemessen hat, stellte fest, dass 82 Prozent davon zu sogenannter Meta-Arbeit geworden waren: Maschinen, die dazu dienen, andere Maschinen zu verwalten. Die Reparaturautomatisierung gehört genau zur Kategorie, die am anfälligsten für diesen Teufelskreis ist.
5. Geben Sie jeder neu gestarteten Sitzung eine eigenständige Zusammenfassung
Eine um 4 Uhr morgens von einem Überwachungssystem gestartete Sitzung verfügt nicht über den Kontext, der beim Prozess vorhanden ist, der das Problem entdeckt hat. Übergeben Sie ihr einen Bericht mit folgendem Inhalt:
- Was kaputtgegangen ist
- Die Beweise
- Was bereits versucht wurde
- Die Grenzen dessen, was bearbeitet werden darf
- Die Definition von Abgeschlossenheit
Diese Grenzen sind es, die oft vergessen werden. Ohne sie wird ein eifriger Mitarbeiter gerne auch benachbarte Probleme beheben, um die niemand gebeten hat – dadurch verwandelt sich eine begrenzte Reparatur in einen umfassenden, unüberprüften Änderungsprozess.
Wenn ein Mitarbeiter einen anderen genehmigt
Eine gängige Empfehlung ist es, einen Agenten dazu zu bringen, einen anderen zu genehmigen – beispielsweise in einem gemeinsamen Chat, wo ein überwachender Agent einem Mitarbeiter mitteilt, weiterzumachen. Es gibt bereits fertige Tools zur Auslösung von Sitzungen auf diese Weise. Dieses Muster funktioniert gut für die ersten Ebene von Aktionen. Genau so werden auch Aktionen der dritten Ebene um 3 Uhr morgens genehmigt, wenn sie sich nicht voneinander unterscheiden. Sobald Aktionen anhand der Umkehrbarkeit definiert sind, ist die Genehmigung von Agent zu Agent sicher anwendbar, denn der Überwacher kann nur das genehmigen, was die Klassifizierung bereits zulässt.
Kernpunkte
- Stellen Sie die Reparatur außerhalb des zu reparierenden Gegenstands und beurteilen Sie den Zustand anhand der Aktualität der Ausgabe statt anhand von Abbruchcodes.
- Ersetzen Sie das Klicken zur Genehmigung durch eine schriftliche Klassifizierung der Aktionen anhand ihrer Umkehrbarkeit und ihres Einflussradius.
- Fordern Sie für massenhafte, klassenweite oder irreversible Anfragen eine einzeilige Bestätigung mit Angabe des Umfangs und der Kosten für einen Rückgang.