[conspire] Risks of automation

[Nick Moffitt]

On 23Aug2018 10:43PM (-0700), Rick Moen wrote:
> 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.

I would probably include something along the lines of "itemise components of a system from inputs through to outputs" as another early step.  You don't need to build a complete model down to each tiny part, but a high-level flow diagram sketching at most a half-dozen nodes can help you isolate problem areas and test in isolation.  You can drill down inside those nodes to analyse problems further later.