Wartungskalender¶
Die meisten Plattformprobleme lassen sich günstiger verhindern als beheben. Diese Seite listet die wiederkehrenden Aufgaben des Plattform-Teams nach Häufigkeit auf und beschreibt, wie du Wartung ankündigst. Nutze sie, um einen Kalender für dein Team aufzubauen. Die Häufigkeiten sind Vorschläge: Dein Vertrag oder deine eigene Richtlinie entscheidet.
Im Managed-Modell erledigt das Plattform-Team (XMMS) diese Aufgaben im Rahmen des Vertrags. Im Eigenbetrieb ist es dein eigenes Plattform-Team (Betriebsmodelle).
Wiederkehrende Aufgaben¶
| Häufigkeit | Aufgabe | Wo |
|---|---|---|
| Wöchentlich | Drift-Check: hub im Modus Plan ausführen. Jede Änderung, die du nicht committet hast, ist drift |
Betriebsverantwortlichkeiten |
| Wöchentlich | Spoke-drift: den neuesten spoke-drift-Bericht lesen, falls du die spoke-drift-pipeline betreibst | Spoke-drift-Erkennung |
| Wöchentlich | Alerts der Woche prüfen: störende Regeln abstimmen, Work Items für echte Probleme anlegen | Monitoring-Regeln, So funktioniert Alerting |
| Wöchentlich | Den Secret Watcher ausführen und auf seine Alerts reagieren | Secret Watcher |
| Wöchentlich | Status der pipelines der Plattform prüfen (fehlgeschlagene oder hängende Läufe) | Pipelines und Workflows |
| Monatlich | Monatlicher Health Check und Bericht | Monatlicher Health Check |
| Täglich (automatisch) | Lauf des Billing-Exports, wenn du Kosten zentral berichtest. Einen fehlgeschlagenen Lauf prüfen | Billing-Export |
| Monatlich | Policy-Ausnahmen prüfen (expires_on) |
Policy-Zuweisungen |
| Monatlich | Empfehlungen von Defender for Cloud und Advisor prüfen | Monatlicher Health Check |
| Monatlich | Secrets und Zertifikate, die innerhalb der Vorlaufzeit ablaufen (zum Beispiel 60 Tage) | Ablauf von Secrets und Zertifikaten |
| Pro Release | Eine neue Plattformversion übernehmen: zuerst canary, dann prod. Lies jeden Upgrade-Leitfaden zwischen der aktuellen und der Zielversion | Was zu tun ist, wenn eine neue Version veröffentlicht wird, Upgrade-Leitfäden der Plattform |
| Pro Release | Prüfen, dass der Code deine Kopie des Code-Repositorys erreicht hat (neuer tag und Branch-Historie vorhanden) | Code-Synchronisierung |
| Pro Release | Das Container-Image und die runner neu bauen | Was zu tun ist, wenn eine neue Version veröffentlicht wird |
| Quartalsweise | Service Level, Post-Mortem-Aktionen und die Roadmap prüfen | Meetings |
| Quartalsweise | Alert-Empfänger und den Rufbereitschaftsweg prüfen: Personen, die gegangen sind, rotierte Webhooks, ein geändertes Tool. Einen Test-Alert senden | Monitoring ausrollen |
| Quartalsweise | Zugriffe prüfen: wer welche Rolle auf den Plattform-Subscriptions hat, sowie Gast- und deaktivierte Konten | Zugriff und PIM |
| Jährlich | Kontaktliste, Rufbereitschaftsweg und Eskalationspfad für Major Incidents sowie die Liste der Personen prüfen, die einen Provider-P1 melden dürfen | Incident-Management |
| Bei Bedarf | Nicht mehr genutzte Spokes und Subscriptions außer Betrieb nehmen | Einen Spoke löschen |
Ablauf von Secrets und Zertifikaten¶
Abgelaufene Secrets und Zertifikate sind eine häufige Ursache für fehlschlagende pipelines und Anwendungen.
- Liste alles auf, was innerhalb der Vorlaufzeit abläuft: Deployment-Identitäten, Service Principals der Spokes, App-Gateway- Zertifikate im Key Vault und App-Registrierungen, die im Tenant existieren.
- Finde für jeden Eintrag den Owner. Bei Plattform-Identitäten ist das das Plattform-Team. Bei App-Registrierungen, die zu einem Workload gehören, das Workload-Team.
- Rotiere oder erneuere vor dem Ablauf, oder ersetze das Secret durch eine föderierte Credential, wo der Service das unterstützt.
- Halte die Rotation im Change-Eintrag fest und prüfe den nächsten Lauf der pipeline, die das Secret verwendet.
- Entferne Registrierungen, die niemandem gehören, nach einer Vorankündigungsfrist.
Eine geplante Prüfung, die vor dem Ablauf alarmiert, ist unter Secret Watcher beschrieben. Details zur Rotation der plattformeigenen Identitäten stehen in den Betriebsverantwortlichkeiten und unter Spoke ändern.
Wartung ankündigen¶
Für geplante Arbeiten, die Workloads unterbrechen können (eine neue Plattformversion, Firewall-Änderungen, die kurze Unterbrechungen verursachen können, Patch-Fenster):
| Schritt | Was |
|---|---|
| Planen | Wähle ein Fenster außerhalb der Spitzenzeiten der Workloads und meide bekannte geschäftliche Spitzen. Prüfe, dass für denselben Bereich keine andere Änderung geplant ist |
| Ankündigen | Sende die Mitteilung an den <announcement channel> und an die betroffenen Workload-Kontakte, mit der Vorlaufzeit deines Service Levels: was, wann, erwartete Auswirkung, wen man kontaktiert |
| Testen | Führe die Änderung zuerst auf canary aus. Zeigt canary Timeouts oder unerwartete Destroys, stoppe und teile die Änderung auf (Post-Mortems) |
| Durchführen | Halte die betroffenen Workload-Kontakte während der Arbeit im vereinbarten Rhythmus informiert |
| Abschließen | Sag ihnen, wenn es erledigt ist, und halte das Ergebnis fest |
Patch-Fenster für Managed VMs (nur wenn deine Plattform sie anbietet)¶
Der MCP-Kern patcht die VMs der Workload-Teams nicht: Das bleibt beim Workload-Team (Verantwortlichkeiten). Ergänzt deine Plattform ein Managed-VM-Angebot, ist ein verbreitetes Muster, mit Azure Update Manager und Maintenance Configurations zu patchen, die automatisch über einen Tag zugewiesen werden. Ein Muster einer Managed Platform:
| Punkt | Beispiel |
|---|---|
| Klassen | Business-critical und non-business-critical. Die Klasse ergibt sich aus der geschäftlichen Klassifizierung des Workloads |
| Fenster | Ein monatliches Fenster pro Klasse, außerhalb der Bürozeiten, etwa zwei Stunden, in einer benannten Zeitzone. Das Business-critical-Fenster liegt eine Woche nach dem Non-business-critical-Fenster, damit Probleme zuerst auf den weniger kritischen Systemen auftreten |
| Dringende Patches | Außerplanmäßig: die Non-business-critical-Klasse am selben Tag, die Business-critical-Klasse am Tag danach |
| Inhalt | Critical-, Security- und Update-Rollup-Klassifizierungen für Windows. Critical, Security und Other für Linux |
| Neustart | Neustart, falls erforderlich |
| Zuweisung | Ein Tag auf der VM (zum Beispiel PatchPriority) wählt die Maintenance Configuration über einen dynamischen Scope aus, sodass neue Subscriptions und VMs ohne Änderungen an der Konfiguration erfasst werden. Nicht getaggte VMs werden dadurch nicht gepatcht |
| Gestoppte VMs | Eine VM mit Auto-Shutdown-Zeitplan wird vor dem Fenster gestartet und danach mit einem Pre-Event und Post-Event wieder gestoppt |
| Benachrichtigungen | Optional: eine Nachricht an das Workload-Team nach dem Update oder einige Tage vorher |
Plane mindestens 40 Minuten vor Beginn des Fensters ein, damit Pre-Events laufen können. Passt eine VM in kein Fenster, vereinbare eine Ausnahme mit dem Plattform-Team. Fehlgeschlagene Patch-Läufe stehen im monatlichen Health Check.