Linux Diagnostics and Troubleshooting Series -
Thread 1 👇
Understanding what Troubleshooting is!
#Linux #diagnostics #troubleshooting #security
Thread 1 👇
Understanding what Troubleshooting is!
#Linux #diagnostics #troubleshooting #security
What is troubleshooting?
Troubleshooting is the art of taking a problem, gathering information about it, analyzing it, and finally solving it.
While some problems are inherently “harder” than others, the same basic approach can be taken for every problem.
Troubleshooting is the art of taking a problem, gathering information about it, analyzing it, and finally solving it.
While some problems are inherently “harder” than others, the same basic approach can be taken for every problem.
Not just fixing!
While fixing a problem is one of the major parts of troubleshooting, there are other parts that cannot be neglected: documenting the problem (and fix), and performing a root cause analysis (RCA).
While fixing a problem is one of the major parts of troubleshooting, there are other parts that cannot be neglected: documenting the problem (and fix), and performing a root cause analysis (RCA).
Documenting the problem (and the fix) can help in the future when another (or possibly the same) administrator is faced with the same, or a similar, problem.
Performing a root cause analysis can help in preventing similar problems in the future.
Performing a root cause analysis can help in preventing similar problems in the future.
Using the scientific method -
A good schema to follow wen troubleshooting is d scientific method:
1.Clearly define d issue-
Take a step & view d larger picture, den clearly define d actual problem. Most of d problems reported r symptoms of another problem, not d actual problem.
A good schema to follow wen troubleshooting is d scientific method:
1.Clearly define d issue-
Take a step & view d larger picture, den clearly define d actual problem. Most of d problems reported r symptoms of another problem, not d actual problem.
For eg, a user might call about a problem signing into a machine. While this is a problem for d user, the actual problem can be a forgotten passwd, an incorrectly configured machine, a nw issue, or something else entirely.
Further investigation is needed to determine d cause.
Further investigation is needed to determine d cause.
2. Collect information -
The next step is collecting as much (relevant) as possible. This information can come from a wide variety of sources: reading log files, information displayed on screen or in a GUI, follow-up questions for the original reporter, etc.
The next step is collecting as much (relevant) as possible. This information can come from a wide variety of sources: reading log files, information displayed on screen or in a GUI, follow-up questions for the original reporter, etc.
3. Form a hypothesis -
After looking at all gathered info, & d symptoms observed/reported, it is time to form a hypothesis abt the cause of d problem.
After looking at all gathered info, & d symptoms observed/reported, it is time to form a hypothesis abt the cause of d problem.
Sometimes this can be easy; for example, when a user has forgotten his password. Other times, it can be harder; for example, when a single service in a high-availability cluster fails to start on Mondays during months with an "e" in their name.
The key to remember during this step is that the hypothesis is just that, a hypothesis: a best guess as to what can be the cause of the issue. During the following steps, this hypothesis will be tested. If it turns out the hypothesis was wrong, a new one can be formed.
4. Test the hypothesis -
With an initial hypothesis formed, it can be tested for validity. How this testing happens depends on d problem & d hypothesis.
With an initial hypothesis formed, it can be tested for validity. How this testing happens depends on d problem & d hypothesis.
For example, when d hypothesis for a login problem states, “The nw connection between d workstation & d KDC is being interrupted by a firewall,” the testing will be different from a hypothesis for a spontaneously rebooting server including a faulty UPS.
5. Fixing the problem -
If a hypothesis was not found to be invalid, an attempt can be made to fix the problem. During this stage, it is vital to only change one variable at a time, documenting all changes made, and testing every change individually.
If a hypothesis was not found to be invalid, an attempt can be made to fix the problem. During this stage, it is vital to only change one variable at a time, documenting all changes made, and testing every change individually.
Keeping backups of any changed configuration files, and reverting to those backups if a change was found to be ineffective, is also crucial. Modifying multiple configurations at once typically only leads to further issues, not fixes.
6. Rinse & repeat -
If the proposed fixes did not actually resolve the issue, the process will need to be restarted from the top. This time, any new information discovered during this cycle can be added to the mix to form a new hypothesis.
If the proposed fixes did not actually resolve the issue, the process will need to be restarted from the top. This time, any new information discovered during this cycle can be added to the mix to form a new hypothesis.
Hope you like this thread. If yes Retweet it!
More to come.
Follow me for more such content.
More to come.
Follow me for more such content.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
