next we have documenting our findings, actions and outcomes and doing our documentation. Even those are last step
documentation is what we're doing throughout our entire process. If we wait until the very end to do all our documentation, then who's to say we don't forget a couple steps that we did or forget an exact input or an exact line that we entered in? So we need to be doing documentation throughout our entire process.
So we should be documenting from the start. And we want to document everything, not just the problem in the solution. We need to document symptoms, causes all of our troubleshooting steps any other issues we discovered and our resolution.
So we're documenting our symptoms documenting what the user came to us with. And they said, Oh, this is this is the issue that I'm having and we document all their different symptoms. We document what we thought that the issue was and what the background for the problem was and the different causes that we tried and even the ones that failed. So
our documentation is a very important fact and are very important component of troubleshooting,
and our documentation is something that we want to do very well. So when we're doing documentation, we're not just doing documentation for ourselves. We're doing documentation for someone else who may encounter later. Say, if we have a ticketing system and a database that someone can refer to, then they may experience to issue two years later and need to pull our documentation.
So because of that, we want to avoid skipping steps. We want to avoid putting in slaying or acronyms that may not be understood by other people. So we want to make sure that our documentation is very clear. And it's very pointed and very step by step, Very detailed.
Now, even if we escalate our documentation, even if we escalate our problem, we may want to keep track of that documentation you know about you may know about police departments that have their cold case file. Well, if you work on a help desk, you may D'oh. Something that I enjoy doing, which is keeping your own cold case file. You say OK,
I worked on this issue. I tried troubleshooting it. I tried my best.
You know, I got really involved with this and I did a lot of research but I still couldn't figure it out. So I had to escalate issue. So I'm gonna just take that ticket number. I'm gonna take that identification number. And I'll just, you know, if if my standard operating procedure allows this,
I'm gonna take that identification number. And I'm just gonna create a work word document called my Cold Cases.
And I'll put that ticket number in there, and then maybe I'll wait a week. I'll wait two weeks or I'll wait until have a little bit of time. Where I have my ticket queue is cleared out or have a little bit of downtown. I'm and I'm gonna open up that cold case file, and I'm gonna say, Okay, let me search for this ticket number. Let me see what happened. What? The resolution waas.
And as I'm going through that cold case file on Macy, Okay, well,
that's not something I can fix. That was a network interface card problem. I don't have the permissions to replace hardware, so I know next time I'm seeing these symptoms, it might be this issue. Okay, That's something I can't fix. That's a network problem. I would have had to escalate that anyway. And then you say, Oh, wait,
Here's something a person was having use an issue someone was having And the next person I escalated to this to just did a configuration change on the person's computer. So then you can take your cold case file. You can consider that one solved, and you can put in. And in your tips and tricks, you can create a document where you put in Okay,
if I'm seeing this same type of issue,
one thing I may want to check is this Because I followed this file, I followed my cold case, and I found that after I escalated it, the person who put in a solution put in that it was this problem, that it was this and that I could fix this myself next time.
So that's another reason why we want to have good documentation as well. Maybe we have someone else who escalated this issue to us, who's following their cold case so we don't want to put in our solution that we fix the problem
because that's not gonna help anybody. If there's someone out there who you know,
is aspiring to do what our department does or is maybe trying to improve their ability to solve issues and not have to escalate issues as much. They're following the ticket and they're like, OK, well, let me see what this next person's gonna do. Let me see if they're gonna fix the problem and you go in, You say, Okay, I just need to change this configuration setting here.
Okay, well, I'm gonna close out this ticket and then the documentation I'm gonna put change change network configuration solved the problem
again. That's not helping anybody. You're going to still get tickets for that same issue. But if you put in a good detailed solution and someone's following that, then they'll say, OK, they went into their network settings. Then they went to change adapter settings. Then they selected I pee before, and then they checked, and they made sure that all of those I pee before settings were correct.
I can do that myself next time
and then next. Then after a couple weeks, you may notice Hey, I'm not getting tickets for this issue for this issue as much or I'm not getting as many escalations from this particular person because your solution that you put in. They were able to follow and they were able to prevent from having to escalate issues to you. So documentation helps everybody.
So make sure that we do documentation well, we do very detailed a very clear documentation, and we'll be able to not only refer to it later, but we'll be able to pass it around to everybody and help solve issues faster.
So thank you for joining us here today on cyber dot i t. Today we talked about our different troubleshooting steps in our troubleshooting methodology and how we go through troubleshooting and how we use troubleshooting to solve issues properly. We talked about how we identify issues and we take those identified issues and we create a hypothesis and we test our hypothesis and then we implement our
potential steps or we escalate our solution.
And we also talked about the importance of documentation and doing things like backing up our settings in our data. So hopefully you'll be able to take these troubleshooting steps. You'll be able to implement this trouble shooting meth all methodology into your own troubleshooting steps, and you'll be able to go forward and be a better network technician, be a better computer technician
and solves solve issues more efficiently and solve them better