An article on effective troubleshooting
…This might sound harsh, but to take it any less literal would be a detriment to the effectiveness of a tech. Of course I mean this from a support perspective. In fact it is one such support issue that inspired me to write this Article.
One of our users called in indicating that his wife had been cleaning up the computer and now he couldn’t login. I immediately thought he forgot his password and reset it for him…this failed to fix the issue. I then realized that I had already broken a cardinal rule of troubleshooting methodology, I was skipping ahead in the troubleshooting process. I took a breath and told myself to stop overthinking things. What would be the first thing to check? Was the user logging in at the correct web portal…check! Was the user using the correct username…check…or maybe not? Yes the user was logging in with their name, but as it turned out this individual was logging in with ‘firstname lastname’ and not the correct format ‘firstname.lastname’.
My guess is that this user in particular had in the past been used to saving his username in a web form. As a result the correct username would have been populated properly each time he want to login. If his wife was indeed ‘cleaning up’ the computer she likely cleared his browser cache or ran a utility that did this. The result was that the username would have been wiped from the web form.
The lesson here was obvious…do not let end users influence your troubleshooting methodology. Always remember to start from the lowest common denominator, Remember the OSI Mode, its a great starting point:
I typically use “All People Seem To Need Data Processing” to remember the model. Applying the Model to our troubleshooting scenario we can safely make a few key assumptions. The user is obviously experiencing an issue between layers 5 and 7. The users computer is obviously on, and they have internet access as they have been able to successfully navigate to the web portal. As such we can skip layers 1 through 5. I would also then very quickly rule out layers 5 and 6, the user is being presented with a web interface which means the means the application is making a connection to the web server. This likely means we are operating somewhere between the presentation and application layers. 99% of the time if i am taking a phone call from a user and there is an issue it is caused either in the application layer, or the physical layer as these are the layers that users have the easiest access to manipulate.
Having narrowed the error down to the application layer it is your job as a technician to ask pointed yet courteous questions, within the confines of that layer. Begin by asking the user the exact steps that they take upon sitting at the computer / device, you may very quickly determine that the user is simply using the wrong program or following the wrong step to achieve there desired result. Ask when the issue started occurring, determine if anyone else might be having the same problem. Does the problem exist only on a certain device? These questions will help refine your troubleshooting sandbox so that you do not waste time on irrelevant logic.
Users often times believe they are a techy because they play games on their computer at home and do a lot of typing and searching on the internet. They have watched a lot of people use computers and they consider themselves to be ‘fluent’ in the language of technology so you may be inclined to trust them. Though there argument could have some merit there is a danger in blindly trusting the users deduction. Consider the hypothetical scenario below:
“A random individual has come across a murder. You being the resident forensic analyst are called in to investigate. The individual considers themselves to be fluent in the language of forensics as they are a huge fan of CSI: Miami and Horatio Caine is like there mentor…For whatever reason you listen to the individual intently and they lead you to believe that a boot print they found has to match the killers. As you are under pressure to solve the case you follow the lead giving the individual the benefit of the doubt. It turns out the boot print was the Gardner’s and they were nowhere around at the time of the murder. You find out the next day that the killer in fact left a fiber of hair containing DNA evidence that 100% links them to the crime.”
While the above may be a complete work of fiction and a stretch at that. The result is the same, had you as the forensics investigator not taken the individuals word for it, your training and forensic framework would have led you to the critical piece of information a lot sooner
The bottom line…If an end-user calls with a technical issue, do not use their often times untrained eye on the problem as the starting point of your troubleshooting. Use a framework like the OSI model along with some Sherlock style deductive reasoning to determine your starting point! You will find that this will make you a far better technical professional in the long term.