Verantwortlichkeiten im Betrieb¶
Jemand muss den Hub betreiben: Incidents, Wartung, Monitoring und Standardänderungen. Im Managed-Modell übernimmt XMMS das im Rahmen des Vertrags. Im Modell Eigenbetrieb (self-managed) übernimmt das Plattform-Team des Kunden das. Diese Seite listet auf, was dafür nötig ist, basierend auf dem Umfang des managed service (Betriebsmodelle).
- Managed (XMMS): Nutze sie, um zu sehen, was der Service abdeckt, um den Vertrag dagegen zu prüfen und um zu wissen, was beim Kunden bleibt (Identity, Security Officer, Genehmigungen, Microsoft-Supportplan, eigene Workloads).
- Eigenbetrieb (self-managed): Nutze sie als Checkliste, wenn du die Plattform übernimmst, und als Definition deines eigenen Service.
Checkliste für Tag eins (Übergabe im Eigenbetrieb)¶
Die Implementierung endet mit einer Übergabe (Übergabe und Reporting). Nutze die Tabelle unten zu diesem Zeitpunkt.
| # | Aktion | Wo |
|---|---|---|
| 1 | Leite Plattform-Alerts an dein Team. Setze die Empfänger beider action groups (general und die mit dem Namen …-mgmtxpirit-…, die die landing-zone-Alerts über die Alert Processing Rules erhält) |
<primary region>/foundation.auto.tfvars: monitor_action_group_general_email_receiver / _webhook_receiver, monitor_action_group_xpirit_email_receiver / _webhook_receiver |
| 2 | Setze den Defender-for-Cloud-Security-Contact. Der Default im Code ist CustomerSupport@Xebia.com |
postdeployment.auto.tfvars: security_contact_email |
| 3 | Entscheide über Alerting außerhalb der Geschäftszeiten für den Hub | hub_247_support (Monitoring-Regeln) |
| 4 | Übernimm die Verantwortung für die Deployment-Identitäten (Service Principals in mcp.json) und ihre Credentials oder Federated Credentials |
Entra ID; update-spn-pipeline im Code-Repository |
| 5 | Richte Genehmigungen ein: Branch Protection im Konfigurations-Repository, Required Reviewers auf dem GitHub-Environment approval-required und einen Approve*-Modus für prod-Läufe |
Pipelines und Workflows |
| 6 | Pinne eine Code-Version, die du getestet hast, und plane, wie du Updates übernimmst | Versionierung |
| 7 | Lies die Bekannten Probleme und prüfe deine Entry-pipelines auf whatIf / mode |
Wiederkehrende Verantwortlichkeiten¶
Technischer Support (Incidents und Service-Anfragen)¶
Zu den Bearbeitungsschritten, Major Incidents und der Post-Mortem-Vorlage siehe Incident-Management und Post-Mortems.
- Intake. Richte eine zentrale Stelle ein, an der Anfragen und Incidents erfasst werden, zum Beispiel ein Ticketsystem oder ein Work-Item- Board. Die Standardänderungen in diesem Leitfaden sind dein Katalog für Service-Anfragen.
- Schweregrad-Modell. Definiere Schweregrade und Reaktionszeiten. Der managed service verwendete dieses Modell; passe es an deine Bedürfnisse an:
| Schweregrad | Bedeutung | Reaktionsziel |
|---|---|---|
| 1 | Kritische Geschäftsauswirkung, kein Workaround | 30 Minuten (24×7 nur mit einem Standby-Service; sonst Geschäftszeiten) |
| 2 | Schwerwiegende Auswirkung; Teile der Plattform nicht verfügbar oder beeinträchtigt; ein Workaround existiert | 2 Stunden (Geschäftszeiten) |
| 3 | Eine Funktion ist nicht verfügbar oder verhält sich fehlerhaft, keine unmittelbare Geschäftsauswirkung | 4 Stunden (Geschäftszeiten) |
- Post-Mortem. Führe für jeden Incident mit Schweregrad 1 innerhalb von fünf Arbeitstagen eine Root-Cause-Analyse durch und halte Verbesserungen fest.
- Eskalation an Microsoft. Du benötigst einen eigenen Azure-Supportplan für Störungen in Azure-Diensten.
Wartung¶
Siehe den Wartungskalender.
| Aufgabe | Wie | Häufigkeit |
|---|---|---|
| Updates des Plattform-Codes (Patches, Minor-Versionen) | Erhöhe den Code-Ref (Versionierung), zuerst canary | Pro release |
| Container-Image und runner | container- und infrastructure-pipelines |
Bei jedem Code-Update |
| Secrets der Deployment-SPNs | update-spn-pipeline, oder Federated Credentials verwenden |
Vor Ablauf |
| Secrets der Spoke-SPNs | Werden beim ersten Spoke-Lauf nach SPNSecretrotationPeriod Tagen rotiert (Spoke ändern) |
Führe die Spoke-pipeline regelmäßig aus |
| App-Gateway-Zertifikate | Im App Gateway Key Vault erneuern, dann key_vault_secret_id aktualisieren, wenn du Versionen pinnst |
Vor Ablauf |
| Policy-Ausnahmen | Die expires_on-Daten prüfen |
Monatlich |
| Drift-Check | hub im Modus Plan ausführen. Jede Änderung, die du nicht committet hast, ist drift: in Code beheben oder in Azure zurücknehmen |
Wöchentlich |
| Azure Advisor / Defender-Empfehlungen | Prüfen und in Backlog-Items überführen | Monatlich |
Service-Management¶
Siehe Service-Level-Management und den monatlichen Health Check.
- Verfügbarkeit. Der managed service zielte auf 99,0 % monatliche Verfügbarkeit der Hub-Komponenten, geplante Wartung ausgenommen, ohne einzelne Störung länger als 20 Minuten. Lege dein eigenes Ziel fest und miss es, zum Beispiel mit Service-Health- und Resource-Health-Alerts (AMBA) sowie firewall-/Gateway-Metriken.
- Kostenmanagement. Die hub layers deployen keine Budgets. Die Beispielkonfiguration enthält eine eigene Policy-
Definition
policy_definition_es_deploy_budget.json, die du zuweisen kannst (Policy-Zuweisungen), oder du verwaltest Budgets in Cost Management. - Reporting. Monatlich: Verfügbarkeit, Anzahl der Incidents nach Schweregrad, Details zu Incidents mit Schweregrad 1 und Änderungen. Quartalsweise: Trends, Verbesserungen, Kosten.
- Service Levels. Wie Servicefenster, Schweregrade, Verfügbarkeitsziele und Reporting zusammenpassen, beschreibt Governance. Änderungen werden als Standard-, Normal- oder Emergency-Änderung klassifiziert (Änderungskategorien).
Aufteilung der Verantwortlichkeiten: Hub vs. Spoke¶
Aus dem Verantwortlichkeitsmodell des managed service (RACI). Im Managed-Modell ist die Spalte „Plattform-Team“ XMMS. Im Eigenbetrieb ist es das eigene Team des Kunden.
| Bereich | Hub (Plattform-Team) | Spoke canvas (Workload-Team) |
|---|---|---|
| Netzwerk: Firewall, Virtual WAN/hub, Gateways, DNS, App Gateway, Bastion, IP groups | verantwortlich (durchführend) und rechenschaftspflichtig | informiert |
| Inhalt der firewall policy (welcher Traffic erlaubt ist) | Kunde/Security rechenschaftspflichtig; Plattform-Team setzt um | Beantragt Regeln |
| IP-Plan | Kunde rechenschaftspflichtig | Rechenschaftspflichtig für die eigenen Bereiche; Plattform-Team setzt im Spoke-JSON um |
| Spoke-VNet, NSGs, Route Tables | – | Rechenschaftspflichtig; Plattform-Team setzt über die Spoke-pipeline um |
| Azure Policy-Compliance (CIS, ISO 27001, MCSB) | Rechenschaftspflichtig auf Plattform-Ebene | Rechenschaftspflichtig für die Compliance der eigenen Ressourcen |
| Kostenmanagement und Budgets | Plattform-subscriptions | Eigene subscription |
| Log Analytics, Alerts, action groups | Plattform | Eigener workspace und eigene Alerts |
| Defender for Cloud, Advisor | Plattform-subscriptions | Eigene subscription |
| RBAC, PIM | Plattform | Eigene Gruppen (über ProductTeamGroupNames) |
| Entra ID-Benutzer, -Gruppen, Conditional Access, SOC | Kunde (Identity-/Security-Teams) | Kunde |
| Pipelines, Repositories, runner | Plattform | Spoke-pipeline: Plattform; eigene App-pipelines: Workload-Team |
| Management groups, subscription-Setup, Namenskonvention | Plattform | – |
| Spoke-Tags | – | Workload-Team (Spoke-JSON tags) |
| Policy-initiatives auf einem einzelnen Spoke | – | Workload-Team |
Eine RASCI-Matrix lesen¶
Die folgende Matrix nutzt die erweiterte RASCI-Form. Die Spalten sind Teams oder Rollen, die Zeilen Aktivitäten.
| Buchstabe | Bedeutung |
|---|---|
| R Responsible (verantwortlich) | Führt die Arbeit aus |
| A Accountable (rechenschaftspflichtig) | Besitzt das Ergebnis und hat das letzte Wort. Nur eine pro Aktivität. |
| S Supportive (unterstützend) | Stellt Ressourcen für die Arbeit bereit |
| C Consulted (konsultiert) | Hat Informationen oder Expertise, die gebraucht werden. Zweiseitige Kommunikation. |
| I Informed (informiert) | Wird über Fortschritt oder Ergebnis informiert, normalerweise nach einer Entscheidung |
Jede Aktivität hat genau ein A und mindestens ein R. Damit die Tabellen kurz bleiben, schließt ein Buchstabe die schwächeren ein:
| Angezeigt | Bedeutet |
|---|---|
| A | Accountable, Responsible, Consulted und Informed, sofern eine Spalte nichts anderes sagt |
| R | Responsible, Consulted und Informed |
| C | Consulted und Informed |
Wenn also Team 1 ein A und Team 2 ein R hat, bleibt Team 1 für das Ganze accountable und hat die Arbeit an Team 2 delegiert, das damit auch consulted und informed ist. Ein Team mit nur einem C muss in Änderungen einbezogen werden und wird auch informiert.
Eine übliche Regel für Managed Platforms
Nur Teams der Kundenorganisation sind accountable. Das Plattform-Team ist, wenn es eine externe Partei ist, responsible. So bleibt die Accountability und damit die Kontinuität des Services innerhalb der Kundenorganisation. Im Eigenbetrieb gehören beide dem Kunden, in zwei verschiedenen Teams oder in einem.
Verantwortlichkeitsmatrix nach Plattformbereich (Beispiel)¶
Ein ausgearbeitetes Beispiel für eine Plattform mit diesen Rollen. Passe die Rollen an deine Organisation an.
| Rolle | Bedeutung |
|---|---|
| Owner | Der Service Owner der Plattform beim Kunden |
| Plattform-Team | XMMS (Managed) oder die eigenen Plattform-Engineers des Kunden (Eigenbetrieb) |
| Security | Der Security Officer oder das operative Security-Team |
| Architecture | Enterprise Architecture |
| Workload | Das Workload-Team (Nutzer) |
Ein Strich bedeutet: keine Rolle bei dieser Aktivität.
Netzwerk¶
| Aktivität | Owner | Plattform-Team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| IP-Plan | A | R (weist die Adressen zu und verwaltet sie) | – | – | I (für die eigenen Bereiche) |
| IP groups, virtual networks, Subnets, Baseline-NSG-Regeln, Virtual WAN und hub, Routing, VPN-Gateways, private DNS forwarding | A | R | – | C | – |
| NSG-Regeln für den Workload | – | R (über die Spoke-pipeline) | – | C | A |
| Azure-Firewall-Ressource | A | R | C | C | – |
| Inhalt der firewall policy | R | R | A | C | I |
| Application-Gateway- und WAF-Ressource | A | R | C | C | – |
| WAF-Policy | C | R | A | – | I |
| Externe Zertifikate des Gateways | R | R | A | C | – |
| Internetzugriff oder Internet-Veröffentlichung für einen Workload erlauben | R | R | A | C | – |
Security und Identität¶
| Aktivität | Owner | Plattform-Team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| Einrichtung des SIEM (zum Beispiel Sentinel) | – | – | A | C | – |
| Security-Alerts und Defender-Empfehlungen für Workload-Ressourcen beheben | C | – | C | C | A |
| Einrichtung von Defender for Cloud | I | I | A | C | – |
| PIM-Rollen und Security-Gruppen gemäß dem RBAC-Modell | R | – | A | C | – |
| Mitgliedschaft in den Gruppen des Workloads | – | – | – | – | A |
| Conditional Access, Benutzer, Enterprise Applications | I | – | A | C | – |
| Service Principals der Spokes | R | – | A | C | – |
Governance und Ressourcen¶
| Aktivität | Owner | Plattform-Team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| Management groups und Ressourcenverwaltung | R | R | – | A | – |
| RBAC auf Plattformebene | R | R | R | A | – |
| Infrastruktur-Policies | A | R | C | C | – |
| Security-Policies (Baseline, CIS, ISO 27001) | I | R | A | C | – |
| Security Contact des Tenants | – | R | A | – | – |
| Kostenmanagement | A | R | – | – | R (eigene Subscription) |
| Lizenzierung und Abrechnung des Tenants | A | – | – | C | – |
| Key Vault, Log Analytics, Alerts, action groups, Automation und Storage der Plattform | A | R | – | – | I (wenn als Teil eines Spokes deployt) |
| Selbst gehostete pipeline-Agents | A | R | – | – | – |
Workloads und Spokes¶
| Aktivität | Owner | Plattform-Team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| Erstellung, Änderung und Löschung eines Spokes | A | R | – | C | I |
| Technisches Monitoring und Compliance des Spokes | A | R | – | C | I |
| Security-Monitoring und Remediation des Spokes | C | R | A | C | I |
| Azure-Ressourcen, die der Workload in seinem Spoke deployt hat: erstellen, aktualisieren, löschen, überwachen | C | – | – | C | A |
| Security-Monitoring dieser Ressourcen | C | – | A | C | C |
| Die fachliche Lösung und ihr Monitoring | C | – | C | C | A |
Bei einem Managed Spoke (Service-Typen) ist das Plattform-Team zusammen mit dem Workload-Team R für Erstellung, Deployment und technischen Betrieb der Workload-Ressourcen. Das Workload-Team bleibt A.