Este tópico descreve o contexto, os princípios, as melhores práticas e exemplos de design de tags.
Contexto
Quando uma empresa possui poucos recursos cloud, é possível classificá-los de memória ou por meio de registros manuais. No entanto, à medida que o número de recursos cloud aumenta — chegando a milhares em grandes empresas — a classificação manual torna-se pouco confiável e exige uma solução baseada em plataforma.
Na Alibaba Cloud, use tags para marcar e classificar seus recursos. Ao criar um recurso, aplique tags com propriedades como titularidade empresarial e financeira. Por exemplo, marque recursos por criador, região ou projeto. Se você não aplicar tags durante a criação, organizar essas propriedades posteriormente será muito mais difícil.
Princípios do design de tags
-
Princípio da exclusividade mútua
O princípio da exclusividade mútua evita o uso de múltiplas chaves de tag para o mesmo atributo de recurso. Por exemplo, se utilizar a chave de tag owner para identificar o proprietário de um recurso, não use chaves semelhantes como own, belonger ou owner_cn.
-
Princípio da exaustividade coletiva
O princípio da exaustividade coletiva exige que todos os recursos tenham chaves de tag planejadas e seus respectivos valores associados. Por exemplo, se uma empresa possui três departamentos de projetos de jogos e utiliza a chave de tag project, deve haver pelo menos três valores de tag para representar esses departamentos.
Uma marcação abrangente e exaustiva é pré-requisito para operações baseadas em dimensões de tag, como recuperação de recursos, alocação de custos, O&M automatizado e controle de acesso.
-
Princípio dos valores limitados
O princípio dos valores limitados consiste em manter apenas os valores de tag essenciais para um recurso e excluir os redundantes. Por exemplo, se uma empresa tem cinco departamentos, deve haver apenas cinco valores de tag correspondentes à chave de tag de departamento. Isso simplifica a gestão.
Esse princípio facilita a recuperação de recursos, a alocação de custos, o O&M automatizado e o controle de acesso.
-
Princípio da consideração de mudanças futuras
Ao projetar tags, planeje mudanças futuras considerando o impacto de adicionar ou remover valores. Definir claramente os limites do negócio torna suas tags mais flexíveis e fáceis de modificar. Por exemplo, uma empresa recém-chegada à cloud pode ter operações centralizadas e usar uma única tag, como department, para gerenciar a propriedade do recurso, a responsabilidade financeira e o O&M automatizado. Conforme a empresa cresce, essa tag única pode ficar sobrecarregada com lógica de negócios, tornando sua separação posterior custosa e difícil. Portanto, avalie seus requisitos de negócios para tags durante a fase inicial de adoção da cloud. Neste exemplo, é melhor usar as tags department, costcenter e ops desde o início.
A modificação de tags pode afetar o controle de acesso baseado em tags, o O&M automatizado ou relatórios de faturamento relacionados. Tanto para casos de uso corporativo quanto pessoal, crie tags relacionadas ao negócio para gerenciar recursos nas dimensões técnica, comercial e de segurança. Ao utilizar O&M automatizado para gerenciar recursos e services, projete tags adicionais e dedicadas para auxiliar nas tarefas de automação.
-
Princípio do design simplificado
O princípio do design simplificado consiste em usar um conjunto fixo de tags com chaves e valores simples que atendam às necessidades do seu negócio. Por exemplo, ao projetar tags para ambientes de projeto, use uma chave consistente para ambientes de teste, como test-environment. Não mantenha várias chaves semelhantes, como pre-test-environment ou formal-test-environment.
Esse princípio reduz erros operacionais causados pelo excesso de chaves de tag.
-
Princípio da nomenclatura padronizada
O princípio da nomenclatura padronizada consiste em adotar um formato de nomeação padrão para tags, garantindo compatibilidade com diferentes ferramentas open source e simplificando futuras integrações via API. Por exemplo, se os nomes das tags incluírem palavras em inglês, utilize apenas letras minúsculas.
Melhores práticas para o design de tags
Uma empresa de internet possui três departamentos: Negócios, Marketing e O&M. Cada departamento gerencia um ou mais projetos. Cada projeto conta com ambientes de produção, desenvolvimento e teste para diferentes estágios do ciclo de vida. A equipe de O&M precisa monitorar os recursos da empresa em tempo real, alocar custos periodicamente para cada projeto, controlar o acesso aos recursos e implementar O&M automatizado.
Para atender a esses requisitos, a empresa estruturou suas tags da seguinte forma.
|
Requisito |
Design de tags |
Descrição |
|
Recuperar e gerenciar recursos |
Crie e associe os seguintes três níveis de tags a todos os recursos:
|
Se sua empresa possuir uma hierarquia organizacional profunda, considere adicionar tags de nível superior, como uma tag para filial (empresa). |
|
Gerenciar custos e alocação de custos |
Crie e associe uma tag de centro de custo a todos os recursos:
|
Nenhuma |
|
Controle de acesso a recursos |
Restrinja o acesso de membros fora do projeto aos recursos do projeto, como instâncias ECS. |
Para mais informações, consulte Use tags to restrict RAM users from managing specified ECS instances. |
|
O&M automatizado |
Crie uma tag de finalidade com a chave purpose para inspeções diárias de recursos. Defina o valor como autocheck-8am para indicar uma inspeção automática às 08:00 todos os dias. Caso uma inspeção detecte anomalias, utilize a tag de proprietário do recurso owner para notificar o responsável pela resolução. |
Nenhuma |
Exemplos de design de tags
A tabela a seguir apresenta exemplos de designs de tags para dimensões comuns.
|
Dimensão de classificação |
Chave da tag |
Valor da tag |
|
Estrutura organizacional |
|
Nomes relevantes |
|
Arquitetura de negócios |
|
Nomes relevantes |
|
Arquitetura de funções |
|
|
|
Finalidade |
|
Valor da finalidade |
|
Projeto |
|
Forneça informações precisas. |
|
Departamento de negócios (para alocação de custos e rastreamento de negócios) |
|
Valores reais |
|
Proprietário da dimensão financeira (para identificar o proprietário do recurso) |
owner |
Nome ou endereço de e-mail |
|
Cliente da dimensão financeira (para identificar o cliente do service de recurso) |
Valor personalizado ou real |
Nome do cliente |
|
Projeto da dimensão financeira (para identificar o projeto suportado pelo recurso) |
project |
Nome do projeto |
|
Pedido da dimensão financeira |
order |
ID da categoria do pedido |