Onboarding und Betrieb
Von Erstgespräch bis Production Go-Live — typisch in 5–7 Werktagen.
gh0stcloud-Onboarding ist engineer-geführt und hat ein klares Ziel: am Ende des Prozesses läuft der erste Tenant-Workload produktiv, mit aktivem Monitoring und konfigurierten Alerts — ohne dass der Kunde eine einzige Infrastrukturkomponente anfassen musste.
Onboarding-Timeline
Phase 1: Discovery (Tag 1–2)
Was passiert:
- Erstgespräch zur Klärung von Workload-Typ, Tier-Auswahl (Starter / Growth / Enterprise) und Zeitplan
- Technisches Briefing: welche Services sollen laufen, welche Storage- und Networking-Anforderungen gibt es
- Vertragsabschluss und Package-Bestätigung
Ergebnis: Onboarding-Scope ist schriftlich festgehalten, Tenant-Org in Keycloak wird angelegt.
Phase 2: Provisionierung (Tag 1–3)
Das gh0stservice-Team provisioniert die gesamte Infrastruktur:
- Keycloak Organization mit initialen Admin-Accounts und Invite-Links
- Isolierter Tenant-Namespace in der Zielumgebung — über unser Provisioning-System automatisiert angelegt
- Secrets-Bereich in OpenBao mit initialen Credentials, ausschließlich zugänglich für deinen Namespace
- RBAC — ServiceAccounts und Bindings nach Least-Privilege-Prinzip
- Admission Policies — Namespace-Labels, Resource Quotas, NetworkPolicies automatisch aktiv
Ergebnis: Namespace ist live, Keycloak-Login funktioniert, Observability beginnt Daten zu sammeln.
Phase 3: GitOps Setup (Tag 2–5)
Dein Git-Repository wird als Flux CD-Source konfiguriert. Von diesem Moment an ist jeder Commit in deinem Repository der einzige Mechanismus, um Änderungen in den Cluster zu deployen — keine manuelle Kubectl-Interaktion, kein direkter Cluster-Zugriff.
Was passiert:
- Dein Repository wird als Flux-Source konfiguriert
- Der erste Reconcile-Zyklus wird ausgelöst und validiert
- Die Deployment-Pipeline wird end-to-end getestet
- Das Tenant-Team führt den ersten Deployment-Zyklus durch
Ergebnis: Erster Workload läuft im Cluster, Flux CD reconciliert bei jedem Commit automatisch.
Phase 4: Go-Live (Tag 5–7)
Checkliste vor Go-Live:
- Alle Workloads reconcilen erfolgreich
- Observability aktiv: Metriken, Logs und (optional) Traces sichtbar im Portal
- Billing-Attribution sichtbar im FinOps-Dashboard
- Alert-Regeln für kritische Services konfiguriert
- Tenant-Admin kann selbstständig Deployments triggern und Logs einsehen
- SLA-Tier aktiv bestätigt
Ergebnis: Produktion ist live, gh0stservice überwacht aktiv, SLA gilt ab diesem Tag.
Day-2 Betrieb
| Änderungstyp | Wie es geht |
|---|---|
| Neues Deployment / Update | Commit in Tenant-Repository → Flux CD reconciliert automatisch |
| Neue Secrets | Secret in OpenBao anlegen → ESO synchronisiert in Namespace |
| Capacity erhöhen | Ticket an gh0stservice → Quota-Update über das Provisioning-System |
| Dedicated Node buchen | Vertragserweiterung → dedizierter Bare-Metal-Server wird zugewiesen |
| Platform-Updates | gh0stservice communiziert Maintenance-Windows, zero-downtime für Tenant-Workloads |
Kein Ops-Team auf Tenant-Seite nötig
Der Tenant braucht für den normalen Betrieb:
- Zugriff auf ein Git-Repository (eigenes oder von gh0stservice bereitgestelltes)
- Grundlegendes Kubernetes/Helm-Wissen für Manifest-Erstellung
- Zugang zum gh0stportal
Kein Cluster-Admin-Zugriff, keine Infrastruktur-Kenntnisse, kein On-Call-Shift für Platform-Issues.
Fragen oder bereit loszulegen?
Mit uns sprechen