Este documento fornece orientações sobre como projetar uma estratégia de rótulos eficaz para sua organização. Antes de começar a criar rótulos, confira alguns princípios gerais que podem ser usados para organizar seus recursos do Google Cloud com rótulos.
Princípios gerais para rótulos
Sempre usar rótulos
Embora os rótulos não sejam obrigatórios, eles ajudam a organizar e gerenciar seus recursos do Google Cloud. Os rótulos podem ser usados para rastrear custos e identificar recursos. Ao usar rótulos para seus recursos, siga as diretrizes rígidas de rotulagem. Recomendamos que você crie uma política de rotulagem formal que esteja alinhada às principais partes interessadas da organização. A tabela de exemplo mostra como é uma política de rotulagem em toda a organização.
Aplicar rótulos de forma programática para consistência
Sempre que possível, aplique rótulos de forma programática. Ferramentas como o Script e o Terraform permitem automatizar o processo de criação de rótulos e ajudar a aplicar a política de rotulagem. Essas ferramentas garantem que os rótulos sejam aplicados de forma consistente em todos os recursos. Use um formato que diferencia maiúsculas de minúsculas para rotular e aplique-o de maneira consistente em todos os recursos.
Padronizar rótulos
Use um conjunto consistente e padrão de rótulos para todos os recursos. Isso facilita a pesquisa, o filtro e o gerenciamento dos recursos. Para simplificar sua estratégia de rótulos, tente não usar mais de 10 rótulos. Alinhe os rótulos com base na forma como você quer informar os custos. Considere usar um conjunto padrão de chaves e valores de rótulos que funcionam melhor para sua organização. Seus rótulos podem abranger casos de uso de negócios, como ambiente, classificação de dados, centro de custo, equipe, componente, aplicativo e compliance.
É crucial padronizar e aderir a uma política de rotulagem para rótulos gerenciados centralmente. 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.
Confira 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-hippa
Evite informações confidenciais
Proteger informações de identificação pessoal (PII) é essencial para a segurança. Evite armazenar PII ou outras informações confidenciais nos rótulos.
Aplicar rótulos não padrão
Embora a adesão a uma política de rótulos seja crucial, eles também podem ser usados para compartilhar
informações específicas de uma equipe ou departamento de produtos. 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, o filtro e o compartilhamento de informações específicas para essas equipes ou departamentos de produtos. 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 e 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 em momentos de evolução dos requisitos de negócios. Conheça as implicações dessas mudanças. Por exemplo, a adição de novos centros de custo, microsserviços ou 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 da hierarquia de várias maneiras, ajudando os usuários a filtrar os recursos necessários. Ao definir o esquema de nomenclatura de rótulos, considere o seguinte:
- Ambiente, centro de custos, equipe, componente, aplicativos, compliance e propriedade associados ao recurso.
- Classificação de dados armazenados 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.
Exemplo de definição de rótulos
Para definir rótulos, considere os seguintes atributos:
| Campo | Descrição |
|---|---|
| Chave de rótulo | A chave de rótulo é um identificador exclusivo de um rótulo. Ele precisa ser uma string com comprimento mínimo de 1 e máximo de 63 caracteres. A chave não pode estar vazia. É possível usar um conjunto padrão de chaves de rótulo que funcionam melhor para sua organização e abrangem casos de uso comerciais, como environment, data-classification, cost-center, team, component, application e compliance. |
| Valor do rótulo | O valor do rótulo é o dado associado à chave. Ele 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, um departamento financeiro de uma organização quer saber o custo de execução do ambiente prod. Eles usariam o par de rótulos chave:valor environment:prod. |
| Recurso de destino | Para cada rótulo, defina um recurso do Google Cloud de destino em que o par de chave-valor chave:valor será aplicado. Por exemplo, a chave de rótulo environment precisa estar em cada recurso do 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 identificadores key:value 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 de rótulo abaixo, 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 do Google Cloud | Não |
| altostrat-data-classification | público, somente interno, confidencial, restrito, na | Segurança | Buckets, bancos de dados e discos permanentes com o Compute Engine | Não |
| altostrat-cost-center | fin-us, mkt-eu, it-jp | Finanças | Recursos do Google Cloud | sandbox-folder |
| altostrat-team | shopping-cart | Líder de equipe | Recursos do Google Cloud | Ambientes que não sejam de produção, componentes não críticos |
| altostrat-component | front-end, cache, aplicativo, banco de dados | Finanças | Recursos do Google Cloud | Opcional |
| altostrat-app | shopping-cart-payment | Finanças | Recursos do Google Cloud | Não. Há uma exceção para recursos multisseções em que não há mapeamento 1:1 com o aplicativo. |
| altostrat-compliance | pci, hipaa | Segurança | Recursos do Google Cloud | Opcional |