Depende muito do ambiente em que você trabalha.
Antes de mais nada - deixe de lado qualquer referência à cultura pop, fique com o significado de & nomes descritivos.
Você pode saber que "zeus" é o servidor proxy, porque você o instalou. Mas qualquer futuro colega gostaria muito de se referir ao servidor pelo o que faz , não pelo nome .
Se você aceitar isso, sugiro que faça uma sessão de brainstorming e anote quais tipos diferentes de entidades em rede ("hosts") você tem, como elas podem ser agrupadas e quais informações são importantes o suficiente para serem codificadas. o nome do host. Sua convenção de nomenclatura deve ser capaz de nomear inequivocamente todos os dispositivos existentes e dar ao usuário uma ideia aproximada do que o host faz. Certifique-se de deixar espaço suficiente para o crescimento se adaptar aos desenvolvimentos futuros, para que você não precise lançar sua convenção de nomenclatura em alguns meses.
Documente sua convenção de nomenclatura (não apenas como, mas por quê), certifique-se de que todos que precisam trabalhar com ela regularmente entendam como ela é exposta, estejam abertos a comentários / sugestões e não a apliquem como um Santo Graal, adaptá-lo quando necessário.
Exemplo
Como alimento para pensar, aqui está o esquema que usamos em um dos meus ex-empregadores:
Provedor de serviços da Web, fazendo desenvolvimento e operações para projetos da web. Principalmente LAMP-stuff, embora em escala maior (tamanho dos projetos, não quantidade).
Para dispositivos físicos:
< SITE < - <; < RACK < - < DEVICE >. < DOMAIN >. < TLD > <
- O SITE era um identificador de site exclusivo, principalmente três letras
- O RACK era um identificador atribuído por nós ou assumido a partir da instalação de hospedagem, deve ser capaz de identificar exclusivamente o rack em SITE
- DEVICE era uma "classe de dispositivo" com um contador após, por exemplo vnodeXX para nós OpenVZ, swge para switches Gigabit, etc.
- DOMAIN / TLD era o domínio do proprietário dos dispositivos fornecidos.
Para entidades lógicas:
Entidades lógicas podem ser qualquer coisa que tenha um endereço IP que não esteja strongmente acoplado a um determinado dispositivo / local físico. Isso foi principalmente endereços IP do sistema operacional convidado (OpenVZ ou ESX no nosso caso).
- PROJECT era um identificador de projeto, que agrupava os vários serviços de um projeto juntos.
- MEIO AMBIENTE pode ser produção, encenação ou desenvolvimento, abreviação de 4 letras
- O SERVICE era relativamente de forma livre, embora os casos comuns fossem padronizados, como web, db, mailout, etc.
- DOMAIN era o domínio principal do projeto em questão.
Para endereços IP:
Todos os nossos serviços eram acessíveis somente a partir de uma rede privada, tínhamos NAT e / ou balanceadores de carga com "endereços IP de serviço", que eram usados por hosts da Internet para acessar nossos serviços. Para aqueles que usamos algo assim:
- IDENTIFIER foi algo que identificou exclusivamente o uso do endereço IP, por exemplo, um endereço que foi usado exclusivamente como o Web VirtualHost para o domínio alemão do projeto pode ser chamado de "wwwde".
Resumindo
A convenção de nomenclatura funcionou bem para nós, alguns (como nossos desenvolvedores;) podem chamá-la de exagerada. Lembre-se de que é completamente exagerado se você mantiver apenas um site e tiver servidores atribuídos a um único projeto. Mas para nós, cumprimos algumas coisas muito importantes.
Ao lidar com um nome de host de uma entidade lógica, sempre soubemos:
- Qual projeto estava envolvido:
Os vários projetos foram de importância variável com diferentes equipes de desenvolvimento responsáveis. Uma rápida olhada no nome do host lhe disse como você precisa priorizar tarefas e quem você precisa perguntar no lado de gerenciamento / desenvolvimento - Em que ambiente o host estava:
Problemas em ambientes de desenvolvimento causam lentidão para os desenvolvedores. Problemas em ambientes de teste causam problemas aos testadores e podem comprometer as apresentações do produto. E se algo é afetado na produção, a empresa perde dinheiro. - Qual subsistema é afetado:
Os spoolers de e-mail, os batch workers, etc. não eram tão importantes, mas se os servidores web ou de banco de dados estiverem em baixo, as coisas ficam sujas rapidamente.
E para dispositivos físicos, a localização exata sempre foi dedutível do nome do host.
O fraco acoplamento entre dispositivos físicos e servidores lógicos pode ser um desligamento para algumas pessoas (por exemplo, como eu sei quais projetos serão afetados quando eu puxar o plug do switch x / server y), mas isso foi uma obrigação em nosso ambiente, já que nossos projetos tinham uma alta taxa de retorno e, na maioria das vezes, nem sabíamos quais projetos seriam hospedados em hardware novo que acabamos de provisionar.