Support: waar kun je terecht en wat geef je mee¶

Hoe support werkt, hangt af van wie je platform beheert. Zie Beheermodellen.

	Managed service (XMMS)	Zelfbeheer
Kanaal	De intake uit je contract of onboardingdocument	Het kanaal van het platformteam van je organisatie
Uren	Zoals gecontracteerd. De standaard managed service dekt kantooruren; support buiten kantooruren geldt voor de hub alleen als dat is afgesproken.	Zoals bepaald door je platformteam
Ernst (severity) en responstijden	Contract (een typisch model is severity 1: 30 minuten, severity 2: 2 uur, severity 3: 4 uur)	Gedefinieerd door je platformteam
Aankondigingen	Release- en onderhoudsberichten van het platformteam	Het aankondigingskanaal van je platformteam

Vul hier de waarden voor je organisatie in, of bewaar ze in je onboardingdocument:

Onderdeel	Jouw waarde
Supportkanaal	`<support channel>`
Onboardingkanaal	`<onboarding channel>`
Aankondigingskanaal	`<announcement channel>`
Supporturen	`<hours>`

Wat het platformteam ondersteunt¶

Onboarding van nieuwe workloads en spokes.
Troubleshooting van platformproblemen: pipelines, netwerk via de hub, DNS, firewall, policies.
Vragen over Azure policies en compliance op het platform.
Toegang: spoke-groepen, PIM-rollen.
Standaardwijzigingen: zie Hoe doe je een aanvraag.
Als je platform ze aanbiedt: managed virtual machines (aanvragen, herstel van een back-up, patchingproblemen, zie Managed virtuele machines), shared build agents (Build agents) en meldingen over verlopende secrets van app registrations (Secrets van app registrations).

Wat het niet ondersteunt¶

Bugs, crashes of performance van je applicatie, en het debuggen van je applicatiecode.
Problemen met bedrijfslogica.
Software die geen onderdeel is van het platform.
Maatwerkontwikkeling van je applicatie.

Neem hiervoor contact op met je eigen ontwikkelteam of applicatie-eigenaar. Zie Verantwoordelijkheden.

Voordat je contact opneemt met het platformteam¶

Een compleet bericht wordt sneller beantwoord. Vermeld:

Wat je ziet en wat je verwachtte.
Wat je al hebt geprobeerd.
Foutmeldingen (bij policy-weigeringen de naam van de policy en de volledige fout).
Naam of ID van de subscription, en de resource group, indien relevant.
Urgentie, en of productie wordt geraakt.
Bevestiging dat het een platformprobleem is en geen applicatieprobleem.
Bij een aanvraag: de velden die staan in Hoe doe je een aanvraag.

Aanvragen met een pull request¶

Voor sommige aanvragen laat het platformteam je de wijziging zelf voorbereiden, bijvoorbeeld firewallregels of een VM- configuratie. Meestal gaat dat zo:

Je maakt de wijziging op een branch van de configuratierepository en opent een pull request. Rond die niet zelf af.
Je maakt ook het ticket aan en zet de link naar de pull request erin. Het ticket is dan het dossier en het goedkeuringsspoor, en de pull request is de wijziging zelf.
Het platformteam (en, waar afgesproken, je architectuur- of securityteam) reviewt de pull request, keurt goed, merget en deployt. Daarna wordt het ticket gesloten.

Dit gaat voor iedereen sneller, omdat een pull request makkelijker te controleren is dan een beschrijving in een ticket. Je hebt toegang tot de repository nodig en wat kennis van Git en van de configuratie. Vraag je platformteam of je team dit kan doen.

Je aanvraag volgen¶

Sommige platformen synchroniseren de tickets naar een work-itembord en geven workload teams leestoegang tot dat bord. Dan kun je zien in welke fase je aanvraag zit (bijvoorbeeld design, resolved, done). Vraag waar je moet kijken en wie je kunt benaderen als een aanvraag niet vordert.

Escalatie¶

Urgente productieproblemen: geef dit duidelijk aan in het bericht en gebruik de urgente route in je contract of onboarding- document.
Major incidents: het platformteam zet een bridge op en geeft regelmatig updates. Zie Incidentbeheer.
Problemen met Azure zelf (een falende Azure-service): controleer eerst Azure Service Health en Resource Health. Je platformteam escaleert naar Microsoft support via zijn supportplan.
Quota of capaciteit: zie Je workload beheren.