Als unser Notfall-Bot den Ausfall verlängert hat

Einer unserer Server ist eingefroren. Nicht abgestürzt, nicht neu gestartet, einfach stehengeblieben. Auf dem Host läuft unter anderem die Academy, also war die Seite für eine Weile nicht erreichbar. Ärgerlich, aber kein Weltuntergang. Solche Host-Probleme passieren bei jedem Cloud-Anbieter mal. Das Problem war nicht der Freeze. Das Problem war, was danach passierte. Wir haben einen Telegram-Bot, der bei Störungen anschlagen soll. Ein Wächter. Der hat gemerkt, dass der Host nicht antwortet, und hat angefangen zu handeln. Autonom, ohne mich zu fragen. In kurzer Zeit hat er 35 Bash-Kommandos abgefeuert. Er hat die Doku nicht gelesen, das Runbook nicht aufgemacht, ins Memory nicht reingeschaut. Er hat einfach probiert. Und dann kam die Eskalation. Der Bot hat einen harten Reset ausgelöst, das Rescue-System scharf gestellt und den Server gestoppt. Auf dem LIVE-Host. Auf dem, der die Academy ausliefert. Aus einem kurzen Freeze, der sich vermutlich von selbst oder mit einem sauberen Neustart erledigt hätte, wurde ein Server, der aus war und im Notfall-Modus festhing. Der Ausfall war danach länger, nicht kürzer. ## Der Bot hat das Falsche mit voller Überzeugung getan Das Fiese daran ist, dass jeder einzelne Schritt für sich plausibel aussah. Server hängt, also reset. Kommt nicht hoch, also Rescue-System an. Das sind Sachen, die ein Mensch im Panikmodus auch machen würde. Genau deshalb ist es so gefährlich, wenn eine KI sie ohne Bremse aneinanderreiht. Als ich mir hinterher das Log der virtuellen Maschine angeschaut habe, war da nichts. Kein Speicherfehler, kein Kernel-Panic, keine kaputte Platte. Sauber. Das heißt: das Problem lag gar nicht bei uns, sondern beim Host-Node des Anbieters. Das konnten wir von außen gar nicht reparieren. Jede destruktive Aktion, die der Bot gefeuert hat, hat die Lage nur verschlimmert, weil die eigentliche Ursache eine Ebene tiefer lag, an die wir nicht rankamen. Der Bot hatte ein Werkzeug in der Hand, mit dem er echten Schaden anrichten konnte, und keine Ahnung, ob er es benutzen sollte. Das ist die schlechteste Kombination. ## Warum ich das überhaupt so gebaut hatte Kurz die ehrliche Selbstkritik. Ich habe dem Bot Power-Aktionen gegeben, weil ich dachte, im Notfall soll er schnell handeln können. Klingt vernünftig. Ich hab dabei nur den Fall "kleiner Fehler, den er glattbuegelt" gedacht und nicht den Fall "großer Fehler, den er verzehnfacht". Autonomie fühlt sich immer gut an, solange nichts schiefgeht. Der zweite Fehler war, dass Diagnose und Handlung nicht getrennt waren. Der Bot durfte im selben Atemzug feststellen "Server antwortet nicht" und "also fahr ihn runter". Zwischen diesen beiden Schritten gehört eine Wand. ## Die Bremse, die jetzt drin ist Wir haben in Claude Code einen sogenannten Hook eingebaut. Ein Hook ist ein kleines Skript, das vor bestimmten Aktionen automatisch läuft und sie erlauben oder blockieren kann. Bei uns sitzt er jetzt vor jedem Kommando und schaut, ob es eine gefährliche Server-Aktion ist. ```bash # PreToolUse-Hook: destruktive Cloud-Aktionen blocken # poweroff, shutdown, reset, rescue, rebuild -> BLOCK # poweron, reboot, status abfragen -> ERLAUBT if echo "$CMD" | grep -Eq 'poweroff|shutdown|reset|enable_rescue|rebuild'; then if [ "$HETZNER_OK" != "1" ]; then echo "BLOCKIERT: destruktive Server-Aktion braucht explizite Freigabe." exit 1 fi fi ``` Der Trick ist die Auswahl, was blockiert wird und was nicht. Alles, was einen Server abwürgt oder zurechtstutzt, ist gesperrt. Was einen Server hochbringt oder nur seinen Status abfragt, bleibt erlaubt. Der Bot kann also weiter diagnostizieren und einen abgestürzten Server wieder anschalten. Er kann nur keinen laufenden mehr hinrichten. Und wenn wirklich mal ein harter Reset nötig ist, geht das über eine bewusste Freigabe, die ich per Hand setze. Dazu kam ein Runbook mit einer einzigen, langweiligen Reihenfolge. Erst lesen. Dann nur mit Nur-Lese-Befehlen diagnostizieren. Dann maximal ein sauberer Neustart. Reicht der nicht, Hände weg und einen Menschen holen. Kein Held sein. ## Was du daraus mitnehmen kannst Wenn du eine KI Aufgaben erledigen lässt, ist die spannende Frage nicht "wie autonom kann sie sein", sondern "wo darf sie ohne Rückfrage nicht weiter". Alltägliches, Umkehrbares, Lesendes darf laufen. Alles, was nicht mehr rückgängig zu machen ist, braucht einen Menschen im Kreis. Das ist keine Bevormundung der KI, das ist die gleiche Trennung, die man in jedem Cockpit hat. Konkret drei Sachen: Trenne Diagnose von Handlung, sonst begründet sich ein Fehlgriff selbst. Sperre destruktive Aktionen per Default und mach sie zur bewussten Ausnahme, nicht andersrum. Und schreib ein stures Runbook für den Notfall, damit im Ernstfall nicht improvisiert wird. Wie so ein Guardrail als Hook aussieht und wann er feuert, zeigen wir Schritt für Schritt im Playbook [Auto-Mode in Claude Code sicher nutzen](/playbooks/claude-code-auto-mode-sicher-nutzen). Und warum ein Mensch an den richtigen Stellen im Ablauf sitzen muss, steckt in der Lektion [Human in the Loop](/levels/5/human-in-the-loop) aus Level 5. Die offizielle Referenz zu den Hook-Events findest du in der [Claude Code Hooks-Doku](https://code.claude.com/docs/en/hooks). Der Freeze hat uns eine Stunde gekostet. Der Bot ohne Bremse hätte daraus einen halben Tag gemacht. Die Bremse hat ihn ein paar Zeilen Skript gekostet. Das ist ein guter Tausch.