Sonntag, Spitzenlast: Ein 5xx-Alarm kommt rein. Der Cache hinter einem Chat-API-Cluster läuft bei 100 Prozent CPU und nimmt neue Verbindungen zu langsam an. Minuten später hängt im Slack-Thread ein Befund: Query-Ergebnis, Codeverweis, ein konkreter Änderungsvorschlag. Stream betreibt die Chat-API und bedient nach eigenen Angaben Apps mit über einer Milliarde Endnutzern. Das Backend-Team dort wollte die erste Untersuchung von Produktionsvorfällen nicht mehr von Hand machen.
Der Agent ist kein Autopilot und kein Chatbot mit Logzugriff. Eher ein Assistenzarzt im Nachtdienst: Er nimmt den Fall auf, erhebt Befunde, ordnet sie ein und notiert zu jeder Messung die Quelle. Operieren darf er nicht. Diese Trennung prägt alle Entscheidungen im Folgenden. Der Text erklärt, wie der Agent arbeitet und mit welchen vier Entscheidungen das Team ihn in Produktion absichert.
Die Fehlersuche kostet mehr Zeit als das Beheben
Fehlersuche in einem Chat-Backend läuft fast immer gleich ab. Eine Meldung oder ein Alarm gehört zu einer App, einer Region und einem Cluster. Dann zieht man die Logs der App im passenden Zeitfenster, vergleicht Fehlerraten über Endpunkte, sucht langsame oder abgebrochene Queries, prüft das letzte Deployment und liest den Codepfad, auf den die Fehler zeigen. Jeder Schritt braucht ein anderes Werkzeug, jede Abfrage eigene Syntax und eigene Zugangsdaten.
Der Autor hat in dieser Phase mehr Zeit verloren als beim eigentlichen Beheben – ob der Alarm um drei Uhr nachts kam oder eine Kundenfrage am Nachmittag. Das ist keine Frage von Fleiß, sondern von Struktur. Die Untersuchung ist breit, leselastig und ihr Ergebnis prüfbar. Wer sagt, die Fehlerrate eines Endpunkts sei gestiegen, kann die Query zeigen, die diese Rate erzeugt.
Der Fix ist etwas anderes. Er verlangt eine Einschätzung von Risiko, Betroffenen und Zeitpunkt, und am Ende muss jemand dafür geradestehen. An dieser Linie teilt das Team die Arbeit: Der Agent gräbt, der Mensch entscheidet. Ist die Teilung akzeptiert, sind die meisten Sicherheitsfragen keine Modellfragen mehr, sondern Fragen an die Umgebung.
Von der Slack-Meldung zum Befund: vier Stationen
Der Agent ist ein Dienst, der Support- und Incident-Kanäle in Slack mitliest. Er startet, wenn ihn jemand markiert, oder automatisch, wenn ein Produktionsalarm für einen Cluster ausgelöst wird. Jeder Fall läuft danach durch eine kurze Pipeline mit vier Stationen.
Erste Station: Triage. Ein kleines, schnelles Modell entscheidet, ob die Nachricht eine Untersuchung braucht. Zweite Station: die Untersuchung selbst. Ein größeres Modell arbeitet in einer Sandbox und liefert eine Antwort oder einen Reparaturvorschlag. Dann folgt die Prüfung: Eine frische Sitzung versucht, das Ergebnis zu widerlegen. Zuletzt die Übergabe. Eine Antwort landet im Thread, ein Vorschlag mit nummerierten Optionen bei einem Ingenieur, der ihn freigeben muss.
Der Fall vom Sonntag zeigt das in der Praxis. Der Cache hinter einem Cluster lief bei 100 Prozent CPU und nahm neue Verbindungen zu langsam an; API-Aufrufe scheiterten. Der Agent fand heraus, dass der Cache nach Speicher dimensioniert war und davon nur einen Bruchteil nutzte. Der Engpass war die CPU. Er schlug vor, die Shard-Zahl von drei auf sechs zu verdoppeln. Das ließ sich im laufenden Betrieb umsetzen. Nach der Freigabe durch den Bereitschaftsingenieur fiel die CPU-Last auf etwa 56 Prozent, die Fehlerrate ging auf das normale Maß zurück.
Der Agent hat nichts repariert. Er hat einen Befund mit Begründung vorgelegt und eine Option empfohlen, die ein Mensch freigegeben hat. Genau darin unterscheidet er sich von einem Werkzeug, das Fakten schafft, die niemand mehr nachprüfen muss.
Jede Behauptung braucht einen Beleg, eine zweite Sitzung widerspricht
Der Agent darf keine Schlussfolgerung aus eigener Autorität ziehen. Jede Aussage muss auf ein Abfrageergebnis oder eine Datei mit Zeilennummer im Code zeigen. Der Prüfschritt testet die Antwort gegen diese Belege. Ein Ingenieur muss die Untersuchung dann nicht wiederholen, sondern prüft die Zitate, auf die es ankommt. Eine falsche Behauptung fällt meist als Zitat auf, das nicht das sagt, was die Antwort behauptet.
Der zweite Mechanismus ist ungewöhnlicher. Bevor eine Antwort oder ein Vorschlag veröffentlicht wird, sieht ihn sich eine separate Sitzung an. Sie startet mit frischem Kontext und erbt die Denkweise der ersten Sitzung nicht. Ihr Auftrag ist nicht zuzustimmen, sondern die alternative Erklärung zu finden, die die Untersuchung übersehen hat. Wer schon einmal einen Fehler mit jemandem besprochen hat, der die Vorgeschichte nicht kennt, kennt den Effekt: Der Blick von außen stellt die Fragen, die man selbst nicht mehr stellt.
Kann die Prüfsitzung eine Schlussfolgerung nicht bestätigen, wird das Ergebnis trotzdem veröffentlicht – als „nicht verifiziert“, mit Begründung. Automatische Wiederholungsrunden gibt es nicht: Jede Runde wäre ein voller Untersuchungslauf und würde die Zahl der bearbeitbaren Fälle pro Tag ungefähr halbieren. Die offenen Fragen wandern stattdessen in das Ticket, wenn eines angelegt wird. So sieht ein Mensch die Lücken, bevor er auf das Ergebnis reagiert. Ein ehrliches „noch nicht bestätigt“ hilft im Bereitschaftsdienst mehr als Schweigen oder ein selbstsicherer Fehler.
Grenzen liegen in der Umgebung, nicht im Prompt
Der Agent liest fremden Text – Kundenmeldungen, Ticketbeschreibungen – und kommt an sensible Daten. Diese Kombination nutzt Prompt Injection aus: Eine Nachricht, die wie eine Supportanfrage aussieht, kann Anweisungen enthalten, die das Modell dazu bringen sollen, Daten preiszugeben oder Befehle auszuführen. Die Entwickler legen die Grenzen deshalb nicht in Anweisungen an das Modell, sondern in die Umgebung. Anweisungen lassen sich wegreden, Container nicht.
Jede Untersuchung läuft in einem isolierten Container mit einer schreibgeschützten Kopie des Codes. Code pushen kann der Agent nicht. Der Zugriff auf die Infrastruktur läuft über eine kleine Sammlung rein lesender Werkzeuge für Logs, Datenbanken, Metriken, Storage und Quellcode. Datenbanksitzungen werden read-only geöffnet. Die Zugangsdaten für die wichtigsten Produktionsdatenbanken bleiben außerhalb der Sandbox auf dem Host; dort führt ein kleiner Dienst die Leseabfragen für den Agenten aus. Das Netzwerk der Sandbox erreicht die Modell-API und die Backends der Werkzeuge, sonst nichts.
Dazu kommt ein Filter für jede Nachricht, bevor sie im Kanal erscheint. Er blockiert Geheimnisse und wörtlich übernommene Kundeninhalte. Selbst wenn jemand dem Modell eine schädliche Anweisung unterschiebt, gibt es keinen Schreibweg, den sie nehmen könnte. Deshalb kann das Team den Agenten unbeaufsichtigt auf Alarme loslassen.
Das Modell schlägt vor, der Dienst handelt
Das Modell führt keine nach außen wirksame Aktion aus. Jeder Seiteneffekt gehört zum Dienst drumherum: gewöhnlicher Code, den das Team geschrieben und geprüft hat. Findet der Agent eine Reparatur, stellt er die Optionen ein. Nur Mitglieder des Chat-Engineering-Teams können eine davon freigeben. Eine freigegebene Codeänderung wird ein Pull-Request-Entwurf und läuft durch das normale Review. Eine freigegebene operative Änderung wird ein Runbook mit Schritten, Prüfmöglichkeit und Risiken, das ein Ingenieur ausführt.
Der Agent führt diese Schritte nicht selbst aus. Das ist keine Vorsichtsmaßnahme am Rand, sondern der Kern des Modells. Sobald ein Werkzeug eine Schreiboperation anbietet, muss man jede mögliche Eingabe durchdenken, jede absichern und jede Erklärung des Modells misstrauisch prüfen. Die Trennung von Vorschlag und Ausführung verkleinert diese Fläche auf null und verschiebt die Verantwortung dorthin, wo sie ohnehin liegt. Wenn die Arbeit einen Eigentümer braucht, legt der Dienst ein Ticket an und weist es zu. Auch das ist gewöhnlicher Code, keine Modellentscheidung.
22 Testfälle, darunter die eigenen Fehler
Unit-Tests decken den Dienst ab, sagen aber nichts darüber, ob der Agent zu richtigen Schlüssen kommt. Dafür gibt es 22 Fälle, zum größten Teil aus echten Support-Threads und Incidents. Jeder Fall läuft durch die echte Pipeline, nur ohne Slack, und wird gegen das bekannte richtige Ergebnis bewertet. Ein Fall kann zusätzlich Aussagen auflisten, die nur eine falsche Antwort treffen würde. Eine Antwort, die eine davon enthält, fällt durch.
Die Fälle sind absichtlich unangenehm. Eine Nachricht wie „lol hat jemand gestern das Spiel gesehen“ muss in der Triage abgefangen werden, bevor eine Untersuchung startet. Dasselbe gilt für die Frage, warum der Agent in bestimmten Threads nicht arbeitet: Sie klingt wie eine Ausfallmeldung, meint aber den Agenten selbst. Eine frühe Version eröffnete dafür eine Untersuchung und legte ein Ticket an. Ein anderer Fall fragt, wie eine Metrik berechnet wird. Das klingt nach einer Datenanfrage, die Antwort steht aber im Code. Ein weiterer meldet hart gelöschte Nachrichten und sieht nach einem Incident aus, obwohl nichts kaputt ist und der Kunde nur eine Zahl braucht.
Dazu kommt eine Falle für Fabrikation: Der Agent soll ein internes Werkzeug ausführen, das es nicht gibt. Ein weiterer Fall beruht auf einem eigenen Fehler. Eine frühe Version meinte, ein Kunde habe verwechselt, welche seiner beiden Queries fehlgeschlagen sei, obwohl der Bericht des Kunden stimmte. Der Thread ist heute ein Testfall; eine Antwort, die die verdrehte Lesart wiederholt, fällt durch. Ein letzter Fall prüft, ob der Agent eine Ursache auf Kundenseite als solche erkennt, statt eine Codeänderung im eigenen System vorzuschlagen.
Die Bewertung nutzt echte Modellaufrufe und kostet echtes Geld. Sie läuft deshalb von Hand, nicht bei jedem Commit. Aus den Erfahrungen hat das Team drei Ratschläge für andere: Guardrails gehören in die Umgebung, nicht in den Prompt; eine kleine Triage spart teure Läufe; falsche Antworten sollten Testfälle werden. Dazu kommt der Aufwand um die Antwort: Er wiegt mindestens so schwer wie die Antwort selbst – wer bekommt das Ticket, welches Label trägt es, wie wird der Fall abgeschlossen. Ein KI-Agent für Produktionsprobleme ist am Ende weniger ein Modell als ein sauber geschnittener Prozess mit einem Modell darin.
Die Bereitschaft übernimmt weiterhin jeden Incident. Eine Root-Cause-Analyse mit KI ersetzt keine Verantwortung. Wer den Thread öffnet, sieht statt eines nackten Alarms einen Befund mit Belegen, Query-Ergebnissen und Codestellen – und bei Bedarf einen Vorschlag, der auf Freigabe wartet. Die 22 Fälle sind keine Produktionsreife, sondern ein Anfang; die manuelle Bewertung bleibt eine offene Flanke. Wer Produktionsvorfälle mit KI analysieren will, sollte die Grenze nicht beim Modell ziehen, sondern beim Schreibzugriff. Automatische Fehleranalyse im Backend funktioniert so weit, wie man den Agenten lesen lässt und ihn am Schreiben hindert. Mehr gibt dieser Aufbau nicht her; die nächste Generation muss zeigen, ob sie ohne diese Grenze auskommt.
Quelle: getstream.io
