The Beacon Pattern:
- This is a “Get out of the business” pattern
- Identify an oft-occurring and annoying task
- Automate and document it to the point of being able to hand it off to someone far less technical
Example:
- System admins were being put in charge of scheduling rooms in the building
- They wrote a PHP web application to help them automate the task
- They refined the app, documented how to use it, and handed it off to a secretary
- They have to maintain the app, but it’s far less work.
The Community Pattern:
- Prior to launch of a new service, create user documentation for it.
- Point a few early adopters at the documentation and see if they can use the service with minimal support
- Use feedback to improve documentation, and the service
- Upon launch, create a mailing list, forum, IRC channel, or Jabber chat room and ask early adopters to help test it out.
- Upon launch, your early adopters are the community, and they’ll tell new users to use the tools you’ve provided instead of calling you.
Example:
- A beowulf cluster for an academic department
- Documented like crazy, early adopters were given early access to the cluster (demand was high)
- Crated a mailing list, early adopters were added to it with their consent, functionality was tested with them.
- Email announcing launch mentioned the early adopters in a ‘thank you’ secion, and linked them to their mailing list.
The DRY pattern
DRY = Don’t repeat yourself
Identify duplicate code in your automation scripts
Put subroutines that exist in an include file, and include them in your scripts.
Example:
- “sysadmin library”
- /var/lib/adm/.*pl
- Elapsed time and # of lines to script a task for which the library was useful plunged dramatically
– new tasks were thought up that were not considered before but were obvious now (ie, users that want to change their username)
– migrating to new services became much easier
The Chameleon Pattern
- Identify commonalities among your services
- Leverage those to create “Chameleon” servers that can be re-purposed on the fly
- Abstract as much of this away from the physical hardware
- Doesn’t need to involve virtualization, though it’s awfully handy if you can do it that way.
[this one is a bit harder to do with MySQL config files]
Example:
[puppet/cfengine were mentioned...]
ldapconfig.py – more than a script: a methodology
- But isn’t installing packages you don’t need bad? Depends on the package….ie, gcc is bad for enterprise
“Junior annoynances”
Terminal issues
Junior:
open terminal, login to machine1
think issue is with machine2, talks to machine1.
log out of machine1
log into machine2
Senior:
opens 2 terminals each of machine1 and machine2 to start
Junior:
networking issue ticket arrives
logs into server
runs tcpdump
Senior:
networking issue ticket arrives
logs into server
looks at logs
“Fix” vs. “Solution” ie “taking orders”
Junior will try fix a problem, senior will try to figure out what the problem is. ie, “I need a samba directory mounted under an NFS mount” a junior admin will try to do exactly that, a senior admin will ask “what are you trying to do with that?” because maybe all they need is a symlink.
Fanboyism
Signs you might be a fanboy:
- Disparaging users of latest stable release of $THING for not using the nightly (unstable) build which fixes more issues
- Creating false/invalid comparisons based on popular opinion instead of experience/facts
- Going against internal standards, breaking environmental consistency, to use $THING instead of $STANDARD (but this is also how disruptive technology works)
- Being in complete denial that most technology at some point or another stinks.
- Evaluating solutions based on “I like” instead of “we need” and “this does”.
Post new comment