A big part of information technology is solving problems.
And in this video, I'll take you through a step
by step process for troubleshooting.
In most organizations, troubleshooting a problem
involves a series of well-documented steps.
These steps are designed to give you a logical path
to follow that will give you a way to troubleshoot
the problem quickly and easily.
One of the reasons we have this formal troubleshooting
flowchart is because of change control.
Change control is a way that we could manage any changes that
might occur in our environment.
This is very commonly seen in organizations
that would like to minimize the amount of downtime ans mistakes
that might occur when a change takes place.
When you're at home, you can make changes
to your operating system or changes to your local network
without informing anyone else the change is taking place.
But outside of your home networks in your organization,
there's a formal process for making these changes.
This process starts with the planning process.
You need to decide what change might occur.
For example, you might need to plan
to perform a software update or an operating system
patch on a server.
Before making that change, you need
to determine what the risk is for that particular change.
If you make a change to a server,
and there is some type of problem,
will that server become unavailable?
And if that server is unavailable,
how does that affect the overall business?
Change management also means that there is a recovery plan,
so you can implement a change, and if that change does not
work, you have a way to revert back
to their original configuration.
It's common to have a duplicate server in a lab
that you can then perform the update
and then perform tests to make sure that the server is working
normally.
Now that you understand the impact
of this particular change, you perform
testing to make sure that it works,
you can document this information
and present your results the change control committee.
At that point, they'll approve or disapprove the change
and then decide where on the schedule
that particular change will occur.
And then on that date, you're able to make those changes.
As you can see, this change control process
is much more involved than making changes by yourself
on your home network, but it's designed
to make sure that all of the systems
and all of the applications are always available
and that everybody knows what changes might
be occurring at what time.
When you're working on solving some type of technical issue
with your network or your operating system,
you'll want to follow a troubleshooting process
to make sure you're able to solve this problem as quickly
and easily as possible.
We'll step through each section of this troubleshooting process
so that you can understand a best practice for being
able to solve these issues.
The first step in solving a problem
is understanding the problem from the beginning.
This is perhaps one of the most critical phases
of the troubleshooting process because if you aren't
able to identify the issue, you won't
be able to solve the problem.
To be able to identify this problem,
then we need to gather information.
We want to gather as many details as possible
about this particular issue.
You want to be able to duplicate this issue.
And one of the ways that we're going
to be able to duplicate it is to know exactly what
the problem is to begin with.
You want to be able to identify all
of the symptoms that are occurring
when this problem is happening.
You may find that multiple symptoms are occurring,
and that might be related to a single problem,
or there might be multiple problems that you're
troubleshooting simultaneously.
If you're working with a user that's having this problem,
make sure you ask them as many questions
as you can about the issue.
What type of problem is occurring?
Do you see the error messages on the screen?
What happens after the error message is displayed?
Trying to gather as much information as possible
so that you can understand exactly what the user is
seeing from their side.
This is where change control might
be able to help you because there's some problem that's
occurring today that wasn't occurring yesterday,
so it might be useful to know if any changes occurred
during that time frame.
If you're identifying multiple problems during this phase,
it might be useful to separate them
into separate pieces that way you're
able to evaluate each one individually.
The problem might be interrelated between all three,
or you may find there is a different root cause
for each individual problem.
It's during this problem identification
that you may want to perform some backups.
You will eventually be making changes to this environment.
So it may be a good idea to have a backup that you can restore
to if you run into problems.
You may also want to check other help desk tickets
or other change records in your organization
to see if things may have changed that the user may not
know about.
There may be changes to the infrastructure
or the underlying network that no one in that department
may know, but may be causing a significant problem
with this application.
You'll also want to make sure that you're gathering
as many log files as possible.
An operating system has extensive log files available,
and some applications will have their own log files
that you can use during the troubleshooting process.
Now that we've gathered information about the problem,
we need to establish a theory about why
the problem is occurring.
And with most things, the simplest explanation
is often the most likely.
So use Occam's razor to be able to make
a list of possible reasons that this problem is occurring.
Of course, sometimes the explanation for the problem
may be relatively complex.
So you need to think about all possible reasons that
might be causing this issue, even
reasons that may not be completely
obvious at first glance.
Make a list of all of the possible causes
for this problem.
Start with the most easiest issues
to resolve at the top, and then the more complex ones
near the bottom.
This means during the testing process,
you can start with the least difficult issues to test.
You may be able to resolve the problem very early on,
or you may find that the issue is more difficult to resolve.
So you may end up going further down the list
to issues that are more complex to be
able to troubleshoot and test.
And of course, you should use external sources
to be able to gather more information.
You can often find details in a third party knowledge base,
or use your Google skills to see if someone else may
have run across one of these more esoteric issues.
Now that we've made this list of theories,
we can perform the testing to see if these theories are
actually resolving the problem.
If your first theory is that it's a bad cable,
you can replace the cable, run your test
and see if the problem was resolved.
If that didn't work you can move to the next theory on your list
and then the next theory down.
At some point you may find that calling an expert
in this particular area might help you out,
whether it's an expert that's internal in your organization
or it's an expert that you can call in from a third party
to help resolve this particular issue.
You'll go through this process of testing a theory,
evaluating it, and then going back
to test the theory over and over until you find a resolution.
And if you do find a resolution, then you're
now able to begin the process of making a plan to resolve
the issue in production.
The goal of this plan should be to resolve the issue
with the minimum amount of impact.
We don't want to bring the system down
for any longer than possible, and we
want to make sure that the user has access
to all of their data.
This might mean that we have to resolve the problem when
the users are not in the building.
If that's the case, we may want to set our hours
during non-production times to be
able to implement this change.
As we're writing down this plan of action,
we may want to consider creating a plan B or even a plan C,
that way if we run into problems with plan A,
we can still resolve this issue by going
to the next plan on our list.
We've now taken our plan to the change control committee.
They've given us a frame that we can use to implement the plan.
And then we show up in the data center
and begin the implementation process.
If this plan is relatively complex,
we may need to call in additional resources.
So don't be afraid to call a third party,
either internal or external to your organization,
to come in to be able to help resolve this issue.
This might be very important, especially
if you have a very small time frame in order
to make this change.
You want to have as many resources
as available and as many people that can
help if you run into problems.
After performing the implementation,
you now need to perform testing to make sure
that the changes you put in are the ones that actually resolve
the problem.
This might be a test that you're able to do yourself,
or it may require bringing your users in
to perform the test that they can duplicate
on their workstations.
Now that the problem's been resolved,
it would be nice if the problem didn't occur again.
So you might want to evaluate the issue
and see if there are any preventative measures that you
can implement, so that this issue doesn't occur again.
If other people run into the same problem,
it would be nice if they had some documentation they could
reference so that they could follow
the same path you use to be able to resolve the issue.
That's why it's so important to document these issues each time
a problem is resolved.
You may have a knowledge base or a database of information
in your environment that you can use
to make sure that others have access to this valuable data.
For example, what was the error message
that people were receiving?
What action did you take?
And what was the outcome of the changes that you made?
You might be able to put this into a centralized knowledge
base.
There might be a wiki or some other type of database
that you can use to document all of this information.
Let's step through the troubleshooting
process one last time we've run into a problem.
So the first thing we're going to do
is gather as much information to identify
what the problem actually is.
This might be error messages, information from our users,
or log files.
Then we can establish a theory of what
we think the problem might be, and then we
can perform some tests to see if our theory is
going to resolve the problem.
If that theory doesn't fix the problem,
we can go to the next theory on our list,
perform the test for that theory until we find
one that resolves the issue.
Now that we think we have a fix we
can document the process for applying that fix
and our production environment.
Our change control team will give us the time and the date,
and we'll be able to implement that plan into production,
and then verify that the system is indeed
working with our fix in place.
With this fix in place, we can then
document everything that we learned during this process.
If this problem occurs again, we'll
have a database or a knowledge base of notes
that we can use to solve the problem
and make sure that everything is working properly.