Onderhoudskalender¶
De meeste platformproblemen zijn goedkoper te voorkomen dan op te lossen. Deze pagina somt de terugkerende taken van het platformteam op per frequentie, en beschrijft hoe je onderhoud aankondigt. Gebruik haar om een kalender voor je team op te bouwen. Frequenties zijn suggesties: je contract of je eigen beleid beslist.
In het managed model voert het platformteam (XMMS) deze taken uit onder het contract. In het zelfbeheermodel is het je eigen platformteam (Beheermodellen).
Terugkerende taken¶
| Frequentie | Taak | Waar |
|---|---|---|
| Wekelijks | Driftcontrole: draai hub in de modus Plan. Elke wijziging die je niet hebt gecommit is drift |
Operationele verantwoordelijkheden |
| Wekelijks | Spoke-drift: lees het laatste spoke-driftrapport, als je de spoke drift pipeline draait | Spoke-driftdetectie |
| Wekelijks | Bekijk de alerts van de week: stem ruisende regels af, maak work items aan voor echte problemen | Monitoringregels, Hoe alerting werkt |
| Wekelijks | Draai de secret watcher en handel de alerts ervan af | Secret watcher |
| Wekelijks | Controleer de status van de pipelines van het platform (mislukte of vastgelopen runs) | Pipelines en workflows |
| Maandelijks | Maandelijkse health check en rapportage | Maandelijkse health check |
| Dagelijks (geautomatiseerd) | Billing export-run, als je kosten centraal rapporteert. Controleer een mislukte run | Billing export |
| Maandelijks | Bekijk policy-uitzonderingen (expires_on) |
Policy-toewijzingen |
| Maandelijks | Bekijk de aanbevelingen van Defender for Cloud en Advisor | Maandelijkse health check |
| Maandelijks | Secrets en certificaten die binnen de doorlooptijd verlopen (bijvoorbeeld 60 dagen) | Verloop van secrets en certificaten |
| Per release | Neem een nieuwe platformversie: eerst canary, dan prod. Lees elke upgradehandleiding tussen de huidige en de doelversie | Wat te doen als een nieuwe versie wordt gereleased, Upgradehandleidingen voor het platform |
| Per release | Controleer of de code je kopie van de coderepository heeft bereikt (nieuwe tag en branchgeschiedenis aanwezig) | Codesynchronisatie |
| Per release | Bouw de container image en de runners opnieuw | Wat te doen als een nieuwe versie wordt gereleased |
| Per kwartaal | Bekijk het servicelevel, post-mortem-acties en de roadmap | Meetings |
| Per kwartaal | Controleer de alertontvangers en de on-callroute: mensen die zijn vertrokken, geroteerde webhooks, een veranderde tool. Stuur een testalert | Monitoring uitrollen |
| Per kwartaal | Bekijk toegang: wie heeft welke rol op de platform-subscriptions, en de gast- en uitgeschakelde accounts | Toegang en PIM |
| Jaarlijks | Bekijk de contactlijst, de bereikbaarheidsroute en het escalatiepad voor major incidents, en de lijst van mensen die een provider-P1 mogen aanmelden | Incidentbeheer |
| Wanneer nodig | Buiten gebruik gestelde spokes en subscriptions opruimen | Een spoke verwijderen |
Verloop van secrets en certificaten¶
Verlopen secrets en certificaten zijn een veelvoorkomende oorzaak van falende pipelines en applicaties.
- Maak een lijst van alles wat binnen de doorlooptijd verloopt: deployment-identiteiten, service principals van spokes, App Gateway-certificaten in Key Vault en application registrations die in de tenant bestaan.
- Zoek bij elk item de eigenaar. Voor platformidentiteiten is dat het platformteam. Voor application registrations die bij een workload horen, het workload team.
- Roteer of vernieuw vóór het verlopen, of vervang de secret door een federated credential waar de service dat ondersteunt.
- Registreer de rotatie bij het wijzigingsrecord en controleer de eerstvolgende run van de pipeline die de secret gebruikt.
- Verwijder registrations die niemand beheert, na een aankondigingstermijn.
Een geplande controle die waarschuwt vóór het verlopen is beschreven in Secret watcher. Rotatiedetails voor de eigen identiteiten van het platform staan in Operationele verantwoordelijkheden en Spoke wijzigen.
Onderhoud aankondigen¶
Voor gepland werk dat workloads kan onderbreken (een nieuwe platformversie, firewallwijzigingen die korte onderbrekingen kunnen veroorzaken, patchvensters):
| Stap | Wat |
|---|---|
| Plannen | Kies een venster buiten de piekuren van de workloads en vermijd bekende bedrijfspieken. Controleer dat er geen andere wijziging voor hetzelfde gebied gepland is |
| Aankondigen | Stuur het bericht naar het <announcement channel> en naar de contactpersonen van de getroffen workloads, met de doorlooptijd van je servicelevel: wat, wanneer, verwachte impact, wie je kunt benaderen |
| Testen | Draai de wijziging eerst op canary. Toont canary time-outs of onverwachte destroys, stop dan en splits de wijziging (Post-mortems) |
| Uitvoeren | Houd de contactpersonen van de getroffen workloads tijdens het werk op de hoogte, in het afgesproken ritme |
| Afsluiten | Vertel ze wanneer het klaar is en leg het resultaat vast |
Patchvensters voor managed VM's (alleen als je platform ze biedt)¶
De MCP core patcht de VM's van workload teams niet: dat blijft bij het workload team (Verantwoordelijkheden). Voegt je platform een managed VM-aanbod toe, dan is een gangbaar patroon patchen met Azure Update Manager en maintenance configurations, automatisch toegewezen vanaf een tag. Een patroon van een managed platform:
| Onderdeel | Voorbeeld |
|---|---|
| Klassen | Business-critical en non-business-critical. De klasse volgt uit de bedrijfsclassificatie van de workload |
| Vensters | Eén maandelijks venster per klasse, buiten kantooruren, ongeveer twee uur, in een benoemde tijdzone. Het business-critical venster ligt een week na het non-business-critical venster, zodat problemen eerst op de minder kritieke systemen zichtbaar worden |
| Urgente patches | Out-of-band: de non-business-critical klasse dezelfde dag, de business-critical klasse de dag erna |
| Inhoud | Critical-, security- en update-rollup-classificaties voor Windows. Critical, security en other voor Linux |
| Reboot | Reboot indien nodig |
| Toewijzing | Een tag op de VM (bijvoorbeeld PatchPriority) selecteert via een dynamic scope de maintenance configuration, zodat nieuwe subscriptions en VM's worden opgepikt zonder aanpassingen aan de configuratie. VM's zonder tag worden er niet door gepatcht |
| Gestopte VM's | Een VM met een auto-shutdown-schema wordt vóór het venster gestart en erna gestopt met een pre-event en post-event |
| Meldingen | Optioneel: een bericht aan het workload team na de update, of een paar dagen ervoor |
Reken voor pre-events op minstens 40 minuten vóór de start van het venster. Past een VM in geen enkel venster, spreek dan een uitzondering af met het platformteam. Mislukte patchruns staan in de maandelijkse health check.