Este documento fornece orientações sobre como projetar uma estratégia de rótulo eficaz para sua organização. Antes de começar a criar rótulos, veja alguns princípios gerais que podem ser usados ao organizar seus recursos do Google Cloud usando rótulos.
Princípios gerais para identificadores
Sempre usar rótulos
Os rótulos não são obrigatórios, mas são úteis para organizar e gerenciar os recursos do Google Cloud. Os identificadores podem ser usados para rastrear custos e identificar recursos. Ao usar rótulos para seus recursos, lembre-se de seguir diretrizes rígidas de rotulagem. Recomendamos que você crie uma política de rotulagem formal que se alinhe com as principais partes interessadas na 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 manter a consistência
Quando 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 ajudar 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 o aplique de maneira consistente em todos os recursos.
Padronizar identificadores
Use um conjunto de rótulos consistente e padrão para todos os recursos. Assim fica mais fácil pesquisar, filtrar e gerenciar seus recursos. Para simplificar sua estratégia, tente não usar mais de 10 rótulos. Alinhe seus rótulos com base em como você quer relatar os custos. Use um conjunto padrão de chaves e valores de rótulo que funcionam melhor para sua organização. Os rótulos podem abranger casos de uso de negócios, como ambiente, classificação de dados, centro de custos, equipe, componente, aplicativo e conformidade.
Padronizar e aderir a uma política de rotulagem é crucial para rótulos gerenciados centralmente. Os departamentos e as equipes de produtos 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 você pode 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 custos:
c23543 - Equipe:
shopping-cart - Componente:
frontend/cache/backend/database - Aplicativo:
shopping-cart-payments - Compliance:
pci-hippa
Evite informações confidenciais
Proteger as informações de identificação pessoal (PII) é fundamental para a segurança. Evite armazenar PII ou outras informações confidenciais nos seus marcadores.
Aplicar rótulos não padrão
Embora a adesão a uma política de rótulos seja crucial, os rótulos também podem ser usados para compartilhar
informações específicas para uma equipe ou departamento de produto. Nesse cenário,
fornecer aos proprietários de recursos de equipes individuais a opção de aplicar rótulos não padrão
a 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 a esses departamentos ou equipes 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, 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 do banco de dados e o status de replicação do nó.
Considerar as implicações das mudanças
Sua estratégia de rotulagem provavelmente mudará com base nos requisitos de negócios em constante evolução. 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 um jeito próprio de organizar os recursos. É possível usar rótulos para categorizar os recursos na 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 custos, equipe, componente, aplicativos, conformidade e propriedade associados ao recurso.
- Classificação de dados de todos os dados armazenados no sistema. Aplicável apenas a sistemas com estado.
- Rótulos que precisam ser aplicados no nível de recurso específico, como Compute Engine, bucket do Cloud Storage ou no 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, aqui estão alguns atributos que você precisa ter em mente.
| Campo | Descrição |
|---|---|
| Chave de rótulo | A chave do 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 ficar vazia. É possível usar um conjunto padrão de chaves de rótulo que funcione melhor para sua organização e abrange casos de uso comerciais, 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, considere definir um conjunto de valores para cada chave de rótulo. Isso ajuda 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 rótulo key:value environment:prod. |
| Recurso de destino | Para cada rótulo, considere definir um recurso de destino do Google Cloud em que o par key:value de rótulo será aplicado. Por exemplo, a chave de rótulo environment precisa estar em cada recurso do Google Cloud no ambiente de produção da organização. |
| Exceção | Considere definir quais chaves de rótulo são obrigatórias em todos os recursos e quais são opcionais para aplicar. 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 de rótulo a seguir, altostrat corresponde ao nome da empresa.
| Chave de rótulo | Valor do rótulo | Parte interessada | Recurso de destino | Exceção |
|---|---|---|---|---|
| Altostrat-ambiente | prod, sb1, staging, dev, ferramentas | Finanças | Recursos do Google Cloud | Não |
| altostrat-data-classification | público, somente uso 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 | pasta-sandbox |
| Altostrat-team | carrinho de compras | Líder de equipe | Recursos do Google Cloud | Ambientes de não produção, componentes não críticos |
| componente altostrat | Front-end, cache, aplicativo, banco de dados | Finanças | Recursos do Google Cloud | Opcional |
| Altostrat-app | pagamento-carrinho-de-compras | Finanças | Recursos do Google Cloud | Não. Há uma exceção para recursos multilocatários, em que não há mapeamento individual com o aplicativo. |
| Altostrat-compliance | pci, hipaa | Segurança | Recursos do Google Cloud | Opcional |