In this lesson, we're going to talk
about step one of the troubleshooting methodology,
which is Identify the Problem.
Now, the way CompTIA words this
is to first identify the problem,
and this includes gathering information from the user,
identifying user changes, and if applicable,
perform backups before making changes.
Also, they say that you should inquire
regarding environmental or infrastructure changes.
So let's dig into this a little bit more.
When we start out our troubleshooting process,
we first are trying to identify the problem.
What exactly is wrong?
What are the symptoms?
What is happening?
And what may have caused this thing to begin with?
That's the whole idea of identifying the problem.
If you're working as a technician
and a customer calls you up
and says, "There's a problem with my computer.
The internet's not working,"
you've got to now figure out what do they mean by that?
Because most likely it's not the internet
that isn't working.
The internet, after all, is a series of lots of servers,
routers, switches, fiber optic cabling,
and lots of things connected all over the world,
and that's probably not what your customer means.
Instead, your customer may mean they can't get to Facebook
or they can't upload a file into Google Drive.
That's what they mean
when they say the internet's not working.
So one of the first things you need to do
is really understand the issue
that is actually occurring,
and you do this by questioning that user.
You always want to ask them what happened?
What was the status before you had this problem,
and what is the status after you had this problem?
For example, if they say
they can't access a certain program, you should ask them,
"Has there been any changes to your system?
Did you get any new software updates?
Has that program been updated recently?"
All these are things that could affect the ability
of that user to access that program.
This is all part of identifying the problem.
So as you identify the problem,
the first thing I want you to do is really spend some time
gathering information from the user.
If you're working on the service desk or the help desk,
you're going to be the one
taking the phone calls from the users,
and it's your job to be able to ask them follow-up questions
that can get you the information you need.
Have them describe the circumstances around the issue
and all the symptoms that they're seeing.
A lot of times, something that may not seem related
will be related to the core problem,
and by identifying that particular symptom,
it will unlock the key for you
to figure out what the problem is and how to solve it.
So, when you're asking questions, ask them things like,
"Did you see any error messages that appear on the screen?
If so, can you read that error message to me now?
Or can you take a screenshot of it and send it over to me?
Or was there some kind of a noise you heard?"
For example, if your hard drive starts to fail,
it's actually going to start making clicking
and grinding noises.
So if the user says, "I heard this grinding sound,"
you should immediately be thinking, "Hmm,
that sounds like the hard drive might be failing,"
and this is one of those symptoms
that can help you identify the problem.
In addition to this, there may be sounds
coming out of the speakers, and that might be a clue to you.
Another thing you might want to ask is,
"Is anybody else in your area having the same problem?"
For example, I used to work in a really large organization.
We had tens of thousands of employees.
And if somebody called up and said,
"I can't access the internet on my system,"
I might ask them, "Can you ask your neighbor
who's sitting right next to you,
can they access the internet?
And if they can, and you can't,
that means it's your computer.
But if you both can't,
then it may be a larger network problem
either for your office, your floor,
or your entire building."
And by being able to figure out
who else is experiencing that same problem,
this can help you figure out what the scope of the problem
is going to be.
Another question you should ask is,
"How long has this been happening?"
For example, I had one issue where somebody called up
and they said, "We're having an issue
where our computer is rebooting every day
between 10 in the morning and 11 in the morning."
And I was like, "Hmm, that's kind of weird."
And I asked, "How long has this been occurring?"
They said, "Oh, it's been happening for about a week."
And so my follow up was,
"Did anything change in the last week?"
And they said, "Yes, our air conditioning
has been out in this office for about a week now."
Well, the actual problem wasn't the computer.
It was that that office was heating up during the day,
and by sometime between 10 and 11 in the morning,
that computer actually got hot enough
where it was actually shutting down to protect itself
because it wanted to make sure
it didn't hurt its interior components
as the temperature of the room was rising.
Now, I know that was kind of an unusual problem,
but the idea here is that if you could figure out
how long something has been happening,
you might be able to tie it in with some of the symptoms
and some of the other causes to figure out
why this problem is occurring in the first place.
Another great question to ask is,
"Has any changes recently been made to that system?"
This might be a configuration change, a hardware change,
a software change, a security patch, or things like that.
All of these things could be something
that is now causing this problem.
Remember, things don't generally just break on their own.
Something usually causes it, and that something is a change.
So we want to figure out what has changed
because that latest change is usually going to be the cause
of your problem.
So if something was previously working
and it stopped working, let's figure out what change,
because that user-initiated change or application change
or software change or environmental change
could all have caused this new problem to occur.
And then the final thing I'd like to ask is,
"Have you tried to do anything to solve the problem yet?"
The reason I ask this is to make sure
I'm not duplicating efforts that they've already done.
For example, one of the most common things I hear IT people
telling users to do is to shut down
and then turn the system back on.
It's kind of this old saying,
"Have you tried turning it off and turning it on again?"
Well, the reason they ask that
is because this can solve a lot of problems.
And so if I'm talking to you on the phone
and you tell me you've already done that,
that means we don't have to go through
that troubleshooting step,
and it'll save us both a little bit of time
and already know what you've tried to do
to fix this problem.
Another thing you want to do here in identifying the problem
is making sure you perform backups.
Before you do any kind of actions
in steps two through six of the troubleshooting methodology,
you want to make sure you have a good backup of that system.
And the reason for this
is that you may have to replace something
inside of that computer.
For example, if you heard that grinding sound,
you might need to replace the hard drive.
And if you do that, that's now going to be a blank hard drive
with a fresh operating system,
which means all of that user's documents,
spreadsheets, PowerPoints and photos are all going to be gone.
You want to make sure you have a good backup of those
before you move to the new system
and you try to implement a solution.
In addition to this, even if you're doing something minor,
like changing a configuration setting,
that could have second and third order effects
that could affect the data on the system,
and doing that backup here in step one is a great idea
to make sure you're covered
as you move through the rest
of the troubleshooting methodology.