This chapter is from the book
This chapter is from the book
This chapter is from the book
Handing Off to the Users
After thoroughly testing each unit, connection, and function of your system (which you learn about in Chapter 4, "Testing Your Systems"), you're ready for the final step of the build-out process—the handoff. This is when you take your finished product, your shiny new servers, and hand them off to the people who will actually be using them. You hand off database servers, for example, to a DBA, so he or she can install database software and set up the databases. You might hand off Web servers to Web developers who will put up some Web content. Maybe you hand off things like DNS and mail servers to yourself, or to a separate operations team who will handle the day-to-day operations of those servers.
The key to a smooth transition between you and the group or person you are handing off to is good documentation. You should have collected requirements from these people as one of your first tasks (see Chapter 1, "Planning Your Architecture"). Now it's time for you to document how the system works and what users are to do when they have problems with the system. Basic operation and troubleshooting documentation can help you avoid getting calls in the middle of the night for routine tasks such as adding an entry to DNS or clearing the mail queue! Handoff documentation can typically be broken down into the following categories:
Procedural documentation
Frequently asked questions
Contact information
Each of these pieces of documentation can be in either electronic format or a hard copy. You may want to utilize both formats so users can read the hard copy whenever the documents are unavailable from their computers.
Preparing Procedural Documentation
The most important documentation you can hand off to a system's end user is procedural documentation. This describes the step-by-step procedures to accomplish common tasks on the system. For example, if you hand off a new mail server to operational staff who are responsible for maintenance of the mail queue, you need to provide some documentation on how to perform the tasks involved with its maintenance. If somebody needed to restart the sendmail mail daemon on this server, the following documentation would clearly demonstrate how to do that:
Log in to the mail server.
su to root.
Type /etc/init.d/sendmail stop.
Type /etc/init.d/sendmail start.
Type ps –ef | grep sendmail to verify that the new sendmail process exists.
Answering Frequently Asked Questions
Before you hand off the system to users, compile a frequently asked questions (FAQ) document to answer several of the most common questions associated with your service or system. As its name implies, this document provides users a quick reference for common problems they might encounter on the system; and it eliminates the need for you to answer the same questions over and over again.
As the administrator of the system, you should be able to predict common questions users might have. You cannot predict everything, however, so the FAQ needs to be a "living document," constantly changing as new features and questions arise. Here is part of a fictional FAQ for a Unix shell service:
What are the names of the Unix shell servers?
There are four Unix shell servers available for your use. They are: apple, cherry, orange, and pear.
How do I change my password?
At the bash$ prompt, type passwd and press the Enter key. Type your original password for verification. You will not see any output. If successful, you will now be asked for your new password. Type in your new password followed by Enter. You will be asked for your new password again for verification. Type your password again and press Enter.
By periodically adding to and updating your FAQ, you can create a document that saves your company time and money. A well-constructed FAQ helps keep users productive and reduces the amount of time you must spend troubleshooting common problems.
Provide Contact Information
When an emergency occurs or a user has a question that nobody else can answer, you should provide contact information so people can get in touch with you or the appropriate staff if necessary. One very convenient place to put this is in the message of the day, /etc/motd, which is printed every time a user logs into a Unix system. Here is an example:
Welcome to the example.com Unix shell server! For technical assistance, please e-mail support@example.com or call 555-1234. For all other questions, comments, and suggestions, e-mail admins@example.com.
You should also provide vendor support information in your motd or FAQ document, in case you or your staff are not available during an emergency. You learn more about using motds in the section titled "Advertising Your Support Department," in Chapter 5, "Support Administration."