Production Hardening: Der langweilige Teil, über den niemand spricht

Das Kassenbon-Scanner-Side-Projekt war feature-complete. Es lief auf meinem Rechner. Die OCR-Pipeline erreichte 97,78 % Konfidenz. Das Frontend fühlte sich flüssig an. Das Backend behandelte Edge-Cases. Ich war stolz drauf.

Es war weit davon entfernt, produktionsreif zu sein.

Das ist die Lücke, über die in der KI-Beschleunigungsdebatte niemand spricht. Alle feiern, wie schnell KI Features baut. Niemand feiert die mühsame Session, in der man alles nachrüstet, was eine öffentliche App davor schützt, missbraucht, kompromittiert oder unter echter Last in die Knie gezwungen zu werden.

Ich habe eine ganze Session nur mit Production Hardening verbracht. Das ist, was ich dabei wirklich eingebaut habe.

Was „Feature Complete” fehlt

Rate Limiting. Jeder öffentliche Endpunkt war völlig offen. Jemand mit einem Skript — ob Angreifer oder einfach neugierige Person — konnte den OCR-Endpunkt unbegrenzt hammern. Ich habe IP-basierte Rate Limits eingebaut, verschiedene Stufen für authentifizierte vs. anonyme Nutzer, und einen vernünftigen Cooldown bei wiederholten Fehlern.

Zweistufige CORS-Konfiguration. Das Frontend brauchte CORS-Zugriff. Aber die API hatte auch interne Endpunkte, die von einem Browser aus nie erreichbar sein sollten. Diese gleich zu behandeln war faul. Eine saubere Konfiguration bedeutet separate CORS-Regeln für die öffentlichen Frontend-Routen und die internen API-Routen.

Fehlermeldungs-Sanitisierung. Die Standard-Fehlerbehandlung ließ Stack-Traces in API-Antworten durchsickern. In der Entwicklung nützlich. In Produktion eine Einladung. Jede unbehandelte Exception verriet der Welt genau, welche Bibliotheksversion lief, welcher Dateipfad geworfen hatte und manchmal welche Datenbankspalte nicht existierte. Alles auf generische Fehlercodes mit internem Logging umgestellt.

Graceful Shutdown. Der Docker-Container starb bei einem Kill-Signal mitten im Request. Keine Drain-Phase, keine Connection-Bereinigung — einfach sofortiger Tod. Bei einem Kubernetes-Deployment bedeutet das dropped Requests bei jedem Deploy. Shutdown-Hooks eingebaut, die keine neuen Anfragen mehr annehmen, laufende Requests zu Ende bringen und dann sauber beenden.

Gzip-Komprimierung. Kassenbon-Bilder und OCR-Response-Payloads gingen unkomprimiert über die Leitung. Im Nachhinein offensichtlich. Compression-Middleware hinzugefügt und sofort deutlich kleinere Response-Größen erreicht.

Wegwerf-E-Mail-Blockliste. Die App hatte User-Registrierung. Ohne Blockliste kann jemand in Minuten 500 Accounts mit Einweg-Adressen anlegen. Eine Blockliste mit 121.000 bekannten Wegwerf-E-Mail-Domains eingebaut. Nicht perfekt — aber der Aufwand für Missbrauch steigt erheblich.

Basis-Prometheus-Monitoring. Ich hatte Logs. Ich hatte keine Metriken. Das ist ein Unterschied. Logs sagen dir, was passiert ist. Metriken sagen dir, ob Dinge in die falsche Richtung driften — bevor sie brechen. Standard-Instrumentierung eingebaut: Request-Counts, Latenz-Histogramme, Fehlerraten, aktive Verbindungen.

OpenAPI-Dokumentation. Streng genommen kein Hardening-Thema, aber Teil davon, einen Service nach außen lesbar zu machen — auch für mich in der Zukunft. Dokumentation aus den tatsächlichen Route-Definitionen generiert, statt separate Docs zu pflegen, die unweigerlich auseinanderdriften.

Dann kamen die Docker-Probleme

Der containerisierte Build brach sofort zusammen. ES-Modul-Auflösung schlug in 19 Dateien fehl. Lokal lief die App problemlos, weil die lokale Node-Version nachsichtig war; das Docker-Image nutzte eine andere Version, die streng war. Jede Datei gesucht, Modul-Syntax korrigiert, neu gebaut.

Dann lief der Demo-Server aus Festplattenspeicher. 14 Gigabyte angesammelte Docker-Image-Layer, alte Build-Artefakte und Log-Dateien. Die Anwendung scheiterte lautlos, weil sie keine temporären Dateien schreiben konnte. In den Logs stand nichts, das erklärt hätte, warum OCR leere Ergebnisse lieferte — nur generische I/O-Fehler. Sobald wir es auf den vollen Disk zurückverfolgt hatten, war es offensichtlich. Aber die Diagnose hat Zeit gekostet.

Der Teil, der wirklich zählt

Was mir in dieser ganzen Session aufgefallen ist: Der KI-Agent hat jede einzelne dieser Aufgaben kompetent erledigt. Rate Limiting — fertig. CORS-Setup — fertig. Wegwerf-E-Mail-Integration — fertig. Prometheus-Metriken — fertig. Docker-Fixes — fertig.

Aber der Agent hat nie von sich aus gesagt: „Hey, du solltest Rate Limiting hinzufügen.” Oder: „Du leakst Stack-Traces.” Oder: „Dein Docker-Container fährt nicht graceful herunter.”

Ich musste wissen, wonach ich fragen muss.

Jeder Punkt auf dieser Liste kam von mir, weil ich weiß, wie ein produktionsreifes Backend aussieht. Die KI hat ausgeführt. Ich habe die Richtung vorgegeben. Das technische Urteilsvermögen — das Bewusstsein, dass diese Dinge existieren und wichtig sind — ist nie auf den Agenten übergegangen.

Das ist der Teil der KI-Beschleunigungsgeschichte, der weggelassen wird. Die Geschwindigkeit ist real. Ein Junior ohne diese mentale Checkliste würde Wochen brauchen für das, was ich in einer Session hinzugefügt habe. Aber er würde es ohne jemanden, der ihm sagt, wonach er suchen soll, gar nicht erst hinzufügen.

Was das für dich bedeutet

Wenn du mit KI-Agenten baust, pflege deine eigene Production-Readiness-Checkliste. Nicht als bürokratische Übung, sondern als Wissensartefakt. Was du aus vergangenen Produktionsvorfällen, Code-Reviews und Postmortems gelernt hast — dieses Wissen lebt in deinem Kopf. Die KI hat es nicht, bis du es explizit machst.

Meine aktuelle Checkliste deckt ab: Authentifizierung und Autorisierung, Input-Validierung, Rate Limiting, Fehlerbehandlung, Logging und Monitoring, Graceful Shutdown, Dependency Security, CORS- und CSP-Header, Datensicherung und Wiederherstellung.

Jeder Punkt steht für etwas, das irgendwann in Produktion kaputtgegangen ist — bei mir oder bei jemand anderem. Die KI wird diese Lektionen nicht für dich entdecken. Du musst sie mitbringen.

Die Werkzeuge sind schneller als je zuvor. Das Urteilsvermögen kostet immer noch Erfahrung. (Der größere Kontext — wie eine komplette App in einer Session gebaut wird und CORS beim ersten Live-Deployment fehlt — gibt es in $187 und 16 Stunden.)