In diesem Dokument finden Sie eine Anleitung zum Entwerfen einer effektiven Labelstrategie für Ihre Organisation. Bevor Sie mit dem Erstellen von Labels beginnen, sollten Sie sich mit den folgenden allgemeinen Prinzipien vertraut machen, die Sie beim Organisieren Ihrer Google Cloud-Ressourcen mithilfe von Labels beachten sollten.
Allgemeine Grundsätze für Labels
Verwenden Sie immer Labels.
Labels sind zwar nicht obligatorisch, aber hilfreich, um Ihre Google Cloud-Ressourcen zu organisieren und zu verwalten. Mit Labels können Sie Kosten erfassen und Ressourcen identifizieren. Beachten Sie bei der Verwendung von Labels für Ihre Ressourcen die strengen Richtlinien für das Labeling. Wir empfehlen Ihnen, eine formelle Kennzeichnungsrichtlinie zu erstellen, die mit den wichtigsten Stakeholdern in der Organisation abgestimmt ist. Die Beispieltabelle zeigt, wie eine organisationsweite Kennzeichnungsrichtlinie aussieht.
Labels programmatisch zur Konsistenz anwenden
Wenden Sie Labels nach Möglichkeit programmatisch an. Mit Tools wie Script und Terraform können Sie den Labelerstellungsprozess automatisieren und die Labelrichtlinien durchsetzen. Mit diesen Tools sorgen Sie dafür, dass Labels einheitlich auf alle Ihre Ressourcen angewendet werden. Verwenden Sie ein Format für die Kennzeichnung, das die Groß- und Kleinschreibung berücksichtigt, und wenden Sie es einheitlich auf alle Ressourcen an.
Labels standardisieren
Verwenden Sie für alle Ressourcen einheitliche und standardmäßige Labels. So können Sie Ihre Ressourcen leichter suchen, filtern und verwalten. Verwenden Sie nicht mehr als zehn Labels, um Ihre Labelstrategie zu vereinfachen. Passen Sie Ihre Labels an die Art der Kostenerfassung an. Verwenden Sie am besten einen Standardsatz von Labelschlüsseln und ‑werten, die für Ihre Organisation am besten geeignet sind. Ihre Labels können Geschäftsfälle wie Umgebung, Datenklassifizierung, Kostenstelle, Team, Komponente, Anwendung und Compliance abdecken.
Für zentral verwaltete Labels ist es wichtig, eine Labelrichtlinie zu standardisieren und einzuhalten. 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 ein Beispiel dafür, wie Sie für jeden Schlüssel einen Standardsatz von Werten 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 entscheidend für die Sicherheit. Speichern Sie keine personenidentifizierbaren Informationen oder andere vertraulichen Daten in Ihren Labels.
Nicht standardmäßige Labels anwenden
Die Einhaltung der Labelrichtlinien ist zwar wichtig, aber Labels können auch verwendet werden, um Informationen zu teilen, die für ein Produktteam oder eine Abteilung spezifisch sind. In einem solchen Szenario kann es hilfreich sein, den Ressourceneigentümern einzelner Teams die Möglichkeit zu geben, nicht standardmäßige Labels auf jede Ressource anzuwenden, um mehr Kontext zu der Ressource bereitzustellen. So können Sie Informationen, die speziell für diese Produktteams oder ‑abteilungen relevant sind, leichter suchen, filtern und freigeben. Eine einzelne Ressource kann beispielsweise eine Reihe von Standardlabels wie environment:prod, data-classification:restricted, cost-center:c23543, team:shopping-cart, app:shopping-cart-payments, component:database und 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 von Änderungen berücksichtigen
Ihre Kennzeichnungsstrategie wird sich wahrscheinlich ändern, wenn sich die Geschäftsanforderungen ändern. Beachten Sie die möglichen Auswirkungen dieser Änderungen. So kann sich beispielsweise die Hinzunahme neuer Kostenstellen, Microservices oder neuer Tools auf Ihre Labels auswirken.
Benennungsschema und -muster für Labels
Jede Organisation hat ihre eigene Art, Ressourcen zu organisieren. Mithilfe von Labels können Sie die Ressourcen in Ihrer Hierarchie auf unterschiedliche Weise kategorisieren und Nutzern so das Filtern nach den benötigten Ressourcen erleichtern. Berücksichtigen Sie beim Definieren Ihres Labelbenennungsschemas Folgendes:
- Umgebung, Kostenstelle, Team, Komponente, Anwendungen, Compliance und Inhaberschaft, die mit der Ressource verknüpft sind.
- 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 Projekt angewendet werden müssen.
- Sie können optionale Labels verwenden, um bei Bedarf weitere Informationen zu Ressourcen anzugeben.
Beispiel für die Definition von Labels
Bei der Definition von Labels sollten Sie Folgendes beachten:
| Feld | Beschreibung |
|---|---|
| Labelschlüssel | Der Labelschlüssel ist eine eindeutige Kennung für ein Label. Er muss ein String mit einer Mindestlänge von einem Zeichen und einer maximalen Länge von 63 Zeichen sein. 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 und Geschäftsnutzungsfälle abdecken, z. B. environment, data-classification, cost-center, team, component, application und compliance. |
| Labelwert | Der Labelwert ist der mit dem Schlüssel verknüpfte Datensatz. Es kann sich um einen String, eine Zahl oder einen booleschen Wert handeln. Als Best Practice empfehlen wir, für jeden Labelschlüssel eine Reihe 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 | Geben Sie die Abteilung an, die den Labelschlüssel zum Filtern von Ressourcen oder Erstellen von Berichten benötigt. Angenommen, die Finanzabteilung einer Organisation möchte die Kosten für die Ausführung der prod-Umgebung ermitteln. Dazu verwendet er das Label Schlüssel:Wert-Paar environment:prod. |
| Zielressource | Sie sollten für jedes Label eine Ziel-Google Cloud-Ressource definieren, auf die das Label-Schlüssel/Wert-Paar angewendet werden soll. Der Labelschlüssel environment muss beispielsweise auf jeder Google Cloud-Ressource in der Produktionsumgebung Ihrer Organisation vorhanden sein. |
| Ausnahme | Sie können festlegen, welche Labelschlüssel für alle Ressourcen obligatorisch und welche optional sind. 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 betrachtet werden, wenn für das Label altostrat-environment der Labelwert tools festgelegt ist. |
Im folgenden Labelbeispiel entspricht altostrat dem Namen des Unternehmens.
| Labelschlüssel | Labelwert | Stakeholder | Zielressource | Ausnahme |
|---|---|---|---|---|
| altostrat-environment | prod, sb1, staging, dev, tools | Finanzen | Google Cloud-Ressourcen | Nein |
| altostrat-data-classification | öffentlich, nur intern, vertraulich, eingeschränkt, – | Sicherheit | Bucket, Datenbanken, nichtflüchtige Speicher mit Compute Engine | Nein |
| altostrat-cost-center | fin-us, mkt-eu, it-jp | Finanzen | Google Cloud-Ressourcen | sandbox-folder |
| altostrat-team | shopping-cart | Teamleiter | Google Cloud-Ressourcen | Nicht-Produktionsumgebungen, nicht kritische Komponenten |
| altostrat-component | frontend, cache, application, database | Finanzen | Google Cloud-Ressourcen | Optional |
| altostrat-app | shopping-cart-payment | Finanzen | Google Cloud-Ressourcen | Nein. Eine Ausnahme gilt für Ressourcen mit mehreren Mietern, bei denen keine 1:1-Zuordnung zur Anwendung besteht. |
| altostrat-compliance | pci, hipaa | Sicherheit | Google Cloud-Ressourcen | Optional |