Onboarding und Betrieb
Wie Teams mit gh0stcloud starten und wie laufender Betrieb aussieht.
Onboarding hängt vom Betriebsmodell ab.
Self-Service-Nutzer brauchen vor allem einen Tenant Workspace, Billing Readiness, GitOps Binding, Namespace Setup und einen ersten Deployment-Pfad. Managed-Application-Kunden brauchen eine Scope-Übergabe, damit gh0stservice versteht, was betrieben werden soll.
Self-Service-Start
Der normale Self-Service-Ablauf:
- Organization erstellen oder beitreten;
- notwendige Billing- und Tenant-Readiness-Schritte abschließen;
- Projekt und Namespace anlegen;
- GitOps-Repository verbinden;
- Storage, Services, Exposure oder Egress nur hinzufügen, wenn die Anwendung es braucht;
- Anwendungszustand über Portal und Observability prüfen.
Self-Service-Kunden besitzen Release und Laufzeitverhalten der Anwendung. Die Plattform zeigt Zustand und erzwingt Guardrails; sie ersetzt nicht die Verantwortung für die Anwendung.
Managed-Application-Start
Managed Application Onboarding beginnt mit einer Scope-Klärung:
- welche Anwendung betrieben wird;
- welche Umgebungen existieren;
- wer Releases freigibt;
- wem Anwendungscode und Credentials gehören;
- welche Backup-, Restore-, Update- und Incident-Aktionen enthalten sind;
- welche Response-Erwartungen vertraglich gelten.
Das Ergebnis sollte ein expliziter Betriebsscope sein, kein vages "alles inklusive".
Day-2-Betrieb
| Bereich | Source of Truth |
|---|---|
| Tenant-Zustand | gh0stportal und gh0stplane |
| Gewünschter Anwendungszustand | GitOps-Repository |
| Plattform-Policy und Limits | Tenant-Konfiguration und Vertrag |
| Billing und Rechnungszustand | Billing-Bereich in gh0stportal |
| Support-Scope | Vertrag, Support-Anhang und Service Scope |
Wenn eine Änderung außerhalb aktueller Policy Bounds liegt, nutzen Sie einen Change Request statt das Plattformmodell zu umgehen.
Fragen oder bereit loszulegen?
Mit uns sprechen