Quelles stratégies pour nommer ses systèmes informatiques ?

Les devs sont-ils meilleurs que les ops pour nommer des ressources ? On en avait brièvement parlé il y a quelques années entre sysadmins, dans le cadre d’une discussion relative à la RFC 1178 de l’IETF.

En « temps informatique », cette recommandation est d’une autre époque (août 1990). Son objet : « Choisir un nom pour votre ordinateur ». Elle revient régulièrement sur le forum Hacker News, où s’est déroulée la discussion en question. La dernière fois, c’était fin mai.

Dans les grandes lignes, deux méthodes s’opposent… avec une multitude d’approches intermédiaires. D’un côté, la technique « animaux de compagnie », consistant à donner aux machines des noms qui font particulièrement sens pour des humains (exemples mentionnés : dieux grecs, vaisseaux de Star Trek, navires de la Seconde Guerre mondiale, etc.). De l’autre, la technique « bétail », qui implique des noms moins « instinctifs » dépendant d’éléments tels que la nature, la fonction ou l’emplacement.

Le témoignage d’un soi-disant ancien de la NASA donne l’illustration d’une approche intermédiaire. À la base, il y avait un format « bétail » fondé sur le code de l’organisation et le numéro de l’inventaire de la machine. Pour simplifier certaines manips humaines, on enregistrait, en parallèle, un alias « animal de compagnie », des préfixes différenciant alors les types de systèmes.

Mono ou multiusage ? Tenir compte du cycle de vie des machines

Certains considèrent que de manière générale, qu’importent les conventions de nommage, les sysadmins devraient toujours pouvoir identifier ce que fait une machine sans avoir besoin de faire appel à la CMDB. D’autant plus si cette machine ne peut être gérée de façon automatisée.

Qu’il s’agisse de son rôle, de son emplacement ou de son environnement d’exécution, une machine peut être amenée à évoluer sur son cycle de vie. Certains l’ont intégré dans leur stratégie, quand d’autres ont, en conséquence, limité voire interdit l’usage d’éléments de nommage fondés sur ces variables.

La multiplication de ces variables peut par ailleurs être source de complexité. Un des témoignages allant dans ce sens concerne un système de gestion de TPU. La variété des configurations (capacité, version, région…) a engendré des identifiants de type tpu-v3-8-euw4a-1, pas idéaux lorsqu’on se connecte répétitivement en SSH. Dans ce cas, il a été décidé de donner aux VM le nom de l’utilisateur qui les sollicite.

Apporter du contexte… quand c’est nécessaire

En fait d’approche intermédiaire, il y a celles qui misent sur les identifiants temporaires. Un client léger sans OS pour lequel toute l’« intelligence » se trouve côté serveur pourra, par exemple, être identifié par son adresse MAC ou DHCP, voire le hash de cette dernière. Il n’y aura effectivement pas besoin de s’en souvenir.

Pour qui choisit la voie « animal de compagnie », attention à utiliser un schéma offrant suffisamment de possibilités. On arrive vite au bout des planètes du système solaire, quand bien même on embraye sur leurs satellites. Le panthéon grec a aussi ses limites.

Il y a, en outre, des raisons d’opter pour des noms évocateurs (« Elvis pour mon serveur de musique, Mathusalem pour mon serveur de sauvegarde », témoigne un utilisateur). En particulier, pour aider à contextualiser les alertes. Et cela vaut aussi pour l’approche « bétail » (la distinction prod/dev, entre autres, permettant de saisir le niveau de sensibilité des machines).

Dans le même esprit, certains ont nommé des machines par paires selon leurs relations fonctionnelles. Un serveur et sont miroir appelés respectivement Itchy et Scratchy, par exemple, en référence au dessin animé du même nom.

L’importance des références communes

En fonction des segments du SI, on peut décider d’une stratégie spécifique pour favoriser certaines fonctions. Le help desk, notamment, en nommant ses postes de travail à partir de leur numéro de série. Ainsi en témoigne en tout cas un internaute. Son raisonnement : si les utilisateurs finaux ne trouvent pas le nom de leur machine, demandez-leur de lire l’autocollant qui se trouve en dessous.

Indépendamment des options retenues, on s’assurera d’établir des référentiels interprétables par toutes les parties prenantes. Une anecdote à ce sujet : « J’ai fait du conseil en admin système. Le nouveau DSI d’un de nos clients a choisir de ne plus désigner les hôtes en fonction de leur rôle (db01, web01, storage01…), mais de leur donner des noms de villes. Lorsqu’une alerte vous signalait que « mulhouse » avait planté, vous deviez savoir à la fois que Mulhouse se trouve en France et que la France abrite vos serveurs de bases de données. »

Au-delà de l’interprétabilité des référentiels peut se poser la question de la réutilisation de noms. Les avis sont partagés sur ce point. Pour un des participants, c’est un non radical depuis une mésaventure liée à la restauration d’un fichier de configuration pointant vers une ancienne machine… dont le nom avait été recyclé.

En fonction des systèmes, la longueur des noms peut être limitée. Ce qui fait dire à certains qu’on peut avoir intérêt à limiter l’usage de caractères potentiellement superflus, comme le tiret bas. Autre conseil formulé : éviter si possible les caractères susceptibles d’entraîner des fautes de frappe (la classique distinction entre un i majuscule et un l minuscule ou entre un o majuscule et le chiffre zéro).

Photo d’illustration © Quardia Inc. – Adobe Stock