Operating Responsibilities¶
Someone has to run the hub: incidents, maintenance, monitoring and standard changes. In the managed model, XMMS does this under the contract. In the self-managed model, the customer's platform team does it. This page lists what that takes, based on the scope of the managed service (Operating models).
- Managed (XMMS): use it to see what the service covers, to check the contract against it and to know what stays with the customer (identity, security officer, approvals, Microsoft support plan, own workloads).
- Self-managed: use it as a checklist when you take over the platform, and as the definition of your own service.
Day-one checklist (self-managed hand-over)¶
The implementation ends with a hand-over (Hand-over and reporting). Use the table below at that moment.
| # | Action | Where |
|---|---|---|
| 1 | Point platform alerts to your team. Set the receivers of both action groups (general and the one named …-mgmtxpirit-…, which receives the landing zone alerts through the alert processing rules) |
<primary region>/foundation.auto.tfvars: monitor_action_group_general_email_receiver / _webhook_receiver, monitor_action_group_xpirit_email_receiver / _webhook_receiver |
| 2 | Set the Defender for Cloud security contact. The code default is CustomerSupport@Xebia.com |
postdeployment.auto.tfvars: security_contact_email |
| 3 | Decide on after-hours alerting for the hub | hub_247_support (Monitoring rules) |
| 4 | Take ownership of the deployment identities (service principals in mcp.json) and their credentials or federated credentials |
Entra ID; update-spn pipeline in the code repository |
| 5 | Set up approvals: branch protection on the configuration repository, required reviewers on the GitHub environment approval-required, and an Approve* mode for prod runs |
Pipelines and workflows |
| 6 | Pin a code version you have tested, and plan how you take updates | Versioning |
| 7 | Read the Known issues and check your entry pipelines for whatIf / mode |
Recurring responsibilities¶
Technical support (incidents and service requests)¶
For the handling steps, major incidents and the post-mortem template, see Incident management and Post-mortems.
- Intake. Have one place where requests and incidents are logged, for example a ticket system or a work-item board. The standard changes in this guide are your service-request catalog.
- Severity model. Define severities and response times. The managed service used this model; adapt it to your needs:
| Severity | Meaning | Response target |
|---|---|---|
| 1 | Critical business impact, no workaround | 30 minutes (24×7 only with a standby service; otherwise business hours) |
| 2 | Serious impact; parts of the platform unavailable or degraded; a workaround exists | 2 hours (business hours) |
| 3 | A function is unavailable or misbehaves, no immediate business impact | 4 hours (business hours) |
- Post-mortem. For every severity 1 incident, run a root-cause analysis within five working days and record improvements.
- Escalation to Microsoft. You need your own Azure support plan for faults in Azure services.
Maintenance¶
See the Maintenance calendar.
| Task | How | Frequency |
|---|---|---|
| Platform code updates (patches, minor versions) | Bump the code ref (Versioning), canary first | Per release |
| Container image and runners | container and infrastructure pipelines |
With each code update |
| Deployment SPN secrets | update-spn pipeline, or use federated credentials |
Before expiry |
| Spoke SPN secrets | Rotated on the first spoke run after SPNSecretrotationPeriod days (Change spoke) |
Run the spoke pipeline regularly |
| App Gateway certificates | Renew in the App Gateway Key Vault, then update key_vault_secret_id if you pin versions |
Before expiry |
| Policy exemptions | Review expires_on dates |
Monthly |
| Drift check | Run hub in Plan mode. Any change you did not commit is drift: fix it in code, or revert it in Azure |
Weekly |
| Azure Advisor / Defender recommendations | Review and turn them into backlog items | Monthly |
Service management¶
See Service level management and the Monthly health check.
- Availability. The managed service targeted 99.0% monthly availability of the hub components, excluding planned maintenance, with no single disruption longer than 20 minutes. Decide your own target and measure it, for example with Service Health and Resource Health alerts (AMBA) and firewall/gateway metrics.
- Cost management. The hub layers do not deploy budgets. The sample configuration contains a custom policy
definition
policy_definition_es_deploy_budget.json, which you can assign (Policy assignments), or manage budgets in Cost Management. - Reporting. Monthly: availability, incident counts by severity, details of severity 1 incidents, and changes. Quarterly: trends, improvements, cost.
- Service levels. How service windows, severities, availability targets and reporting fit together is described in Governance. Changes are classified as standard, normal or emergency (Categories of change).
Responsibility split: hub vs spoke¶
From the responsibility model of the managed service (RACI). In the managed model the "platform team" column is XMMS. In the self-managed model it is the customer's own team.
| Area | Hub (platform team) | Spoke canvas (workload team) |
|---|---|---|
| Network: Firewall, Virtual WAN/hub, gateways, DNS, App Gateway, Bastion, IP groups | Responsible & accountable | Informed |
| Firewall policy content (which traffic is allowed) | Customer/security accountable; platform team implements | Requests rules |
| IP plan | Customer accountable | Accountable for its own ranges; platform team implements in the spoke JSON |
| Spoke VNet, NSGs, route tables | – | Accountable; platform team implements through the spoke pipeline |
| Azure Policy compliance (CIS, ISO 27001, MCSB) | Accountable at platform scope | Accountable for compliance of its own resources |
| Cost management and budgets | Platform subscriptions | Its own subscription |
| Log Analytics, alerts, action groups | Platform | Its own workspace and alerts |
| Defender for Cloud, Advisor | Platform subscriptions | Its own subscription |
| RBAC, PIM | Platform | Its own groups (through ProductTeamGroupNames) |
| Entra ID users, groups, Conditional Access, SOC | Customer (identity/security teams) | Customer |
| Pipelines, repositories, runners | Platform | Spoke pipeline: platform; its own app pipelines: workload team |
| Management groups, subscription setup, naming convention | Platform | – |
| Spoke tags | – | Workload team (spoke JSON tags) |
| Policy initiatives on a single spoke | – | Workload team |
Reading a RASCI matrix¶
The matrix below uses the extended RASCI form. Columns are teams or roles, rows are activities.
| Letter | Meaning |
|---|---|
| R Responsible | Does the work |
| A Accountable | Owns the result and has the final say. Only one per activity. |
| S Supportive | Provides resources for the work |
| C Consulted | Has information or expertise that is needed. Two-way communication. |
| I Informed | Is told about progress or the result, normally after a decision |
Every activity has exactly one A and at least one R. To keep the tables short, a letter implies the weaker ones:
| Shown | Means |
|---|---|
| A | Accountable, Responsible, Consulted and Informed, unless a column says otherwise |
| R | Responsible, Consulted and Informed |
| C | Consulted and Informed |
So when team 1 has an A and team 2 an R, team 1 stays accountable for the whole and delegated the work to team 2, which is therefore also consulted and informed. A team with only a C must be involved in changes, and is also informed.
A common rule for managed platforms
Only teams of the customer organisation are accountable. The platform team, if it is an external party, is responsible. That keeps accountability, and so continuity of the service, inside the customer organisation. In the self-managed model both belong to the customer, in two different teams or in one.
Responsibility matrix by platform area (example)¶
A worked example for a platform with these roles. Adapt the roles to your organisation.
| Role | Meaning |
|---|---|
| Owner | The customer's service owner of the platform |
| Platform team | XMMS (managed) or the customer's own platform engineers (self-managed) |
| Security | The security officer or operational security team |
| Architecture | Enterprise architecture |
| Workload | The workload team (consumer) |
A dash means: no role in this activity.
Network¶
| Activity | Owner | Platform team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| IP plan | A | R (assigns and administers the addresses) | – | – | I (for its own ranges) |
| IP groups, virtual networks, subnets, baseline NSG rules, Virtual WAN and hub, routing, VPN gateways, private DNS forwarding | A | R | – | C | – |
| NSG rules for the workload | – | R (through the spoke pipeline) | – | C | A |
| Azure Firewall resource | A | R | C | C | – |
| Firewall policy content | R | R | A | C | I |
| Application Gateway and WAF resource | A | R | C | C | – |
| WAF policy | C | R | A | – | I |
| External certificates of the gateway | R | R | A | C | – |
| Allow internet access or internet publication for a workload | R | R | A | C | – |
Security and identity¶
| Activity | Owner | Platform team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| SIEM (for example Sentinel) setup | – | – | A | C | – |
| Resolving security alerts and Defender recommendations on workload resources | C | – | C | C | A |
| Defender for Cloud setup | I | I | A | C | – |
| PIM roles and security groups according to the RBAC model | R | – | A | C | – |
| Membership of the workload's groups | – | – | – | – | A |
| Conditional access, users, enterprise applications | I | – | A | C | – |
| Service principals of spokes | R | – | A | C | – |
Governance and resources¶
| Activity | Owner | Platform team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| Management groups and resource management | R | R | – | A | – |
| RBAC at platform scope | R | R | R | A | – |
| Infrastructure policies | A | R | C | C | – |
| Security policies (baseline, CIS, ISO 27001) | I | R | A | C | – |
| Security contact of the tenant | – | R | A | – | – |
| Cost management | A | R | – | – | R (own subscription) |
| Tenant licensing and billing | A | – | – | C | – |
| Key Vault, Log Analytics, alerts, action groups, automation and storage of the platform | A | R | – | – | I (when deployed as part of a spoke) |
| Self-hosted pipeline agents | A | R | – | – | – |
Workloads and spokes¶
| Activity | Owner | Platform team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| Spoke creation, change and deletion | A | R | – | C | I |
| Spoke technical monitoring and compliance | A | R | – | C | I |
| Spoke security monitoring and remediation | C | R | A | C | I |
| Azure resources the workload deployed in its spoke: create, update, delete, monitor | C | – | – | C | A |
| Security monitoring of those resources | C | – | A | C | C |
| The business solution and its monitoring | C | – | C | C | A |
In a managed spoke (Service types) the platform team is R for the creation, deployment and technical operation of the workload resources together with the workload team. The workload team stays A.