Home

Pflogging

the never-ending quest for pragmatic solutions, useful plans, flawless execution, and designs that endure
Home Areas of interest Agents of change Core skill sets Diagnosing

User login

  • Create new account
  • Request new password

A number of key features are only available to registered users. They include:

  • Access to the full content of top-rated material (only teasers are available to anonymous users after the material has been posted for 45 days)
  • The ability to search site content
  • The ability to access reviews of books relevant to site material
  • The ability to access key quotes relevant to site material
  • The ability to access content from partner sites
  • The ability to rate material
  • The ability to post comments
  • The ability to post new information and propose it for publication
  • The ability to request email notification when selected content is added or updated

Troubleshooting 101

  • View
  • links
Submitted by Bryan Pflug on Sat, 10/13/2007 - 18:44
  • Diagnosing

Troubleshooting for a problem with a particular system is best when it can follow a previously defined checklist, flowchart, or procedure. Developing such organized approaches in advance allows sufficient thought about the steps to take and organizing the problem isolation activities into the most efficient steps. When such material does not exist, it's important to be organized.

Some of the challenges with troubleshooting are when problems are intermittent, or when multiple problems lead to the symptoms which are being observed. Possible steps include:

  1. Define the problem.
  2. Gather data/evidence.
  3. Identify issues that contributed to the problem.
  4. Find root causes.
  5. Develop solution recommendations.
  6. Implement the recommendations.
  7. Observe the recommended solutions to ensure effectiveness.

Ideas

  • Back out the most recent change
  • Keep a log of activities and circumstances under which symptoms are observed
  • Look for other occurrences of the situation in other environments, to rule out local configurations
  • only change one thing at a time
  1. Define symptoms
  2. Obtain a system block diagram
  3. Establish a list of possible causes for the symptoms (in medicine, this would be called a differential diagnosis)
  4. Develop a hypothesis

Efficient methodical troubleshooting starts with a clear understanding of the expected behavior of the system and the symptoms being observed. From there the troubleshooter forms hypotheses on potential causes, and devises (or perhaps references a standardized checklist) of tests to eliminate these prospective causes. Two common strategies used by troubleshooters are to check for frequently encountered or easily tested conditions first (for example, checking to ensure that a printer's light is on and that its cable is firmly seated at both ends), and to "bisect" the system (for example in a network printing system, checking to see if the job reached the server to determine whether a problem exists in the subsystems "towards" the user's end or "towards" the device).

This latter technique can be particular efficient in systems with long chains of serialized dependencies or interactions among its components. It's simply the application of a binary search across the range of dependences.

Simple and intermediate systems are characterized by lists or trees of dependencies among their components or subsystems. More complex systems contain cyclical dependencies or interactions (feedback loops). Such systems are less amenable to "bisection" troubleshooting techniques.

 

‹ The problems begin up My configuration ›
  • Login or register to post comments