The myth of a completely shared knowledge base across sysadmins

April 14, 2010

There is a quietly pervasive myth in multi-sysadmin groups that there can be an environment without specialists, where every sysadmin can do every job that the group does equally well. If you do much work of any complexity, this idea is not just false but crazy.

I call it crazy because of what it requires. In general, it invariably takes a significant amount of research, learning, and experimentation to become a (semi-)expert in a technical area such as Exim configuration, OpenBSD firewalls, ZFS, and so on. To say that everyone should be more or less equally good at these tasks is to say that everyone needs to invest all of that learning time for all of the technical areas that your group is involved in. Unless you are not involved in very many complex areas or you're not going very deep in them, this is a lot of time; learning even a single area can require an investment of weeks of time and effort.

If not all sysadmins invest this large amount of time, there will inevitably be specialists for each particular area. Everyone may understand Exim in general and can do straightforward stuff, but one or two people will be the only ones who've invested the time to read all of the Exim documentation and really understand how your complex configuration works, and so on.

(At the same time, it is absolutely useful for everyone to have as much knowledge as feasible of every area you work in. Speaking from personal experience, I think that non-siloed environments are better than siloed ones.)

It's tempting to think that you can pass on this knowledge rapidly by teaching your co-workers, but I don't think that this works; while you can give people an introduction, you can't expect to teach deep knowledge very fast. I can write somewhat superficial introductions to Exim all I want and wave my hands in front of a whiteboard, but for real, deep knowledge you have to read the Exim manual (and play around with configurations), just as I did. All I can do is save you from going down dead ends and maybe clarify any confusions that you wind up with. This will save some time, but I don't think it will save a lot of it.

(Exceptions to this mean that the particular area's documentation is bad, or perhaps that you are a really excellent teacher.)


Comments on this page:

By Random at 2010-04-15 11:25:30:

This, x100.

We were only rescued from this by my coworker staking out entirely and clearly separate ground and getting his job redefined. Until then, there was constant headscratching about why we didn't know all the same things (and it still happens to an extent.)

The primary issue to me is simple, and you touched on it: you can impart information (documentation, teaching, whatever), but you can't teach experience. And, lo and behold, to gain 20 years of experience with some particular thing takes, well, 20 years.

R

From 132.24.126.26 at 2010-05-17 13:07:57:

This is true of technical issues. What about non-technical issues?

There are many common/overlapping areas in system administration. This is why conferences like LISA draw such a diverse audience.

What are those techniques that we take between technicalities? I would argue that those techniques are what separate technicians from sysadmin.

josephkern/www.semafour.net

Written on 14 April 2010.
« The impact of single-disk slow writes on mirrors (and other RAID arrays)
The standard format Unix error messages »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Apr 14 01:47:31 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.