I had a perfect example yesterday.  I'm about to drive to the airport and the car won't move (I'm a modern tomboy, I can write stories about hair and stories about cars). Not at all.  It's stuck.  I can't reverse out of my parking space.

The first thing that occurs to me is something is stuck under the car.  Like a cat.  Those buggers hide in the stupidest of places.  So I get out and check there's nothing wedged against the wheels, which seems like the most logical thing that would stop the car moving.

(OK that's not true.  The first thing that occurs to me is oh-my-god-I'm-going-to-miss-my-plane-and-I-haven't-got-a-backup-plan-to-get-to-the-airport-and-I've-already-paid-for-parking-and-I-would-like-to-cry-now-but-that's-not-going-to-help)

Since there's nothing under the car, the next thing that occurs to me is the handbrake is stuck on - it feels like it's the rear left wheel that won't move, and I know (probably as I had a similar problem on my previous car, my lovely but ancient MX5, or maybe because I've seen far too much Top Gear) that the handbrake applies to the rear wheels.

• A basic understanding of how the hardware works can prevent you calling an expensive expert to do a simple fix.
• Always have a backup plan (Disaster Recovery/High Availability - if not hardware, then at least some sort of process).  I was much more stressed because without the car, I had to come up with a whole new transportation plan with a very limited time budget and having no knowledge of or experience with alternatives.
• I need to drive my car more, because then a) I would have either discovered the problem sooner, or b) it would never have got to that point.  I'm going to say that in this tenuous analogy, the equivalent is to do testing in a live-like environment, and actually do DR scenario testing.  Then you know how your hardware and software behaves under abnormal circumstances, and have some concept of how to get back to normal.