In this lesson, we're going to discuss
how you can understand the troubleshooting process
by walking through an example of an issue
that you may experience as a network technician
or administrator.
We're going to take this step by step
and walk through all seven portions
of these steps in order in just a few minutes.
Now, the first step is to identify the problem.
So let's pretend you're working
at the help desk and a user reports
that they have intermittent network connectivity issues.
Now, as you start working with this person,
you're gathering information, you're questioning the user,
and you're trying to identify the symptoms.
When you ask the user questions,
they tell you that based on their observations,
it seems that the connection is dropping
and then resuming sporadically.
And they tell you that there's no rhyme or reason.
It's happening at all times of the day,
no matter what program they're using.
So we really don't know what's causing it yet,
but we're going to gather as much information as we can.
We'll ask them additional questions,
we'll identify those symptoms,
and we're going to ask things like, has anything changed,
and can we duplicate the problem?
Also, we're going to approach multiple problems individually,
even if we have multiple users calling up
and telling us they're all having the same issue.
It's important to note
that there are multiple people having this issue,
but we're going to treat each individual user
as their own ticket and their own problem
because each one may be caused by different issues.
This brings us to our second step.
We now need to establish a theory of probable cause.
So here we're going to think to ourself,
what could be causing this issue?
Why is this connection sporadically dropping and resuming?
Well, it could be a faulty router.
It could be that your bandwidth is overloaded.
It could be there's an IP conflict.
It could be the switchboard is failing on the router.
It could be a faulty cable.
There are lots and lots of different things,
but our goal here is to establish
a theory of probable cause.
And when we do this, we are going to question the obvious,
and we're going to consider different approaches
such as the top-to-bottom approach,
the bottom-up approach, or the divide and conquer approach.
Now, because we're having an issue
with intermediate network connectivity,
we might want to go ahead and do this from the bottom up.
And the bottom up would be starting with the physical layer.
So if this is a wireless connection,
we might want to see is there any wireless frequency issues
that are causing this connection to drop?
If it's a cabling issue, we may want to check the cable
and verify it's working correctly.
Now, at this point in step two,
we're not going to take the actual actions yet.
We're just coming up with the idea
of what we think the probable cause is,
and then we move into step three.
So let's move into step three,
and we're going to test the theory to determine the cause.
Here, we need to go ahead and test this theory
and see is this theory correct, and if it's confirmed,
then we would figure out what steps
we need to do to resolve the issue.
If it's not correct and we've ruled it out,
then we need to come up with a new theory,
and we'll start this process again by going back to step two
and then into step three again.
So in our case,
let's say that we believe it was an issue with the router,
so we're going to go ahead and test the router,
and we're going to check its logs and reboot it.
At this point, we've done that and we see if it works.
Nope, we're still getting sporadic issues
with the connectivity.
All right, in that case, we'll move back to step two,
establish a new theory of probable cause.
In this case, we're going to think it's overloaded bandwidth.
So we go into step three,
and we test our theory by monitoring bandwidth usage
to rule out if it's overloaded or not.
In this case, we look at our bandwidth and it looks normal.
It's all within our normal bands and tolerances.
So we go back to step two and we go ahead
and think of another probable cause.
Well, if it keeps dropping network connectivity
and then it resumes itself automatically,
maybe it's an IP conflict.
So I'm going to go into step three and test my theory,
and I'm going to go ahead and scan the network
to see if anybody else is using that IP address.
And if we're using DHCP,
I'm going to see if that DHCP address
is being handed out to multiple people.
At this point, let's say that was the issue.
So now that we know that's the issue,
we have to establish a plan of action.
And this brings us to step four.
In step four, we're going to establish a plan of action
to resolve the problem and identify potential effects.
Now, when we do this, we are going to go ahead
and figure out what is causing this IP conflict.
Maybe we're using static IP addresses
and somebody isn't doing proper IP management.
Or maybe it's a problem with the DHCP server.
In either case, we have to establish what our plan is,
and then we're going to go about fixing that plan in step five.
So for this case, let's go ahead
and say it was an issue with our DHCP server.
So we come up with a plan to go ahead
and troubleshoot that DHCP server to reconfigure it
and to change our scope addresses inside the DHCP server.
This now brings us to step five,
which is to implement the solution or escalate as necessary.
In this case,
if I have permission to do that change on the DHCP server,
I can implement that change.
But if I don't, I'm going to have to escalate that
to the change advisory board for their approval
for us to make a change to the DHCP server
and to the technicians who are responsible
for that DHCP server.
When we get into step six,
we need to verify full system functionality
and implement preventive measures if applicable.
So let's say that the DHCP server had a configuration issue,
we got permission to make the change,
we implemented that change.
Now, we want to see does this solve the problem?
And when we look at it, we figure out that, yes,
it does solve the problem.
We've verified full system functionality,
everybody's getting the proper IP addresses
and everyone is happy.
The only problem is we figured out the issue was,
somebody went in and made a configuration change
to the DHCP server without permission and without going
through the configuration management process.
Now, we have a preventative measure
that we need to implement.
And here we're going to work within the bounds
of our organizational structure to figure out
how do we implement preventative measures.
In this case,
it's probably going to involve talking with your manager,
and having your manager talk with the technician
who made the unauthorized change
to ensure that doesn't happen again in the future.
And then we go into our seventh step,
which is to document our findings, actions, outcomes,
and lessons learned throughout the process.
As we're going through and doing all these different steps,
we are going to be documenting this
inside of our trouble ticket system
so we know exactly what's going on.
And if you go home for the day
and this is still an issue,
somebody else can come in behind you
and start working on this issue too.
So as you're doing this,
we want to record the issue symptoms we gathered in step one.
We want to talk about the different theories we had.
We want to talk about what the diagnostic steps
and tests were in step three,
where we're testing our theory to determine the cause.
We want to talk about the solution that we came up with
and how it worked when we tried to implement it.
And then we want to talk about the outcome
and what changes we made,
and what we're now seeing as a result of those changes.
All of these are things that we want to document
inside our trouble ticket system
and in some cases in our lessons learned system too,
so we can then share these lessons with other people.
That's the idea of how you work
through this troubleshooting methodology methodically,
going from step one down to step seven
by identifying the problem,
establishing a theory of probable cause,
testing the theory to determine the cause,
establishing a plan of action to resolve the problem
and identify potential effects,
implement the solution or escalate as necessary,
verify full system functionality
and implement preventative measures if applicable.
And then finally document findings, actions, outcomes,
and lessons learned throughout the process.