Uma estratégia de rótulos eficaz ajuda a organizar e rastrear os recursos doGoogle Cloud em toda a organização. Antes de criar rótulos, revise estes princípios gerais para estabelecer um gerenciamento de recursos consistente.
Princípios gerais para rótulos
Sempre use rótulos
Embora os rótulos não sejam obrigatórios, eles são úteis para organizar e gerenciar os recursos doGoogle Cloud . Os rótulos podem ser usados para rastrear custos e identificar recursos. Ao usar rótulos para seus recursos, siga as diretrizes de rotulagem rigorosas. Recomendamos que você crie uma política formal de rotulagem que esteja alinhada com as principais partes interessadas da organização. A tabela de exemplo mostra como é uma política de rotulagem para toda a organização.
Aplicar rótulos de maneira programática para garantir a consistência
Sempre que possível, aplique rótulos de maneira programática. Ferramentas como o Script e o Terraform permitem automatizar o processo de criação de rótulos e ajudam a aplicar a política de rotulagem. Essas ferramentas garantem que os rótulos sejam aplicados de maneira consistente em todos os recursos. Use um formato que diferencia maiúsculas de minúsculas para rotulagem e aplique-o de maneira consistente em todos os recursos.
Padronizar rótulos
Use um repositório curricular consistente e padrão para todos os recursos. Isso facilita a pesquisa, a filtragem e o gerenciamento dos recursos. Para simplificar sua estratégia de rótulos, tente não usar mais de dez rótulos. Alinhe os rótulos com base em como você quer informar os custos. Considere usar um conjunto padrão de chaves e valores de rótulo que funcionem melhor para sua organização. Os rótulos podem abranger casos de uso comercial, como ambiente, classificação de dados, centro de custo, equipe, componente, aplicativo e compliance.
A padronização e a adesão a uma política de rotulagem são essenciais para rótulos gerenciados de forma centralizada. As equipes de produtos e os departamentos também podem adicionar rótulos personalizados aos recursos para compartilhar informações específicas da equipe. Para mais informações, consulte Aplicar rótulos não padrão.
Veja um exemplo de como definir um conjunto padrão de valores para cada uma das chaves:
- Ambiente:
prod/dev/staging - Classificação de dados:
public/internal-only/confidential/restricted/na - Centro de custo:
c23543 - Equipe:
shopping-cart - Componente:
frontend/cache/backend/database - Aplicativo:
shopping-cart-payments - Conformidade:
pci-hipaa
Evite informações confidenciais
Proteger informações de identificação pessoal (PII) é fundamental para a segurança. Evite armazenar PIIs ou outras informações confidenciais nos rótulos.
Aplicar rótulos não padrão
Embora seja crucial aderir a uma política de rótulos, eles também podem ser usados para compartilhar
informações específicas de uma equipe de produtos ou departamento. Nesse cenário,
oferecer aos proprietários de recursos de equipes individuais a opção de aplicar rótulos não padrão
para cada recurso pode ajudar a fornecer mais contexto sobre o recurso. Isso facilita
a pesquisa, a filtragem e o compartilhamento de informações específicas dessas equipes de produtos
ou departamentos. Por exemplo, um único recurso pode ter um conjunto de rótulos padrão, como environment:prod, data-classification:restricted, cost-center:c23543, team:shopping-cart, app:shopping-cart-payments, component:database, compliance: pci. O proprietário do recurso pode adicionar rótulos não padrão,
como version:5.0.1 e replica:primary, para indicar a versão
do cluster de banco de dados e o status de replicação do nó.
Considere as implicações da mudança
Sua estratégia de rotulagem provavelmente vai mudar conforme os requisitos de negócios evoluírem. Esteja ciente das implicações que essas mudanças podem ter. Por exemplo, a adição de novos centros de custo, microsserviços ou novas ferramentas pode afetar sua estratégia de rotulagem.
Esquema e padrão de nomenclatura de rótulos
Cada organização tem uma maneira própria de organizar os recursos. É possível usar rótulos para categorizar os recursos na sua hierarquia de várias maneiras, ajudando os usuários a filtrar os recursos de que precisam. Ao definir o esquema de nomenclatura dos rótulos, considere o seguinte:
- Ambiente, centro de custo, equipe, componente, aplicativos, compliance e propriedade associados ao recurso.
- Classificação de dados de qualquer repositório de dados armazenado no sistema. Isso só é aplicável a sistemas com estado.
- Rótulos que precisam ser aplicados no nível do recurso específico, como o Compute Engine, o bucket do Cloud Storage ou o projeto.
- Flexibilidade para usar rótulos opcionais, conforme necessário, para fornecer mais informações sobre os recursos.
Codificação de rótulos e caracteres aceitos
Todos os caracteres de chave e valor precisam usar a codificação UTF-8. Caracteres internacionais são permitidos. As chaves precisam começar com uma letra minúscula ou um caractere internacional. As chaves e valores contêm apenas letras minúsculas, caracteres numéricos, sublinhados e traços.
Exemplo de definição de rótulos
Para definir rótulos, confira alguns atributos que você precisa considerar.
| Campo | Descrição |
|---|---|
| Chave de rótulo | A chave do rótulo é um identificador exclusivo de um rótulo. Precisa ser uma string com no mínimo 1 caractere e no máximo 63 caracteres. A chave não pode ficar vazia. É possível usar um repositório curricular de chaves de rótulo que funcionem melhor para sua organização e que cubram casos de uso comercial, como environment, data-classification, cost-center, team, component, application e compliance. |
| Valor do rótulo | O valor do rótulo são os dados associados à chave. Pode ser uma string, um número ou um valor booleano. Como prática recomendada, defina um conjunto de valores para cada chave de rótulo. Isso pode ajudar as equipes a selecionar e atribuir valores adequados para cada chave. Por exemplo, uma chave environment pode ter valores como prod, staging, dev ou tools. |
| Parte interessada | Identifique o departamento que precisa da chave de rótulo para filtrar recursos ou criar relatórios. Por exemplo, o departamento financeiro de uma organização quer saber o custo de execução do ambiente prod. Eles usariam o par de chave-valor do rótulo environment:prod. |
| Recurso de destino | Para cada rótulo, considere definir um recurso de destino Google Cloud em que o par de chave-valor do rótulo precisa ser aplicado. Por exemplo, a chave de rótulo environment precisa estar em cada recurso Google Cloud no ambiente de produção da sua organização. |
| Exceção | Defina quais chaves de rótulo são obrigatórias em todos os recursos e quais são opcionais. Na tabela de exemplo, há alguns pares de rótulos key:value que são opcionais, como environment:tools. A chave de rótulo altostrat-team pode ser considerada opcional quando o rótulo altostrat-environment tem o valor definido como tools. |
No exemplo rotulado a seguir, altostrat corresponde ao nome da empresa.
| Chave de rótulo | Valor do rótulo | Parte interessada | Recurso de destino | Exceção |
|---|---|---|---|---|
| altostrat-environment | prod, sb1, staging, dev, tools | Finanças | Recursos doGoogle Cloud | Não |
| altostrat-data-classification | público, somente interno, confidencial, restrito, n/a | Segurança | Buckets, bancos de dados, discos permanentes com o Compute Engine | Não |
| altostrat-cost-center | fin-us, mkt-eu, it-jp | Finanças | Recursos doGoogle Cloud | sandbox-folder |
| altostrat-team | shopping-cart | Líder da equipe | Recursos doGoogle Cloud | Ambientes que não são de produção, componentes não críticos |
| altostrat-component | front-end, cache, aplicativo, banco de dados | Finanças | Recursos doGoogle Cloud | Opcional |
| altostrat-app | shopping-cart-payment | Finanças | Recursos doGoogle Cloud | Não. Há uma exceção para recursos multilocatários em que não há mapeamento 1:1 com o aplicativo. |
| altostrat-compliance | pci, hipaa | Segurança | Recursos doGoogle Cloud | Opcional |