Yesterday I went (in a RedPixie capacity) to the annual IPexpo at Earls Court. In another capacity I am familiar with these events as an exhibitor – but that’s another story. It’s a great event if you are an organisation shopping for IT and for vendors a good way to meet all your customers and show your wares at one time. As a “vendor” without a stand it’s not a good venue to meet people unless you are into randomly approaching people with a chat-up line. I am not.
However the event also provides several streams of seminars and I spent most of the day attending those. If I have an opportunity I will write something about them later.
The main topic for today is “Naming Conventions”. This is prompted by my desire to explain my theory of what a good naming convention should be, originally for the benefit of RedPixie but hey, why not for the world too! I fully appreciate that people have strong feelings on this, and it is easy for organisations to spend an inordinate amount of time and bitter internecine warfare on this topic but here’s my philosophy…
Fundamentally, names are for people to use to communicate. Machines use MAC address and IP addresses. That doesn’t suit humans at all so we use words. (In general I mean for servers, but it could be anything.) The main problem I see in naming conventions is that people use “words” that can’t be spoken. This is a barrier when trying to communicate clearly. When you are trying to convey a production server name over a noisy phone line in times of stress, it pays to have something you can say quickly and clearly. Something like “ldnlxprg0099” does not cut the mustard. That would be “ludunellexprogohohninetynine”.
The problem stems from the laudable aim to codify as much meaning as possible into the name. When you are talking about supporting a server you generally want to know where it is, what OS it runs, who supports it, what apps it runs, and of course a number for uniqueness. Unfortunately there is a temptation to cram so much in that you end up with something grossly overloaded which will break at the first unusual case.
One solution, as a colleague has pointed out is to call everything “server” followed by a number. I find this quite attractive. It does at least force you to maintain a good CMDB, and use it, to find out what server0786 actually is. By way of compomise, I think we can put some information in a name, to make it a bit more interesting and useful, but not at the expense of readability.
I would advocate putting no more than three pieces of information in a name. More than this and the name starts to get too long if you want to make it sayable. As a side note, I am against forcing everything into the same length just so columns line up in a report. The question is “What three bits of information”? And the answer depends on your priorities as an organisation.
Most naming conventions I have come across start with a location. Perhaps there is something territorial and human-natureness in this. If I was going to start with this I would use “lon” or “par” or “san” to get you off to a good sayable start instead of “ldn” which is unsayable. But I propose sacrificing location for operating system. In a traditionally silo’d world, in most cases the team supporting Unix servers is not the same as that supporting Windows servers.
So I start with “uni” or “win” followed by “ser” for server. “uniser”, “winser”: quite easy to say and audibly distinct. So far so good, we have conveyed two pieces of information: O/S and machine type. The alternative to “ser” is “desk”. But I will come onto “non servers” shortly.
From experience, it is useful to know if a machine is prod, dev, qa, test or something else. So useful I would encode this in the name. This brings us to “uniserp”, “uniserd”, “winsert”. Here I’m getting into territory I don’t like so much because some of these sound a bit to similar. Finally a number is needed, three or four digits depending on your requirement. An important aspect of the number portion, often overlooked, is to make sure it is unique across the entire asset register. Integers: there’s an infinite number. Don’t be stingy. The worst thing you can do is have prod, dev, qa and test servers all differing in one letter but with the same number. It’s a recipe for disaster. “Oh you meant lonutserv01, I thought you said lonupserv01”. Seen it happen. Every new piece of hardware gets a new number.
So what we’ve ended up with is some examples as follows:
uniserp001
winserd022
uniserq003
winserd004
As an alternative, to get rid of potentially similar sounds I would expand the type and reduce the static “ser” as follows:
unisprod001
winsdev002
unisqa003
winsdev004
If you want to have a different naming convention for desktops (or even if you don’t) you can get rid of the “s” to leave:
uniprod001
windev002
uniqa003
windev004
I like that.
Now for desktops I would follow a similar line and use something like this:
xpdesk001
vistadesk002
win7desk003
I also have a cunning plan to distinguish physical from virtual machines using readable names but that can wait for a later date.
