UNIX System Administration Handbook - Evi Nemeth [472]
Of those completing the survey, 84% were from the United States, with about 50% labeling themselves as system administrators and another 24% as network administrators. The other categories were much smaller percentages. Here are some of the more interesting results:
• The OS type mix was quite different: 63% NT, followed by Solaris at 14%, Novell NetWare at 6%, and everything else below 3%. Linux was the primary operating system for only 2.1% of those completing the survey.
• The peak of the experience curve was at 3–4 years, instead of 5 as for the LISA/SAGE crowd.
• The median salary was in the low 50s for NT admins and mid 60s for UNIX admins. Gender cost female NT admins $2K and female UNIX admins $4K (normalized to similar education and experience levels). 12% of the respondents were women.
• A BS degree was worth $5K to an NT admin and $8K to a UNIX admin; a master’s degree added another $5K–$8K.
• Novice, junior, and senior administrators received salaries that increased with expertise, but there was some compression on the top end.
• The average work week was 46.8 hours, with NT and UNIX admins reporting almost identical values.
27.4 SCOPE OF SERVICE
The services provided by an administrative support group must be clearly defined, or users’ expectations will not match reality. Here are some issues to consider:
• Response time
• Service during weekends and off-hours
• House calls (support for machines at home)
• Weird (one of a kind) hardware
• Ancient hardware
• Supported operating systems
• Standard configurations
• Special-purpose software
• Janitorial chores (cleaning screens and keyboards)
In addition to knowing what services are provided, users must also know about the priority scheme used to manage the work queue. Priority schemes always have wiggle room, but try to design one that covers most situations with few or no exceptions. Some priority-related variables are:
• The number of users affected
• The importance of the affected users
• The loudness of the affected users (squeaky wheels)
• Importance of the deadline (late homework vs. research grant proposal that partially funds the sysadmin group)
Our support group for faculty, staff, and graduate students has developed a set of documents that delineates their services, priority scheme, and contact mechanisms. This group of customers contains several levels of importance and squeakiness. The policy documents have been used for a few years with good, but not perfect, results. Copies are available from www.admin.com.
27.5 TROUBLE-REPORTING SYSTEMS
Our trouble-reporting system uses an email alias called “trouble.” At one time we were bombarded with trouble reports that were either incomplete or incomprehensible. We wrote a script that asked the user specific questions, such as
• On what host does the problem occur?
• Is the problem repeatable?
• How important is it that the problem be fixed immediately?
The user rebellion started about an hour later, and within a day we had backed the system out. Its only value seemed to be that with the furor over the script, many users actually read the questions it was asking and the quality of our free-form trouble reports improved.
Another site dealt with this problem by sending out a message that explained what information is important in a trouble report and showed examples of useless reports. When a useless report was received, it was answered with an apology (“Sorry, I don’t have enough information to...”) and a copy of the explanatory message. The users caught on quickly.
You need to use some sort of trouble ticketing system or problems will either receive five answers (the easy ones) or no answers (the hard ones). The system should log resolved trouble messages and perhaps send a copy of the resolution to novice sysadmins and trainees. The log files become a useful source of data