this is less than $15.1 best practice mythology to resolve problems. We're gonna look at resolving problems in trouble shooting. In this lesson, we're gonna take a detail, step by step approach to resolving problems in trouble shooting. So let's go and get started on Jeff writing, and we have a lot of information to cover in this lesson.
A lot of times when you have a device that's not working, whether they be a system, hardware issue or network issue and unique need to make a change to that device, it's easy to take it off line if you're in a small network and make that change when you're in a larger production environments such as the customers, network or organization,
there is a different process to handle that you would not be able to take a device off line
to do patch management or updates and so forth. There is a formal process that you would have to follow in order to make that change, And that's where one of the policies in an organization's list of policies will be changed. Management.
There's a change control policy that you have to follow.
It's a formal process for making changes in this way, you're going to avoid downtime, confusion and mistakes. It follows their corporate policy and procedures.
So basically, what you're gonna have to do is all changes are gonna have to go through a formal process. There's gonna be a key person or committee that those processes orders changes we're gonna have to go through. So in this way, you can plan for that change that you need to make. You can estimate the risk involved. You could have a recovery plan if it doesn't work out
and you can test it before you make that change,
you document all this, then you get the steps approved before you take those steps. And a lot of times in in different environments that I've worked with as coming in as even though the vendor or the the I T consultant, we had to follow this change management process.
And it's really insurers
their stability as well as not interrupting their workflow as much as possible.
In one situation where there was a device that needed to be switched out because it was failing, we have to document the steps that we were going to take. We have a plan for that change. We have to have a backup plan and which we did get a backup plan for any event that that device or that change did not work.
Once it was proved, we were able to go ahead and get the green light to make that change.
So there's change, man. It is a process that you have to follow when you're making changes to devices, foreign users or your customer in a production environment.
So let's look at a detail troubleshooting step plan on. We're gonna break thes steps apart, but let's go through them first of all. So if there was an issue that was reported and we we've got that issue and we begin troubleshooting to exactly find out what may have happened, we identify the problem is the next step.
I want to be identified what the problem is. We want to establish a theory
whether they may be one theory, a couple theories, why we believe that that problem occurred.
Then we want to test that theory, test that theory before we go into production with that change, to see if that theory is, in fact correct. Did this theory work. Yes or no? If no, we won't establish another theory. We want to go back around this until we get that theory proven.
And if we did prove it,
Yes, the theory worked out. We know that what the problem is we got a theory in it. We tested out in it. It is the issue. Then we want to establish a plan of action. That action may be to document the process. Like I just mentioned, we may have to go to a change in management born and change control process
to dock and get that before them to get approval to make that change.
Once that approval has been given, we want to implement the plan implementing the plan. Maybe something is gonna happen off hours or after hours or certain peculiar time or whatever the case may be. Um, after we implement the pan, we want to verify foot fully that it's functional. Eso fully
verified that it's working.
Not just you tested, but the end user may tested. The customer may test it, and because they're right off once they are satisfied with that is going to give you the green light.
After that, do you want to document the findings, document everything that you've found, everything that you implement it and everything along the way. It's gonna help you for their future reference, and after that, that's when the issue is fully resolved. So let's look at these individually step by step.
OK, so first we want identify the problem. That's when your information gathering begins. Get as many details as possible. And if you can duplicate the issue that that helps out tremendously and again, you want to follow the corporate policy and procedures as you're doing this,
identify the symptoms. There could be multiple or related symptoms.
Sometimes when you have a system that has an issue, you may know exactly what the problem is, even though you have the knowledge and you may know what the problem is. Steel gather facts because you don't want to make an assumption, and it not be the case. So sometimes why did, as I took that,
that that idea what I had you may want to park it,
been test other things because as you gather more information, you can help deduce the fax as faras what the problem could be,
um, you want also want to estimate the risk of a change as you're doing this, what problems could occur.
You want to talk to your in users. They have a lot more involvement as faras what that issue is doing to them. They may not be able to understand it, what's going on or even describe it to you in your terms. But when you describe it from the way they see it, you may get a better idea of what's going on. So it's very key to listen to the end user.
Determine if anything changed. That's where you wanna go back to control management to see if there was a process
that may have happened before you got involved. Eso approach multiple problems individually. That's key right there. Don't ballpark. Don't assume. Approach him individually.
Establish your theory. Start with the obvious. Start with the easy items, which are the most obvious. If it was, you think it's a bad patch court. Try that. The most obvious thing is what you want to start with, and also you want to consider everything, even things that you may not consider. Consider everything be open here because you're gathering facts.
Make a list of possible causes and start with the easy items, things that's not gonna disrupt anything. Start with those items. First, research symptoms. Symptoms that you may not be familiar with. Get outside Helper. Resource is, I did this a lot and continue to this
if spit specifically, if its software hardware I may reach out to the vendor, the manufacturer, or the maker of that software and tell him what I'm seeing
and how it happened in nine environment. They may have insight on the back inside that you don't have so always reach out thio vendors. Um, other technicians can help you out as well. Knowledge bases and forms are great of resource for information
test your theory confirmed the theory. Determine the next steps in to resolve the problem. Now that theory didn't work. Re establish a new theory or escalated, seek outside assistance and repeat. That's the process. You're gonna work as your gathering and testing out these theories to find exactly what is the problem there.
Now, if the theory worked Great. Now what?
Make a plan to resolve that issue,
establish a plan of action, build a plan, resolve the issue with the least impact to the customer or the client off hours or after hours. There are many times when I had to come in before the organization started or after they left.
That's our time to go in and make those changes because it was less impactful to the business environment.
A nasty things there. You want to not impact your customers production time. That's one of the worst things that you can do. Went as a technician.
Identify potential heirs of problems, have a backup plan. Have a backup plan to that backup plan and have a backup team to the previous backup plans. You want to always make sure that you wouldn't recover to the point where before use, touched anything or started anything. So plan plan back up,
I can't stress it enough.
Okay? Implement the pan. You want to resolve the issue. You have clearance. You have to go ahead. Go ahead and resolve that issue. Everything's planned out. You are working at a time that does not impact production. And so carry on now escalated necessary call in the Calvary. I did this a lot again. If it was a hardware situation,
I called in the vendor,
especially if your equipment is under warranty. Ah, lot of times we would have the vendor meters there to resolve issues, or they would do their portion or their part. Sometimes it was troubleshooting over the phone again. Get outside assistance. The inn
desire or goal is you want that customer or that corporations
or that in users, device and systems to be working the back where they expected to.
Okay, verify functionality. The problem is not resolved until it's tested and verified. Make it a part of the plan. The customer need to confirm that it's resolved. They need to test it out and need to pass there. Okay, you need to get their seal of approval.
How do we prevent this again from happening again? That's where after everything is resolved, after all, the smoke is cleared and everything is resolved. How did this happen? How can we not prevent this from happening again on what steps can be implemented to prevent this process controls?
It could be a policy change. It could be one of anything.
That's where as your your trouble shooting and you're fixing these issues once it's resolved, you think back over the process. That what Kurth were occurred? What stopped? You want to be proactive here cause you don't want this to happen again or something related as the expert make informed recommendations How not for this to happen again?
Document the findings. This is another thing out. Stress document Document document.
Do not lose that valuable knowledge. Document the steps that got you here. The resource is that you put in what was found. What was the initial it on the initial issue. You want to document all of this? There's key reasons why you want to do this. Number one. You don't want it to happen again. Number two
two years from now, you may not remember all the details. They may be fuzzy to you.
And if it happens again, you don't want to be stuck trying to remember exactly what happened. Document Build a resource as you have these situations happen. I had a knowledge base that I built every time when we had a customer headed. Is situation or a problem? I documented the steps. What we found what with the issue was and how do we replaced it?
You want to document that and you want to either like idea howto the knowledge base,
our database or sorry, um, or even put it in your help desk ticket notes. Therefore, you can always go back to that information, or it may even help others out in your organization as you move forward.
Okay, so here's the steps. Again. Again, Issue was reported. We identified the problem. We established a theory. We tested that there, and if it didn't work, we tested and got another theory tested that then after we tested it and we found that it worked, we established a plan of action that may be getting outside
approval from a change controller Change Management board.
It may be getting, of course, approval from your customer to move forward. Whatever the resource you need to pull in or whatever the case may be, then implement the plan. When you again implement that plan, remember your customer. Put your customer first. You do not want to impact their business or their production time. Do it in the least impactful way.
Verify functionality just cause you fixed it and you feel confident is the fix. Let the customer try it out. They are the ones who would have to work with this or use it on a day to day basis. Let them give you the seal of approval.
Then again, Document, document, document, document. Your findings document. Everything have happened, which you did to resolve the issue. After that, the issue is resolved.
All right, so that was our lesson for today. I hope you learned a lot. And this will help you as faras in the on the world's a technician when you're dealing with customers and Delaware corporations and policies Or it could be your own business. These are the steps that Cantina has set forfeits forest,
this standard troubleshooting process.
this is it for this lesson, and we will see you in the next lesson.