In diesem Dokument finden Sie eine Anleitung zum Entwerfen einer effektiven Labelstrategie für Ihre Organisation. Bevor Sie mit dem Erstellen von Labels beginnen, finden Sie hier einige allgemeine Grundsätze, die Sie beim Organisieren Ihrer Google Cloud Ressourcen mit Labels verwenden können.
Allgemeine Grundsätze für Labels
Immer Labels verwenden
Labels sind zwar nicht obligatorisch, 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 die strengen Labelrichtlinien einhalten. Wir empfehlen Ihnen, eine formelle Labelrichtlinie zu erstellen, die mit den wichtigsten Stakeholdern in der Organisation abgestimmt ist. Die Beispieltabelle zeigt, wie eine organisationsweite Labelrichtlinie aussehen kann.
Labels programmatisch anwenden, um Konsistenz zu gewährleisten
Wenden Sie Labels nach Möglichkeit programmatisch an. Mit Tools wie Script und Terraform können Sie die Labelerstellung automatisieren und die Labelrichtlinie erzwingen. Diese Tools sorgen dafür, dass Labels konsistent auf alle Ihre Ressourcen angewendet werden. Verwenden Sie für die Labelerstellung ein Format, bei dem die Groß- und Kleinschreibung beachtet wird, und wenden Sie es konsistent auf alle Ressourcen an.
Labels standardisieren
Verwenden Sie für alle Ihre Ressourcen einen konsistenten und standardmäßigen Satz von Labels. So lassen sich Ihre Ressourcen einfacher suchen, filtern und verwalten. Um Ihre Labelstrategie zu vereinfachen, sollten Sie nicht mehr als zehn Labels verwenden. Richten Sie Ihre Labels danach aus, wie Sie Kosten erfassen möchten. Verwenden Sie einen Standardsatz von Labelschlüsseln und ‑werten, 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.
Die Standardisierung und Einhaltung einer Labelrichtlinie ist für zentral verwaltete Labels von entscheidender Bedeutung. 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 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-hipaa
Vertrauliche Informationen vermeiden
Der Schutz personenbezogener Daten ist für die Sicherheit von entscheidender Bedeutung. Vermeiden Sie es, personenbezogene Daten oder andere vertrauliche Informationen in Ihren Labels zu speichern.
Nicht standardmäßige Labels anwenden
Die Einhaltung einer Labelrichtlinie ist zwar von entscheidender Bedeutung, Labels können aber auch verwendet werden, um
Informationen zu teilen, die für ein bestimmtes Produktteam oder eine bestimmte Abteilung relevant sind. In einem solchen Szenario,
kann es hilfreich sein, Ressourceninhabern einzelner Teams die Möglichkeit zu geben, nicht standardmäßige Labels
für jede Ressource anzuwenden, um mehr Kontext zu der Ressource zu liefern. So lassen sich Informationen, die für diese Produktteams
oder Abteilungen spezifisch sind, einfacher suchen, filtern und teilen. Eine einzelne Ressource kann beispielsweise eine Reihe von
Standardlabels haben, z. B. environment:prod, data-classification:restricted,
cost-center:c23543, team:shopping-cart, app:shopping-cart-payments,
component:database, compliance: pci. 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 Labelstrategie ändert sich wahrscheinlich mit den sich ändernden geschäftlichen Anforderungen. Sie sollten sich der Auswirkungen bewusst sein, die diese Änderungen haben können. Beispielsweise kann die Hinzufügung neuer Kostenstellen, Microservices oder neuer Tools Ihre Labelstrategie beeinflussen.
Namensschema und Muster für Labels
Jede Organisation hat ihre eigene Art, Ressourcen zu organisieren. Sie können Labels verwenden, um die Ressourcen in Ihrer Hierarchie auf verschiedene Weise zu kategorisieren, damit Nutzer nach den benötigten Ressourcen filtern können. Beachten Sie beim Definieren Ihres Namensschemas für Labels 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 zustandsbehaftete Systeme.
- Labels, die auf der Ebene der jeweiligen Ressource angewendet werden müssen, z. B. Compute Engine, Cloud Storage-Bucket oder auf Projektebene.
- Flexibilität, optionale Labels nach Bedarf zu verwenden, um weitere Informationen zu Ressourcen bereitzustellen.
Labelcodierung und unterstützte Zeichen
Alle Zeichen für Schlüssel und Werte müssen UTF-8-codiert sein. Internationale Zeichen sind zulässig. Schlüssel müssen mit einem Kleinbuchstaben oder einem internationalen Zeichen beginnen. Schlüssel und Werte dürfen nur Kleinbuchstaben, Ziffern, Unterstriche und Bindestriche enthalten.
Beispiel für das Definieren von Labels
Beim Definieren von Labels müssen Sie einige Attribute berücksichtigen.
| Feld | Beschreibung |
|---|---|
| Labelschlüssel | Der Labelschlüssel ist eine eindeutige Kennung für ein Label. Er muss ein String mit einer Mindestlänge von 1 Zeichen und einer Höchstlä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äftliche Anwendungsfälle wie environment, data-classification, cost-center, team, component, application und compliance abdecken. |
| Labelwert | Der Labelwert sind die Daten, die mit dem Schlüssel verknüpft sind. Er kann ein String, eine Zahl oder ein boolescher Wert sein. Als Best Practice sollten Sie einen Satz von Werten für jeden Labelschlüssel definieren. So können Teams die entsprechenden 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. Beispielsweise möchte die Finanzabteilung einer Organisation die Kosten für den Betrieb der prod-Umgebung ermitteln. Dazu verwendet sie das Schlüssel:Wert-Paar environment:prod. |
| Zielressource | Definieren Sie für jedes Label eine Ziel Google Cloud ressource, auf die das Schlüssel:Wert-Paar angewendet werden soll. Der Labelschlüssel environment muss beispielsweise für jede Google Cloud Ressource in der Produktionsumgebung Ihrer Organisation vorhanden sein. |
| Ausnahme | Definieren Sie, welche Labelschlüssel für alle Ressourcen obligatorisch sind und welche optional angewendet werden können. In der Beispieltabelle gibt es einige optionale Label-key:valuePaare, 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 | public, internal-only, confidential, restricted, na | Sicherheit | Buckets, Datenbanken, nichtflüchtige Festplatten mit Compute Engine | Nein |
| altostrat-cost-center | fin-us, mkt-eu, it-jp | Finanzen | Google Cloud Ressourcen | Sandbox-Ordner |
| 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. Es gibt eine Ausnahme für Mandantenressourcen, bei denen keine 1:1-Zuordnung zur Anwendung besteht. |
| altostrat-compliance | pci, hipaa | Sicherheit | Google Cloud Ressourcen | Optional |