What’s in a name – quite a lot you know

I was having a conversation with a colleague who’s a server engineer for an Insurance company in London.  I was seeking his views on server naming conventions, believe it or not, it is one of those subjects that can easily become emotive.  What do I mean by naming standards? The process for naming your desktop, laptop or server, why does it matter? Well we need the name to mean something to someone so that we can easily identify systems when logging a call, reporting an issue or identifying systems in scope for a change. These naming standards tend to be mandated by a central team based on a set of standards, for example based on platform, operating system, business line or environment, maybe even a mixture or combination of all four.

What’s the issue?

Everyone tends to have an opinion about it.  Why then does your infrastructure team have a set naming convention? Well it is usually to ensure consistency across environments, for uniformity and to aid in systems management, if they all start with for example geographic code and then a number, it is easier to locate that system and therefore make it that little bit easier to identify and track back who owns that server and what it does.

What do we need to think about?

The name needs to be relatively annonymous – linking a server name to a role can raise issues

The name needs to be easy to say – there’s nothing worse than trying to explain or a say a long server name at three in the morning

The name needs to eliminate confusion – too many similar characters LONSO19000 – is that LONS019000 or is that an O?

The name needs to deliminate platforms ideally – I don’t want to create confusion between app teams and infrastructure teams as to what the OS is.

So why not have the server name contain the role/application?

Let’s go over some issues that I’ve mentioned before.

I build LONSQL1002D, which is a development SQL server, suppose the app team want to make it an IIS server, do I rename it? How will the DBA’s know it’s not SQL at three in the morning?  Suppose the server is moved to production, are we renaming it LONSQL1002p as it’s now prod? But that means reinstalling SQL if we’re going to follow the rules of safety and olden days engineering.

I name the server LONSQL1002D, so it’s my trusted Bladewatch SQL server, I then virtualize it, so do I rename it to LONSQL1002DV? If I move it to our office in Renfrew (Gran’s house), do I rename it RENSQL1002D and if it’s virtualized, then is it RENSQL1002DV, and then for those smart people out there, I could create aliases, but then how to we link it all back in the inventory?

I name a server LONSQLFI1002D, our Fixed Income SQL development server in London, if it’s moved to back office, is it now renamed LONSQLBO1002d? If I remove SQL and make it Apache, is it now LONAPA1000D?

I name a server LONSQLFI1002D our Fixed Income SQL development server in London, I want to rebuild it AIX, is that AIXAPPFI1002D?

Ultimately as a business user, as a customer buying application compute resources or infrastructure as a service it doesn’t matter, to the infrastructure teams, to the people keeping lights on, having a relatively simple and anonymous naming convention reduces operational complexity, can reduce what the name means to the app team, but at the same time leaves name ranges which can be used just as effectively.

John had different thoughts basing his experience and viewpoint on his own internal naming standards, he had views on what the naming convention should be, whether the name should include the environment, the application and the location for example. It’s an issue that is set to continue. An uninteresting discussion one could argument, but remember as we’ve written about before it’s the nuts and bolts that can often be the problem factors in your deployment, in your delivery – sorry we can’t go live with that, your server should be a REDSQL not a LONSQL as we don’t have that network in our London site, so we’ll need to host it in Reading.

Category: News, Virtualisation