Betriebsmodelle: Wer ist „das Plattform-Team“?¶

In dieser Dokumentation ist das Plattform-Team das Team, das die Managed Cloud Platform (MCP) betreibt: den hub, die pipelines, das Konfigurations-Repository und die Standardänderungen. Dasselbe Produkt kann auf zwei Arten betrieben werden.

	Managed service (XMMS)	Eigenbetrieb (self-managed, Plattform-Team des Kunden)
Wer ist das Plattform-Team?	Xebia Microsoft Managed Services (XMMS) im Rahmen eines managed-service-Vertrags	Das eigene Team des Kunden (oder ein anderer von ihm gewählter Partner), der die Plattform gekauft hat, um sie selbst zu betreiben
Wem gehört das Code-Repository?	XMMS. Kunden erhalten veröffentlichte Versionen über den code sync.	XMMS veröffentlicht releases; der Kunde synchronisiert und fixiert eine Version
Wem gehört das Konfigurations-Repository?	XMMS betreibt es für den Kunden, der Kunde ist wo vereinbart Reviewer oder Genehmiger	Dem Plattform-Team des Kunden
Wer führt die pipelines aus und genehmigt Pläne?	XMMS-Engineers, im Rahmen des Änderungsprozesses des Vertrags	Das Plattform-Team des Kunden
Wer aktualisiert die Plattform auf eine neue Version?	XMMS plant es mit dem Kunden (Was zu tun ist, wenn eine neue Version veröffentlicht wird)	Der Kunde entscheidet, wann er den pin verschiebt, und folgt dem Upgrade-Leitfaden
Intake für Anfragen	Der im Vertrag vereinbarte Kanal und das vereinbarte Tooling (zum Beispiel ein Ticketsystem)	Der eigene Intake des Kunden: Ticketsystem, Board oder Chat
Behandlung von Incidents und Service-Anfragen	Severities, Reaktionszeiten und support-Zeiten aus dem Vertrag	Vom Kunden definiert (Betriebsverantwortlichkeiten, Incident Management)
Azure support (Microsoft)	Laut Vertrag	Der Kunde braucht einen eigenen Azure-support-Plan
Security Officer, Identity-Team, SOC	Kunde	Kunde

Was sich nicht ändert

Das Produkt, das Konfigurationsformat, die pipelines, die Standardänderungen und der Abwärtskompatibilitäts-Vertrag sind in beiden Modellen gleich. Nur wer die Arbeit macht und über welchen Kanal unterscheidet sich.

So liest du die Seiten dieser Dokumentation¶

„Plattform-Team“ bedeutet, wer auch immer diese Rolle in deiner Situation ausfüllt. Wenn deine Organisation einen managed-service- Vertrag mit XMMS hat, lies es als XMMS. Wenn du die Plattform selbst betreibst, lies es als dein eigenes Team.
Vertragsspezifische Details (support-Zeiten, Reaktionsziele, Intake-Tool, Kontaktadressen) sind in dieser Dokumentation nie festgelegt. Sie stehen als Platzhalter wie <support channel>. Die echten Werte stehen in deinem onboarding-Dokument oder Vertrag.
Operator-Seiten (Plattform) richten sich an die Menschen, die die Plattform betreiben. Im managed Modell ist das XMMS, und der Kunde liest sie, um zu verstehen, was in seinem Auftrag geschieht. Im Eigenbetrieb sind sie das Runbook.
Nutzer-Seiten (Nutzer) sind für workload-Teams, in beiden Modellen.

Wer macht was in welchem Modell¶

flowchart LR
    subgraph consumers["Workload-Teams (Nutzer)"]
        w["Anfragen, nutzen, bauen"]
    end
    subgraph pt["Plattform-Team"]
        direction TB
        m["Managed: XMMS-Engineers"]
        s["Eigenbetrieb: Engineers des Kunden"]
    end
    subgraph xms["XMMS-Produktteam"]
        r["Releases, Upgrade-Leitfäden, release notes"]
    end
    w --> pt
    xms -->|"neue Versionen"| pt
    pt -->|"Konfiguration + pipelines"| azure["Azure: hub und spokes"]

Aktivität	Managed (XMMS)	Eigenbetrieb
Anfragen entgegennehmen und triagieren	XMMS	Plattform-Team des Kunden
Die Änderung vorbereiten (pull request auf das Konfigurations-Repository)	XMMS	Plattform-Team des Kunden
Eine Änderung prüfen und genehmigen	XMMS-Reviewer; der Kunde genehmigt, wo der Vertrag es vorsieht	Plattform-Team des Kunden (Vier-Augen-Prinzip innerhalb des Teams)
`Plan` / `Apply` in den Entry-pipelines ausführen	XMMS	Plattform-Team des Kunden
Auf canary testen	XMMS	Plattform-Team des Kunden
Eine neue Plattformversion übernehmen	XMMS schlägt ein Zeitfenster vor, der Kunde stimmt zu	Der Kunde wählt den Zeitpunkt; liest release notes und Upgrade-Leitfaden
Die Plattform überwachen, Alerts bearbeiten	XMMS, in den vertraglich vereinbarten Zeiten	Plattform-Team des Kunden, Zeiten vom Kunden definiert
Deployment-Identitäten rotieren	XMMS	Plattform-Team des Kunden
Policies und Firewall-Inhalte festlegen	Security/Architektur des Kunden entscheidet; XMMS setzt um	Security/Architektur des Kunden entscheidet; das Plattform-Team setzt um
spoke-Baseline und Standardänderungen für workload-Teams	XMMS	Plattform-Team des Kunden

Wechsel von managed zu Eigenbetrieb (oder zurück)¶

Die Seite Betriebsverantwortlichkeiten enthält eine Day-one-Checkliste für einen Kunden, der die Plattform übernimmt: Alert-Empfänger, Defender-Kontakt, Deployment-Identitäten, Genehmigungen, version pinning. Beim Rückwechsel zu einem managed service dient dieselbe Liste als Übergabeinventar.

Konsequenzen für Nutzer¶

Thema	Managed (XMMS)	Eigenbetrieb
Wohin sende ich eine Anfrage?	Vertraglicher Intake	Intake deines eigenen Plattform-Teams
Wie schnell kommt eine Antwort?	Laut Vertrag	Laut den eigenen Zielen deines Plattform-Teams
Wen rufe ich außerhalb der Geschäftszeiten an?	Nur wenn der Vertrag after-hours support für den hub enthält	Die eigene Rufbereitschaft deiner Organisation, falls vorhanden
Wer genehmigt Ausnahmen und Firewallregeln?	Dein Security Officer; XMMS setzt um	Dein Security Officer; dein Plattform-Team setzt um

Siehe Support und Wie du Anfragen stellst.