Wir haben einen Assistenten auf unsere eigenen Vorfälle gesetzt
Um drei Uhr nachts ist der schwierige Teil eines Vorfalls nicht die Behebung, sondern die Orientierung: Was hat sich geändert, was ist betroffen, was gab es schon einmal? Das ist ein Abrufproblem — und dort lassen wir einen Assistenten helfen.
Was um drei Uhr nachts wirklich schwer ist
Nicht die Reparatur. Wenn jemand weiß, welche Komponente ausfällt und warum, ist die Behebung meist eine dokumentierte Prozedur. Teuer sind die zwanzig Minuten davor: Dashboards lesen, einen Deployment-Zeitpunkt gegen eine Fehlerspitze halten und sich erinnern, ob es das schon einmal gab.
All das ist Abruf über Dinge, die wir ohnehin speichern: Änderungsnachweise, Alarme, Protokolle, frühere Vorfallsberichte. Es ist die Art Arbeit, in der ein Assistent wirklich gut ist — und die niemand zu automatisieren gedacht hatte, weil sie sich nach Denken anfühlt statt nach Nachsehen.
Was er tut
Löst ein Alarm aus, stellt er eine Kurzübersicht zusammen: was in den letzten sechs Stunden ausgerollt wurde, welche Alarme gemeinsam feuern, welche Dienste vom betroffenen abhängen und welcher frühere Vorfall ähnlich beschrieben ist. Jeder Punkt trägt einen Verweis auf seine Quelle.
Das dauert rund zwanzig Sekunden und steht auf dem Bildschirm, bevor sich jemand fertig angemeldet hat. Dieses Timing ist der größte Teil seines Werts: Er ist nicht klüger als der Techniker, er ist früher.
Die Forschung mit derselben Gestalt
Xiang und Kollegen veröffentlichten 2025 eine Arbeit zur Ursachenanalyse in Kubernetes, die einen Zustandsgraphen des Clusters mit einem Sprachmodell verbindet — dieselbe Arbeitsteilung, bei der wir gelandet sind: etwas Deterministisches, das die Topologie kennt, und ein Modell, das darüber liest und zusammenfasst.
Am direktesten übernommen haben wir, dass die Struktur aus dem System kommt und nicht aus dem Modell. Unsere Abhängigkeitsinformation wird aus der Konfiguration gelesen, nicht erschlossen — eine Aussage darüber, welcher Dienst von welchem abhängt, ist damit eine Tatsache und keine Vermutung.
| Der Assistent tut | Der Assistent tut nicht |
|---|---|
| Zusammenstellen, was sich änderte und betroffen ist | Sagen, was die Ursache war |
| Ähnliche frühere Vorfälle zeigen | Sagen, es sei derselbe Vorfall |
| Hypothesen mit Belegen vorschlagen | Eine Maßnahme empfehlen |
| Protokolle, Metriken, Änderungen lesen | Irgendetwas anfassen. Immer nur lesend |
Die Regel, die ihn ehrlich hält
Er darf nicht sagen, was zu tun ist. Er schlägt Hypothesen vor, jede mit den stützenden Belegen, und hört auf. Das ist eine bewusste Grenze, und sie hat eine Diskussion überstanden — denn ein System, das sagt, starte den Dienst neu, liegt oft genug richtig, um Vertrauen zu gewinnen, und falsch genau in den Momenten, in denen dieses Vertrauen teuer ist.
Die Hypothesen sind außerdem nach Belegen sortiert und nicht nach Zuversicht. Eine Hypothese, die durch ein zeitlich passendes Deployment und eine übereinstimmende Fehlersignatur gestützt ist, steht über einer, die auf Textähnlichkeit zu einem alten Vorfall beruht — und die Reihenfolge wird berechnet, nicht vom Modell ausgedrückt.
Wo er nutzlos ist
In den letzten zehn Minuten. Ist die Ursache bekannt, ist die Arbeit ein Urteil über eine Behebung unter Zeitdruck, mit Wissen darüber, was sonst läuft und was der Kunde verkraftet — nichts davon steht in einem System, das er lesen kann.
Nutzlos ist er auch bei wirklich neuartigen Fehlern, und das gehört gesagt, denn das sind die Vorfälle, die am meisten zählen. Sein Abruf ähnlicher Vorfälle ist genau dann am besten, wenn das Problem schon einmal auftrat — also dann, wenn sich ein Mensch vermutlich ohnehin erinnert hätte.
Was wir gemessen haben
Die Zeit vom Alarm bis zu einer richtigen Hypothese im Vorfallskanal, vorher und nachher, über rund vierzig Vorfälle. Der Median fiel von etwa elf Minuten auf vier. Die Zeit bis zur Behebung fiel weniger — die ehrliche Gestalt des Ergebnisses: Er beschleunigt den Anfang, nicht das Ende.
Wir haben außerdem gezählt, wie oft seine oberste Hypothese die spätere Ursache war: etwas unter der Hälfte. Diese Zahl ist niedrig genug, dass es falsch wäre, sie als Antwort zu präsentieren, und hoch genug, dass es zwanzig Sekunden wert ist, sie zuerst zu lesen.
Warum er nur lesen darf
Weil ein Vorfall der denkbar schlechteste Moment für eine automatische Aktion ist — und weil wir ihn sonst nicht durch unsere eigene Prüfung bekommen hätten. Seine Zugangsdaten dürfen Metriken, Protokolle und Konfiguration lesen und sonst nichts.
Diese Beschränkung machte das Ausrollen auch leicht. Ein nur lesendes Werkzeug ohne Schreibweg war eine Komponente, die unsere Sicherheitsprüfung an einem Nachmittag freigab; dasselbe Werkzeug mit der Möglichkeit, einen Pod neu zu starten, wäre ein Monat Diskussion für einen Nutzen gewesen, den niemand beziffern konnte.
Was wir nicht behaupten
Wir behaupten nicht, er diagnostiziere etwas. Er ruft ab und ordnet, und die Diagnose macht eine Person, die das Abgerufene liest. Die Unterscheidung klingt pedantisch und ist genau das, was verhindert, dass dem Werkzeug mehr vertraut wird, als es verdient.
Wir behaupten auch nicht, die sieben Minuten Medianersparnis seien übertragbar. Es sind unsere Infrastruktur, unsere Alarmierung und unsere Vorfallshistorie — ein Team mit besseren Dashboards fände weniger zu gewinnen, weil sein Orientierungsproblem bereits kleiner ist.