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

Thu May 16 23:41:23 MST 2013

What kind of servers do you manage where knowing what is in /etc and /var
is sufficient?
Ho
w
 are you sure you aren't recreating problems from the original server on
the new one?

On Thu, May 16, 2013 at 11:36 PM, Nathan England <nathan at nmecs.com> wrote:

> **
>
>
> 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  <http://wiki.obnosis.com>
>
> --
>
>
> (503) 754-4452 Android
> (623) 239-3392 Skype
> (623) 688-3392 Google Voice
> **
> it-clowns.com <http://it-clowns.com/c/index.php>
> Chief Clown
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20130516/ab27c5ae/attachment.html>