The names don’t have to be friendly. Larger sites can use generic names, like alpha-472, and dns aliases to define the “rtpfiweb01″ style of information – so that when it changes, a rebuild isn’t necessary. If the warning emails aren’t giving enough information to identify the machine immediately, that’s another problem. :)

The key advantage of functional names is that they can include metadata. Say you have 5 web servers for Foobar International in RTP – if you choose a functional naming convention (say, rtpfiweb01-05), the hostname alone contains several pieces of information:

1) It tells you where the machine is (RTP)
2) It tells you what the client is (fi)
3) It tells you what the machine does (web)
4) It tells you that the machine is one of a number of related machines (05)
5) It tells you how to find those other related machines (by modifying the sequence number).

Now, sure, you could look all of this up in the documentation if you had to, and if you work with the site on a daily basis you’ve probably got it all memorized.

But what if your NOC technician or junior admin gets an alert at 3 am? The functional name reveals everything he needs to properly route his call. There’s no question – if he knows how to read the hostname, he doesn’t need to look anywhere else.

Now, I still like friendly names for small sites, where there are few sysadmins and few servers. In such a situation, it’s absolutely normal for services to move around or are added – “bombadil” may do 10 different things with no logical relationship between them, at which point functional names are impractical. But in large sites – where machine purposes are narrowly defined and largely immutable (until a machine is entirely repurposed and rebuilt, at which point it’s also renamed) – functional names can work quite well.