Asset-Management

Wie das Plattform-Team den Überblick über das behält, was es betreut: was ein Asset ist, wo die Wahrheit darüber liegt, wie es getaggt wird und wie du jederzeit eine Übersicht der aktiven Assets erzeugst. Derselbe Ansatz funktioniert in beiden Betriebsmodellen.

Scope

Alle Azure-Ressourcen, die das Plattform-Team betreut: der hub, die spoke-Baselines und optionale Angebote wie die Managed Virtual Machines. Ressourcen, die ein workload-Team selbst deployt, sind Assets des workload-Teams (Verantwortlichkeiten).

Strategie: zwei Quellen der Wahrheit, die übereinstimmen müssen

Quelle	Enthält	Beantwortet
Das Git-Repository mit der Infrastructure as Code (Code- und Konfigurations-Repositories)	Den Soll-Zustand	Was existieren soll, warum, seit wann und wer es genehmigt hat
Azure selbst	Den Ist-Zustand	Was gerade jetzt existiert

Alles, was die Plattform betreut, wird aus Code deployt. Es gibt keine separate Asset-Datenbank, die du von Hand synchron halten müsstest: Das Deployment, das eine Ressource erstellt, ist das Artefakt, das sie festhält. Eine Tabelle driftet. Ein Repository plus eine Live-Abfrage kann das nicht, weil ein Unterschied zwischen beiden selbst der Befund ist (Drift, gefunden vom wöchentlichen Plan-Lauf im Wartungskalender).

Für spokes führt die pipeline spoke drift detection diese Prüfung pro spoke-Datei aus und speichert einen Report.

Für Ressourcen unter Terraform-Verwaltung sind manuelle Änderungen im Azure-Portal nicht erlaubt. Das Repository ist die einzige Quelle der Wahrheit, und eine Änderung, die nicht darüber lief, ist eine Abweichung (Incident-Management).

Das ergibt drei Eigenschaften:

Eigenschaft	Bedeutung
Versioniert	Jedes Asset und jede Eigenschaft, auch Tags, hat eine Commit-Historie: wann sie hinzugefügt, geändert oder entfernt wurde und in welchem pull request
Reproduzierbar	Die Umgebung lässt sich aus dem Repository neu aufbauen
Geprüft	Ein Asset kommt über einen pull request mit einem zweiten Reviewer in den Bestand (Pull-Request-Review), nicht über einen spontanen Klick

Halte die Dokumentation eines Assets im selben Repository wie seinen Code, damit sich Beschreibung und Definition im selben pull request ändern.

Tagging

Tags identifizieren und gruppieren Ressourcen über ihre Ressourcen-ID hinaus: die Umgebung, den Owner, die Anwendung oder den Kostenverantwortlichen.

Das Tag-Set wird pro Organisation vereinbart, weil es zu deren Kostenzuordnung und Ownership-Modell passen muss. Standard ist, wie Tags behandelt werden:

• Tags werden im Infrastructure-as-Code-Repository definiert, nie von Hand gesetzt. Hub-Tags: Hub-Tags. Spoke-Tags: die tags der spoke-JSON.
• Eine Änderung an einem Tag oder am Tag-Set ist ein pull request wie jede andere Änderung, also geprüft und nachvollziehbar.
• Weil Tags beim Deployment gesetzt werden, trägt jede über die pipeline deployte Ressource sie. Eine Ressource ohne sie wurde nicht über deinen Prozess deployt.
• Tags dienen dem Abfragen: Kostenzuordnung, Filtern eines Dashboards auf eine Anwendung oder Umgebung und Eingrenzen einer Impact-Analyse, wenn eine Schwachstelle oder ein Incident eine Klasse von Ressourcen betrifft.
• Wenn Tags erzwungen und nicht nur angewendet werden sollen, verwende Azure Policy (Policy-Zuweisungen, Governance-Assessment).

Plattform-Tags auf Managed Virtual Machines

Wenn deine Plattform das Managed-VM-Modul anbietet, fügt es der resource group jedes VM-Konfigurationssets eigene Tags hinzu, damit sich eine Ressource zu der Konfiguration zurückverfolgen lässt, die sie erstellt hat. Beispiel aus einer Version des Moduls:

Tag	Identifiziert
source	Das Deployment, aus dem die Ressourcen stammen
vm_configuration	Das VM-Konfigurationsset
environment	Die Umgebung des Sets
os_type	Windows oder Linux
vm_size	Die VM-SKU
public_ip	Ob eine öffentliche IP angebunden ist
shutdown_schedule_hours	Der Shutdown-Zeitplan
owner1, owner2, ...	Die Owner der Konfiguration, je ein Tag

Die Tags, die der Kunde definiert, werden zusätzlich auf die VM-Ressourcen angewendet. Prüfe, welche Tags deine Modulversion schreibt, bevor du dich auf diese Tabelle verlässt.

Asset-Details innerhalb der Maschine

Tags und Azure Resource Graph beschreiben die Azure-Ressource. Bei virtuellen Maschinen musst du auch wissen, was auf der Maschine ist. Mit dem Managed-VM-Modul deckt das Change Tracking and Inventory ab: eine VM-Extension plus eine Data Collection Rule, die an den Log-Analytics-Workspace sendet. Es verfolgt installierte Software, Dateien, Registry-Schlüssel und Services oder Daemons unter Windows und Linux, sodass das Software-Inventar abfragbar ist und seine Historie rekonstruiert werden kann. Update Manager ergänzt den Patch-Stand jeder VM, sodass die Update-Compliance Teil des Asset-Datensatzes ist.

Abfragen und Reporting

Mittel	Verwendung
Azure Resource Graph	Ein Inventar der aktiven Ressourcen erstellen, gefiltert nach beliebigen Tags, bei Bedarf statt im Voraus gepflegt. Abfragen: Asset-Abfragen
Dashboards	Ein Dashboard-Tool wie Grafana mit der Azure-Monitor-Datenquelle bietet einen Ort, an dem du aktive Ressourcen und ihren Zustand siehst, mit Drill-down ins Portal (Monitoring)
Monatlicher Health Check	Eine datierte Reihe von Berichten, sodass du Trends siehst und nicht nur eine Momentaufnahme (Monatlicher Health Check)
Kosten-Tooling	Kosten-Scans berichten über dieselben Ressourcen von der Verbrauchsseite, was über- und untergenutzte Assets zeigt (Kosten und Reservierungen). Für zentrales Reporting über alle subscriptions siehe den Billing export

Assets mit den Systemen verbinden, die den Service betreiben

System	Verbindung
Work Tracking (Azure DevOps oder GitHub)	Jede Änderung an einem Asset ist ein Work Item und ein pull request, sodass die Historie eines Assets mit dem Grund seiner Änderung verknüpft ist
On-Call- und Incident-Tool	Alerts auf einer Ressource erreichen die diensthabenden Personen (So funktioniert Alerting)
Ticketing-Tool des Kunden	Wo der Kunde ein eigenes Tool betreibt, synchronisiere die Work Items, damit Assets und Änderungen auch dort sichtbar sind

Lifecycle

Phase	Was mit dem Asset-Datensatz passiert
Onboarding	Die Umgebung wird in Code beschrieben und deployt. Assets existieren ab dem ersten Commit im Repository
Änderung	Ein pull request. Die Commit-Historie ist der Audit-Trail
Monatliches Review	Wird im monatlichen Health Check berichtet und mit dem Kunden besprochen
Offboarding	In umgekehrter Reihenfolge des Onboardings entfernt, einschließlich subscription, Entra-ID-Objekten und allem Kosten-Tooling (Einen spoke löschen)

Rollen und Kontrolle

Rolle	Verantwortung
Solution oder Service Owner	Das Asset-Modell: was deployt ist, wie es getaggt ist, wie es berichtet wird
Customer Lead oder Service Owner auf Kundenseite	Das Tag-Set und seine Passung zum Kostenmodell des Kunden
Plattform-Engineers	Deployen und ändern Assets über Code und pull requests

Aktivität	Häufigkeit
Peer Review jeder Änderung an einem Asset oder seinen Tags	Pro Änderung
Monatlicher Health-Bericht	Monatlich
Kosten-Scan oder -Assessment, um den Verbrauch mit dem deployten Bestand abzugleichen	Mehrmals im Jahr, abhängig von den Ausgaben
Review des Bestands mit dem Kunden	Monatlich, im taktischen Meeting (Meetings)