On Sat, Oct 18, 2008 at 11:23 PM, Edward Beckmann
<edward.beckmann@???> wrote:
> Other than that, has anyone paused to analyse how they go about
> fault-finding? For example, loads of decisions are made in a split-second
> by experienced people, but there may be an underlying sequence that we could
> discover / discuss / compare.
This is something I used to cover when I was helping teach technical
theatre courses, as you allude to the trouble shooting procedure is
the same whether you're debugging a AJAX driven web app, a non working
light or a car. As processes go, it's quire a simple one to
articulate, but a difficult one to follow, especially with a partial
understanding of what's
I'm not offering to do a talk, my weekends are booked up for a
significant distance in the future, but the procedure I follow is
something along the lines of:
IDENTIFY the components: think of everything as a system, try drawing
a mental flow chart of how it should work. This is often the most
difficult bit - I know little about cars, so don't know what
components fit in where. If it's very complex, then you'll need to
remove parts until it becomes simple enough to grasp.
ISOLATE each step to see where the problem is - this is where you
search the log files looking for where the app falls over, or poke
around with the multi-meter in a light. With hardware issues, this is
where you swap out components or leads to see what the common point of
failure is. (E.g. with a non booting computer, I'd plug a desk lamp
into the socket see if that's working, if so, it's not the socket.
Swap the kettle lead out next)
INSPECT: Now you need to work out how the component should work (back
to the flow chart) - what's coming in, what's going out and compare
that with what is actually happening (With code, this is where you'd
spot any logic errors, with hardware you'd, e.g. spot the lack of a
12V output)
IMPROVE: Swap that faulty kettle lead for a good one, fix that logic
error, add the correct configuration flag.
With experience, you can dive right in and inspect the common point of
failure - that's where the speed gains occur.
Example: Debugging a mail configuration issue I had recently, where a
client's hosted domain wasn't receiving any email.
- IDENTIFY:
Email address -> MX Record -> Server IP address -> Mail Server
Software -> Software's incoming rules -> .forward file -> end email
address -> end mail box.
- ISOLATE:
Check the email addresses they expect to use are the same as the
one you've set up
Is the primary MX Record pointing to the same IP as your server has?
Is the mail server listening?
Does the log file show a test message you send being accepted?
Does the .forward file contain the correct end address?
Can the end address receive email from the server?
- In this example the last step was the fatal one - the emails
weren't being forwarded to the end address.
- INSPECT:
The log files, Google and the MX records on the end address pointed
to several Yahoo help pages, that told me 1) btinternet addresses are
handled by Yahoo 2) Yahoo considered all emails to that particular
address spam, for reasons it wasn't willing to disclose.
- IMPROVE:
Yahoo provided a contact address for complaints and concerns -
however they ignored it, so I swapped that component out, using an
alternate end address for the client who now gets email again.
Sometimes with the inspect and improve sections I need to call in some
experts who have a greater level of details of the system than I do
(hence membership on this list) e.g. My understanding of cars is
aproximately: I turn the key in the car's ignition, lights come on,
the engine starts, all is well. If lights don't come on, I guess the
battery has a problem, but if the engine doesn't start that's when my
AA membership is used - they understand it to a greater level of
granularity than I do, so can tell me the coil is bust, or I've run
out of petrol, or something.
HTH,
David.
--
http://www.travellingkayak.com/
