In the course of the after-action report some screen dumps were shown to the executives in which the "whimsical" server names appeared.They were (understandably) in a rather agitated and non-whimsical mood, and incorrectly (in my opinion) correlated the seriousness of the problem which the perceived lack of seriousness of the naming scheme.
They could not see that the naming scheme was not whimsical - it was in fact quite methodical and conveyed more meaning to the engineers who lived with the machines everyday than the strict, sanitized names we eventually ended up with.
Somehow I just don't have that much respect for people who've gotten where they are by duping professors and wowing everyone with some impressive degree or family pedigree. It's not the same.
For any manager to be worth their salt to me, they have to demonstrate that they've had a lot of good old-fashioned practice in thinking. And the management fast-track just doesn't portend that to me. And I think that's why most companies > 50 employees slowly crumble as their engineers and other thinkers are crowded out by MBAs.
(I'm curious as to what seemed so out-of-place in a serious action report. Mythological gods seem like they'd be OK... but maybe Seven Dwarves or Deadly Sins or Slang Drug Terms would be embarrassing?)
Even if you want "safe" sanitized names though, I can't understand why people create these elaborate multi-part naming conventions for servers. Seriously, if the hostname is harder to remember and type than the IP address, YOUR NAMING CONVENTION IS BROKEN!
Your own personal laptop is a different matter.
Moreover, if you want personality, just set up your ~/.ssh/config to retain the legacy name for yourself, e.g. "ssh middleearthname" to connect to server001.foo.com
Exactly. For instance, my firewall is called "charon". Personification is a good thing and should be encouraged. It's easier to visualize things that way. From an inside-out perspective (people such as accountants who see everything but, for the most part, do not understand it), naming servers like $function_$row_$rack_$slot or whatever else makes sense...it will simplify things.
The problem is that it simplifies things from an inventory perspective, not from a "I'm trying to visualize this so that it all works" perspective.
Think about it like this: you have things in your kitchen, right? Say you have a toaster, a refrigerator, a mixer, and a microwave. You would NEVER call them things like "appliance_counter1_left", "appliance_floor_right" etc. This would be confusing. It is for this reason that humans give things names; toaster, refrigerator, and mixer are all names, they're just very common ones.
> The problem is that it simplifies things from an inventory perspective, not from a "I'm trying to visualize this so that it all works" perspective.
That depends - I'd much rather a firewall rule that told me that Glasgow Database Server 2 can talk to London Mail Server 3 for SMTP traffic than one that told me MissPiggy can talk to Kermit for χάρτης traffic.
Especially when it's not a system I deal with every day and I haven't cached the name/function mappings in my head.
On the other hand, the UK postal system works well with a mixture of numeric sequences (house and flat numbers), cutesy names (road names, city names) and arbitrary government assigned gibberish (Post Codes).
I personally have very nearly experienced a disaster because the official naming convention had only one character difference between production and UAT...
Anyway, you've missed my point a bit. It doesn't matter much in the grand scheme of things what the boxes are called. It DOES matter than your company is employing people to impose pointless, trivial changes and policies on people with real work to do.
The big win, though, for a more clinical naming is that shared context/training can be easier, and in a larger org the standardization of course makes things a lot easier to deal with. But of course, standardization can be done with the more whimsical names. And a lot of the time the naming scheme that is drawn up by committee takes just as long to learn as the more fun ones (mostly because they need to be abbreviated a bunch).
I suppose the one thing you can say for formal naming systems that is fairly inarguable is that once you understand the rules, you can look at an unfamiliar machine name and know instantly what it does. For machines named after fictional characters that's only true if you read/watch the same books/shows as the people doing the naming.
The confusion this causes for new hires and non-natives is real, albeit somewhat comical.
edit: ServerXX is no better-the names should give a clue to what function they perform (i.e. IRV-FNP01 = located in irvine, file and print server, 01 [oldest server])
I have nothing against naming things in such a manner (my computers at home are cartoon characters), but the problem is that it doesn't scale. The company I work for is under 10 years old, and while a bit too old to still be called a startup, we already have more print servers than there are planets, let alone DB, dev, QA, and web servers. The last couple start-ups I had also had hundreds of boxes, and I'd go insane if "db-35" was actually named "WASP-18b" and I had to remember a list of 50-ish planets.
If you had a Pluto before the IAU changed its classification from planet to "ball of rock" you have a nice excuse to use whatever spherical lumps of rock you feel like.
It may not solve your problem forever, but, then, you can expand the naming to "potato-shaped lumps of stuff". That should give you some mileage.
So, what type of machine is "mercury"?
I've never seen a theme-based naming scheme that didn't eventually run into ambiguities like this.
It's not hard to have DNS CNAME and TXT records for machines, so that you can have both a naming theme for certain classes of servers, as well as descriptive names that indicate function, location, etc.
The way I handle the problem is pretty simple. Functionality gets a subnet 'name' under the root, and there are TXT records and aliases within that to handle description. So, if you have a datacenter in Sacramento, your DB and web machines would be named and alised:
johnny.sac.mycorp.com => db1.sac.mycorp.com TXT Rack 1, Slot 1-4
devi.sac.mycorp.com => db2.sac.mycorp.com TXT Rack 1, Slot 5-8
spooky.sac.mycorp.com => db3.sac.mycorp.com TXT Rack 1, Slot 9-12
tenna.sac.mycorp.com => db4.sac.mycorp.com TXT Rack 1, Slot 13-16
zim.sac.mycorp.com => web1.sac.mycorp.com TXT Rack 2, Slot 1
gir.sac.mycorp.com => web2.sac.mycorp.com TXT Rack 2, Slot 2
For ambiguous names (like 'mercury' existing in both { planets } and { elements }), only one copy of that name can exist on the network. The people who work with that machine will know it's theirs, and for everybody else, there's CNAME and TXT records for when they're not sure.
That's true. However, humans do better with names than numbers. Otherwise, DNS wouldn't exist. The real question is who do you want to optimize for?
staging: dwarves
prod: elves
Or, actually, there are, but they are actually Elves...
And I can't go back and fix it either!
s/gnomes/hobbits/
Well, let's hope no hobbits read this website.
I bet you could save $10,000 a year by eliminating the arbitrary names and calling them ServerXXX.
Sorry for the attempt at a witty reply. Let's start again. Agreed, there are efficiencies. The point of the article is that when you institute changes like this, you may create unintended consequences like a mass exodus of people who liked working for a company where the servers were named after Muppet characters and associate "Server042" with a company where professional managers demand cover sheets for their TPS reports.
Before making such a change, ask yourself this question: Is what I'm doing good for the company?
If you knew what the consequences were going to be then they wouldn't be unanticipated, but if you didn't know then you couldn't accurately answer the question.
Aren't you just asking people to 'know the unknown unknowns' and never make poor decisions?
Wouldn't it be a more realistic suggestion to ask them to ask "Was this good for the company and if not, should we revert to how it was before?"
By the time management realises that soda should have been free, the opinions of the top engineers have irreversibly changed.
In the movie, the PHBs hold a meeting in which they solemnly instruct all their employees to ask "Is what I'm doing good for the company?" before they do anything.
The audience rolls its eyes in sympathy, for the reasons you've pointed out here.
You sigh and roll your eyes because it's a patronising request which stamps the bosses authority and makes it clear that the boss thinks all the employees are a bit slow. (Or perhaps because you think it should be up to the boss to decide what's good for the company then organise the employees to do it, and by asking the employees to do that he's trying to avoid work by pushing his job onto the employees while still keeping his position and salary).
The parent post I was responding to was suggesting "try to see the unexpected consequences" and I was countering "that's like trying to find all the bugs - you'll never know when you've finished; more helpful would be managerial humility and willingness to notice negative results and revert the changes".
Which is what disturbs me about the story. A CFO is paid to think big picture, to confer with the CTO about morale, and so forth. In a well-run company I would expect a middle manager to suggest quashing free drinks and the CFO to demur after conferring with colleagues.
Given the story as told, I wonder if an Engineering-Business war was breaking out and if the CFO new exactly what was going to happen.
Am quite surprised that people see this as linked to sodas and drinks. Those sodas are cheap productivity wins. So is systematic/meaningful naming.
(Perhaps this is the open vs. free software debate. The open source POV is that free sodas are good because they increase productivity, in ways that are not obvious in the short term but no less real. If they decreased productivity that'd be a different matter. The free software guys are more ideological about things. )
By contrast, "hq-web-001" is an early webserver at head quarters, while "br1-sql-020" is a later database server at branch office 1, and the next server name is the next in the appropriate sequence.
I'm not a systems admin, but I presume this is because you can write a for loop that counts through your machines and does something to each, right?
In that case, couldn't you just have nested arrays?
machines = ['mailservers'=>['Earth'=>'some IP', 'Mars'=>'some IP'],'devservers'=>['Dopey'=>'some IP', 'Sneezy'=>'some IP']] ...etc.
Now everyone can connect to a machine with a memorable name, AND you can loop through all the dbservers if you need to, AND anyone who doesn't understand the system can look in one place to grok it.
What's the problem?
I am a sysadmin, and I can tell you that I outgrew cute server names many years ago because they hurt more than they could ever help. Reading this thread, it is painfully obvious to me that most people here have not been meaningfully exposed to large server installations. The last time I had servers with cute names, there were 12 machines total. Since then, I've worked in environments with hundreds and thousands of hosts.
Even past a couple dozen servers, cute names become a liability and a significant distraction. Divining purpose, location, and other meaning by looking at a cute name when you have 30 servers is difficult and unnecessary. Applying the 3am standard (can a sleep deprived sysadmin do this task with minimal error at 3am?) cute names actually become rather cruel. The answer is to build an inventory system that lets the sysadmin map cute names to functional information. Or simply build that functional information in to the naming scheme.
So sorry guys. As a professional sysadmin and fellow engineer I appreciate that you are looking out for what you perceive to be our sysadmin needs, but cute names are one thing we don't want or need. Unless perhaps you can come up with a justification for renaming the functions and classes in your code with cute names...
Names like server001 are great and fine for a cluster of more or less identical, interchangable machines (Beowolf cluster, cluster of VMware hosts, etc.). But it sucks ass for most other circumstances. Seriously. Try having discussions about a project involving a dozen servers (out of hundreds in the company mind you), each with names like server3056, server3087, server3109. It sucks, because 5 minutes after talking about it you find yourself wondering: Hmmm... was I supposed to reboot 3087? or 3078? :-)
The HQ is for Headquarters, DC for Domain Controller, 01. HQDS01 for Headquarters Development Server 01, etc... It's an MCSE best practices naming convention to locate and indentify servers.
Furious but didn't contest it.
They're no longer in business.
Hell, from most of the stories I've heard from people working for bigger places, people who don't log into the machines frequently don't even know that the machines have names.
i used to work for a company where i wrote critical pieces of their software infrastructure. it's a series of interconnected apps which i named after marsupials. i have now left, and they are in the process of giving the apps boring names that more directly indicate what they do.