Support: Where to Go and What to Include¶
How support works depends on who runs your platform. See Operating models.
| Managed service (XMMS) | Self-managed | |
|---|---|---|
| Channel | The intake from your contract or onboarding document | Your organisation's platform team channel |
| Hours | As contracted. The standard managed service covers business hours; after-hours support applies to the hub only if it was agreed. | As set by your platform team |
| Severity and response targets | Contract (a typical model is severity 1: 30 minutes, severity 2: 2 hours, severity 3: 4 hours) | Defined by your platform team |
| Announcements | Release and maintenance notices from the platform team | Your platform team's announcement channel |
Fill in the values for your organisation here, or keep them in your onboarding document:
| Item | Your value |
|---|---|
| Support channel | <support channel> |
| Onboarding channel | <onboarding channel> |
| Announcement channel | <announcement channel> |
| Support hours | <hours> |
What the platform team supports¶
- Onboarding new workloads and spokes.
- Troubleshooting platform problems: pipelines, networking through the hub, DNS, firewall, policies.
- Questions about Azure policies and compliance on the platform.
- Access: spoke groups, PIM roles.
- Standard changes: see How to request.
- If your platform offers them: managed virtual machines (requests, restore of a backup, patching problems, see Managed virtual machines), shared build agents (Build agents) and notifications about expiring app registration secrets (App registration secrets).
What it does not support¶
- Bugs, crashes or performance of your application, and debugging of your application code.
- Business logic issues.
- Software that is not part of the platform.
- Custom development of your application.
Contact your own development team or application owner for these. See Responsibilities.
Before you contact the platform team¶
A complete message is answered faster. Include:
- What you see, and what you expected.
- What you already tried.
- Error messages (for policy denials, the policy name and the full error).
- Subscription name or ID, and resource group, if relevant.
- Urgency, and whether production is affected.
- Confirmation that it is a platform problem and not an application problem.
- For a request: the fields listed in How to request.
Requests with a pull request¶
For some requests the platform team lets you prepare the change yourself, for example firewall rules or a VM configuration. Typically:
- You make the change on a branch of the configuration repository and open a pull request. Do not complete it yourself.
- You also create the ticket and put the link to the pull request in it. The ticket is then the record and the approval trail, and the pull request is the change itself.
- The platform team (and, where agreed, your architecture or security team) reviews the pull request, approves, merges and deploys. Then the ticket is closed.
This is quicker for everyone, because a pull request is easier to check than a description in a ticket. It needs access to the repository and some knowledge of Git and of the configuration. Ask your platform team whether your team can do it.
Follow your request¶
Some platforms synchronise the tickets to a work-item board, and give workload teams read access to that board. Then you can see in which phase your request is (for example design, resolved, done). Ask where to look, and who to contact when a request does not move.
Escalation¶
- Urgent production problems: say so clearly in the message and use the urgent route in your contract or onboarding document.
- Major incidents: the platform team runs a bridge and gives regular updates. See Incident management.
- Problems with Azure itself (a failing Azure service): check Azure Service Health and Resource Health first. Your platform team escalates to Microsoft support through its support plan.
- Quota or capacity: see Operate your workload.