Every machine needs a name. As soon as the second server is ready to go, the name SERVER no longer seems like a great idea. When deciding how to name servers, there are two primary conventions: functional names and unique names.

Functional Names

Functional names take the job assigned to the server, add a unique identifier if there is more than one server doing that job, and call it done. Thus if you have three mail servers, they are MAIL1, MAIL2, and MAIL3. This naming convention has two perceived advantages over other conventions:

• Quick and Easy
  Since the formula for selecting server names is predefined, it's only a matter of seconds before the next server name is determined. Adding a third database server? DB3 it is!
• Self-Documenting
  The least fun aspect of system administration is documentation. Generally, it's tedious and just no fun at all. By naming servers by what they do, half the job of documentation is already done.

As indicated above, these advantages are really only a matter of perception. This convention is only self-documenting on a network that experiences no evolution. Over time, server responsibilities change as the needs of the users change. For example, a server called WEBMAIL is obviously the webmail server. But, it is also a prime candidate for another web-based application (perhaps the IT department's trouble ticketing system). Once this happens, WEBMAIL is no longer just the webmail server. WEBAPP would be a better name, but renaming the server is not an easy process. Now the documentation must be updated to note that the trouble ticket system resides on the webmail server. Unfortunately, since the staff is used to the "self-documenting" nature of the functional naming convention, no one remembers to update the documentation, and no one knows where to look when they can't find a server called TICKETS.

Unique Names

Unique names can be of the human-readable variety (FRED) or machine-generated (7C0). Any name at all is acceptable, so long as the network documentation is updated regarding the responsibilities of the server. This naming convention focuses on the fact that, over it's lifetime, a server will most likely provide many functions. Rather than deriving generic function names that can (hopefully) accommodate any changes, the unique naming convention throws that out and avoids any future confusion. Administrators are trained from the beginning to review documentation when a question arises, and are more likely to maintain the documentation when changes are implemented.

In general, both naming conventions have their merits. Over time, the functional naming convention loses out as its benefits lead to a lackadaisical approach to network documentation. The unique naming convention not only encourages maintenance of the network documentation, it requires it. In the end, finding the right server to work on when necessary is the only thing that really matters.