In diesem Dokument erfahren Sie, wie Sie eine effektive Labelstrategie für Ihre Organisation entwerfen. Bevor Sie mit dem Erstellen von Labels beginnen, sollten Sie die folgenden allgemeinen Prinzipien beachten, wenn Sie Ihre Google Cloud-Ressourcen mithilfe von Labels organisieren.
Allgemeine Prinzipien für Labels
Immer Labels verwenden
Labels sind zwar nicht obligatorisch, sind aber hilfreich beim Organisieren und Verwalten Ihrer Google Cloud-Ressourcen. Labels können verwendet werden, um Kosten zu verfolgen und Ressourcen zu identifizieren. Wenn Sie Labels für Ihre Ressourcen verwenden, müssen Sie strenge Labelrichtlinien einhalten. Wir empfehlen, eine formelle Richtlinie für die Labelerstellung zu erstellen, die mit den wichtigsten Stakeholdern in der Organisation übereinstimmt. Die Beispieltabelle zeigt, wie eine organisationsweite Labeling-Richtlinie aussieht.
Labels aus Konsistenzgründen programmatisch anwenden
Wenden Sie Labels nach Möglichkeit programmatisch an. Mit Tools wie Script und Terraform können Sie die Labelerstellung automatisieren und die Labeling-Richtlinie erzwingen. Diese Tools sorgen dafür, dass Labels einheitlich auf alle Ressourcen angewendet werden. Bei Labels wird zwischen Groß- und Kleinschreibung unterschieden und die Regel wird einheitlich auf alle Ressourcen angewendet.
Labels standardisieren
Verwenden Sie für alle Ressourcen einen einheitlichen Satz von Standardlabels. Dies vereinfacht das Suchen, Filtern und Verwalten Ihrer Ressourcen. Um Ihre Labelstrategie zu vereinfachen, sollten Sie nicht mehr als zehn Labels verwenden. Stimmen Sie Ihre Labels danach ab, wie Sie Kosten melden möchten. Ziehen Sie die Verwendung eines Standardsatzes von Labelschlüsseln und -werten in Betracht, die für Ihre Organisation am besten geeignet sind. Ihre Labels können geschäftliche Anwendungsfälle wie Umgebung, Datenklassifizierung, Kostenstelle, Team, Komponente, Anwendung und Compliance abdecken.
Beachten Sie, dass die Standardisierung und Einhaltung einer Labeling-Richtlinie für zentral verwaltete Labels von entscheidender Bedeutung ist. Produktteams und Abteilungen können Ressourcen auch benutzerdefinierte Labels hinzufügen, um teamspezifische Informationen zu teilen. Weitere Informationen finden Sie unter Nicht standardmäßige Labels anwenden.
Hier sehen Sie ein Beispiel dafür, wie Sie einen Standardsatz von Werten für jeden der Schlüssel definieren können:
- Umgebung:
prod/dev/staging - Datenklassifizierung:
public/internal-only/confidential/restricted/na - Kostenstelle:
c23543 - Team:
shopping-cart - Komponente:
frontend/cache/backend/database - Anwendung:
shopping-cart-payments - Compliance:
pci-hippa
Vertrauliche Informationen vermeiden
Der Schutz personenidentifizierbarer Informationen ist für die Sicherheit von entscheidender Bedeutung. Vermeiden Sie es, personenidentifizierbare Informationen oder andere vertrauliche Informationen in Ihren Labels zu speichern.
Nicht standardmäßige Labels anwenden
Obwohl die Einhaltung einer Label-Richtlinie von entscheidender Bedeutung ist, können Labels auch verwendet werden, um Informationen zu teilen, die für ein Produktteam oder eine Abteilung spezifisch sind. In einem solchen Szenario kann die Angabe von Ressourceninhabern einzelner Teams, für jede Ressource nicht standardmäßige Labels anzuwenden, dazu beitragen, mehr Kontext zur Ressource bereitzustellen. Dies vereinfacht das Suchen, Filtern und Teilen von Informationen, die für diese Produktteams oder Abteilungen spezifisch sind. Beispielsweise kann eine einzelne Ressource eine Reihe von Standardlabels wie environment:prod, data-classification:restricted, cost-center:c23543, team:shopping-cart, app:shopping-cart-payments, component:database, compliance: pci haben. Der Ressourceninhaber kann nicht standardmäßige Labels wie version:5.0.1 und replica:primary hinzufügen, um die Version des Datenbankclusters und den Replikationsstatus des Knotens anzugeben.
Auswirkungen der Änderung berücksichtigen
Ihre Labeling-Strategie ändert sich wahrscheinlich, wenn sich die Geschäftsanforderungen ändern. Seien Sie sich der möglichen Auswirkungen dieser Änderungen bewusst. Das Hinzufügen neuer Kostenstellen, Mikrodienste oder neuer Tools kann sich beispielsweise auf Ihre Labeling-Strategie auswirken.
Namensschema und Muster für Labelnamen
Jede Organisation hat ihre eigene Art, Ressourcen zu organisieren. Sie können Labels verwenden, um die Ressourcen in Ihrer Hierarchie auf verschiedene Arten zu kategorisieren, sodass Nutzer nach den benötigten Ressourcen filtern können. Beachten Sie beim Definieren des Labelbenennungsschemas Folgendes:
- Mit der Ressource verknüpfte Umgebung, Kostenstelle, Team, Komponente, Anwendungen, Compliance und Eigentum.
- Datenklassifizierung aller im System gespeicherten Daten. Dies gilt nur für zustandsorientierte Systeme.
- Labels, die auf einer bestimmten Ressourcenebene wie Compute Engine, Cloud Storage-Bucket oder im Projekt angewendet werden müssen.
- Optionale Labels können bei Bedarf flexibel verwendet werden, um mehr Informationen zu Ressourcen bereitzustellen.
Beispiel für das Definieren von Labels
Beachten Sie beim Definieren von Labels die folgenden Attribute.
| Feld | Beschreibung |
|---|---|
| Labelschlüssel | Der Labelschlüssel ist eine eindeutige Kennung für ein Label. Es muss sich um einen String mit einer Mindestlänge von 1 Zeichen und einer maximalen Länge von 63 Zeichen handeln. Der Schlüssel darf nicht leer sein. Sie können einen Standardsatz von Labelschlüsseln verwenden, die für Ihre Organisation am besten geeignet sind, um geschäftliche Anwendungsfälle wie environment, data-classification, cost-center, team, component, application und compliance abzudecken. |
| Labelwert | Der Labelwert sind die mit dem Schlüssel verknüpften Daten. Es kann sich um einen String, eine Zahl oder einen booleschen Wert handeln. Es hat sich bewährt, für jeden Labelschlüssel eine Gruppe von Werten zu definieren. So können Teams geeignete Werte für jeden Schlüssel auswählen und zuweisen. Ein environment-Schlüssel kann beispielsweise Werte wie prod, staging, dev oder tools haben. |
| Stakeholder | Ermitteln Sie die Abteilung, die den Labelschlüssel zum Filtern von Ressourcen oder zum Erstellen von Berichten benötigt. Beispiel: Eine Finanzabteilung in einer Organisation möchte wissen, welche Kosten für die Ausführung der prod-Umgebung anfallen. In diesem Fall würde das Label key:value-Paar environment:prod verwendet. |
| Zielressource | Erwägen Sie, für jedes Label eine Google Cloud-Zielressource zu definieren, auf die das Label-Paar key:value angewendet werden soll. Der Labelschlüssel environment muss sich beispielsweise in jeder Google Cloud-Ressource in der Produktionsumgebung Ihrer Organisation befinden. |
| Ausnahme | Definieren Sie, welche Labelschlüssel für alle Ressourcen obligatorisch sind und welche Schlüssel optional angewendet werden können. In der Beispieltabelle gibt es einige Label-key:value-Paare, die optional sind, z. B. environment:tools. Der Labelschlüssel altostrat-team kann als optional angesehen werden, wenn für das Label altostrat-environment der Labelwert auf tools gesetzt ist. |
Im folgenden Labelbeispiel entspricht altostrat dem Namen des Unternehmens.
| Labelschlüssel | Labelwert | Stakeholder | Zielressource | Ausnahme |
|---|---|---|---|---|
| altostrat-umgebung | prod, sb1, staging, dev, tools, Staging, Entwicklung, Tools | Finanzen | Google Cloud-Ressourcen | Nein |
| Klassifizierung von „altostrat-daten“ | öffentlich, nur intern, vertraulich, eingeschränkt, na | Sicherheit | Buckets, Datenbanken, nichtflüchtige Speicher mit Compute Engine | Nein |
| altostrat-cost-center | fin-us, mkt-eu, it-jp | Finanzen | Google Cloud-Ressourcen | Sandbox-Ordner |
| altostrat-team | Einkaufswagen | Teamleiter | Google Cloud-Ressourcen | Nicht-Produktionsumgebungen, nicht kritische Komponenten |
| altostrat-Komponente | Front-End, Cache, Anwendung, Datenbank | Finanzen | Google Cloud-Ressourcen | Optional |
| Altostrat-App | Bezahlung des Einkaufswagens | Finanzen | Google Cloud-Ressourcen | Nein. Es gibt eine Ausnahme für mehrmandantenfähige Ressourcen, bei denen keine 1:1-Zuordnung zur Anwendung erfolgt. |
| altostrat-Compliance | PCI, HIPAA | Sicherheit | Google Cloud-Ressourcen | Optional |