In this lesson,
we're going to talk about step two
of the CompTIA troubleshooting methodology.
Now in step two, we want to establish
a theory of probable cause and question the obvious.
Also, if necessary, you're going to be conducting
external or internal research
based on the symptoms you're observing.
So when we talk about establishing
a theory of probable cause,
we are trying to guess what we think the problem is
based on all the symptoms we've observed up to this point.
If we've gotten good answers
from our initial questions from our end users,
this is going to help us determine the severity of the problem,
such as how many people are being affected,
and how bad is it, as well as a rough idea
of what we need to investigate
such as is this a hardware issue,
is it a software issue,
is it an operating system or an application issue,
or maybe it's a driver issue.
All these are things that we have to figure out,
and by doing all that initial questioning
back in identify the problem,
we should now have a lot of data to start building our case
and figure out what is our theory that we want to go with
as far as what we're going to try next to solve things.
Now, when we talk about establishing
a theory of probable cause,
we have to talk about what is probable cause.
Well, when we talk about probable cause,
we are talking about all of the different possible causes
that may have happened, but which one is most likely?
For example, it is possible that aliens came down
and scrambled up the bits and bytes on your computer,
but it's probably not very likely,
so I don't think that's my probable cause,
even though it might be a very unlikely possible cause.
So keep that in mind.
When you think about probable cause,
you really need to think to yourself
what is the most likely thing,
because there's probably three
or four things that it could be,
and you're going to want to select the most possible one first,
we're going to try that, figure it out,
and if it doesn't solve the problem,
then we can come back again later
and try number two, number three, number four,
until we identify exactly what was wrong.
Remember, the idea here is to do it in a systematic method
so that we're not overlooking any possible issues
while still doing things in the most efficient
and effective way possible.
For example, if I had a user
who was watching video on Netflix
and all of a sudden it stopped working,
well that can have a lot of different reasons.
It could be their TV is turned off,
maybe they didn't pay their electric bill,
it could be their internet service went out,
it could be that Netflix is down,
or it could be the fact that their wireless network
that's connecting between their TV that's watching Netflix
and their network to get to the internet
is no longer transmitting and that's causing a broken link.
This is the idea.
There are lots of problems,
and right now we need to pick one of them
that we think is the most likely
and that's the probable cause that we're going to go after.
Again here, I always want to remember to question the obvious.
If you're thinking about something like Netflix,
they are a really big company
that does a really good job of keeping their servers
up and running almost all of the time,
so it is probably less likely that Netflix is down
than there being an issue with your system
or your internet connection,
and so you might want to check those things first
before you start blaming Netflix and their servers.
Now, in addition to establishing your theory
and picking your probable cause,
we'll also be doing internal or external research
based on the symptoms we see.
For example, when I'm dealing with this Netflix example,
one of the easiest things I can do
to see if it's my problem or Netflix's problem,
is to go online to a site like Downdetector
and type in netflix.com.
That website tracks and reports on other users
who say that different websites are up or down.
And so if you think Netflix is down,
you can go check Downdetector
and see if other people are having the same issue.
This, again, is going to help us verify if our probable cause
is the real cause or if we need to figure out
a different probable cause.
In addition to that,
you're not going to know everything as a technician,
but you should at least be able to figure out
how to research and find answers.
For example, I've been doing this for over 20 years
and I can tell you I still don't know
everything there is to know about them.
That being said, I can solve
almost any problem you throw at me
because I know how to conduct research.
If somebody says there's this issue, or this symptom,
or this error code, I can look those things up
because Google and other search engines
are really your best friend here.
You're going to find a lot of the things
that you're going to do on a daily basis
can be answered by Google,
and usually it's going to be the first, second,
or third result in Google if you search properly.
So don't be afraid to do research
based on the symptoms you're observing.
Also, you want to look at that machine
and make a physical inspection of it
as you're trying to establish and test your theory.
For example, as you go over to the machine,
you're going to look at it and you're going to listen.
Do you hear the fan spinning?
Do you hear a clicking sound
or a grinding sound of the hard disc?
Do you smell something that's burning?
Any of these things are symptoms and clues
to tell you what is wrong with that system.
For example, if you smell a burning smell,
it could be that you've damaged your processor
or one of the components in your motherboard.
If you're hearing a clicking or a grinding sound
that tells you there's something wrong with your hard drive
if you're using a traditional
mechanical hard drive in that system.
If you hear that there's no fan spinning,
that could be a power issue
or it could be a broken fan issue.
All these are things you can figure out
by making that physical inspection.
Another thing to keep in mind is
sometimes when you go to fix the system,
the symptom that you originally had is no longer there,
and so you may want to try to reproduce the problem.
This happens a lot in large organizations
when you're working for their help desk or support system.
For example, in one organization I worked at,
it usually took them one to two days
to send a technician out to your desk
to repair your computer.
So if you had an issue today, such as a program crashing,
you're not just going to sit there for two days and not work.
Instead, you're probably going to reboot your machine,
you're going to try a workaround
and you'll start getting back to work where you can
while you're waiting for somebody
to come fix the issue you're having as the root cause.
During that time, you're doing other things
and there may be other symptoms that come up
that you could then tell the support technician about.
Now, on the other side of that equation,
if you're working as a support technician,
and you're coming in to fix somebody's problem
when they put in a ticket a day or two days ago,
they've already done other things to that system,
so you're going to want to try to recreate the problem
that they initially had
to see if you could see that error message again
or those other symptoms happen.
Some problems are going to be intermittent,
but most problems can be reproduced.
So if you can reproduce it,
that's going to be able to give you more information
and help you figure out
if you've got the right probable cause
that you're trying to solve.
Another thing to think about when doing your research
is that you can use research not just online,
but also in the system itself.
Each system has its own system documentation,
it has installation and event logs,
it has diagnostic tools for you to figure out
what is working and what is not working,
and all of those things are part of that internal research
to learn more about the system
and learn what the probable cause is
for that particular outage or problem.
Next, let's talk about a couple
of different approaches you can use
when you're trying to establish a theory.
Now, the first one we have is what's known as
a top to bottom approach.
Now, when you're using a top to bottom approach,
you're going to use the OSI model as your guide.
So we're going to start with layer seven
and work our way down to layer one.
So if I'm having problems accessing a website,
I'm going to check layer seven in the OSI model first,
which is the application layer,
to see if I can access that website using port 80 and HTTP
or port 443 using HTTPS.
Then if that works, I know everything's working fine,
and if it's not, I would move down to layer six
and then check out something else.
For instance, the encryption is a layer six function,
and so if you're using HTTPS,
maybe there's an issue with the encryption,
which is why the website isn't showing.
As you continue down from layer seven to six to five
to four to three to two to one,
you're trying from the highest levels
down to the lowest levels.
This brings us to our next approach,
which is what we call the bottom up approach.
In a bottom up approach, we do the exact opposite
and we start at layer one of the OSI model
and work our way upward until we get to layer seven.
So what this might look like is
I would first look at the cable connection
and verify that I have a valid layer one
network connection to the network.
This may involve something like a copper or fiber cable
going from my desktop computer to a wall jack.
If I can verify that is working,
I would then move to layer two
and I would then check if I can access other systems
locally on the local area network using their MAC address.
If that works, I'll go to layer three.
And layer three, I might ping the default gateway
or the router of my network
to see if I can get out of my subnet,
and then I can see if that works.
Then I can go to layer four,
which includes ICMP which is ping traffic.
And I might ping something like the Google DNS server
at 8.8.8.8 to see if that is responding to my queries.
And if it is, that tells me my internal network is working
and I have a valid connection
to the outside world over the internet
because I can reach Google's DNS server.
And we would keep doing this all the way up to layer seven
until we identify the problem.
Now, the last type of approach we have
is what we call divide and conquer.
Instead of going from layer seven to layer one
with a top down approach,
or layer one to layer seven using the bottom up approach,
I can actually pick somewhere right in the middle
and start there first.
For example, if somebody says the internet isn't working,
one of the first things I do is I'll open up a terminal
and I'll type in ping space 8.8.8.8,
and this will send four ping packets
by default on a window system
or unlimited ping packets on a macro Linux system
out to that IP address of 8.8.8.8,
and listen to the replies.
If that works, I know that layers one through four
are all valid and they are working,
and now I know I have a layer five, six, or seven problem.
If it doesn't work,
that tells me that I know right off the bat
that something is wrong between layers one and layers four,
and I can then troubleshoot there.
By doing this type of a divide and conquer method,
I'm kind of picking the center point
or the midpoint of the OSI model and testing it there first,
and that way I could say the problem exists above me
or below me based on the layer that I'm testing
for my divide and conquer technique.
And finally, if somebody else
has already worked on that system,
you want to talk to them and figure out what did they do.
If you're working in a small business
and you're the only technician,
then you're probably the only person fixing the machines.
But if you're working for a large organization,
there may be 20, 30, a couple of hundred other people
who are doing these tickets,
and if somebody else has been working on that system already
and they weren't able to fix it,
and they pass that off to you,
you now need to figure out what did they already do?
What have they already touched?
Or if this person says, you know,
I've had a lot of problems with this computer,
you're the third technician in four months
who's had to come out and fix it,
well, let's go talk to the other technicians as well
and figure out what did they do,
what did they think the problem was,
and what did they try to do to solve it
because you don't want to do the exact same thing
because it's probably not going to fix it
because it didn't fix it the last two or three times.
And you're just going to upset your customer
because they feel like you're wasting time
by doing the same thing the other person did
last week or last month.
So keep in mind when it comes to step number two,
your whole goal in step number two
is to establish a theory of probable cause,
and you always want to question the most obvious things first.
If you don't know the answer,
always feel free to look it up using external documentation
such as the internet,
or internal research such as the system itself,
diagnostic tools, and the systems logs.