Auf dieser Seite
Cloud-Produktstatus
Erkennen Sie, was für einen vereinbarten Pilot dokumentiert ist, was die Cloud-Weboberfläche plant und was noch Qualifizierung oder Freigabe benötigt.
Diese Planung können Sie heute für Ihre Anfrage und das Pilotangebot verwenden. Vertragliche Leistungen gelten erst nach schriftlicher Vereinbarung.
Bevor Sie starten
Diese Seite erklärt die geplante Produktentwicklung. Sie ist weder Release-Termin noch Service Level Agreement oder Auftragsbestätigung. Maßgeblich für Ihren Leistungsumfang ist Ihr angenommenes Pilotangebot.
1. Status richtig einordnen
Die Dokumentation trennt bewusst Anleitungen für die Zeit nach einer Pilotübergabe von geplanten Funktionen. Ein dokumentierter Kubernetes-Ablauf bedeutet allein nicht, dass der zugehörige Managed Service allgemein verfügbar ist.
| Status | Bedeutung | Einordnung |
|---|---|---|
| Auf dieser Website nutzbar | Planungsanleitungen, Preisentwürfe und das Anfrageformular sind ohne Cloud-Konto verfügbar. | Workload beschreiben und Angebot anfragen. |
| Geplante Cloud-Funktion | Die Funktion gehört zur geplanten Entwicklungsrichtung, wird aber nicht als allgemein verfügbar dargestellt. | Noch keine Produktivabhängigkeit darauf aufbauen. |
| Qualifizierung erforderlich | Technischer Nachweis, Betriebserfahrung, kaufmännische Freigabe oder vertragliche Definition fehlen noch. | Vor Nutzung im Angebot bestätigen lassen. |
2. Geplanten Lieferweg verstehen
Der Cloud-Service wird in kontrollierten Stufen veröffentlicht. Jede Stufe hängt von nachgewiesenen Ergebnissen der vorherigen ab; ein bestandener Code-Review ist keine Produktivabnahme.
- 01
Bestehendes Produkt prüfen
Bereitgestellte Architektur, Identität, Datenspeicher, Routen und Betriebsverantwortung prüfen, bevor Portale zusammengeführt oder außer Betrieb genommen werden.
- 02
Kaufmännische Basis qualifizieren
Organisationsfähige Identität, gehostete Zahlung, Abonnementstatus, Berechtigungen, Angebote und korrekte Rechnungsdaten vorbereiten. Kein Zahlungsablauf gilt vor einer Ende-zu-Ende-Qualifizierung als produktiv.
- 03
Infrastruktur und Cluster-Lifecycle nachweisen
ClusterPilot-eigene Infrastruktur mit Mandantentrennung sowie nachvollziehbaren Create-, Scale-, Upgrade- und Delete-Vorgängen bereitstellen.
- 04
Konsole und Anwendungsabläufe vereinen
Cluster-, Anwendungs-, Verbrauchs-, Abrechnungs-, Organisations- und Supportansichten in einer Cloud-Konsole zusammenführen und anschließend die unterstützten Bereitstellungswege qualifizieren.
- 05
Betriebs- und Release-Gates bestehen
Vor einem breiteren Start reale Ende-zu-Ende-Nachweise, Sicherheitsprüfung, Wiederherstellungstests, Wirtschaftlichkeitsprüfung und ausdrückliche menschliche Freigabe verlangen.
3. Geplante Customer Journey verstehen
Das Zielbild beginnt auf der öffentlichen Website und endet in einer einheitlichen Betriebskonsole. Während der Pilotphase ersetzen Anfrage, Angebot und Übergabe die noch nicht qualifizierten Self-Service-Schritte.
| Bereich | Geplantes Cloud-Zielbild | Aktueller Pilotweg |
|---|---|---|
| Konto und Organisation | Self-Service-Registrierung, Login, Organisation/Workspace und Rollen. | Identität und Ansprechpartner werden in Qualifizierung und Übergabe vereinbart. |
| Tarif und Zahlung | Monatlicher oder jährlicher Tarif, gehosteter Checkout, Abonnementstatus und Kundenportal. | Eine Pilotanfrage führt zu einem individuellen Angebot; online wird keine Zahlung angenommen. |
| Infrastruktur und Cluster | Angebot, von ClusterPilot bereitgestellte Ressourcen und nachvollziehbarer Lifecycle ohne Provider-Account des Kunden. | Kapazität, Preis und unterstützte Vorgänge werden vor Bereitstellung bestätigt. |
| Anwendungen | Browserbasierte Release-Wege für ein freigegebenes OCI-Image oder ein unterstütztes YAML/Helm-Paket. | Nur Eingang, Ziel und Anwendungsumfang Ihres Piloten verwenden. |
| Betrieb | Status, Aktivitäten, Monitoring, Backups, Upgrades, Verbrauch, Abrechnung und Support in einer Browser-Arbeitsfläche. | Browseransichten und vereinbarten Supportkanal für die im Pilot qualifizierten Funktionen nutzen. |
4. Freigabegrenzen kennen
Folgende Punkte benötigen weiterhin Nachweise und ausdrückliche Freigabe: endgültige Tarifpreise und Limits, Steuern und Abrechnungsregeln, Monitoring-Abdeckung, Backup-Aufbewahrung und erfolgreiche Restores, Hochverfügbarkeit, RPO/RTO, Support-Reaktionsziele sowie ein Termin für die allgemeine Verfügbarkeit. Bis zur Bestätigung gelten sie als geplant oder angebotsspezifisch.
- ✓Preisseite als transparenten Entwurf behandeln, bis Ihr Angebot Plattform- und Infrastrukturkosten bestätigt.
- ✓Ein beobachtetes Restore-Ergebnis verlangen, bevor Backups als betrieblicher Schutz gelten.
- ✓Gemessenes Verhalten und vereinbartes Design verlangen, bevor Sie sich auf Hochverfügbarkeit oder Wiederherstellungsziele verlassen.
- ✓Abonnement-, Verbrauchs- und Rechnungsstatus erst nach bestandenen Ende-zu-Ende-Freigaben des kaufmännischen Ablaufs nutzen.
ClusterPilot Enterprise bleibt ein separates Self-Hosted-Angebot für den Betrieb in der Kundenumgebung. Die Dokumentation und die separat abgegrenzte Technical Evaluation bleiben verfügbar; sie sind kein Nachweis, dass eine Cloud-Funktion bereits geliefert wird.
Diese Anleitung gilt für Ihren vereinbarten Pilotumfang. Technische Kubernetes-Beispiele sind kein Nachweis einer allgemein verfügbaren Cloud-Funktion.