Checkliste für die Produktionsreife

Verwenden Sie diese Checkliste als Freigabeprotokoll, nicht als Liste, die ein Operator stillschweigend abhakt. Der Dienstverantwortliche legt die geschäftskritischen Pfade fest, der Plattformverantwortliche weist die Wiederherstellung der Infrastruktur nach, der Sicherheitsverantwortliche gibt Identität und Erreichbarkeit frei, und die Anwendungsverantwortlichen weisen Daten und Rollback nach. Weisen Sie jeden Abschnitt vor der Bereitschaftsprüfung zu.

Eine produktionsreife Installation hat bekannte Verantwortliche, getestete Wiederherstellung, beobachtbare Kundenpfade und Belege dafür, dass häufige Fehler keine Improvisation auf dem Host erfordern. Ein erfolgreicher Build oder grüne Karten in der Oberfläche sind notwendig, aber nicht ausreichend.

Control Plane

• Kanonische HTTPS-URL, Cookies, WebSockets und OAuth-Weiterleitungen funktionieren.
• PostgreSQL, Redis, die Identität von Relay, Verschlüsselungsschlüssel und hochgeladene Artefakte sind persistent und gesichert.
• Relay besitzt den öffentlichen Port 9443/tcp und erholt sich nach einem Neustart.
• Mindestens zwei Relays laufen auf anderen Hosts als dem Opfield-Host, in unterschiedlichen Fehlerdomänen (Host, Stromversorgung, Netzwerkpfad); siehe Wie viele Relays.
• Lizenzzustand und benötigter Leistungsumfang sind fehlerfrei.

Identität

• Es gibt zwei unabhängige Wiederherstellungswege für Administratoren.
• MFA und Gruppen-Scopes sind mit echten Benutzern ohne Administratorrechte getestet.
• API-, OAuth- und MCP-Zugangsdaten haben minimale Rechte und sind erfasst.

Verwaltete Nodes

• Jede Rolle meldet die erwarteten Fähigkeiten und den Update-Kanal.
• Offline-Verhalten, Daemon-Neustart, Node-Neustart und erneuter Verbindungsaufbau sind getestet.
• Firewalls erlauben nur dokumentierten Datenverkehr.
• Storage Nodes erreichen ghcr.io, und ein LXC-Storage-Node hat einen Pool von Loop-Devices, der für jede verwaltete Instanz und jedes gleichzeitige Backup dimensioniert ist.
• Docker Nodes, die Availability-Leases halten, führen den Lease-Watchdog aus und erreichen jedes Relay.

Workloads und Daten

• Deployment, Health Check, Rollback, Logs, Backup und Wiederherstellung sind nachgewiesen.
• Bindings verwalteter Datenbanken überstehen Tests mit Neustarts von Opfield, Relay, Daemon und Node sowie Neuerstellungen des Workloads.
• In der Workload-Konfiguration sind keine Zugangsdaten von Besitzern vorhanden.

Kundenverkehr

• DNS, TLS-Verlängerung, Ingress-Migration, Wartungsmodus und Upstream-Ausfall sind getestet.
• Benachrichtigungen und die Kommunikation über die Statusseite erreichen ihre vorgesehenen Empfänger.

Betrieb

• Runbooks für Update und Rollback haben Verantwortliche.
• Alarme für Festplatte, Zertifikate, Datenbanken, Warteschlangen, Relay und Nodes sind aktiv.
• Eine Vorfallübung wurde abgeschlossen, ohne sich auf undokumentierte Shell-Änderungen zu verlassen.

Belegpaket

Geben Sie die Produktion nicht allein aufgrund einer Sichtprüfung frei. Bewahren Sie Belege auf für:

• Installationsversion und Image-Digests;
• abgeschlossenes Backup und einen aktuellen Wiederherstellungstest;
• externe Prüfung von DNS, TLS und HTTP;
• Berechtigungstests ohne Administratorrechte;
• Tests zu Neustart und erneutem Verbindungsaufbau von Nodes für jede bereitgestellte Rolle;
• das Neustartverhalten von Opfield, Relay, Daemon und Workload;
• Abfrageergebnisse von Datenbank-Bindings vor und nach einer Neuerstellung;
• Öffnen und Erholen von Alarmen und die Zustellung von Benachrichtigungen;
• eine Probe von Update und Rollback;
• offene Ausnahmen mit Verantwortlichem und Ablauf.

Go/No-Go-Entscheidung

Das Deployment ist No-Go, wenn die Wiederherstellung für Administratoren nicht getestet ist, persistente Schlüssel nicht gesichert sind, Produktionsverkehr allein vom lokalen Relay abhängt, Relay einen unbekannten Wiederherstellungsweg hat, Fehler bei Node-Fähigkeiten ignoriert werden, Kundenverkehr nicht extern geprüft werden kann oder ein Datenbank-Binding eine manuelle Reparatur von Container oder Rolle erfordert.

Eine akzeptierte vorübergehende Ausnahme muss die Auswirkung auf Kunden, die ausgleichende Kontrolle, den Verantwortlichen, die Frist und den Auslöser für ein Rollback angeben. „Funktioniert auf dem aktuellen Host“ ist kein Argument für die Produktionsreife.

Beobachtung am ersten Tag

Beobachten Sie nach dem Aktivieren des Geschäftsverkehrs den Health-Zustand der Routen, TLS, Druck auf Relay, Aktualität der Nodes, Neustarts von Workloads, Datenbankverbindungen, Festplattenwachstum, Benachrichtigungswarteschlangen und Audit-Aktivität. Halten Sie den Verantwortlichen für das Rollback während des Beobachtungsfensters verfügbar und vermeiden Sie unabhängige Plattformänderungen.

Format der Bereitschaftsprüfung

Führen Sie die Prüfung für ein benanntes Release und eine benannte Installation durch. Halten Sie für jeden Bereich pass, accepted exception oder no-go fest, dazu einen Link zum Beleg und einen Verantwortlichen. Übernehmen Sie keine Belege aus einem älteren Release, wenn sich die relevante Lebenszyklus-, Daemon-, Relay-, Datenbank- oder Ingress-Komponente geändert hat.

Verwenden Sie eine Zeile pro Abnahmeprüfung, damit ein weniger erfahrener Prüfer sehen kann, was getestet wurde, und ein erfahrener Benutzer es reproduzieren kann:

Bereich	Verantwortlicher	Durchgeführte Prüfung	Ergebnis	Beleg	Ausnahme oder Nachverfolgung
Beispiel: öffentliche Anwendung	Anwendungsteam	Externes DNS, TLS und primärer Benutzerpfad	Pass	Link zu Task, Anfrage oder Bericht	Keine

Schreiben Sie nicht nur „funktioniert“ oder „geprüft“. Der Beleg sollte die genaue Ressource, Version, den Testort, die Zeit und das erwartete Ergebnis nennen.

Beginnen Sie mit den drei Abläufen, die unmittelbare geschäftliche Auswirkungen hätten: Wiederherstellung für Administratoren, öffentlicher Kundenverkehr und Anwendungszugriff auf persistente Daten. Prüfen Sie dann unterstützende Fähigkeiten wie Builds, Pages, Benachrichtigungen, KI und optionale Integrationen danach, was die Installation tatsächlich verwenden wird. Ungetestete, ungenutzte Funktionen blockieren den Start nicht; aktivierte kritische Funktionen schon.

Mindestszenarien für die Abnahme

1. Ein neuer berechtigter Benutzer meldet sich an, schließt MFA ab und wird bei einer Ressource außerhalb seines Geltungsbereichs abgewiesen.
2. Ein unterstützter Workload wird bereitgestellt, beobachtet, neu gestartet und zurückgesetzt, ohne Änderungen am Host.
3. Eine öffentliche Route wird aus einem externen Netzwerk mit dem erwarteten Zertifikat und Health-Verhalten geprüft.
4. Ein verwalteter Node trennt sich und verbindet sich erneut, ohne den Sollzustand zu verlieren.
5. Opfield startet neu, während Kunden-Workloads in ihrem dokumentierten Zustand bleiben.
6. Ein Backup wird in eine saubere, kompatible Umgebung wiederhergestellt, und die benötigten Secrets lassen sich entschlüsseln.
7. Alarme öffnen und erholen sich während eines kontrollierten Ausfalls, und der vorgesehene Empfänger erhält sie.

Die Freigabe sollte den getesteten Umfang nennen. Behaupten Sie nicht, dass das gesamte Produkt validiert ist, wenn nur eine Node-Rolle, eine Datenbank-Engine, ein Laufzeitprofil oder ein Update-Weg geprüft wurde.