Production-Readiness-Checkliste: 12 Fragen, die erfahrene Teams im Kopf haben

Es gibt einen Beitragstyp, den man im Netz oft findet: die Production-Readiness-Checkliste, die man vor dem Go-live durchgeht und abhakt. In der Praxis habe ich das so gut wie nie erlebt. Deployments laufen aus Erfahrung, aus Gewohnheit und aus dem, was beim letzten Ausfall wehgetan hat. Es gibt festgeschriebene Prozesse — Freigaben, Wartungsfenster, ein Vier-Augen-Prinzip —, aber keine Liste, die jemand jedes Mal von oben nach unten abarbeitet.

Das ist auch kein Zeichen von Unprofessionalität. Die Situation ist bei jedem Release anders, und eine Liste, die alle Situationen abdecken will, wird nach dem dritten Mal ignoriert. Nützlich sind diese Fragen an zwei anderen Stellen: früh, wenn die Architektur entsteht und die Antworten noch billig sind, und danach, wenn etwas schiefgegangen ist und man wissen will, welche Frage man sich hätte stellen sollen.

So sind die folgenden zwölf Fragen gemeint. Nicht als Abnahme, sondern als das, was erfahrene Leute ohnehin im Kopf haben — aufgeschrieben, damit auch die es haben, die noch nicht dabei waren.

1. Observability: Was sehen wir, wenn etwas schiefgeht?

Ohne Logs, Metriken und Traces ist ein Incident ein Ratespiel. Die Frage ist nicht, ob es Fehler gibt, sondern ob das Team sie schnell findet.

• Gibt es zentrale Logs mit Korrelations-IDs? Anfragen über mehrere Services hinweg müssen nachvollziehbar sein.
• Welche Metriken werden überwacht? Nicht nur CPU und RAM, sondern Geschäftsmetriken wie Fehlerraten, Wartezeiten, Queue-Längen.
• Gibt es sinnvolle Alerts? Ein Alarm, der ständig feuert, wird ignoriert. Ein Alarm, der niemanden erreicht, ist wertlos.

Wenn Sie nur eine dieser Fragen beantworten können, dann die mittlere. Ein Team, das die Geschäftsmetrik seines Systems kennt, merkt einen Ausfall, bevor der Kunde anruft. Ein Team, das nur Infrastrukturmetriken hat, merkt ihn danach.

2. Betrieb: Wer kümmert sich um laufende Probleme?

Ein System, das niemandem gehört, veraltet und versickert. Vor dem Go-live muss klar sein, wer den Betrieb übernimmt.

• Wer ist der erste Ansprechpartner bei einem Incident? Nicht eine Rolle, sondern ein Name.
• Gibt es ein Runbook für die wahrscheinlichsten Fehler? Das wichtigste Dokument ist nicht die Architektur, sondern die Anleitung für den nächsten Ausfall.
• Ist der Rollbackpfad getestet? Ein Rollback, der nur theoretisch funktioniert, ist kein Rollback.
• Können Sie nach einem Vorfall rekonstruieren, was passiert ist — oder nur, was jetzt gilt? Systeme, die ausschließlich den aktuellen Zustand speichern, können auf die Frage „wie kam es dazu" nicht antworten. Wie teuer das wird, zeigt dieses Praxisbeispiel aus der Auftragsabwicklung.

Die entscheidende Frage ist die dritte. Ein getesteter Rollback macht aus jedem Deployment eine umkehrbare Entscheidung — und umkehrbare Entscheidungen darf man schneller treffen.

3. Sicherheit: Ist das System abwehrtauglich?

Sicherheit ist kein einmaliger Check, sondern eine Eigenschaft, die mit dem Betrieb wächst.

• Sind Secrets getrennt vom Code und rotierbar? Keine Passwörter in Repositories, keine langlebigen Keys ohne Plan.
• Gibt es einen Patch-Prozess für kritische Abhängigkeiten? Wenn eine CVE bekannt wird, muss klar sein, wer reagiert und wie schnell.
• Ändert dieses Release, wer was sehen oder tun darf — und merkt es jemand? Mehr gehört zum Zugriffsmodell nicht in eine Deployment-Betrachtung. Wie Rollen, Mandanten und Token strukturell sauber werden, ist eine Architekturfrage; dazu steht mehr in Multi-Tenancy mit Keycloak.

Die dritte Frage wird am häufigsten übersehen, weil Berechtigungsänderungen selten im Changelog auftauchen. Sie sind aber die einzige Sicherheitsänderung, die ein einzelnes Release wirklich einführen kann.

4. Organisation: Wer trägt die Verantwortung?

Technische Readiness reicht nicht, wenn die Organisation nicht bereit ist.

• Wer entscheidet nach dem Go-live über Änderungen? Klare Befugnis verhindert, dass jede Kleinigkeit durch mehrere Gremien läuft.
• Wer vertritt das System im Fachbereich? Adoption braucht einen Namen, nicht eine Rolle.
• Gibt es einen klaren Übergabeplan von Projekt zu Betrieb? Ein Datum auf dem Papier reicht nicht; es braucht gemeinsame Zeit, Dokumentation und getestete Prozesse.

Wenn hier nur eine Frage beantwortet ist, sollte es die erste sein. Alles andere lässt sich nachholen; eine ungeklärte Entscheidungsbefugnis blockiert dagegen jede Korrektur, die nach dem Go-live nötig wird. Warum das so ist, steht in Ownership statt Rollen.

Wie diese Fragen tatsächlich nützlich werden

Nicht als Formular. Zwei Anwendungen funktionieren:

In der Architekturphase. Wenn geklärt wird, wie das System aussehen soll, sind diese Antworten fast kostenlos. Sechs Wochen vor dem Go-live kosten dieselben Antworten Umbauten. Deshalb gehen wir sie am Anfang durch, nicht am Ende.

Nach einem Vorfall. Ein Ausfall ist der einzige Moment, in dem eine Organisation bereit ist, ehrlich über Betriebsfragen zu reden. Dann ist die Liste keine Bürokratie, sondern eine Landkarte: Welche dieser zwölf Fragen hätte uns gewarnt?

Unser Platform- & Production-Readiness-Paket setzt genau dort an — nicht als Abnahme am Ende, sondern als Begleitung von der Architektur bis zur Übergabe in den Betrieb.

Wann das nicht passt

Für Prototypen, Machbarkeitsstudien und interne Werkzeuge, die bewusst kurzlebig sind, ist das Überbau. Auch wenn ein Team seit Jahren dasselbe System deployt und die Antworten längst kennt, bringt eine schriftliche Liste nichts — dort ist der Nutzen höchstens, sie einmal aufzuschreiben, bevor die Person geht, die alles weiß.

Nicht passend ist es auch als reine Kapazitätsfrage. Wer jemanden sucht, der die Liste stellvertretend abarbeitet, kauft ein Dokument, kein belastbares System.

Kurzfassung

Niemand hakt vor dem Deployment eine Checkliste ab, und das muss auch nicht sein. Die zwölf Fragen zu Observability, Betrieb, Sicherheit und Organisation sind ein Denkwerkzeug für zwei Momente: wenn die Architektur entsteht und wenn etwas schiefgegangen ist. Wer sie dann stellt, vermeidet die klassische Falle — ein System, das technisch live ist, aber organisatorisch nirgendwo ankommt.

Wenn Sie prüfen wollen, was Ihr System heute tatsächlich belegen kann: Der Nachweis-Check stellt zehn Fragen dazu. Den größeren Rahmen — von NIS2 bis EU AI Act — sammeln wir unter Nachweisbarkeit.