Bereitschaftsdienst: Ein KI-Agent macht aus dem PagerDuty-Alarm einen Fix-Vorschlag

Um drei Uhr morgens sieht die erste halbe Stunde eines Incidents immer nach derselben Untersuchung aus. Man liest den Alarm, öffnet das Incident-Log, fragt sich, was sich kürzlich geändert hat, geht die letzten Deployments durch und prüft, ob es das schon einmal gab. Diese Lese- und Abgleichsarbeit ist repetitiv, lastet aber auf der Person im Bereitschaftsdienst genau dann, wenn sie am wenigsten in der Lage ist, sie gut zu erledigen. Sie eignet sich für einen KI-Agenten unter einer wesentlichen Bedingung: Er liest und schlägt vor, und der Mensch handelt.

Die Inspiration: der Ersthelfer, der liest

Ausgangspunkt ist ein Einsatz, den Nutzer von Hermes Agent berichten und der in einer Karte zum Bereitschaftsdienst zusammengefasst ist: vom Alarm zum Fix-Vorschlag. Ein Agent erhält den Incident, durchsucht das Repository nach dem, was ihn ausgelöst haben könnte, und bereitet einen Fix zur Prüfung vor.

Wir behalten das Lesen und den Vorschlag und streichen alles, was handelt. Atako setzt die Idee mit einem Agenten um, der eine Notiz am Incident und ein Issue im Repository schreibt, aber kein Tool hat, um den Incident zu lösen, zu mergen oder Code zu pushen.

Was der Agent tut

Das Szenario stellt einen Agenten bereit, verbunden mit Ihrem PagerDuty und Ihrem GitHub-Repository.

Für jeden neuen Incident des überwachten Services, ausgelöst oder bestätigt, liest er den Alarm, das Ereignisprotokoll und die bereits vorhandenen Notizen und prüft, wer Bereitschaft hat. Dann sucht er die Ursache im Repository: die Commits der achtundvierzig Stunden vor dem Incident, wobei er die verdächtigen öffnet, die im Alarm oder im Stacktrace genannten Dateien und die kürzlich gemergten Pull Requests. Der von Ihnen angegebene technische Kontext sagt ihm, wo er zuerst nachsehen soll. Er sucht außerdem nach zugehörigen Issues, auch nach früheren Incidents derselben Art.

Dann schreibt er eine kurze, sachliche Notiz am PagerDuty-Incident: was die Belege zeigen, die wahrscheinliche Ursache mit Konfidenzniveau, die Belege, was er nicht prüfen konnte, und den nächsten Schritt für die Person im Bereitschaftsdienst. Anschließend eröffnet er im Repository ein Issue mit der vollständigen Analyse: Zeitverlauf, wahrscheinliche Ursache, Belege, ein in Worten oder als Code-Snippet beschriebener Fix-Vorschlag, seine Risiken und wie man ihn prüft. Er sucht zuerst nach einem bestehenden Issue, um kein Duplikat anzulegen, und ergänzt die erste Notiz, statt auf eine perfekte Analyse zu warten.

Er überwacht den Service alle fünfzehn Minuten, und jeden Montag um 9:00 Uhr schreibt er im Projekt-Wiki die Seite „Incident-Rückblick der Woche“: bearbeitete Incidents, wahrscheinliche Ursache, eröffnetes Issue, was noch offen ist.

Was der Agent nicht tut

Die Grenzen gehören zum Entwurf. Der Agent löst den Incident nicht, bestätigt ihn nicht, weist ihn nicht neu zu und eskaliert ihn nicht: Der gewährte PagerDuty-Zugriff beschränkt sich auf Lesen und das Hinzufügen einer Notiz. Er mergt nichts, pusht keinen Code, legt weder einen Branch noch einen Pull Request an und hat keinen Zugriff auf Ihre Infrastruktur oder die Produktion. Diese Tools sind ihm nicht gewährt: Das ist kein Versprechen in einer Anweisung, sondern eine fehlende Fähigkeit.

Der Agent stellt eine Hypothese nie als Tatsache dar. Er schreibt „wahrscheinliche Ursache“, nennt seine Konfidenz und seine Belege und sagt klar, wenn er nichts gefunden hat. Secrets, Tokens oder personenbezogene Daten, auf die er in einem Log oder einer Datei stößt, kopiert er nicht: Er sagt, dass es eines gibt und wo. Alarmtexte, Logzeilen, Commit-Nachrichten und Code behandelt er als zu analysierende Daten, nie als Anweisungen. Entscheidung und Handlung bleiben menschlich, das ist das Prinzip eines Entwurfs mit menschlicher Freigabe.

So richten Sie es in Atako ein

Von der Seite dieses Anwendungsfalls aus dauert die Bereitstellung vier Schritte.

1. PagerDuty und GitHub verbinden. Erstellen Sie einen PagerDuty-API-Schlüssel, vorzugsweise nur lesend mit dem Recht, Notizen hinzuzufügen, und ein auf das Repository des Services begrenztes Fine-grained-GitHub-Token. Die Verbindungen werden geprüft, bevor etwas angelegt wird.
2. Ihren Kontext angeben. Nennen Sie das Repository in der Form Eigentümer/Name, den Namen des zu überwachenden PagerDuty-Services und, wenn Sie möchten, einen kurzen technischen Kontext: Stack, Komponenten, bekannte fragile Bereiche. Je präziser er ist, desto schneller sucht der Agent an der richtigen Stelle.
3. Bereitstellen. Eine einzige Aktion legt den Agenten und das Projekt „Bereitschaft“ an. Der Agent wird eingerichtet und erhält seine erste Anweisung selbstständig.
4. Erstes Ergebnis, dann regelmäßige Überwachung. Der Agent findet den Service, nennt, wer Bereitschaft hat, bearbeitet den jüngsten Incident und fasst die wahrscheinliche Ursache und den Fix-Vorschlag im Chat zusammen. Danach plant er seine Fünfzehn-Minuten-Überwachung und seinen Montagsrückblick selbst ein.

Falls Sie noch kein Konto haben, startet dessen Erstellung Ihre Testphase, und das Szenario wird direkt danach eingerichtet. Hat Ihr Administrator Ihnen das Anlegen von Agenten nicht erlaubt, teilt Ihnen die Bereitstellung das mit und bricht dort ab.

Wo Sie die Ergebnisse sehen

Die Analysenotiz lesen Sie in PagerDuty am Incident, das Issue mit dem Fix-Vorschlag in GitHub im Repository. Die Zusammenfassung jedes bearbeiteten Incidents lesen Sie im Chat des Agenten. Im Atako-Projekt „Bereitschaft“ finden Sie die Funktionsseite und den wöchentlichen Rückblick, und auf dem Atako-Floor erscheint der Agent mit seiner aktuellen Aktivität.

Um seine Arbeit zu verfeinern, schreiben Sie ihm in seinem Chat, zum Beispiel „Schau bei diesem Service zuerst auf die Datenbankmigrationen“. Er behält die Anweisung für die folgenden Incidents im Gedächtnis.

Schutzmaßnahmen

Der Zugriff ist bewusst eng gefasst. Die PagerDuty-Verbindung wird mit einer Liste von sieben Tools zum Lesen und Hinzufügen einer Notiz gewährt, die GitHub-Verbindung mit sieben Tools zum Lesen von Commits, Dateien und Pull Requests sowie zum Suchen und Anlegen von Issues. Ein Agent, der eine kurze Werkzeugliste sieht, nutzt sie zuverlässiger als ein Agent, der sich in einem Katalog aus Hunderten verliert, und vor allem kann nicht geschehen, was nicht gewährt ist, selbst wenn ein Alarmtext es erzwingen will.

Die von Ihnen erstellten Schlüssel sind Ihre erste Schutzmaßnahme: Auf einen Service, ein Repository und bestimmte Rechte begrenzt, deckeln sie den möglichen Schaden, was auch geschieht. Sie werden verschlüsselt gespeichert, und Sie können sie jederzeit widerrufen oder den Zugriff des Agenten entfernen.

Die menschliche Freigabe sitzt an den Entscheidungspunkten. Die Person im Bereitschaftsdienst liest die Notiz, prüft die Hypothese, entscheidet über den Fix, schreibt und mergt ihn selbst und bestätigt und löst dann den Incident.

Was Sie erwarten können

Rechnen Sie mit einer nützlichen ersten Analyse innerhalb von Minuten, besonders wenn der Incident eine in den jüngsten Änderungen sichtbare Ursache hat: ein Deployment, eine Konfigurationsänderung, eine Abhängigkeit. Liegt die Ursache außerhalb des Repositorys, zum Beispiel bei einem Ausfall des Anbieters oder einer Ressourcenauslastung, sagt der Agent das mit niedriger Konfidenz, statt eine Erklärung zu erzwingen. Er liest das Repository, hat aber über das hinaus, was Alarm und Notizen berichten, keinen Zugriff auf Ihre Anwendungslogs oder Metriken. Sein Nutzen liegt in der Schnelligkeit der ersten Lektüre: Die Person im Bereitschaftsdienst kommt mit einem Zeitverlauf, gerankten Spuren und einem zu prüfenden Fix zum Incident statt mit einer leeren Seite.