Production-Audit: Ist dein Projekt bereit für echte Nutzer?

Was ein Production-Audit ist, einfach erklärt

Du hast zu Hause einen Kuchen gebacken. Für dich. Schmeckt - du bist zufrieden. Und jetzt stell dir vor: Morgen platzen 300 Gäste rein. Jedem ein Stück servieren, fünf haben eine Nussallergie, drei wollen den ganzen Kuchen mitnehmen, und einer fragt seelenruhig nach einer Quittung.

Spürst du den Unterschied? „Kuchen zu Hause gebacken“ und „300 Leute satt gemacht“ sind zwei verschiedene Berufe. Das Erste ist dein Projekt auf dem Laptop. Das Zweite ist der Prod (production): der Moment, in dem fremde, unbekannte und völlig unberechenbare Leute anfangen, es zu benutzen.

Warum „läuft bei mir“ nicht gleich „startklar“ ist

Du bist Vibecoder. Hast was zusammengebaut, es läuft, und es juckt dir in den Fingern, es der Welt zu zeigen - online stellen, den Link an Freunde schicken, Werbung anwerfen. Der süßeste Moment. Und der gefährlichste. Denn genau hier kommt am häufigsten der Schlag ins Gesicht:

• jemand hat sich unter einem fremden Account eingeloggt und blättert seelenruhig durch fremde Daten;
• ein Mensch hat bezahlt, aber die Ware kam nicht an - oder kam doppelt, und das Geld wurde zweimal abgebucht;
• du hast ein Update ausgerollt, alles ist abgeschmiert, und zum Zurückrollen gibts nichts;
• das Formular läuft bei dir perfekt, aber am Handy kommt man an den Button einfach nicht ran.

Ein Startklarheits-Audit ist keine Paranoia. Es ist wie das Auto vor einer langen Fahrt zu checken: einen platten Reifen findet man lieber auf dem Parkplatz als auf der Autobahn im strömenden Regen.

Prod Prod (production) - die „scharfe“ Version deines Projekts, die echte Leute benutzen. Das Gegenteil davon ist dein lokaler Rechner oder eine Testumgebung, wo du folgenlos alles kaputtmachen darfst. verzeiht deutlich weniger als dein Laptop. Gute Nachricht: Die KI kann dein Projekt durch eine Startklarheits-Checkliste jagen. Du musst nur wissen, worum du bitten sollst.

Wie die KI das Startklarheits-Audit durchführt

Ein vernünftiges Audit ist kein „guck mal, ob alles okay ist“. Es ist eine strenge Reihenfolge von Prüfungen, von den billigen zu den teuren. Der Skill production-audit läuft genau so ab.

Schritt 1. Was rollen wir überhaupt in den Prod

Zuerst schaut die KI, was sich geändert hat und was auf den Live-Server geht: die letzten Änderungen, der aktuelle Branch, wodurch sich diese Version von der vorherigen unterscheidet. Die Logik ist simpel - man kann nichts prüfen, was man nicht versteht.

Schritt 2. Gefahrenzonen, wo am häufigsten alles kracht

Danach geht der Agent die „Hotspots“ durch: Login und Zugriffe, Umgang mit Daten, Bezahlung, Hintergrundaufgaben, Deploy. Das sind keine zufälligen Stellen. Das sind genau die Nahtstellen, an denen Projekte wie ein Kartenhaus zusammenfallen.

Schritt 3. Kurzes Urteil: geht oder geht nicht

Kein „na ja, sieht okay aus“. Auf den Punkt: starten oder nicht. Und wenn nicht - was zuerst zu fixen ist.

Vier Zonen, wo der Prod am häufigsten umfällt

Der Skill production-audit schaut auf das Projekt durch mehrere „Linsen“. Hier sind die vier wichtigsten. Lern sie auswendig - das ist deine persönliche Startklarheits-Checkliste.

Login und Zugriff: Sicherheit der Nutzer

Der schlimmste Albtraum - ein Fremder sieht, was er nicht sehen darf. Die KI prüft: Sind öffentliche Seiten und der Admin-Bereich getrennt? Wird der Zugriff auf dem Server geprüft und nicht nach dem Prinzip „Button versteckt, passt schon“? Sind keine Secrets Secrets - Passwörter, API-Zugriffsschlüssel, Bezahl-Token. Das, was an einem geschützten Ort liegen sollte, statt direkt in den Code der Seite eingebaut zu sein, den jeder Nutzer sieht. im Code gelandet, den der Browser an jeden Beliebigen ausliefert?

Geld und Bezahlung ohne Doppelabbuchungen

Wo Zahlungen sind, ist eine Zone mit erhöhtem Risiko. Das Schlüsselwort hier ist Idempotenz Idempotenz - ein kompliziertes Wort mit simpler Bedeutung: Wenn dieselbe Aktion versehentlich zweimal passiert, soll das Ergebnis so sein wie nach einem Mal. Eine Bestellung wurde einmal bezahlt - die Ware geht einmal raus, selbst wenn das System dreimal eine Benachrichtigung geschickt hat. . Bezahlsysteme lieben es, eine Benachrichtigung mehrfach zu schicken. Bist du darauf nicht vorbereitet - zahlt der Mensch einmal und bekommt (oder verliert) zweimal.

Daten und der Weg zurück

Die Hauptfrage: Gibt es einen Weg zurück? Ein Update hat die Datenbank verhunzt - kann man es wieder auf alt zurücksetzen? Die KI prüft, dass Datenbank-Änderungen sauber durchlaufen und dass der Rollback-Plan nicht nur Gerede ist, sondern bereitliegt.

Start bei null auf einem sauberen Server

Klingt banal, legt aber Projekte mit beneidenswerter Regelmäßigkeit lahm. Fährt das Projekt auf einem sauberen Rechner strikt nach Anleitung hoch? Bei dir ist alles über Jahre eingerichtet und hängt an deinem Gedächtnis. Ein neuer Server ist leer. Und ein Gedächtnis hat er auch nicht.

Der Rollback-Weg: die wichtigste Regel für einen sicheren Start

Wenn du aus der ganzen Lektion eine einzige Sache mitnimmst - dann diese. Starte niemals etwas, das du nicht zurückrollen kannst.

Der Rollback-Weg Rollback-Weg (rollback) - eine vorab vorbereitete Methode, das Projekt schnell in einen funktionierenden Zustand zurückzusetzen, falls die neue Version alles kaputtgemacht hat. Wie ein „Rückgängig“-Knopf, aber für eine ganze Seite. ist deine Versicherung. Jeder, der schon öfter gestartet hat, weiß eisern: früher oder später rollst du ein Update aus, und es macht etwas kaputt. Die Frage ist nicht „ob“, sondern „wann“. Und in diesem Moment entscheidet genau eines - kannst du schnell auf alt zurücksetzen.

Bereit für Menschen oder noch nicht: die Startklarheits-Checkliste

Beispiel aus dem Leben: drei Brände an einem Abend

Du hast eine Seite zum Verkauf von Stickerpacks gebaut. Alles läuft: Ware lässt sich hinzufügen, die Bezahlung geht durch, Freunde haben getestet - geil. Du wirfst Werbung an, an einem Abend kommen 200 Leute. Und schon gehts los:

1. Das Bezahlsystem hat die Zahlungsbenachrichtigung zweimal geschickt (passiert öfter, als man denkt) - und ein Käufer bekam zwei Abbuchungen. Idempotenz gabs nicht.
2. Jemand hat in der Adresszeile die Bestellnummer auf eine fremde geändert - und sah eine fremde Lieferadresse. Der Zugriff wurde nur auf der Seite geprüft, nicht auf dem Server.
3. Du hast in Panik einen „Fix“ ausgerollt, der hat den Rest auch noch kaputtgemacht - und die funktionierende Version war da längst weg. Kein Rollback.

Ein Abend - drei Brände. Und alle drei hätte die KI vorab gefunden, hättest du sie vor dem Start gefragt. So fragst du.

Führe ein Startklarheits-Audit meines Projekts für echte Nutzer durch. Glaub nicht, dass grüne Tests bedeuten, dass der Prod nicht kaputtgeht.
Prüfe der Reihe nach und sag für jeden Punkt direkt: ist es in Ordnung oder nicht.

Sicherheit. Wird der Zugriff serverseitig geprüft und nicht nur durch einen versteckten Button. Sind keine Passwörter und Schlüssel in den Code gelandet, den der Browser sieht.
Geld. Falls es eine Bezahlung gibt - was passiert, wenn die Zahlungsbenachrichtigung zweimal ankommt. Wird nicht doppelt abgebucht und die Ware nicht doppelt ausgegeben.
Daten. Lassen sich Datenbank-Änderungen zurückrollen, falls die neue Version sie kaputtmacht.
Start. Fährt das Projekt auf einem sauberen Server nach Anleitung hoch, ohne Wissen, das nur in meinem Kopf existiert.
Handy. Funktionieren die Hauptszenarien und Formulare auf dem mobilen Bildschirm.
Gib am Ende ein kurzes Urteil ab: starten oder nicht. Falls nicht - eine Liste dessen, was zuerst zu fixen ist, nach Wichtigkeit. Und zähl auf, was genau du geprüft hast: welche Dateien und Stellen.

Das Audit-Urteil: geht, geht nicht oder mit Vorbehalten

Ein gutes Audit endet mit einer Entscheidung, nicht mit einem nachdenklichen Seufzen. Der Skill production-audit nutzt dafür eine einfache Skala - übersetzen wir sie ins Menschliche:

• Blockiert - starte nicht, bis du das Wichtigste gefixt hast (keine Zugriffsprüfung auf fremde Daten, die Bezahlung kann doppelt abbuchen, kein Rollback).
• Riskant - starte vorsichtig, erst mal nur für eine kleine Gruppe, nicht gleich für das ganze Publikum.
• Mit Vorbehalten möglich - starte, wenn du die übrigen kleinen Risiken bewusst in Kauf nimmst.
• Zuversichtlich - keine offensichtlichen Blocker in Sicht.

Häufige Fehler beim Start in den Prod

• Grüne Tests für Startklarheit halten. Tests prüfen, ob der Code das Gewollte macht. Das Audit prüft, ob der Prod unter echten Leuten nicht umfällt. Verschiedene Fragen.
• Ohne Rollback starten. Früher oder später geht etwas kaputt. Ohne „Zurück auf alt“-Knopf ist das schon eine Katastrophe und nicht nur ein Ärgernis.
• Den Zugriff nur auf der Seite prüfen. Einen Button verstecken ist kein Schutz, sondern ein Feigenblatt. Der Zugriff muss auf dem Server geprüft werden.
• Secrets in den Code einbauen. Passwörter und Schlüssel im Code der Seite sind für jeden sichtbar. Ihr Platz ist ein geschützter Speicher, nicht das Schaufenster.
• Idempotenz bei der Bezahlung vergessen. Eine doppelte Zahlungsbenachrichtigung bedeutet eine doppelte Abbuchung, wenn das Projekt darauf nicht vorbereitet ist.
• Nur auf dem eigenen großen Bildschirm testen. Die Hälfte der Leute kommt vom Handy. Ein Formular, das man dort nicht drücken kann, füllt keiner aus.
• Ein Urteil ohne Liste des Geprüften akzeptieren. Hat die KI nicht gesagt, was genau sie angeschaut hat - dann ist das kein Audit, sondern eine Vermutung mit selbstsicherem Gesicht.