[caw]

I've done both an encoded data name scheme (what this is) and the cattle method (srv0001, srv0002, etc etc). SRV can even encode a bit of information like datacenter location. Avoid rack/row because stuff gets moved around. Airport codes are popular to distinguish datacenters.

As far as encoded name schemes go, and even with the cattle method, I like the physical/virtual distinction. It lets me know whether I can iLO/IPMI/drac or need to open vSphere/equivalent for when SSH doesn't fix everything.

Where I don't like encoded schemes is because your departments and users inevitably want to change the environment or service. Experimental/test servers tend to feature creep into production because "it works, let's just promote and build a new test box". Also you end up with weird combo servers with multiple services because "it's only this one thing and we can't wait for a new box just for it". So now the web server isn't just a web server or an app server.

My opinion is to keep naming however you're naming. I'd consider dropping the environment and most likely department. Encode that into the CNAME, or keep another database of ownership.

This article is pretty good on naming schemes: https://mnx.io/blog/a-proper-server-naming-scheme/

[mercnet]

I also bookmarked that article at mnx.io and think it is very straight forward naming schema.

[billias]

I used till now the mnx.io style of naming, which is from more specific to more generic approach... and found it also easy to remember.

Last but not least, on multiple environments you have the same local naming, and your applications can work without even touching them.