Objectives| Introduction| Policy and Penalty| Records| User Liaison| Observation| Conclusion| Review Questions
These machine independent tasks include
Exercise 5-1. What factors do you think would affect the setting up of a sites policy and penalty components? e.g. the type of work being carried out the company might affect security procedures.
Exercise 5-2. For what other issues might it be important to have policies on?
What happens if the Systems Administrator didn't record the solution? Unless he or she is blessed with a photographic memory there is liable to be another two to three days lost trying to fix the problem.
Records of everything done to the system must be kept and must be accessible at all times.
It is typical for a Systems Administrator and/or a computer site to maintain some type of log book. There is no set format to follow in keeping a log book.
Electronic Paper For Against For Against easy to update if the machine is down less prone to harder to update and search there is no access machine down time and search easy to include can be hard to can be carried can become messy command output include diagrams around and hard to read Table 5-1. Comparison of electronic versus paper log books.
It is possible that a log book might be divided into separate sections. The sections might include
If you intend using a paper based log book then one suggestion is to use a ring binder. Using a ring binder you can add pages to various sections if they are starting to fill up.
The following reading was first published in "The Australian Systems Administrator" (Vol 1, Issue 2, June/July 1994) the bi-monthly newsletter of the Systems Administrators Guild of Australia (SAGE-AU). It provides an example of how a real-life System Administrator handles user liaison.
Next to balancing conflicting demands, communicating with users is the hardest part of my job. I tend to make a great effort for little gain, whereas in technical endeavours a little effort can produce a major, long-lasting improvement (for example, taking ten minutes to set up regular, automated scratch area cleanups has saved me hours of tedious work and the users a lot of frustration).
Also, with users there are emotions to take into account. It doesn't matter whether the computer respects you, but if the users respect you life is a lot easier.
My aim in communicating with users is to make life (my job and those of the users) easier by:
Probably the method most useless with the general user community is the policy statement. The typical user just isn't going to read it. However, it can be a good way of communicating with management. Drafting a good policy statement (based on discussions with everyone, but especially with them) shows you mean business and understand how your work fits into the organisation. It should cover the responsibilities of the systems administrator as well as those of the users.
Group meetings, whether of the users in general or of a committee of representatives, can help people -- again, especially senior people -- feel more confident that things are going OK, but aren't much use for disseminating information. If a meeting is run well you can have a productive discussion of major issues, but if run badly it is likely to turn into a gripe session.
Paper memos are to be avoided, because they encourage stiffness and formality. I use them only to answer other people's paper memos (which are usually complaints) and then only when I don't think the person will read it if I do it by email. Replying by email to a memo has the effect of saying "There's no need to be so formal".
There are a number of leading-the-horse-to-water methods, which only work if the user makes an effort. You can use electronic information services, such as bulletin boards, newsgroups, Gopher, or online manuals; and you can get together a library of printed manuals and books. If you provide easy access to high-quality information, the interested user can learn a lot. Unfortunately it's often the disinterested user that you really want to reach.
People often come to my office to ask me things. You'd think that face-to-face communication would work the best, but in this particular setting it doesn't because I am not comfortable. It's not so much that I resent interruptions -- it's that I don't have an office, only a desk. There's no room for a visitor's chair; to talk to anyone I have to swivel round and face backwards; and people make a habit of sneaking up on me. Hopefully, one day my campaign for proper accommodation will be successful, and it will be interesting to see how much difference it makes.
Talking on the phone is only good for emergencies. Someone is always interrupted; there's no body language; and you tend to forget half of what you wanted to say.
I write a column, "Computer Corner", in our staff newsletter. I sometimes write about issues (such as what I'm trying to achieve) and sometimes about technical tips. This column isn't as useful as I'd hoped. The first problem is that there isn't room to say much, because the newsletter is short and a bit, shall we say, irregular. The second problem is that the rest of the newsletter tends to be kind of dull (lists of visitors; dry field-trip reports; the occasional births and deaths) so people aren't so eager to read it. When I pointed this out I was told that it is deliberately impersonal and non-funloving because some of the more senior readers are rather easily offended. Sigh.
Next on the scale are signs (on doors, noticeboards, etc) and electronic messages-of-the-day. People have a strong tendency to miss the former and ignore the latter. It may help to make them more interesting with graphics, pictures and human-interest items.
Seminars and workshops are worthwhile if you can get people to attend, but they're a lot of work. If not many turn up, you don't get much return on your investment. Students can sometimes be induced to attend by making it count towards their marks. In other situations, offering food, door prizes, alcohol, sex, drugs or rock-n-roll may help.
For explaining specific information (how to pick a good password; how UNIX file permissions work) I've found paper handouts reasonably effective. Some users take them quite seriously, even filing them for later reference. Unfortunately, others toss them straight in the bin.
After about 3 months in my current job I emailed everyone a questionnaire, asking such things as what they used the systems for, what new services they would like to see, and how often they did backups. I offered a chocolate frog to each person who replied. The subject line "Apply here for your FREE chocolate frog" caused some of the more pokerfaced members of staff to delete the mail without reading it, but otherwise the response was surprisingly good. In hindsight, I guess the questionnaire generated more PR than information, although it did confirm my suspicion that most people did not back up their data even though they were supposed to.
For me, the second most effective communication vehicle is email. Email is as informal as a personal visit or phone call, but you can get in a lot more information. It is also asynchronous: no-one has to be interrupted, and you don't have to wait for people to be available.
I often use email broadcasts for notification -- to tell people about impending downtime, for example. Email is quick, convenient, and reaches people who are working offsite. It is also informal and I think people feel more at ease with it than they do with paper memos and printed signs.
1-to-1 email gives people a sense of personal service without much of the hassle that normally entails. At my site people can email problem reports and questions to a special address, "computerhelp". Our stated aim is to respond within 2 working days. We don't always make it. But it does give people a point of contact at all times, even after hours, and it means we get a few less interruptions.
You'd think all of that might be enough, but no. My boss said, "You need to communicate more with the users, to tell them about what you're doing". I agreed with him. So I now produce a fortnightly emailed bulletin. It is longer and more formal than a typical email message, with headings and a table of contents. Most of the information in it is positive -- new software that we've installed, and updates on our programme of systems improvements. I also include a brief greeting and a couple of witty quotations. Judging by the feedback I've received, this seems to be working remarkably well -- much better than the staff newsletter column.
The only thing that works better than email is personal visits where I am in their office, usually leaning over their screen showing them how to do something. Taking an interest in their work helps a lot. I find this easy where they are graphing the temperature of a lake in glorious colour, but more difficult where they are typing up letters. I don't do enough personal visiting, partly because I'm so busy and partly because I'm not keen on interrupting people. It usually happens only when they've asked a question that requires a "show me" approach.
A disadvantage of personal visits is that they help only one person at once, whereas with email you can reach all your users.
To sum up: in communicating with users, I aim to teach them things and get them to respect me. By sending email I can help the most people for the least effort, although personal visits have much more impact. There are other useful methods, such as policy statements, newsletters, handouts and seminars, but they may not reach the ones who need it most.
It's hard. Very hard. If you have any insights or ideas in this area, I'd love to hear them, and I'm sure the rest of the readers would too.
The sort of regular observations required include
Another important reason for making AND recording these observations is to use them in negotiations with management when it becomes time to lobby for better equipment. It is easier to convince management that you need another disk drive if you can show them reports that demonstrate that disk usage on the system has consistently run at 95% or higher.
We will examine the methods used on UNIX system to do this logging and observation in section 16.
The importance of
5.2. Decide on a format for your logbook (something you may already have done). Collect all the information that is mentioned in this section and anything else you consider important.
David Jones (author)