Betriebshandbuch

Diese Seite beschreibt, wie die DQC Platform in einer Private-Cloud- oder On-Premises-Installation betrieben wird: die wiederkehrenden Abläufe, das Vorgehen nach einer Störung und die Einstellungen, mit denen eine Installation gehärtet wird.

Aufgabenteilung: Sie betreiben Cluster, Datenbank und Netzwerk; DQC stellt die Container-Images, die Deployment-Vorlagen und den Support bereit. Alles Folgende läuft in Ihrer Infrastruktur und unter Ihrem Change-Management.

Standardabläufe

Ablauf	Häufigkeit	Was passiert
Erstinstallation	Einmalig, je Umgebung	Werkzeuge und Konfiguration prüfen, Manifeste rendern, das Ergebnis des Dry-Runs durchsehen, dann ausrollen. Die Reihenfolge ist NATS, Kratos, Oathkeeper, Keto, die Plattform-Manifeste und - im Self-hosted-Modus - das KI-Gateway.
Konfigurationsänderung	Bei Bedarf	values.yaml ändern, erneut rendern, die gerenderten Manifeste vergleichen, dann anwenden. Konfiguration und Secrets werden nie direkt im Cluster bearbeitet.
Versionsupdate	Je Release	Die neuen Image-Tags in values.yaml setzen und erneut ausrollen. Zustandslose Komponenten werden im Rolling Update ersetzt; das Datenbankschema wird beim Start der API automatisch migriert.
Datensicherung	Täglich, automatisiert	Die Plattform-Datenbank mit den Bordmitteln Ihrer PostgreSQL-Installation sichern (Point-in-Time-Recovery, Snapshots), die persistenten Volumes bzw. den Object Storage mit den Mechanismen Ihrer Plattform. Vor jeder Änderung am Deployment zusätzlich einen Release-Snapshot ziehen.
Zustandsprüfung	Laufend sowie nach jeder Änderung	Jede Komponente antwortet auf einem Health-Endpunkt, den Kubernetes für Liveness- und Readiness-Probes nutzt. Nach einer Änderung prüfen, ob die Workloads qserviceapi, qserviceworker, qui, kratos, oathkeeper, keto, nats - und im Self-hosted-Modus bifrost - laufen.
Benutzerverwaltung	Bei Bedarf	Einladungen, Rollen und Gruppen werden in den Einstellungen der Plattform verwaltet, nicht im Cluster. Wo SSO im Einsatz ist, bleibt der Identity Provider das führende System.
Störung und Support	Im Ereignisfall	Symptom, betroffene Komponente und die einschlägigen Container-Logs sammeln, dann den DQC-Support kontaktieren. Bei einer fehlerhaften Änderung zuerst zurückrollen, danach analysieren.

Die Deployment-Vorlagen automatisieren diese Abläufe. Die Kommandos werden im Verzeichnis Ihrer Installation ausgeführt:

make check-config    # validate values.yaml and the secrets
make render          # render the manifests from the templates
make dry-run         # assemble complete-manifests.yaml, deploy nothing
make deploy          # roll out (charts first, then the platform manifests)
make update          # apply changed platform manifests only
make status          # state of the deployed components
make backup          # snapshot of the current release state
make rollback COMPONENT=<name>   # roll a single component back

In einem GitOps-Setup erfolgt der Render-Schritt einmal je Änderung beim Erstellen; der Cluster synchronisiert ausschließlich die gerenderten Manifeste.

Wiederanlauf- und Wiederherstellungsplan

Die Komponenten starten in einer festen Reihenfolge, weil jede auf der vorherigen aufbaut: Message-Bus, Identität, Access-Proxy, Autorisierung, Plattformdienste und zuletzt das KI-Gateway. Ein vollständiger Wiederanlauf folgt derselben Reihenfolge.

Szenario	Vorgehen
Einzelner Pod oder Knoten fällt aus	Kubernetes startet den Pod neu und plant ihn neu ein. Die zustandslosen Komponenten benötigen keinen manuellen Schritt; laufende Prüfungen werden über den Message-Bus wieder aufgenommen.
Fehlerhaftes Update	Die betroffene Komponente auf das vorherige Release zurückrollen, danach aus der letzten funktionierenden Konfiguration erneut rendern und anwenden.
Plattform-Datenbank nicht verfügbar	API und Worker können keine Anfragen bedienen. Die Datenbank aus der Sicherung wiederherstellen oder auf den Standby umschalten, danach API und Worker neu starten. Das Schema wird beim Start automatisch geprüft und migriert.
Identitäts- oder Autorisierungsdienst nicht verfügbar	Die Anmeldung schlägt fehl, während der Rest der Plattform weiterläuft. Kratos, Oathkeeper und Keto in dieser Reihenfolge neu starten; Keto lädt seine Namespace-Konfiguration beim Start neu.
KI-Gateway nicht verfügbar	Nur die KI-Funktionen fallen aus; Prüfungen, Profiling, Exporte und Alarme sind nicht betroffen. Endpunkt, Schlüssel und - in abgeschotteten Netzen - Proxy und CA-Bundle prüfen.
Vollständiger Verlust der Umgebung	Den Cluster neu bereitstellen, Datenbank und persistente Volumes aus der Sicherung wiederherstellen, danach aus der versionierten Konfiguration ausrollen. Wiederanlaufzeit und tolerierbarer Datenverlust ergeben sich aus Ihrem Sicherungsregime, nicht aus der Plattform.

Vor jedem Eingriff: einen Snapshot des aktuellen Zustands ziehen, um dorthin zurückkehren zu können.

make backup                      # snapshot the current release state
make rollback COMPONENT=keto     # roll a single component back
make render && make update-all   # re-apply from the known-good configuration

Härtungsleitfaden

Bereich	Empfehlung
Transport	TLS 1.2 oder 1.3 am Ingress terminieren und einfaches HTTP umleiten. Die Zertifikate stammen entweder von cert-manager oder aus Ihrer eigenen Zertifikatsverwaltung.
Netzwerk	Interner Verkehr verbleibt im Cluster; nach außen ist ein einziger Ingress-Endpunkt exponiert. Cloud-Datenbanken über private Endpunkte anbinden und ausgehenden LLM-Verkehr über Ihren Proxy führen, wo einer vorgeschrieben ist.
Secrets	Zugangsdaten gehören in Kubernetes Secrets oder einen externen Secret Store, nie in die Konfigurationsdatei und nie in die Versionsverwaltung. Die Konfiguration referenziert sie über Umgebungsvariablen.
Container	Alle Komponenten laufen ohne Root-Rechte und lassen sich auf eine feste User-ID festlegen, wie es ein restriktiver Security Context - etwa OpenShift restricted-v2 - verlangt.
Images	Die Images aus der zugriffsgeschützten Registry von DQC beziehen oder in eine eigene Registry spiegeln und statt eines beweglichen Tags auf ein konkretes Release festlegen.
Datenbankkonten	Der Plattform einen eigenen Datenbankbenutzer geben und jeder angebundenen Quelle ein Konto, das nur die für die Prüfungen nötigen Leserechte hat. Für Datenbankverbindungen TLS verlangen.
Identitäten	Wo möglich Single Sign-on nutzen und Mehr-Faktor-Authentifizierung erzwingen - die Plattform unterstützt TOTP ebenso wie WebAuthn. API-Token regelmäßig überprüfen.
Berechtigungen	Tenant-Berechtigungen sparsam vergeben und den Zugriff auf Konnektoren, Tabellen und Regelsätze über Objektrechte steuern. Mandanten sind auf Ebene der Datenbankschemata getrennt.
Telemetrie	Fehler-Tracking und Produkt-Telemetrie sind optional und lassen sich vollständig abschalten; Logs und Traces verbleiben dann in Ihrem eigenen Observability-Stack.

Überwachung

Alle Komponenten schreiben strukturierte Logs auf die Standardausgabe und können Traces und Metriken über OpenTelemetry an Ihren eigenen Collector exportieren.
Liveness- und Readiness-Probes sind Bestandteil jedes Workloads, sodass Kubernetes eine nicht mehr antwortende Komponente neu startet.
Alarmierung lohnt sich auf: nicht bereite Pods, Datenbankverbindungen und Plattenbelegung, fehlgeschlagene geplante Prüfungen sowie Fehlerraten am KI-Gateway.