Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

How Much Unix Knowledge For Helpdesk Staff? 24

Posted by Cliff from the stuff-to-think-about dept.
Shisha asks: "I have to train IT helpdesk staff to be able to solve UNIX related problems. The trouble is I don't really know what will be most useful for them. I can't teach them all about shells, processes, deamons, sendmail, Xwindows etc. because that's just too complex. Another problem is in the slight differences between AIX, Solaris, Irix and Linux. The idea is that they should be able to solve simple problems, so that the really qualified people won't have to waste their time on them. We are talking about 16,000 potential users, on 5-10 multiuser servers and about 300 Xwindows workstations, so the number of problems daily is high. Also what commands would they need with root privileges (through sudo)? So the question is what should they know and what access rights should they have."
This discussion has been archived. No new comments can be posted.

How Much Unix Knowledge For Helpdesk Staff? More

How Much Unix Knowledge For Helpdesk Staff?

Comments Filter:

  • Standardize, standardize, standardize!!! (Score:1)

    by Anonymous Coward
    First, get rid off all the shitty Solaris, AIX, and IRIX boxes. Have the machines crushed before final disposal to prevent someone else from using them. Second, put a PC on everyone's desk. Now you should have management forbid the use of Linux or even the posession of Linux CDs on company property. Call Microsoft about site licensing agreements for Windows 2000 and Windows Millenium Edition. Put it on *ALL* machines and destroy any machines which will not run it. Fire or preferably kill anyone who opposes this action.

    ore information can be found here:
    Microsoft [microsoft.com]
  • "What do I teach them?" - Teach them to fix what is broken.

    It sounds like a flame, but it is not intended to be one. If you don't want to waste time teaching them stuff they wouldn't need (or would be confused by), you first need to know what problems are likely.

    Ideally, you would look at the records of past problems (you *do* keep logs of each call and the problem, don't you?) and solutions used to figure out what the common problems are. You say you're only using these guys as first line weeding, so hitting the ~80% of problems which get repeated over and over again is all they need.

    But since it seems like you might be building things from the ground up, you may not have the usage history to do that. In this case, look at what others cover. If you're tech support for an ISP, look at ISP web pages for troubleshooting guides and FAQs. Look at help files on the programs/systems you use. (Not the official manuals, but the "I'm not associated with this project, but I wrote a help file for new users." ones)

    Remember, you're not reading this for your own benefit. If you find yourself reading something for the fourth time, that should be a red flag that this is an important point to cover. Don't just skip over it as redundant.

    Above all, remember iterative development. Track help cases and determine what the frequent/easily solved problems are. Keep a manual on these items, and require your support staff to stay up-to-date on it. Just because they passed through the first day's training doesn't mean that they've finished learning.

    And another thing ... make your troubleshooting manual publicly availible. That way, when another person finds themselves in the same position you are in now, they can benefit from your wisdom.

  • THis thread is something I want to see /. opinions on, and here it is a deaad thread. With two or three good entrys. Foo.
    SPOON!!!
  • Set up an internal IRC server that all of your techs are connected to. I worked in tech support once where we had that, and it was invaluable. Your newbies have access to the old guys, and someone whose expertise in one area could stand improvement has access to the guys whose expertise in that area shines.
    All your base are belong to us.
  • i'd advise against this for the simple fact that if bob is the only one who knows how to do x then what happens on the day he decides to call in sick? quit? get hit by a bus? specializing in one area is ok as long as everyone has some knowledge, but compartmentalizing it may be a bad idea.
    "Leave the gun, take the canoli."
  • It's hard to say what they'll need to know without knowing more about the enviroment (apps, etc), but it's safe to say that they are going to need access to the passwd command to reset the passwords that are going to be forgotten every day (obviously, you would want some sort of wrapper around the actual passwd command that only allowed changing passwords on end-user accounts), some way to unlock locked accounts (if you have implemented account lockouts after a certain number of failed logins), and probably a way for them to restore user files from backup.
  • Add to that how to go to a terminal from X and how to go back (Ctrl-Alt-F1 and Ctrl-Alt-F7, or whatever your box uses).

    I would also add how to use top, how to kill a process, the Left Alt-sysRq sequence (LAlt-SysRq-r,s,e,i,u,and b) or whatever is used to proform an emergency shutdown, and emergency recovery procedures (how to deal with a failed filesystem check, the system hanging at boot, ect. and how to use a rescue disk, boot to a diffrent runlevel, ect.).
  • If I were you I would make a (mysql/php ?) based system in which you put sollutions to the problems that are encountered often. Your helpdesk workers can then type in some keywords describing the problem in a webpage they have open and some hints or even better, the solution to the problem will show up in their webbrowser. Doesn't have to cost anything, very usefull. Whenever your helpdeskpeople run into a new problem a few times, let them (or a tech-guy) write down the sollution and let one of your guru's read and add it to the database if he agrees on it. Over at our company we have a system like that, and it's very effective.
  • on a similar note, when I was managing a helpdesk (about a year ago), we managed to get ahold of ICQ Groupware. We got everyone connected with it, then specified paging groups (Tier 1, Tier 2, admins, managers)... It worked pretty well, and the techs didn't have to keep track of (or learn to use) an entire IRC window; just about everyone knows how to use ICQ these days...
  • A runbook.

    Thats what they really need, its a if-this-is-the-problem, do this book.

    /*
    *Not a Sermon, Just a Thought
    */
  • First, teach them the basics, have them run the apps the people they are supporting are going to run, tell them to try and break them, and then fix them. Second, the Rute users guide is pretty good, watch the licensing terms though. http://rute.sourceforge.net
  • Coming from a help desk for a major corporation, I think that I may offer some perspective. First, if the needs of the organization requires some UNIX knowledge, then require it. Otherwise, like in my situation, they taught us some of the basics. One of the admins sat us down and gave us a crash course in UNIX, Perl, and vi.

    We now have had training in VAX/VMS, UNIX, and we primarily use Windows 2K. If you are looking into just getting some fundamentals, check the course listings at the local community college. Or buy a decent book.

  • Although this is probably the best way to go, it's going to be quite costly and time consuming. What's the price to take the RHCE courses and tests now? Multiply that by 16,000 and we're talking big bucks. Then again, if the company is buying that much equipment than they can obviously afford it (whether they will want to or not is another story).

  • Get them RHCE certified.
    That should teach them quit bit,
    thyen some minor training on other unices may be required.
    And teach them to always, always, read the read-me or man page
  • I say this because you mention "potential" users. If it was business, your users would probably be required to participate.

    Even if I'm wrong, I'd bet that those "potential" (read: infrequent, inexperienced) users are after a very short list of features. Most questions probably center around permissions, html related things, network disk space, and email (Pine?). One thing that can be useful is setting up "joe user" accounts in way that forces them to use a specific sub-directory for their web documents. Then set the default permissions so that "joe" doesn't have to change them.

    Also check out The HelpDesk Institute [helpdeskinst.com].

  • This seems like the most educated answer you have ever given. Spewing out garbage like that only show your low intelligence. Narrow-minded individuals like yourself should get what they really deserve. Cut your legs off right below your knees. Oh, almost forgot to cut your tongue out. Sit back and let the grown-ups talk, and only speak when spoken to.
  • If they are techs, they are probably somwhat curious and hackish. Give them unix accounts and teach the VERY basics... They will figure out a lot on their own if they know the basics and about things like Search on redhat.com.

    I am saying this because I remember that the people who got unix accounts at my college were always the first to jump in and try to fix unix issues. The college, by the way, did teach a basics unix class. One near you would probably have a nice course outline.
  • I believe the RHCE was for the helpdesk-staff, not the 16k employees... otherwise I think the problem stated/considred would/should disappear ;-)
  • There are many good suggestions. This sounds like a university and/or large company with that many different servers. You should survey all the systems to find out what applications are being used and on which platforms. You may even want to get some type of label maker and make labels for every screen with some id# that makes sense so when you do get a call, you can have them read the label so you'll know what platform you are dealing with. You might want to look into installing vnc on every platform. vnc comes in many flavors for many different os's and allows you to remote control a system. Make sure you watch your security settings. With vnc, you can use a windows vnc client to see the screen on a *nix box with a vnc server. A book of common problems and solutions is good. Maybe a couple *nix sysadmin type books for reference. There are a couple I've seen mentioned, though I dont'h ave the titles/authors handy. You might want to look into a basic stock of O'Reilly books on various things for a reference library. One thing you should try to emphasize is sharing problem and asking for help. Its better to pass the buck to someone mor knowledgable then proceed and make some mistakes. Sometimes the best answer is, "I don't know, let me try to find someone who does".
  • Actually, I guess I wasn't completely clear. Of course there should be overlap. If you teach each of the staff a certain number of things, and overlap their knowledge so that at least 2 of them know the same stuff. As time goes by, they can pick up on the stuff they haven't learned yet.

    You are right, though. Compartmentalizing would be bad in the case you described. I should have been more specific :)
  • I don't know diddly about your environment, so it's a bit hard to give specific advice. The smartass answer is to teach your techs everything you can about Unix, but that probably isn't practical.

    It's painful, but the only way to really identify where you need training is to log *all* your support calls/visits/escalations for a couple of weeks.

    By looking at your calls, you can see what kinds of questions the techs are getting, and you can identify the most critical training needs for the techs, and maybe even justify some user training.

    Repeat this process every 6 months or so. Logging everything is hell, but it does pay off.

    Maybe you've already got a tech support ticketing system in place, in which case maybe you should be trolling your ticket database instead of surfing /.
  • Like everyone else said, look at problem history, but they would probably find the following useful:

    • ifconfig
    • more and tail
    • ps auxwww|more (orps -auxwww|more or whatever that unix flavor uses)
    • ps auxwww|grep -i whatever
    • How to kill and restart the X server (like control-alt-backspace then startx -- -bpp 24 or whatever the X startup script is for that box. Though of course your boxes might not go to a terminal if X is killed, just an X logon)
    • top
    • chmod, chown, chgrp and a little bit about file permissioning (wouldn't let them do that as su though)

    I'd give them a rough overview of processes and pids, show them how to check network connectivity (with ifconfig, traceroute, etc), various configuration files in /etc, and maybe what messages to look for during bootup. And oh, reboot of course.
    --
  • In my early days in computer support, my manager kept a 'recipe book' of the things that commonly went wrong, and the fixes to them. Today this is known as the FAQ.

    We were encouraged to add to this collective journal anything that we thought would help other helpdesk people, and to use it to help solve problems. This covered all the operating systems in use and any gotchas about making them interact.

    As far as training goes, you need to know what problems you are trying to solve, then plan around those. The recipe book was a huge resource for the types of questions being asked and answered. We used the tools to raise our own questions, and try to solve the problems.

    If you are supporting (for example) staroffice, then have the helpdesk people actually use it in their own work producing real output. Give them some time to work out problems among themselves. Don't pressure them do be as productive using the new tools as they were with their old favourites. This will give them a chance to apply any knowledge they may have of general principles from other office suites, and also highlight any needs to bring in expertise for training.

    Another tool used by the same manager was to encourage game playing (and game writing) at suitable times on the systems that he wanted people to become familiar with. At different times, our team devised tetris for a dumb ascii terminal(!!) and an interactive game run in a spreadsheet(!!!) While all this was happening we were enjoying the pleasure of hacking while gaining useful (to the organisation) familiarity with systems that we otherwise may not have chosen.
  • Why not have each of your staff learn a particular area and learn it well, then have the users direct themselves to the "Expert" of the area in question. If by phone, a "Press 1 to speak to someone about x-windows video issues".

    All of this is even easier on a web form, because you can just have a pull-down menu of the type of question, and that choice dictates who gets the first shot at answering the question.

    Perhaps at that point, if the first person can't answer it, you can put it into a "pool" where the rest of the helpdesk staff can see it and try to respond. Generally, you would hope that this pool would only be used once in a while.

    Just off the top of my head, a few suggestions. The point being, since the scope of what you're trying to teach them is so large, it might be a good idea to get them to specialize. Jack of all trades, master of none rule might apply here.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close