If all else fails, read the manual. When you can't figure out the solution, try the resources that you often forget to access.
When debugging, change one thing at a time. By changing one thing at a time, you see which change actually affected the system. This avoids confusion as the debugging process proceeds.
Always test your work. Some people never seem to make mistakes. I find that they are the people who do a lot of testing—we just don't see it.
You aren't done until your customer tests it, too. You may think you've tested things sufficiently, but until the customer has done his own tests, you really don't know whether you've fixed his problem.
The strangest problems often turn out to be misconfigured DNS. DNS is critical to so many subsystems, often in obscure ways, that a problem with DNS can mask itself as other problems. This goes for a client that can't reach its DNS servers, as well as a host with invalid DNS data describing it, or a client trying to reach a host with invalid DNS data.
The delegate, record, or do process permits you to take back control of your time. Use this when your project work is interrupted.
When you record it, you gain the ability to plan and schedule rather than being interrupt driven. This is something we discuss further in Chapter 8.
When you acknowledge a request, you should do it in a visually meaningful way. Make sure the person sees you record it, and confirm it with her.
Customers would rather have a request acknowledged than not know whether it was received, even if this means the request is being delayed.
Request-tracking systems like RT let you record requests in a central database that other system administrators can access and that customers can use to check a request's status.
Never trust your brain to remember a request. Record the request on paper or digitally. Your brain has better things to do.
Just Start
Once you get started, it won't be as difficult as you thought. In fact, often we don't begin a task because we make excuses about how much time something will take, but once we get started, we find out that the task is relatively quick.
A friend who promised to give me feedback on chapters of this book as they were written was weeks late with her notes on Chapter 1. She kept putting off getting started because she told herself she couldn't start until she found a full two-hour block to do a really good job. It turned out that Chapter 1 was less than 10 pages and only required about a half-hour to review.
If she had just started—instead of making up rules about when she could start—she would have been done much sooner.
Chapter 3. Routines
The term 'routine' has a bad reputation. How many times have you seen advertisements for products that promise to 'get you out of that old routine' or refer to a 'boring routine?' Boring is bad, right?
No! As a system administrator I crave boredom. I want an entire week when things happen on schedule, projects get done on time, software installs without trouble, and documentation gives me the right answer. 'Give me just one boring day!' I shout when a big server crashes or a customer comes to me with an impossible but urgent request.
What I wouldn't give for an entire boring month!
There are technical means to improve the situation. We can make things more boring (in a good way!) through long-term planning and suitable infrastructure that makes things run smoother. For example: automating new machine installation so that every host starts out the same, controlling and enforcing updates so all hosts stay in sync, keeping security infrastructure in place so that it is ubiquitous and less burdensome, and so on. There are books about those topics already—I happen to prefer
I don't want to make system administration 100 percent boring—I don't think that's actually possible. As long as there are new software
