Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!verber From: verber@pacific.mps.ohio-state.edu (Mark Verber) Newsgroups: comp.unix.admin Subject: Re: How many administrators needed per site? Message-ID: Date: 16 Jan 91 15:52:35 GMT References: <1991Jan15.230613.8451@rastro.uucp> Sender: news@pacific.mps.ohio-state.edu Distribution: na Organization: Ohio State University; Physics Department Lines: 152 In-reply-to: boyko@rastro.uucp's message of 15 Jan 91 23:06:13 GMT A while ago, I saw a posting calling for input about how many administrators any given site should have. I believe the poster was going to gather the info and publish the stats. I never caught the results. I didn't recall seeing the results either. Well, due to "budget cutbacks", I am in danger of losing my partner/fellow administrator. It seems they think I'm good enough to handle this site all by myself. I'm flattered, but mostly, I'm panicked. I don't think that this is a 1-person job. (I have ~50 Suns on site and ~15 PC's) So to justify my partner's existance, I need to know: What's the average administrator-to-machine ratio? How about the average administrator-to-USER ratio. Is it different from admin:machine? The administrator to machine ratio that is reasonable depends on what level of service is expected and what responsibilities the sysadm has. In addition to these two parameters, there are two other issues that will temper the equation: (1) Single sysadm sites are not very desirable (except financially) in most cases. Is that it is difficult for a single person to have the breadth of knowledge and experience to run a really first class operation, no matter how few machine you have. There will always be some area that a single person will be weak on. It also means that when the sysadm is on vacation, (or gets run over by a bus) the site is vulnerable. Carrying a sky-pager on vacation isn't my idea of fun, and no one can predict when a bus might strike. (2) The larger a site is, the less people that are needed because you can get a good economy of scale. I have seen at larger sites at a 1:100 sysadm-to-machines where things ran pretty well, although more people would have been nice. I am not sure that there are any hard and fast rules for ratios. The thought of administrating 60 Suns that are more or less alike, a server or three with mainly diskless or dataless clients that are clones of each other wouldn't scare me. That is a pretty manageable task. You would *need* need to be proactive rather than reactive to tasks, make use of existing tools or building some for yourself that permits your work to be multiplied, eg. running something like rdist,target,sup for automatic updates, setting up backups to run automatically (how did we ever live without exebytes), etc, etc. A lot would depend on the level of support your users expect. The best way to figure out how many people are needed, it to figure out what level of service your users expect and whether the environment helps or hurts the maintainces of software. Rarely are sysadms doing only UNIX sysadm tasks. Here is a list of things that I find myself doing in addition to the normal "sysadm" tasks like backups, account installs, OS maintaince, etc. (1) User Services How much hand holding is expected? Some sites have users than are pretty self-sufficient. Other sites have users than need their hands held for everything. Can yours take care of themselves, or do the need/want the admin to do the simplest tasks for them. For example, I have a friend whose users would demand him to do the most basic things for them. Things like moving their files from one directory to another. (Anything that wasn't running the text editor and reading mail was Unix, therefore a job for the adm). This sort of support requires something like a 1:2 ratio. Does the site want you to conduct workshops, prepare extensive local documentation? To what extent is the sysadmin expected to consult on technical issues? Just using Unix, or other realms. For example, lets say your site has heavy users of FrameMaker, TeX, Mathamatica, Common Lisp, C++, X11, PostScript, and Sybase. Is the sysadms suppose to be able to answer detailed questions on all those topics? One person can not be an expert on all these things. Something that many people don't appreciate is that if someone is to consult on a topic area, they need some time to play, experiment, and generally develop in that area. (2) Diversity of Arch/OS/Setup Of course, each type of machine (arch/OS) that a site has multiples the complexity of the support task, especially if your users expect all machines to behave identically. Each install program will have to be installed N times. OS upgrades will have to be done at least once by hand for each arch/OS, etc, etc. Workstations can be arranged in ways that make it easier, or harder to do distributed administration on. If you can configure all your workstations to use the identical configuration, and have identical tools, etc, it is easy to support a larger number of machines. If each your machines is configured differently: swap sizes different, some diskless, some dataless, some diskful, with different software installed, etc. you are going to have headaches. If you can have one 'prototypical' machine that you can clone from, installs, upgrades, etc can be done pretty easily/automatically. For example, lets say you run a dataless configuration with /, /var, and parts of /usr on a local disk, and everything else accessed via an automounter. Your could have a diskless partition on a server that would boot up, install SunOS on a disk, do your local customizations, and reboot as a newly configured workstation ready for action just by editing your ethers file and a configuration file. If you have to do each machine by hand, you will have to waste a lot of times every time you install a new machine or have to do an OS upgrade. (3) Software Support? How much PD/freeware software do people want installed, and what level of support are they expecting? Just compiling and installing software doesn't take much time, but often times (and rightly so) a sysadm is expected not only to compile and install new software, but to test the software before people get at it, to debug any problems, port it if necessary, and be a general expert. This takes time which varies with the quality and complexity of the software. Keeping a current version of kermit or perl isn't hard (I wish everyone did as nice a job as Larry has with perl), keeping ontop of g++ takes a quite a bit more time. (4) Custom Software? Most places not only expect the sysadms to keep the world running, but create tools for the user population when needed. This is understandable, especially in small site where the sysadm might be the decent programmer. If there is this expectation, time must be given for the development process. (5) Site Planning/Admin Overhead How much site planning is the sysadm expected to handle. Are you going to have to know about AC/heating loads and power? How much paperwork is there? (6) Hardware/Network Maintaince Who crawls through the ceiling to pull wires? How finds the flaky transceiver when the ethernet starts to go crazy? When a terminal or workstation dies do you just call your vendor and wait, or are more creative solutions required. Do you buy all of your peripherals ready to install, or do you save money by purchasing components and do the integration yourself? All of these things take time. (7) Leading Technology Is the sysadm suppose to anticipate new technology and advise the company as to where they might like to take there environment? Most places I have been, the syadm were expected to have a good feel for what was state of the art and what was looking promising. Not just products, but research. Keeping up with what is going isn't easy. trade rags can give you a picture of what is being sold, but they aren't particularly good at helping people to anticipate what might be in a year or three. Forward looking is often necessary given many sites have a 2-5 year planning and/or depreciation schedule. Cheers, Mark