Discussion: "The Server IS the Documentation" (OR Standard Process [Obnosis] verses Useless Arrogance [Experience/Training])

[Nathan England]

>From my experiences with server rebuilds after catastrophic failures, I absolutely have 
to agree. The server *is* the documentation. I have rebuilt servers using extensive 
documentation about how it was setup, with scripts and plans included in the 
documentation and why it was set up the way it was set up. I have also rebuild servers 
after massive failures using only data backups.

If I had to rebuild a server today, in a time crunch, and I had the choice of complete 
documentation of how and why vs a copy of the /etc folder.... I'd go /etc in a heart 
beat. I wouldn't even flinch.

Who is to say I am going to understand someone else's logic when reading their 
documentation. Who's to say the system wasn't built by a genius and then 
documented by a teenage kid still wet behind the ears having only built his first 'puter 
a week ago.

vs

A complete backup of /etc and /var from a machine that was running as intended 2 
hours before the SHTF.

I agree completely that this kind of attitude comes across as arrogance. But is it really 
arrogance if I really am just better than you? (lol - ducks)

When you build a machine for a client it is highly recommended that you well 
document the system. But at the end of the day, if the admin who must fix what is 
broken can't figure it out from looking at the code or reading the configuration files 
what makes you think endless reems of documentation is going to help? 

I know a few guys who could figure it out, but where some of us could rebuild the 
machine in a couple of hours given that /etc backup, the other guy might take days...

The server *is* the documentation.

Good post Lisa!

Nathan



On Thursday, May 16, 2013 09:03:57 PM Lisa Kachold wrote:


Across the board, the number 1 worst attribute that I see working with the PLUG, 
technology teams, and mentoring (at or around year 3 in academics, and year 3 - 10 in 
IT/linux professionalism) = arrogance.


What exactly is arrogance anyway.  Where is this found?  Why? 


It's the place in the discussion where one person dominates assuming that their 
position or knowledge is greater (without investigation).  This is also referred to as 
"OneUpManShip".
It's the place in the presentation where students and PLUG peers write off the person 
who has taken on the role to "present on the subject" based on their ability to verbally 
spiel acronyms.  This is referred to "Minimizing".
It's the place in the team dissemination of project roles and tasks where a member's 
enthusiasm is downplayed based on experience.  This is referred to "Dues Hierarchy". 
This is the place in the interview where the employer fails to realize all they need to 
do is very the work history, since everything for a Linux professional is motivated by 
and driven from an ethical systems administrator viewpoint (not any communications 
with or responsibilities disseminated from the employer); just as we are woken from 
sleep to work on or check systems; and jazzed beyond belief by a well engineered 
hardware server like IBM Blade (can you say Fiber channel switched backplane?)...


There are a great many examples where an ego based emotional assumption of or 
judgement is placed on our peers, our work, and even ourselves at one point or 
another.


The ability to understand linux systems requires a certain type of systemic theory; 
which can be daunting for some people; such systems integration can be hard to 
troubleshoot [and successfully negotiate within] without inherent abilities but can be 
done with a great deal of complex experience, however this is NOT ROCKET SCIENCE. 
So the people who do well at what we do, are usually those that find that they 
inherently find this easy.  


It is, however, far from easy, since most of us work long hours, without adequate 
physical exercise and balanced stress free environments. The sheer amount of 
responsibility and ultimate reliance in all shops on the unique abilities of the 
Unix/Linux systems administrator are daunting to most once they get a full view.


However, we each learn standard process applied across the OSI stack and/or fed 
through the kernel/memory/processor for systems or DevOps applications 
performance and integration, security or troubleshooting.


Standard process, which includes a few easy to learn rules, relies on logs and linux 
tools, completely supplants any experience, past systems history knowledge (available 
on/in the server), most visio documentation or RunBooks (which should not exist 
unless something cannot be known by server view alone).


Ironically, to people who are not linux-ish, the statement that "The Server IS the 
documentation" seems incredibly arrogant, when in fact, it simplifies all the arrogant 
posturing and 7 deadly sin based profit from the misunderstanding of unix/linux 
administration and engineering.


We all intimately understand the concept of "obnosis" or Knowledge by Observation  - 
rather than what is imparted via formal rote learning and scholastic pursuit.  


What do you think?  Is the adage "There is NO substitute for experience" correct or can 
anyone using standard process (as opposed to documented process)  and NIX 
command line skills (yet bringing no experience) get to the finish line at the same 
time?


http://wiki.obnosis.com [1]
-- 




(503) 754-4452 Android(623) 239-3392 Skype(623) 688-3392 Google Voice**

it-clowns.com[2]




--------
[1] http://wiki.obnosis.com
[2] http://it-clowns.com/c/index.php
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20130516/3589f7da/attachment.html>