Dan,
I used the Nemeth book when I didn’t know how to do the odd thing or finding a tool,
but the book was predicated on a very specific Academic environment.
You can see why she’d suggest making tools reliable, robust and ‘complete’ (done
‘properly’)
in their environment with a large, constantly changing workforce, kids all too prone to
‘exploring’ things
or breaking something and then not knowing what to do…
From 1995, I spent around a decade doing contract SysAdmin.
The well run, well staffed and “no drama” sites never needed me :)
I got “parachuted behind enemy lines”, having to fight my way out,
so many times that I discovered I had a process for “Digging myself Out”
<https://stevej-on-it.blogspot.com/2007/06/digging-out-turning-around-challenged.html>
The key is to gain time by automating tasks, starting with what gains the most time for
you,
not business or managerial priorities.
There’s at least three levels of script / tool,
I thought were all covered in that Bill Plauger PDF recently but aren’t:
<https://indico.cern.ch/event/318305/attachments/612388/842557/PJPlauger-ITSeminar-Fifty_years.pdf>
1. Stuff for yourself.
2. A "Program Product" for a small, competent group.
3. A hardened product / Application that the unwashed masses will use and test to
destruction.
As a lone Sys Admin it’s incumbent on you to leverage the Automation under your control,
not drown in entropy.
If you do Admin in seriously large sites, eg AWS or GOOG, practices have to be adapted to
avoid outages - any outage will have massive impact.
At Internet Scale, the only methodology that can work is:
"systems are cattle not pets”- create tools that easily scale to the entire fleet
& are particularly robust & reliable.
Admins can’t be allowed to ever type at a production console - much more controlled than
the old Boulder Uni environment.
HTH
sj
On 1 Mar 2023, at 13:34, Dan Cross
<crossd(a)gmail.com> wrote:
Nemeth, E., Synder, G., & Seebass, S. (1989).
UNIX System Administration Handbook (5th edition is another fatty)
This book gave me some terrible advice when I was very young and impressionable.
In there somewhere it says something about not doing something unless
you're prepared to do it right lest one spend more time working around
a work-around than one would have spent just doing it well in the
first place.
The conclusion is, of course, true, but the admonition ignores all
sorts of externalities, like waiting users. And in some cases it could
really lead to paralysis ("omg _everything_ is broken and I can't do X
until I do Y, but to do Y I have to do this other thing and if I
really want to do it right I need to start by traveling to Nepal and
shaving this Yak, but I need to get my passport renewed and damn I
really oughta lose 20 pounds before I get my passport photo taken for
the next ten years, so I guess I oughta join a gym...but I can't even
find one because the network is down and I can't get to Google, but
how can I fix the network if I have not shaved the Nepalese yak?!").
Talk about letting the perfect be the enemy of the good.
Hopefully nowadays we have a better appreciation of the power of
incrementalism; those grand plans for the perfect system rarely come
to fruition. It's better to be flexible and make small, impactful
changes along the way towards a better system, always being mindful of
and tamping down encroaching entropy.
- Dan C.
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au
http://members.tip.net.au/~sjenkin