Assetbeheer

Hoe het platformteam bijhoudt wat het beheert: wat een asset is, waar de waarheid erover staat, hoe het wordt getagd, en hoe je op elk moment een overzicht van de actieve assets maakt. Dezelfde aanpak werkt in beide beheermodellen.

Scope

Alle Azure-resources die het platformteam beheert: de hub, de spoke-baselines en optionele aanbiedingen zoals de managed virtual machines. Resources die een workload team zelf uitrolt, zijn assets van het workload team (Verantwoordelijkheden).

Strategie: twee bronnen van waarheid die moeten overeenkomen

Bron	Bevat	Beantwoordt
De Git-repository met de infrastructure as code (code- en configuratierepositories)	De beoogde staat	Wat er hoort te bestaan, waarom, sinds wanneer en wie het heeft goedgekeurd
Azure zelf	De werkelijke staat	Wat er nu bestaat

Alles wat het platform beheert, wordt vanuit code uitgerold. Er is geen aparte assetdatabase die je met de hand synchroon moet houden: de deployment die een resource aanmaakt, is het artefact dat hem vastlegt. Een spreadsheet loopt uit de pas. Een repository plus een live query kan dat niet, omdat een verschil tussen die twee zelf de bevinding is (drift, gevonden door de wekelijkse Plan-run in de onderhoudskalender).

Voor spokes doet de spoke drift detection-pipeline deze controle per spoke-bestand en slaat hij een rapport op.

Voor resources onder Terraform-beheer zijn handmatige wijzigingen in de Azure-portal niet toegestaan. De repository is de enige bron van waarheid, en een wijziging die er niet doorheen is gegaan, is een afwijking (Afhandeling van incidenten).

Dit geeft drie eigenschappen:

Eigenschap	Betekenis
Versiebeheer	Elke asset en elke eigenschap, inclusief tags, heeft een commitgeschiedenis: wanneer ze is toegevoegd, gewijzigd of verwijderd, en in welke pull request
Reproduceerbaar	De omgeving kan uit de repository opnieuw worden opgebouwd
Gereviewd	Een asset komt het landschap binnen via een pull request met een tweede reviewer (Pull request review), niet via een ad-hocklik

Bewaar de documentatie van een asset in dezelfde repository als de code, zodat beschrijving en definitie in dezelfde pull request wijzigen.

Tagging

Tags identificeren en groeperen resources op meer dan hun resource-ID: de omgeving, de eigenaar, de applicatie of de kostenverantwoordelijke.

De tagset wordt per organisatie afgesproken, omdat die moet aansluiten op het model voor kostentoewijzing en eigenaarschap. Wat standaard is, is hoe tags worden behandeld:

• Tags worden gedefinieerd in de infrastructure as code-repository en nooit met de hand toegepast. Hub-tags: Hub-tags. Spoke-tags: de tags van de spoke-JSON.
• Een wijziging van een tag of de tagset is een pull request zoals elke andere wijziging, dus gereviewd en herleidbaar.
• Omdat tags bij de deployment worden gezet, dragen alle resources die via de pipeline zijn uitgerold ze. Een resource zonder tags is niet via jullie proces uitgerold.
• Tags worden gebruikt om te bevragen: kostentoewijzing, een dashboard filteren op één applicatie of omgeving, en de impactanalyse afbakenen als een kwetsbaarheid of een incident een klasse resources raakt.
• Wil je dat tags worden afgedwongen en niet alleen toegepast, gebruik dan Azure Policy (Policy-toewijzingen, Governance-assessment).

Platformtags op managed virtual machines

Als je platform de managed VM-module aanbiedt, voegt die eigen tags toe aan de resource group van elke VM- configuratieset, zodat een resource herleid kan worden tot de configuratie die hem heeft aangemaakt. Voorbeeld uit één versie van de module:

Tag	Identificeert
source	De deployment waar de resources vandaan komen
vm_configuration	De VM-configuratieset
environment	De omgeving van de set
os_type	Windows of Linux
vm_size	De VM-SKU
public_ip	Of er een publiek IP-adres is gekoppeld
shutdown_schedule_hours	Het uitschakelschema
owner1, owner2, ...	De eigenaren van de configuratie, elk met een eigen tag

De tags die de klant definieert, worden naast deze tags op de VM-resources toegepast. Controleer welke tags jouw moduleversie schrijft voordat je op deze tabel vertrouwt.

Assetdetail binnen de machine

Tags en Azure Resource Graph beschrijven de Azure-resource. Voor virtual machines moet je ook weten wat er op de machine staat. Met de managed VM-module wordt dat gedekt door Change Tracking and Inventory: een VM-extensie plus een data collection rule die naar de Log Analytics-workspace stuurt. Het volgt geïnstalleerde software, bestanden, registersleutels en services of daemons op Windows en Linux, zodat de software-inventaris bevraagbaar is en de geschiedenis kan worden gereconstrueerd. Update Manager voegt de patchstatus van elke VM toe, zodat updatecompliance deel uitmaakt van het assetrecord.

Bevragen en rapporteren

Middel	Gebruik
Azure Resource Graph	Maak een inventaris van de actieve resources, gefilterd op elke tag, op verzoek in plaats van vooraf bijgehouden. Queries: Assetqueries
Dashboards	Een dashboardtool zoals Grafana, met de Azure Monitor-databron, geeft één plek om actieve resources en hun gezondheid te zien, met drill-down naar de portal (Monitoring)
Maandelijkse health check	Een reeks gedateerde rapporten, zodat je trends ziet en niet alleen een momentopname (Maandelijkse health check)
Kostentooling	Kostenscans rapporteren over dezelfde resources vanuit de verbruikskant, waardoor over- en onderbenutte assets zichtbaar worden (Kosten en reservations). Voor centrale rapportage over alle subscriptions, zie de billing export

Assets koppelen aan de systemen die de dienst draaien

Systeem	Koppeling
Work tracking (Azure DevOps of GitHub)	Elke wijziging aan een asset is een work item en een pull request, zodat de geschiedenis van een asset is gekoppeld aan de reden van de wijziging
Tool voor bereikbaarheid en incidenten	Alerts op een resource bereiken de mensen met dienst (Hoe alerting werkt)
Ticketingtool van de klant	Draait de klant een eigen tool, synchroniseer dan de work items zodat assets en wijzigingen ook daar zichtbaar zijn

Levenscyclus

Fase	Wat er met het assetrecord gebeurt
Onboarding	De omgeving wordt in code beschreven en uitgerold. Assets bestaan in de repository vanaf de eerste commit
Wijziging	Een pull request. De commitgeschiedenis is het audit trail
Maandelijkse review	Gerapporteerd in de maandelijkse health check en besproken met de klant
Offboarding	Verwijderd in omgekeerde volgorde van de onboarding, inclusief de subscription, Entra ID-objecten en eventuele kostentooling (Een spoke verwijderen)

Rollen en beheersing

Rol	Verantwoordelijkheid
Solution owner of service owner	Het assetmodel: wat er is uitgerold, hoe het is getagd, hoe erover wordt gerapporteerd
Customer lead of service owner aan de kant van de klant	De tagset en hoe die past bij het kostenmodel van de klant
Platform engineers	Rollen assets uit en wijzigen ze via code en pull requests

Activiteit	Frequentie
Peer review van elke wijziging aan een asset of de tags ervan	Per wijziging
Maandelijks healthrapport	Maandelijks
Kostenscan of -assessment, om verbruik af te stemmen op het uitgerolde landschap	Een paar keer per jaar, afhankelijk van de uitgaven
Review van het landschap met de klant	Maandelijks, in het tactische overleg (Overleggen)