Section 21: Troubleshooting Methodology

Steps of Troubleshooting Methodology (7)

1. Identify the problem

2. Establish a theory of probable cause

3. Test the theory

4. Establish a plan of action

5. Implement the solution

6. Verify system functionality

7. Troubleshooting documentation

Identify the Problem

• First step in troubleshooting methodology

• Gather info from user

• Identify user changes and perform backups if applicable

• Inquire about environmental or infrastructure changes

Identify the Problem: Techniques

• Ask user to describe the issue, symptoms, and changes

• Ask about error messages, noises, or other symptoms

• Inquire if others have this same problem

• Determine how long the issue has been happening

• Ask about recent changes to the system

• Check if the user has tried any troubleshooting steps

Importance of Backups

• Perform backups before proceeding with steps 2-6

• Backups ensure data safety, especially when replacing hardware or making config changes

• Helps to restore data in case of unintended consequences during troubleshooting

Establish a Theory of Probable Cause

• Second step in troubleshooting methodology

• Requires questioning the obvious and conducting internal or external research based on observed symptoms

• Goal

  • To guess the problem based on symptoms, severity, and initial questioning of end users

• Consider if the issue is hardware, software, operating system, application, or driver-related

• Probable Cause

  • Most likely cause for the problem

  • Select the most likely cause first

    • If it does not solve the problem, try other possibilities systematically

Research and Inspection

• External research

  • Utilize online resources like Google and Downdetector

• Internal research

  • Use system documentation, logs, and diagnostic tools for research

• Physically inspect the machine for clues like fan noise, hard drive sounds, or burning smells

• Reproduce the problem if necessary, especially in large organizations where there may be a delay in technician response

Troubleshooting Approaches (3)

• Top-to-bottom

• Bottom-up

• Divide and conquer

Top-to-bottom approach

• Start from layer 7 (application layer) of the OSI model and work down to layer 1 (physical layer), checking each layer for issues

Bottom-to-top approach

• Start from layer 1 (physical layer) and work up to layer 7 (application layer) , checking each layer for issues

Divide and conquer approach

• Start from a midpoint in the OSI model and test for issues, then determine if the problem lies above or below that point

Collaboration and Knowledge Sharing

• Communicate with other technicians or colleagues who may have worked on the same issue to avoid duplication of efforts

• Learn from others’ experiences and document what has been tried already to avoid repeating steps

Test the Theory

• Third step of troubleshooting methodology

• Purpose

  • Determine the cause of the problem

• CompTIA’s Definition

  • Test the theory to determine the cause

    • Once confirmed, determine the next steps to fix the problem

    • If not confirmed, establish a new theory or escalate

Focus of Step 3

• Testing the theory without making any config changes to the system

  • Example

    • Testing a theory that a computer won’t turn on because it’s unplugged from the wall outlet

    • Solution

      • Confirm the theory by plugging in the computer and turning it on

• If the Theory is Not Confirmed

  • Establish a new theory based on observed symptoms

    • Example

      • The computer still doesn’t turn on after being plugged in, consider that the wall outlet may not provide enough power

      • Testing the New Theory

        • Use tools like a volt meter to test the theory (e.g., measuring voltage in the wall outlet)

• If the Theory is Confirmed

  • Determine the next steps to resolve the problem (e.g., fixing or replacing the power supply)

Possible Outcomes of Step 3

• Theory Confirmed

  • Proceed to fix the issue

• Theory Not Confirmed

  • Come up with a new theory

  • Test the new theory

  • If confirmed, proceed to fix the problem

• Lack of Skills and Authority

  • Escalate if the problem requires skills or authority

  • Example

    • If a fix requires a part replacement or policy change outside expertise, escalate to the relevant team

• Inability to Solve

  • Escalate to higher-tier support (e.g., Tier 2 or Tier 3 technicians) for additional assistance

  • Tiered Support Structure

    • Tier 1 - Basic problem solving

    • Tier 2 - More advanced problem-solving

    • Tier 3 - Subject matter experts (SMEs) and system administrators

Establish a Plan of Action

• Fourth step of troubleshooting methodology

• Purpose

  • Solve the underlying probable cause identified in steps 2 and 3

• Options

  • Repair

  • Replace

  • Create a workaround

• Considerations

  • Repair cost versus replacement costs

  • Organizational guidelines on repair versus replace

  • Temporary solutions for critical issues

  • Cost-effective solutions for temporary needs

Implement the Solution

• Fifth step of troubleshooting methodology

• Devise a plan detailing resources, time, and cost associated with the solution

• Identify impacts on other users or systems

• Seek permission according to corporate policies and procedures

• Examples

  • Rebooting servers

  • Updating systems

  • Replacing hardware

• Stick to the plan and seek reauthorization for any changes

• Impact of solutions

  • Consider the scale of the system affected (e.g., end-user machine versus server)

  • Rebooting servers can impact authentication and access across the organization

  • Disconnecting users from a file server may not affect other services like printing

Verify System Functionality

• Sixth step of troubleshooting methodology

• Purpose

  • Ensure the resolution implemented in previous steps effectively addresses the root cause and prevents future issues

Verification Process

• Confirm resolution addresses original problem

• Check replaced components for proper operation (e.g., power supply, RAM)

• Ensure system functions normally post-resolution

• Inspect for any additional damage or disconnected components

• Verify disabled/uninstalled software remains inactive

• Review logs and diagnostic tools for abnormalities

• Update software and device drivers for security and functionality

Implementing Preventative Measures

• Educate users on secure practices (e.g., safe downloading habits)

• Enforce policies (e.g., restricting downloads, no food/drink near equipment)

• Address recurring issues by proposing policy changes to management

Role of Technician

• Ensure system functions as well as or better than before the issue

• Prevent future issues through education or policies

• Collaborate with management to implement effective preventative measures

Troubleshooting Documentation

• Seventh step of troubleshooting methodology

• Documenting findings, actions, and outcomes

  • What was wrong

  • What was done about it

  • How to prevent it in the future

Troubleshooting Documentation: Methods (3)

• Trouble Ticketing System

• Internal Knowledge Base

• Frequently Asked Questions

Trouble Ticketing System

• Document problems, assignments, actions taken, and solutions

Internal Knowledge Base

• Store troubleshooting steps and lessons learned

Frequently Asked Questions (FAQs)

• Contains support articles based on common user questions

Troubleshooting Documentation Benefits

• Helps new technicians learn from past experiences

• Facilitates trend analysis to identify common issues

• Justifies resource needs based on workload

Troubleshooting Documentation Tools

• Any system can be used as long as it allows for documentation of findings, actions, and outcomes

• Examples

  • Freshdesk

  • Jira

  • Help scout

  • Intercom

Troubleshooting Documentation Usage

• Document findings as soon as problems are identified

• Update documentation as troubleshooting progresses

• For larger problems, update documentation regularly

Trend Analysis Example

• Password Reset Trend

  • Identified through ticket analysis

  • Led to implementing self-service password reset option

  • Resulted in a 90% reduction in password-related tickets

Resource Justification Example

• Increased ticket volume due to new systems without user training

• Used ticket data to justify need for more help desk staff

• Highlights the importance of adequate resources for efficient support