Eine effektive Labelstrategie hilft Ihnen, IhreGoogle Cloud -Ressourcen in Ihrer Organisation zu organisieren und zu verfolgen. Bevor Sie Labels erstellen, sollten Sie sich diese allgemeinen Grundsätze ansehen, um eine einheitliche Ressourcenverwaltung zu erreichen.
Allgemeine Grundsätze für Labels
Labels immer verwenden
Labels sind zwar nicht obligatorisch, aber hilfreich, um IhreGoogle Cloud -Ressourcen zu organisieren und zu verwalten. 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 Labeling-Richtlinie zu erstellen, die mit den wichtigsten Stakeholdern in der Organisation abgestimmt ist. Die Beispieltabelle zeigt, wie eine organisationsweite Labelrichtlinie aussieht.
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 den Prozess der Labelerstellung automatisieren und die Labelrichtlinie durchsetzen. Mit diesen Tools können Sie dafür sorgen, dass Labels auf alle Ihre Ressourcen einheitlich angewendet werden. Verwenden Sie ein Format mit Berücksichtigung der Groß-/Kleinschreibung für die Labelerstellung und wenden Sie es einheitlich auf alle Ressourcen an.
Labels standardisieren
Verwenden Sie für alle Ihre Ressourcen einen einheitlichen und standardmäßigen Satz von Labels. So können Sie Ihre Ressourcen leichter 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 melden möchten. 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ä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 entscheidend 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 ist 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-hipaa
Keine vertraulichen Informationen angeben
Der Schutz personenidentifizierbarer Informationen (PII) 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
Die Einhaltung einer Labelrichtlinie 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, für jede Ressource nicht standardmäßige Labels anzuwenden, um mehr Kontext zur Ressource bereitzustellen. So lassen sich Informationen, die für diese Produktteams oder Abteilungen spezifisch 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, compliance: pci haben. Der Ressourceneigentümer 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 Labeling-Strategie wird sich wahrscheinlich ändern, wenn sich die Geschäftsanforderungen weiterentwickeln. Beachten Sie die möglichen Auswirkungen dieser Änderungen. Beispielsweise kann das Hinzufügen neuer Kostenstellen, Mikrodienste oder neuer Tools Auswirkungen auf Ihre Labelstrategie haben.
Namensschema und Muster für Labels
Jede Organisation hat ihre eigene Art, Ressourcen zu organisieren. Mit Labels können Sie die Ressourcen in Ihrer Hierarchie auf verschiedene Arten kategorisieren, damit Nutzer nach den benötigten Ressourcen filtern können. Beachten Sie beim Definieren des Benennungsschemas 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 zustandsorientierte Systeme.
- Labels, die auf der Ebene einer bestimmten Ressource wie Compute Engine, Cloud Storage-Bucket oder auf Projektebene angewendet werden müssen.
- Flexibilität, optionale Labels nach Bedarf zu verwenden, um weitere Informationen zu Ressourcen bereitzustellen.
Labelcodierung und unterstützte Zeichen
Alle Schlüssel- und Wertzeichen müssen die UTF-8-Codierung verwenden. 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 die Definition von Labels
Hier sind einige Attribute, die Sie beim Definieren von Labels berücksichtigen müssen.
| Feld | Beschreibung |
|---|---|
| Labelschlüssel | Der Labelschlüssel ist eine eindeutige Kennung für ein Label. Es muss ein String mit einer Mindestlänge von 1 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äftliche Anwendungsfälle wie environment, data-classification, cost-center, team, component, application und compliance abdecken. |
| Labelwert | Der Labelwert sind die mit dem Schlüssel verknüpften Daten. Es kann ein String, eine Zahl oder ein boolescher Wert sein. Als Best Practice sollten Sie für jeden Labelschlüssel eine Reihe von Werten definieren. So können Teams die passenden Werte für jeden Schlüssel auswählen und zuweisen. Beispielsweise kann ein Schlüssel environment 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. Beispielsweise möchte die Finanzabteilung einer Organisation die Kosten für die Ausführung der prod-Umgebung erfahren. Sie würden das Label-Schlüssel/Wert-Paar environment:prod verwenden. |
| Zielressource | Überlegen Sie sich für jedes Label, ob Sie eine Zielressource Google Cloud definieren möchten, auf die das Schlüssel/Wert-Paar des Labels angewendet werden soll. Beispiel: Der Labelschlüssel environment muss für jede Google Cloud -Ressource in der Produktionsumgebung Ihrer Organisation vorhanden sein. |
| Ausnahme | Überlegen Sie, welche Labelschlüssel für alle Ressourcen obligatorisch und welche optional sind. In der Beispieltabelle gibt es einige optionale Label-key:value-Paare, z. B. environment:tools. Der Labelschlüssel altostrat-team kann als optional betrachtet werden, wenn für das Label altostrat-environment der Labelwert auf tools gesetzt ist. |
Im folgenden Beispiel 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 Speicher mit Compute Engine | Nein |
| altostrat-cost-center | fin-us, mkt-eu, it-jp | Finanzen | Google Cloud -Ressourcen | sandbox-folder |
| altostrat-team | Einkaufswagen | Teamleiter | Google Cloud -Ressourcen | Nicht-Produktionsumgebungen, nicht kritische Komponenten |
| altostrat-component | Frontend, Cache, Anwendung, Datenbank | Finanzen | Google Cloud -Ressourcen | Optional |
| altostrat-app | shopping-cart-payment | Finanzen | Google Cloud -Ressourcen | Nein. Es gibt eine Ausnahme für mandantenfähige Ressourcen, bei denen keine 1:1-Zuordnung zur Anwendung besteht. |
| altostrat-compliance | pci, hipaa | Sicherheit | Google Cloud -Ressourcen | Optional |