Umgang mit Incidents und Major Incidents¶
Diese Seite beschreibt, wie das Plattform-Team Incidents auf der Plattform behandelt: den hub, die pipelines und die Baseline der Spokes. Sie erklärt auch, wie du einen Priority-1-Incident (P1) beim Support des Cloud-Providers meldest, wenn die Ursache Azure selbst ist.
Wer das Plattform-Team ist, hängt von deinem Betriebsmodell ab. Schweregrade, Reaktionszeiten, Zeiten und Kontaktdaten kommen aus deinem Vertrag (Managed Service) oder aus deiner eigenen Definition (Eigenbetrieb). Sie stehen hier als Platzhalter. Was Workload-Teams tun und was in eine Meldung gehört, steht in Support. Für ein erstes Schweregrad-Modell siehe Betriebsverantwortlichkeiten.
Incident, Service-Anfrage oder Änderung¶
| Es ist ein… | Wenn | Behandelt als |
|---|---|---|
| Incident | Etwas, das funktionierte, funktioniert nicht mehr oder schlechter | Diese Seite |
| Service-Anfrage | Ein Workload-Team fragt etwas an, das die Plattform anbietet | So stellst du eine Anfrage, eine Standardänderung (Häufige Anfragen) |
| Änderung | Das Plattform-Team ändert die Plattform (Code-Version, Konfiguration, eine Einstellung in Azure) | Änderungs-Workflow |
Halte sie in deinem Ticketsystem getrennt. Zwei Gründe: Lösungszeiten bedeuten für jede Art etwas anderes, und viele Incidents werden durch eine Änderung verursacht, die niemand dokumentiert hat (siehe die erste Lektion in Post-Mortems).
Einen Incident bearbeiten¶
flowchart LR
a["1. Register"] --> b["2. Acknowledge + classify"] --> c["3. Diagnose"] --> d["4. Restore service"]
d --> e["5. Close + inform"] --> f["6. Post-mortem (sev 1 / major)"]- Erfassen. Jeder Incident bekommt einen Eintrag im vereinbarten Ticketsystem, auch wenn er per Chat oder Telefon gemeldet wurde. Mindestfelder: Melder, Workload und Spoke (oder hub-Komponente), Beschreibung, Startzeit, ob die Produktion betroffen ist, Screenshots oder Fehlermeldungen. Ein P1, der nur per Chat bearbeitet wird, hinterlässt keine Spur für das Post-Mortem.
- Bestätigen und klassifizieren. Antworte innerhalb des Reaktionsziels und setze den Schweregrad. Klassifiziere neu, wenn du mehr weißt. Ein Problem, das klein aussieht, kann Schweregrad 1 sein, wenn die Produktion seit dem Wochenende ausgefallen ist: Klassifiziere nach Auswirkung, nicht danach, wie lange es schon läuft.
- Diagnostizieren. Beginne mit den Prüfungen unter Wo du zuerst nachsiehst. Halte Erkenntnisse laufend im Eintrag fest.
- Service wiederherstellen. Das erste Ziel ist, den Service wiederherzustellen, das zweite, die Ursache zu finden. Eine vorläufige Lösung ist in Ordnung, wenn du sie dokumentierst und die dauerhafte planst. Behebe einen Incident nicht, indem du Azure von Hand änderst, ohne es zu dokumentieren: Der nächste pipeline-Lauf macht es rückgängig, oder es verdeckt die eigentliche Ursache (Drift).
- Abschließen und informieren. Sag dem Melder, was falsch war und was du getan hast. Schließe den Eintrag mit Ursache und Lösung ab.
- Post-Mortem. Pflicht für jeden Incident mit Schweregrad 1 und jeden Major Incident (Post-Mortems).
Schweregrad¶
Verwende das Schweregrad-Modell deines Vertrags oder dein eigenes. Ein Modell, das auf Managed Platforms verwendet wurde, steht in den Betriebsverantwortlichkeiten. Unabhängig von den Zahlen halte für jeden Schweregrad fest:
| Punkt | Wert |
|---|---|
| Definition, mit ein oder zwei Beispielen deiner Plattform | <definition> |
| Zeiten, in denen er bearbeitet wird | <hours>. Gib klar an, ob Schweregrad 1 außerhalb der Bürozeiten bearbeitet wird und für welche Komponenten |
| Reaktionszeit | <response target> |
| Häufigkeit der Updates an den Melder | <every n minutes / hours> |
| Wer wird wie angerufen | <on-call contact> |
Major Incidents¶
Ein Major Incident ist ein Incident mit schwerwiegender geschäftlicher Auswirkung, der mehr als den normalen Ablauf braucht: mehrere Personen gleichzeitig, ein gemeinsames Lagebild und eine Kommunikationsleitung. Typische Auslöser:
- Produktionsanwendungen eines oder mehrerer Workload-Teams sind nicht erreichbar;
- die Verbindung zwischen Azure und On-Premises ist ausgefallen;
- eine Plattformänderung ist in der Produktion schiefgegangen und lässt sich nicht schnell rückgängig machen;
- ein Incident hat Schweregrad 1 und die erste Diagnose hat die Ursache nicht innerhalb von
<n minutes>gefunden.
Rollen¶
Bei einem kleinen Plattform-Team kann eine Person mehr als eine Rolle übernehmen, aber nenne sie zu Beginn laut.
| Rolle | Aufgabe |
|---|---|
| Incident Manager | Besitzt den Incident bis zum Abschluss. Entscheidet über Schweregrad, Eskalation und darüber, wann Schluss ist. Macht nicht die technische Arbeit |
| Technical Lead | Leitet Diagnose und Wiederherstellung. Entscheidet, welche Änderung als Nächstes versucht wird |
| Communication Lead | Hält Stakeholder in der vereinbarten Frequenz informiert. Zentraler Ansprechpartner für Kunden, Workload-Teams und Partner |
| Scribe | Schreibt die Timeline mit Zeitstempeln auf: was gesehen wurde, was entschieden wurde, was geändert wurde, von wem |
| Partner- und Provider-Kontakte | Engineers anderer beteiligter Parteien, zum Beispiel das On-Premises-Netzwerk- oder Firewall-Team, der Anwendungs-Owner, der Support des Cloud-Providers |
Wie es abläuft¶
- Eine Bridge eröffnen (Call oder Chatraum), sobald der Incident als Major erklärt ist, mit allen, die etwas ändern können: das Plattform-Team, der Owner des betroffenen Workloads und die Owner angebundener Systeme (On-Premises-Netzwerk, Identity). Trage den Ort der Bridge im Ticket ein.
- Die Fakten klären: was betroffen ist, seit wann, und was sich zuletzt geändert hat (Plattformänderungen, Releases, Änderungen anderer Teams).
- Andere Änderungen stoppen im betroffenen Bereich, bis der Incident abgeschlossen ist.
- In kurzen Zyklen arbeiten: Hypothese, Prüfung, Aktion, Dokumentation. Ändere immer nur eine Sache und schreibe sie auf.
- In festem Rhythmus kommunizieren, auch wenn es nichts Neues gibt. Jedes Update nennt: aktuelle Auswirkung, was bekannt ist, was getan wird, Zeitpunkt des nächsten Updates.
- Als gelöst erklären, wenn der Service wiederhergestellt ist und der Melder es bestätigt. Ist ein Workaround im Einsatz, lass das Problem offen.
- Das Post-Mortem planen innerhalb von
<n>Arbeitstagen (das Schweregrad-Modell des Managed Service verwendet fünf).
Was in echten Incidents funktioniert hat¶
- Eine benannte Person, die regelmäßig einen Überblick über den Status gab, sodass alle anderen arbeiten konnten.
- Menschen, die kurzfristig dem Call beitraten, und ein Plattformwissen, das gut genug war, um die Ursache schnell zu finden.
- Die anderen Parteien (On-Premises-Netzwerkteam, Partner) in denselben Call einzubinden, statt Nachrichten weiterzureichen.
Wo du zuerst nachsiehst¶
Die meisten Incidents auf der Plattform fallen in wenige Gruppen. Die Tabelle ist ein Einstieg in die Diagnose, kein vollständiges Runbook.
| Symptom | Sieh dir an | Typische beobachtete Ursachen |
|---|---|---|
Benutzer erhalten 403 Forbidden bei einer Anwendung hinter dem Application Gateway |
WAF-Logs: welche Regel getroffen hat, bei welcher Anfrage | Eine WAF-Einstellung oder ein Regelwerk wurde ohne Test geändert (zum Beispiel die Prüfung des Request Body). Deaktiviere die passende Regel vorübergehend und behebe dann die Ursache. Siehe Application Gateway |
Benutzer erhalten 502 Bad Gateway |
Backend-Health des Application Gateway; DNS-Auflösung des Backend-Namens vom hub aus; Firewall-Logs | Der Backend-Name lässt sich nicht auflösen, weil der private DNS-Eintrag fehlt, sodass der Traffic die Firewall nie erreicht. Eine gerade neu erstellte Firewallregel kann wie die Ursache aussehen, ist es aber nicht immer |
| Ein Workload erreicht ein Ziel nicht | Firewall-Logs für Quelle und Ziel (Tabellen für Netzwerk- und Application-Regeln, siehe unten); NSG und Route Table des Spokes | Fehlende oder entfernte Regel, falsche IP group, Rule Collection mitten in einem Deployment (Firewallregeln) |
| Die Verbindung zwischen Azure und On-Premises ist ausgefallen, und das Portal zeigt connected | Traffic auf der Verbindung, nicht nur ihr Status; die Logs der Gegenseite; ob eine zweite Verbindung funktioniert | Der Verbindungsstatus ist connected, aber es fließt kein Traffic. Das Zurücksetzen der Verbindung auf beiden Seiten (den Link bearbeiten und ohne Änderungen speichern) stellte in einem gemeldeten Fall den Traffic wieder her. Klärt ab, wer welche Seite zurücksetzt, bevor ihr anfangt |
| Ein pipeline-Lauf schlägt fehl oder läuft in ein Timeout | Der fehlgeschlagene Job und layer; Bekannte Probleme | Timeouts bei großen Firewall-Änderungen, ein state, der von Azure abweicht, ein abgelaufenes Deployment-Secret |
| Viele Alerts auf einmal | Azure Service Health und Resource Health | Ein Problem auf Provider-Seite. Siehe Einen P1 beim Cloud-Provider melden |
Geh nicht davon aus, dass zwei Symptome eine Ursache haben
Bei einem gemeldeten Incident erzeugten eine Änderung an einer Firewallregel und ein fehlender DNS-Eintrag gleichzeitig dasselbe 502.
Teste jede Ursache einzeln, bevor du dein Fazit ziehst.
Logs¶
Plattform-Logs werden normalerweise an einen zentralen Log-Analytics-Workspace gesendet und mit Kusto (KQL) abgefragt.
| Quelle | Wo | Hinweise |
|---|---|---|
| Azure Firewall | Die Firewall-Ressource, Logs. Ressourcenspezifische Tabellen wie AZFWNetworkRule, AZFWApplicationRule, AZFWNatRule, AZFWDnsQuery, AZFWFlowTrace und AZFWIdpsSignature (und die Aggregationsvarianten) |
Setzt voraus, dass die Firewall-Diagnose an Log Analytics aktiviert ist (Firewallregeln) |
| Application Gateway und WAF | Die Application-Gateway-Ressource, Logs | Je nach Diagnoseeinstellung liegen die Daten in der gemeinsamen Tabelle AzureDiagnostics (der ältere Modus) oder in ressourcenspezifischen Tabellen |
| Workload-Logs | Der eigene Log-Analytics-Workspace des Spokes | Im Besitz des Workload-Teams (Deinen Workload betreiben) |
Der Zugriff auf die Logs ist eine Rolle auf den Workspace-Tabellen und Monitoring Reader auf der Ressource. Gib Workload-Teams auf einer Managed Platform
eine schreibgeschützte Gruppe für ihren eigenen Traffic, wenn sie ihn selbst untersuchen müssen, statt
das Plattform-Team zu bitten, für sie Logs zu lesen.
Einen P1 beim Cloud-Provider melden¶
Manche Incidents werden von Azure verursacht, nicht von der Plattform oder vom Workload. Dann meldet das Plattform-Team (oder das Workload-Team, wenn dein Setup es zulässt) einen P1 beim Support des Cloud-Providers. Wer das darf und über welchen Kanal, hängt von deinem Support-Vertrag ab: ein eigener Microsoft-Supportplan oder ein Partner (zum Beispiel ein Cloud Solution Provider), der es weitergibt. Siehe Betriebsmodelle und Support.
Ist es ein Provider-P1?¶
| Einen Provider-P1 melden bei | Keinen melden bei |
|---|---|
| Einem Ausfall eines Azure-Services, der die Produktion betrifft | Performance-Problemen durch zu wenige Ressourcen (skaliere hoch, prüfe die Quota) |
| Einem unerwarteten Systemfehler von Azure | Problemen in der Anwendung |
| Kritischen Verfügbarkeitsproblemen eines Azure-Datenbankservices | Ressourcen, die keine Azure-Ressourcen sind |
| Einer Störung eines Azure-Cloud-Services | Problemen in Marketplace-Anwendungen von Drittanbietern |
| Subscriptions, die außerhalb des Support-Vertrags liegen |
Prüfe zuerst Azure Service Health und Resource Health. Meldet Azure das Problem bereits, ergänzt du es um deine Auswirkung.
Wer meldet¶
Beschränke das Recht, Provider-P1 zu melden, auf wenige benannte Personen oder Rollen, zum Beispiel die Engineers des Plattform-Teams in Rufbereitschaft
(<roles allowed to raise a P1>). Ein Workload-Team, das keinen melden darf, wendet sich an das Plattform-Team und sagt,
dass das Problem nach einem Provider-Problem aussieht. Schreibe die Liste in dein Onboarding-Dokument.
Was in den Eintrag gehört¶
Lege im Ticketsystem oder im Portal des Providers einen Incident mit der Priorität critical (P1) an, mit einem klaren Titel. Fülle die Beschreibung in dieser Reihenfolge aus:
| Abschnitt | Inhalt |
|---|---|
| Incident-Überblick | Was: welcher Azure-Service ist gestört. Auswirkung: Anzahl der Benutzer oder Services. Wann: seit wann. Status: die aktuelle Lage. Fehler: die relevanten Fehlermeldungen |
| Technische Details | Resource IDs der betroffenen Ressourcen, die Subscription, zugehörige Monitoring-Alerts, relevante Logzeilen |
| Kontaktdaten | Hauptkontakt mit Telefonnummer, Backup-Kontakt, der Kanal, in dem Updates gepostet werden (<update channel>), weitere zu informierende Stakeholder |
| Schritte zur Reproduktion | Genaue Schritte, um das Problem zu sehen: wo man nachsieht (Portalpfad, Ressourcenname), was man tut, was passieren sollte, was stattdessen passiert |
Während des Incidents:
- Halte die Beschreibung aktuell.
- Versieh jedes Update mit einem Zeitstempel.
- Dokumentiere jede vorläufige Lösung und jeden Lösungsversuch.
- Sag den betroffenen Workload-Teams, wo sie den Status verfolgen können.
Vertragsabhängig
Ob Provider-P1 rund um die Uhr bearbeitet werden und von wem, ist Teil deines Vertrags oder Supportplans. Versprich Workload-Teams keine Bearbeitung rund um die Uhr, solange sie nicht für den hub vereinbart ist (Support).
Verwandte Seiten¶
-
Post-Mortems: Vorlage und Lektionen.
- Meetings: wo Incidents und Trends besprochen werden.
- Service-Level-Management: Ziele und wie man sie misst.
- Bekannte Probleme: Probleme der Plattform selbst, mit Workarounds.