Padronização de nomes

By | October 20, 2014

Quando comecei minha carreira em TI a vida era bem mais simples. No primeiro ISP que trabalhei tínhamos 7 servidores, 2 roteadores e uns 3 switches layer 2. Faz muito tempo e não lembro o nome deles, mas era algo como “webserver1, webserver2, firewall, router-telefonica, router-embratel” ou quase isso.

Não é ruim mas, como vou discutir mais abaixo, é bem limitado.

Em outras instâncias trabalhei em lugares maiores onde o pessoal tinha mais imaginação e os servidores tinham nomes baseados em personagens dos Simpsons (homer, bart, lisa) ou em mitologia greco-romana (quimera, romulus).

Esse tipo de padronização eu não gosto nem um pouco. Passados de 10 servidores fica bem complicado. Caiu o banco de dados. Qual changemen era o MySQL mesmo? Dragon ou Mermaid?

Mas conforme fui trabalhando em empresas maiores e maiores é que eu vi como padronização de nomes é importante. Cheguei a trabalhar numa empresa que tinha 25 mil servidores. Boa sorte pra achar personagem de video-game pra isso tudo.

O caso não precisa ser tão extremo assim. Com o advento da virtualização e a incapacidade técnica de muitos programadores de conseguirem fazer duas aplicações coexistirem pacificamente o número de servidores numa empresa razoavelmente pequena pode facilmente ultrapassar uma centena.

Empresas com diversas filiais, pontos de venda, armazéns, fábricas, etc podem ter diversas localidades físicas e quando seu sistema de monitoramento alertar um problema no equipamento XYZ você precisa saber onde raios isso fica localizado.

Além disso se você começa a brincar com coisas como Splunk e utilizar filtros, indexes e expressões regulares para analisar seus logs você vai facilmente perceber como é bom ter uma padronização nos nomes dos seus equipamentos.

Já vou adiantar que não existe um jeito certo ou errado de escolher o padrão mas certamente você deve analisar pelo menos:

  • Dispersão geográfica
  • Tipo de equipamento / uso do servidor
  • identificador único

Dispersão geográfica

Aqui vai variar MUITO dependendo do tamanho da sua empresa e como os servidores estão instalados.

Alguns exemplos:

Em apenas um data-centre físico aqui no Canadá uma empresa fornece serviço no país inteiro mas separa os clientes em servidores de acordo com a localidade deles. Portanto servidores podem ter nomes incluindo “east, central e west“. Ou simplesmente et, ct e pt (referência aos timezones Eastern Time, Central Time e Pacific Time)

Uma outra empresa pode ter escritórios em São Paulo e Curitiba e os equipamentos terem prefixos relacionados ao código de seus aeroportos: GRU e CWB.
Ou São Paulo e São Bernardo e prefixos como spo e sbc.

Mas naquela empresa gigante que eu trabalhei os servidores eram identificados como DATACENTRE-LADO-ANDAR-CORREDOR-RACK-SHELF-BLADE (cada data-centre tinha lado A e B). O nome de um servidor então poderia ser algo como ny-a-3-17-1C-4-08. Nada prático pra usar no hostname de um script, mas fenomenal quando você precisa de alguém pra ir checar um cabo de rede.

Tipo / Uso

Se você está fazendo as coisas direito é bem provável que tenha separado seus servidores de acordo com a funcionalidade. Também é provável que tenha diferentes tipos de equipamentos, como impressoras, firewalls, routers, etc.

Exemplos de nome incluem coisas como:

  • appsrv (Servidor de aplicações)
  • dbsrv (Banco de dados)
  • fw (Firewall)
  • ap (Access point)

Mas podem ficar mais complexos conforme a necessidade:

  • rx (equipamentos de rede)
    • rx-fw (firewall)
  • sx (Servidores Unix)
    • sx-db (Banco de dados)
    • sx-as (Servidor de aplicações)
  • sw (Servidores Windows)
    • sw-db (Banco de dados)
    • sw-as (Servidor de aplicações)

Identificador único

Aqui costuma prevalecer o mais simples: Um número. É só uma questão de escolher quantos dígitos. Não acho que nada menos do que dois dígitos seja uma escolha boa. Mesmo que você só planeje ter 3 servidores web nos próximos 10 anos, chamar de 01, 02 e 03 não vai te causar nenhum problema.

Com uma padronização estabelecida crie uma documentação clara e flexível. Não é porquê você não tem uma impressora 3D na sua rede hoje que você nunca vai ter. E imagino que usar o mesmo padrão que impressoras normais não ia ser legal. Pense no futuro.

Pessoalmente eu gosto de hostnames que identificam a localização física e tenham algum tipo de mnemônico no acrônimo. Prefiro quando a localização física é prefixo (ao invés de sufixo) e utilizar hífen para separar cada campo, mas você deve analisar o que melhor vai funcionar para o seu caso.

Pense em automatização em primeiro lugar. É muito mais simples uma regex como “.*-app[0-9]{2}-.*”  do que uma lista com 50 linhas com o nome dos servidores. Pense em Ansible, Puppet, Splunk e todas os seus maravilhosos scripts e como eles ficam bem mais simples com shell expansions e expressões regulares.

Mas antes de tudo: Não esqueça que você está fazendo isso para o time de TI! Para facilitar a sua vida e diminuir sua carga de trabalho, mas não espere que seus usuários entendam ou aprendam isso. Não seja um imbecil e tenha certeza de atender todas as necessidades de seus usuários usando CNAME! Em momento algum você vai querer que seus usuarios acessem http://sp-spo-sxw-01.dominio.com.br ao invés de http://intranet  (-_-)