my take ...
the amount of SAs required --- whatever platform you have --- is dependent on:
1. The amount of work that needs to be done on a daily or routine basis.
Desktop support would theoretically need more people to deal with but that may not apply if you have a technically astute user population that can handle most of the work themselves as long as root rights are not required. Contrast that to a user population who cannot even tell whether they are working on a PC or a Unix desktop --- as in a lot of financial services users --- and it is easy to see the difference.
On the server side, the basic build and function of the servers dictate the amount of people needed. When servers of the same OS are built to a certain basic standard and managed the same way as much as possible, the server-SA ratio could be much higher than a server farm that has multiple build standards per OS as management of the servers are more labor-intensive by default. With server function, I will tend to look for more people if the majority of the server population I support are normally labor-intensive (i.e., database servers, backup servers, development servers, etc.). Usually I would consider NIS+/LDAP/NIS servers not labor-intensive but that is dependent on the turnover rate of the user population --- the higher the turnover rate, the more labor-intensive they are. There is also the amount of physical work required (i.e., install servers, replace parts on aging servers, power-cycling servers, etc.). If your server population requires much physical work, a lower server-SA ratio will be better for all involved. A server population that is mostly newer and more stable hardware-wise generally will not affect the server-SA ratio.
2. The technical and people skills of the SA.
A highly skilled SA --- especially one who can script very well --- will be able to handle more servers by default thru automation than compared to someone with minimal to no scripting skills. SAs who script tend to get a lot more done on a lot more servers in a more consistent way than non-scripting SAs who will generally take more time to type in a series of commands on each server they need to work on. Because of the tediousness of repeating a command series over and over on different servers, non-scripting SAs are also more likely to miss a step that they may not catch for a while. There is the risk that a scripting SA will kill more servers with one stroke than a non-scripting SA --- I've done this myself
--- but the benefits of having a scripting SA far outweigh the risks. It is much easier to get an SA to be careful than it is to get a lesser skilled SA to get done quicker. When troubleshooting an issue, highly skilled SAs are more able to extrapolate knowledge gained from past situations to deal with a totally new problem than lesser skilled SAs who do not have the practical know-how. Much like reading how to build a server, it will not tell you how much partition sizing counts until you actually build one and your server runs out of space on the / filesystem. For people who have never built servers, running into a space issue on a filesystem usually gets them into panic mode. However, people who have built servers are more likely to instinctively think about the cause as well as options --- i.e., remove large logfiles, symlink directories from bigger filesystems, etc. --- which means they can then fix the problem quicker and more efficiently and most likely longer term. A longer term fix then translates to less work on the issue.
As for people skills, the SA who cannot communicate in non-technical terms and who have problems interfacing with the user community will tend to not deal with them. This is okay if your user contact is very minimal to non-existent (i.e., your group is in charge of a server farm with no user interaction at all) but it is a big problem if you have high user contact. This then translates to somebody else needing to be the "middleman" between this SA and the user community which means that a simple request now requires 2 people to get done like a bad lightbulb joke. While it does not directly affect the server-SA ratio per se, most sane SAs I think will not want to be the middleman as they themselves are quiet busy. Unfortunately --- or fortunately depending on your employment status --- more than a few managers will tend to hire more SAs to compensate for a "non-social" SA who is highly skilled.
3. Server builds, redundant setups, monitoring tools and others.
A server population with a high number of high priority 24x7 servers without redundant systems will make me want to have more bodies just in case I get situations where I need to get servers up in a hurry. Since routine/daily work will always be there, anything that requires recovering a server is extra work and will take a body off from the routine work. This then translates to "normal" work piling up and then piling up some more as the server recovery process gets prolonged. For a 24x7 production environment that do not have good monitoring tools --- which is an oxymoron BTW --- I will tend to want more bodies monitoring everything. This will allow me to be more proactive instead of waiting to react to problems. Preventing fires is always much easier than trying to put them out.
Bottom line? Look at your computing environment --- server/desktop builds and functions, user population, risk tolerance and other factors --- and then decide what you can live with. Staffing formulas that do not take into account the computing environment will not only be costly to the company but will also affect SAs directly.
For your site, 3 will be good even though 1 may be able to easily handle it with a little help from good monitoring tools and from the non-Unix SAs. If you can't get 3, push for at least 2 and cite the redundancy factor as one of the main reasons for the 2nd body. And you might want to point out the difference between *nix and Windows so your president understands why the Windows SAs cannot really be the backup to your current Unix SA.
Good luck!
12-23-2005
