SQL TIPS:Server Naming Convention(s)

13FEB

I learned a new word in a recent and quite heated discussion about server naming conventions. That word is Camel Casing. I know of the concept and actually prefer CamelCasingForServerNamingConventions.

Camels aside, I learned quite a few things about the history of our servers from a discussion we server admins had at my shop. What it boiled down to is there are only a couple guidelines we should and do follow but the rest of the blanket regulations don’t have much benefit.

One of the comments that I heard was, why bother because our naming conventions only last 6 months. This is terribly true, historically speaking.

To get to the point where everyone can agree, or at least agree to disagree, we need to have a good conversation. It would be easy to come up with a naming convention and force it upon the lesser, non-decision making folks. This method, regardless of your experience will not provide the best naming convention. So I suggest getting the opinions of everyone involved.

Government bodies often debate agenda items that seem like a huge waste of time. That is just how government works. I agree with the average person who says government is inefficient. But some of those inefficiencies generate long standing rules and regulations. That way they are not reworking something as simple as a naming convention every 6 months. Technology changes faster than social norms so the comparison is a stretch. However, a naming convention is a healthy team building (or breaking) exercise to attack.

Now, first thing on the agenda for a naming convention for servers is who to invite. Devs? NO, at least not yet, maybe later… DBAs? well maybe… or maybe not. Server Admins? Yes, these folks should be the first people involved in discussing the server naming convention. To be more specific, I suggest a verbal brainstorming effort to identify all considerations. Brainstorming does not include negativity. One thought that is interesting is the difference between verbal and written communication. In my shop, all of our written communication mediums are tied directly to our name. If we had a medium that was not directly tied to our name brainstorming in written communication could be more effective. So for now, verbal less-documented communication generates more ideas than a written discussion because when most people are asked to write down their thoughts, and they know they will be accountable, they are less likely to submit bad or mediocre ideas.

So go through the brainstorming phase which will probably produce something like this:

1. 15 chars or less, because of stupid apps that force netBOIS name resolution
2. put environment (prod or test) in the name
3. 8 chars or less because the mainframe can’t count very high
4. 3 character environment names PRD, TST, SND, DEV, QAS
5. Environment names should go first
6. 1 character environment names because that leaves 7 chars for mainframe apps
7. fixed length names
8. should always end in a number (1, 2, 3…)
9. last three characters should be a number (001, 002)
10. ALLCAPSFORSVRNMS
11. CamelCaseForSrvNms
12. Ambiguity for security (names of stars, xmen characters)
13. The number at the end should count up for every server.
14. The number at the end should start at 1 for each environment
15. Database servers should have SQL in the name
16. servers should have their DR tier in the name
17. web servers should have “web” or “iis” in the name
18. non-web application servers should have “app” in the name
19. servers should never have “srv” “svr” “server” in the name because its redundant
20. servers part of a cluster should have “c” in the name
21. servers should have the building they are in in the name
22. servers should have the floor that they are on in the name
23. physical servers should have a “p” in the name
24. virtual servers should have “vm” in the name

So this could drone on and on for a long time but I think I have covered the basics. Once your team has all had their say its time to start grouping contradictory items. At this point it would be a good idea to bring in some outside viewpoints from development and the business users who may have to type in the server name. (ahem, dns pointers) One good point is developers have this naming convention conversation about their code all the time. Sometimes its even more important for them to have a good naming convention.

Then its time to start voting like a good democracy. Each item should be allowed a yes or no vote to gather statistics. Also, if you say yes or no include a reasoning behind each vote. If you get any items with 20 nos and 1 yes you can throw those out. Then reconvene to have a discussion about the results and to get closer to a naming convention. Make sure to have some time in between meetings so that bad ideas can work themselves out and good ideas can iron themselves in.

In this meeting after the brainstorming meeting be considerate to others and start to trim down your list of requirements. Some people may get upset that things aren’t going their way and run to their blog and create a large post. These people should be thankful for their opportunity to participate in the discussion.

Next, on the hot button issues, do some pros/cons analysis. I think that the ambiguity option will quickly be cut because although it does have a solid pro, there are far too many costs associated with that option. Take a practical or even imaginary application environment and test out your newly designed convention. Consider resent developments in technology and future growth that may affect your naming convention. Take into account programming constraints such as “-” in sql server names that require [ ].

Finally, when you make a decision, stay the course. Unless its a bad course :]