Support: Wohin du dich wendest und was du angeben solltest

Wie Support funktioniert, hängt davon ab, wer deine Plattform betreibt. Siehe Betriebsmodelle.

	Managed Service (XMMS)	Eigenbetrieb (self-managed)
Kanal	Der Intake aus deinem Vertrag oder Onboarding-Dokument	Der Kanal des Plattform-Teams deiner Organisation
Zeiten	Wie vertraglich vereinbart. Der Standard-Managed-Service deckt die Geschäftszeiten ab; Support außerhalb der Geschäftszeiten gilt für den hub nur, wenn er vereinbart wurde.	Wie von deinem Plattform-Team festgelegt
Schweregrad und Reaktionsziele	Vertrag (ein typisches Modell ist Schweregrad 1: 30 Minuten, Schweregrad 2: 2 Stunden, Schweregrad 3: 4 Stunden)	Von deinem Plattform-Team definiert
Ankündigungen	release- und Wartungsmitteilungen des Plattform-Teams	Der Ankündigungskanal deines Plattform-Teams

Trage hier die Werte für deine Organisation ein oder halte sie in deinem Onboarding-Dokument fest:

Punkt	Dein Wert
Support-Kanal	<support channel>
Onboarding-Kanal	<onboarding channel>
Ankündigungskanal	<announcement channel>
Support-Zeiten	<hours>

Was das Plattform-Team unterstützt

• Onboarding neuer Workloads und Spokes.
• Fehlersuche bei Plattformproblemen: pipelines, Netzwerk über den hub, DNS, firewall, Policies.
• Fragen zu Azure-Policies und Compliance auf der Plattform.
• Zugriff: Spoke-Gruppen, PIM-Rollen.
• Standardänderungen: siehe So stellst du eine Anfrage.
• Falls deine Plattform sie anbietet: Managed Virtual Machines (Anfragen, Wiederherstellung eines Backups, Patching-Probleme, siehe Managed Virtual Machines), gemeinsame Build-Agents (Build-Agents) und Benachrichtigungen über ablaufende Secrets von App Registrations (Secrets von App Registrations).

Was es nicht unterstützt

• Bugs, Abstürze oder Performance deiner Anwendung sowie das Debugging deines Anwendungscodes.
• Probleme in der Geschäftslogik.
• Software, die nicht Teil der Plattform ist.
• Individualentwicklung deiner Anwendung.

Wende dich dafür an dein eigenes Entwicklungsteam oder den Anwendungseigentümer. Siehe Verantwortlichkeiten.

Bevor du das Plattform-Team kontaktierst

Eine vollständige Nachricht wird schneller beantwortet. Gib an:

• Was du siehst und was du erwartet hast.
• Was du bereits versucht hast.
• Fehlermeldungen (bei Policy-Ablehnungen den Policy-Namen und den vollständigen Fehler).
• subscription-Name oder -ID und gegebenenfalls die resource group.
• Dringlichkeit und ob die Produktion betroffen ist.
• Bestätigung, dass es ein Plattformproblem und kein Anwendungsproblem ist.
• Bei einer Anfrage: die Felder aus So stellst du eine Anfrage.

Anfragen mit einem pull request

Bei manchen Anfragen lässt dich das Plattform-Team die Änderung selbst vorbereiten, zum Beispiel Firewallregeln oder eine VM- Konfiguration. Typischerweise:

1. Du machst die Änderung auf einem Branch des Konfigurations-Repositorys und öffnest einen pull request. Schließe ihn nicht selbst ab.
2. Du legst außerdem das Ticket an und trägst den Link zum pull request darin ein. Das Ticket ist dann der Nachweis und die Genehmigungsspur, und der pull request ist die Änderung selbst.
3. Das Plattform-Team (und, wo vereinbart, dein Architektur- oder Security-Team) prüft den pull request, genehmigt, merged und deployt. Danach wird das Ticket geschlossen.

Das ist für alle schneller, weil ein pull request leichter zu prüfen ist als eine Beschreibung in einem Ticket. Es setzt Zugriff auf das Repository und etwas Kenntnis von Git und der Konfiguration voraus. Frag dein Plattform-Team, ob dein Team das tun kann.

Deine Anfrage verfolgen

Manche Plattformen synchronisieren die Tickets auf ein Work-Item-Board und geben Workload-Teams Lesezugriff darauf. Dann siehst du, in welcher Phase deine Anfrage ist (zum Beispiel design, resolved, done). Frag, wo du nachsehen kannst und wen du kontaktieren sollst, wenn sich eine Anfrage nicht bewegt.

Eskalation

• Dringende Produktionsprobleme: Sag das in der Nachricht deutlich und nutze den Dringlichkeitsweg aus deinem Vertrag oder Onboarding- Dokument.
• Major Incidents: Das Plattform-Team führt eine Bridge und gibt regelmäßige Updates. Siehe Incident-Management.
• Probleme mit Azure selbst (ein ausfallender Azure-Dienst): Prüfe zuerst Azure Service Health und Resource Health. Dein Plattform-Team eskaliert über seinen Support Plan an den Microsoft-Support.
• Kontingent oder Kapazität: siehe Workload betreiben.