[conspire] Risks of automation

[Ross Bernheim]

Rick,

There are two main situations. Totally dead equipment and equipment that has
some level of function. When troubleshooting the latter you need to exercise 
all modes of operation to make sure you get all the symptoms.

Ross

> On Aug 23, 2018, at 10:43 PM, Rick Moen <rick at linuxmafia.com> wrote:
> 
> Quoting Ross Bernheim (rossbernheim at gmail.com):
> 
>> Rick,
>> 
>> A point stressed many times in the 33S training I took in the Army was not
>> to rush the observation phase. Make sure you collect all the symptoms.
>> 
>> By not collecting all the symptoms under all operating modes you could
>> be led to believe there was a different problem than the real one.It
>> was surprising how many flunked out of the course for this reason.
> 
> Yes, very much this.  Good point, so thank you, and my thanks to the
> U.S. Army's Military Occupational Specialty trainers.
> 
> A fellow on the SF-LUG mailing list wanted to have their recent Tuesday
> meeting devoted to teaching troubleshooting.  'Course, the guy
> suggesting this would not be at the top of my list of people to organise
> that or anything else.  In this case, he wanted someone _else_ to 
> magically put that together at the last minute.  Not sure it happened,
> but more than likely not.
> 
> But teaching the principles of diagnosis seems a great idea, and I
> actually pointed the SF-LUG people to this thread as a modest example, 
> saying it typifies my personal favourite way to teach that subject,
> which is to dissect a situation where I screwed diagnosis up.  ;->
> 
>> Expertise helps in understanding how the piece of equipment or system 
>> operates helps insure that you don’t miss anything.
> 
> I would say that expertise makes that _easier_, quicker, more certain.
> 
> Just careful observation and logic -- if careful enough -- I would
> maintain will always get you there.
> 
> 
> Anyway, I've been spitballing (just in my head, until now never in
> writing) about principles of troubleshooting.  Off the top of my head, a
> few:
> 
> o  Observe all symptoms (as you said), and keep detailed records.
> o  Where possible, establish known-good and known-bad components.
> o  Where possible, use simple tools with reliable, known traits.
> o  Make sure you are extremely clear on what the problem _is_.
> o  Any candidate explanation must account for all the symptoms.
> o  Don't trust any candidate explanation you haven't tested.
> o  Distrust coincidence.
> o  Always remember that causes are only imputed, not an empirical reality.
> o  Be careful not to change more than one thing at a time.
> o  See if you can eliminate groups of possible causes, e.g., 
>  to test whether it's hardware or software.
> o  Lateral thinking often wins.
> 
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire