An Introduction to Patterns
Many years ago I discovered the book “A Pattern Language” by Christopher
Alexander and his Berkeley architecture group. It documents a set of
patterns, modules, best practices, etc for producing human-friendly and
livable spaces, from the macro level Countryside patterns (City/Country
Fingers, for instance) to the micro level Detail patterns (Many Small
Panes in Windows).
Intuitively, it seems to me that an approach like this holds the key to
codifying system administration practices. The expectation of differing
levels of scope, plus the pick and choose aspect of the individual
patterns within scope levels, lends itself to documenting systems
administration across the different styles and levels of “best practice”
today. The “best practice” for a 500-user corporate site is something
of an overlapping Venn diagram with the “best practice” for a 3500-user
university site, so we need something that will capture that difference
and relegate neither set of practices to second-class.
A lot of work in patterns has been done in the areas of Object Oriented
Programming, as well as code reuse and the like. There are some
smalltalk related sites that have evolved into general discussions of
patterns– for instance, the Portland Pattern Repository at
http://c2.com/ppr/ or the Hillside Pattern Group at
http://www.hillside.net/patterns/.
Sysadmins may have an advantage in using Patterns, at least as originally
conceived by Christopher Alexander, because so much of what we do maps
into “architecture” very easily. On the other hand, patterns have
inherent contextual goals. In the case of Alexander’s patterns, it is
creating spaces that are livable and humane. What will be the focus of
sysadmin patterns? Maintainability? Scalability? Usability? (from
whose perspective, the admins or the users?)
As you can probably tell by now, I’m much more interested in patterns
than in taxonomy. To name and classify practices, however, is the first
step in evaluating them.
Patterns and Taxonomy
My question to the other participants in the list– do you view taxonomy
as a way of identifying all practices out there or of selecting a set
of “best practices” and classifying those?
If the latter, we need to make sure that good practices for small sites
don’t crowd out ones for large (or more likely, vice versa). There may
be value in identifying common practices that Just Don’t Scale or even
Just Don’t Work as well. We’d like to help folks who think they’ve
invented “The Wheel that Stays Where You Put It” realize that instead
they’ve invented “The Square Wheel”. Though in some applications,
square wheels that you can quickly round down are a virtue!
To somewhat rephrase this into more pointed questions, what do we view
as the scope of our work here together? Is our primary goal to expand
upon Geoffrey’s excellent collection of “boxes” or is it to put “things”
into those boxes? If we are putting things into the boxes, are they
only “good” things, or are they “most things we can think of, with
a value judgement/context pair”?
My belief is that if we establish a set of “boxes” and put them out
with minimal examples (deliberately minimal!) of “best practices”,
we can create a living document that will be updated by the
Usenix/SAGE/LOPSA community worldwide. We may need to establish some
guidelines or ground rules for “officially” putting updates into the
master copy of the taxonomy. I envision an interactive website and
mailing list that can be harvested by sysadmins at all experience levels
in order to more effectively do their work.
Collection of SysAdmin Patterns
If you are interested in being part of a mailing list discussing system
administration patterns, subscribe by sending mail to me (strata Who Is At virtual.net).
Relentless Inquiry 