\section{Troubleshooting Levels}

\begin{frame}
   {Troubleshooting Levels}

   Three Levels of Troubleshooting:
   \begin{itemize}
      \item
      \textbf{Beginner:} Can be taught very quickly.
      \item
      \textbf{Experienced:} Comes after a few years of practice.
      \item
      \textbf{Wizard:} Some people think you have to be born
      this way, but that is nonsense; all skills can be learned.
   \end{itemize}

\end{frame}

\cprotect\note{


   Even the best administered \textbf{Linux} systems will
   develop problems.

   \textbf{Troubleshooting} can isolate whether the problems
   arise from software or hardware, as well as whether they
   are local to the system, or come from within the local
   network or the Internet.

   Troubleshooting properly requires judgment and
   experience, and while it will always be somewhat of an
   art form, following good methodical procedures can really
   help isolate the sources of problems in a reproducible
   fashion.

}
\section{Troubleshooting Techniques}
\begin{frame}
   {Basic Troubleshooting Techniques}

   \begin{itemize}
      \item
      Characterize the problem.
      \item
      Reproduce the problem.
      \item
      Always try the easy things first.
      \item
      Eliminate possible causes one at a time.
      \item
      Change only one thing at at time; if that does not
      fix the problem, change it back.
      \item
      Check the system logs (\filelink{/var/log/messages},
      \filelink{/var/log/secure}, etc.) for further
      information.
   \end{itemize}

\end{frame}

\cprotect\note{

   Sometimes the ruling philosophy and methodology requires
   following a very established procedure; making leaps based
   on intuition is discouraged.  The motivation for using a
   checklist and uniform procedure is to avoid reliance on a
   wizard, to ensure any system administrator will be able to
   eventually solve a problem if they adhere to well known
   procedures.  Otherwise, if the wizard leaves the
   organization, there is no one skilled enough to solve tough
   problems.

   If, on the other hand, you elect to respect your intuition
   and check hunches, you should make sure you can get sufficient
   data quickly enough to decide whether or not to continue or
   abandon an intuitive path, based on whether it looks like it
   will be productive.

   While ignoring intuition can sometimes make solving a
   problem take longer, the troubleshooter's previous track
   record is the critical benchmark for evaluating whether to
   invest resources this way.  In other words, useful intuition
   is not magic, it is distilled experience.

}



