UNIX System Administration Handbook - Evi Nemeth [473]
We used a home-grown trouble ticketing system called queuemh or troubmh for years. Our current favorite is wreq (www.math.duke.edu/~yu/wreq). wreq is based on req from the University of Maryland, to which it adds extra functionality and a web interface. It has almost as many features as the commercial offering Remedy, but is easier to configure and use and easier to fit into your budget (free!).
wreq ’s graphs of tickets submitted, resolved, and rotting are especially useful for both sysadmins and management. They can help you detect long-term trends. wreq ’s main disadvantage is its poor (ever-so-close to nonexistent, really) documentation.
27.6 MANAGING MANAGEMENT
It’s essential for your managers to respect and support you. Management support for tough security policies is sometimes the hardest to get. Tightening security invariably means inconveniencing users, and the users usually outweigh you both in number and in whining ability. Make sure that any security change that impacts users (changing from telnet to ssh , converting from passwords to RSA keys, etc.) is announced well in advance, is well documented, and is well supported at changeover time. Documentation should be easy to understand and should provide cookbook-type recipes for dealing with the new system. Allow for extra staffing hours when you first cut over to the new system so that you can deal with the panicked users who didn’t read their email or the motd .
Upper management often has no idea what system administrators do. Keeping a diary for a week that records what you do and how long it takes will surprise even you. This kind of documentation is essential when you campaign for additional staff or equipment. It can also be a source of power in day-to-day political squabbles. It may be wise to keep good records even in the absence of a particular goal.
Managers, especially nontechnical managers, are often way off in their estimates of the difficulty of a task or the amount of time it will take to complete. This is especially true of troubleshooting tasks.
Try to set expectations realistically. Double or triple your time estimates for large or crucial tasks. If an upgrade is done in two days instead of three, most users will thank you instead of cursing you as they might have if your estimate had been one day.
It is sometimes hard for a sysadmin to get a written policy put in place. In that case, document existing practices and policy. For example, “We have 8 licenses for Excel and 47 copies installed.” Ask for money to buy more copies. If this fails, write a memo documenting the problem with a copy to upper management. Fortunately, good system administrators are in demand, so your job search should be short.
27.7 HIRING, FIRING, AND TRAINING
There are two approaches to building a staff of system administrators:
• Hire experienced people.
• Grow your own.
Experienced people usually come up to speed faster, but you always want them to unlearn certain things. To do their job, they need root access. But you do not know them and may not be willing to put your company’s data in their hands immediately.
It takes quite a bit of time and effort to train a sysadmin, and production networks are not an ideal training ground. But given the right person (smart, interested, curious, careful, etc.), the end result is often better.
We have developed two evaluation tools for experienced applicants. We used to call them “tests,” but have found that some institutions are not allowed to test applicants. We no longer test; we evaluate and assess.
The first not-a-test, a written evaluation, asks applicants to rate their experience and knowledge of various system and networking tasks. The scale of familiarity is 0 to 4:
• Never heard of