Linux Troubleshooting Course with Practical Examples | Imran Afzal | Skillshare

Linux Troubleshooting Course with Practical Examples

Imran Afzal, Systems Manager / Instructor

Linux Troubleshooting Course with Practical Examples

Imran Afzal, Systems Manager / Instructor

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
77 Lessons (12h 52m)
    • 1. Course Promo Video

      1:19
    • 2. Course Syllabus

      7:01
    • 3. Welcome to Troubleshooting Best Practice

      2:37
    • 4. Follow Policies and Standards

      3:38
    • 5. Documentation Or Ticketing Process

      5:21
    • 6. Patience To Work with the Users Group

      6:30
    • 7. Get Online Help

      4:39
    • 8. Understanding the Issue Before Making a Decision

      2:36
    • 9. Involve Vendors if Needed

      3:15
    • 10. Log Monitor

      3:21
    • 11. Be Honest and Ask Questions

      3:18
    • 12. Welcome to lab setup

      2:48
    • 13. What is VirtualBox

      1:52
    • 14. Download and Install VirtualBox

      3:32
    • 15. Creating First Virtual Machine

      5:20
    • 16. Linux CentOS Installation

      23:24
    • 17. Welcome to Conceptual Troubleshooting

      0:09
    • 18. Who is who

      4:23
    • 19. Cannot Access Server

      6:35
    • 20. Cannot Install OS

      4:33
    • 21. VM Running Slow

      4:50
    • 22. Welcome to System Access Troubleshooting

      0:09
    • 23. Server is Not reachable

      14:08
    • 24. Cannot Connect to a Website or an Application

      12:55
    • 25. Cannot SSH as Root or Other User

      14:12
    • 26. Firewall

      6:29
    • 27. Terminal or Client is Not Working

      4:43
    • 28. Troubleshooting Putty Connection

      11:41
    • 29. Welcome to Filesystem Troubleshooting

      0:09
    • 30. Cannot CD Into a Directory

      18:53
    • 31. Cannot Open a File Or Run a Script

      10:19
    • 32. Having Trouble Finding Files and Directories

      10:28
    • 33. Cannot Create Links

      18:22
    • 34. Cannot Write to a File

      12:21
    • 35. Cannot Delete, Copy, Rename or Move a File

      17:56
    • 36. Cannot Change File Permissions Ownership

      15:01
    • 37. Disk Space Full

      22:21
    • 38. Add Disk and Create Standard Partition

      12:19
    • 39. Add Disk and Create LVM Partition

      12:26
    • 40. Extend Disk with LVM

      14:10
    • 41. How to Delete Old Files

      7:27
    • 42. Script to Delete Old Files

      10:52
    • 43. Filesystem Corruption

      21:21
    • 44. fstab Corruption

      16:56
    • 45. Welcome to System Administration Troubleshooting

      0:09
    • 46. Running Out of Memory

      32:14
    • 47. Add Swap Space

      12:59
    • 48. System Rebooted Or Process Restarted

      13:10
    • 49. Unable to get an IP Address

      19:08
    • 50. IP Address Assigned but not Reachable

      20:37
    • 51. Having Trouble Using vi Editor

      9:53
    • 52. Cannot Run Certain Commands

      14:59
    • 53. Cannot Change Password

      13:16
    • 54. User Has No Home Directory

      13:16
    • 55. How to Change Every Instance of a Word in a File

      5:17
    • 56. How to Use sed Command

      6:30
    • 57. How to Kill a Process, User or Terminal

      9:55
    • 58. Recover Root Password

      5:26
    • 59. Sosreport

      6:34
    • 60. List of Users Logged in by Date

      15:30
    • 61. System is Running Slow

      33:54
    • 62. Rollback Updates and Patches

      14:22
    • 63. Welcome to System Recovery

      0:09
    • 64. Recover Virtual System

      9:03
    • 65. Recover Physical System

      3:51
    • 66. Disaster Recovery

      6:20
    • 67. Welcome to Bonus Section

      0:09
    • 68. Introduction to File System

      5:14
    • 69. File Ownership Commands

      11:35
    • 70. Files and Directory Permissions

      12:57
    • 71. System Log Monitoring

      11:08
    • 72. Hard and Soft Link

      12:28
    • 73. Curl and ping

      9:56
    • 74. Programs and Service Management

      17:35
    • 75. Processes and Jobs

      19:38
    • 76. New network command

      3:52
    • 77. Difference Between Linux 5, 6 and 7

      14:45
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

164

Students

--

Projects

About This Class

Maintain a reliable and highly available Linux server infrastructure, and reduce costly downtime. In this Linux troubleshooting training course, you gain the expertise to effectively diagnose and fix common and complex Linux server configuration and administrations issues, and learn to apply those skills in production environment

Linux Troubleshooting Course

Section 1 – Introduction and Course Overview

• What is this course about

• Syllabus Overview

• Download Syllabus

Section 2 – Troubleshooting Best Practices

• Follow Policies and Standards

• Documentation or Ticketing Process

• Patience To Work With the Users / Group

• Get Online Help

• Understanding the Issue Before Making a Decision

• Involve Vendor If Needed

• Log Monitor

• Be Honest and Ask Questions

Section 3 - Lab Setup

• What is VirtualBox?

• Installing Oracle VirtualBox

• Creating First Virtual Machine

• Linux Installation

Section 4 - Conceptual Troubleshooting

• Who is Who?

• Cannot Access Server

• Cannot Install Linux

• Linux Virtual Machine Running Slow

Section 5 - System Access Troubleshooting

• Server is Not Reachable

• Cannot Connect to a Website or an Application

• Cannot SSH as root or a Specific User

• Firewall Issue

• Terminal Client is not working

• Cannot Connect using Putty to a VirutalBox VM

Section 6 - FileSystem Troubleshooting

• Cannot cd into a Directory

• Cannot Open a File or Run a Script

• Having Trouble Finding Files and Directories

• Cannot Create Links

• Cannot Write to a File

• Cannot Delete, Copy, Move or Rename a File

• Cannot Change File Permissions or View Other Users Files

• Disk Space Full or Add More Disk Space

• Add Disk and Create Standard Partition

• Add Disk and Create Standard Partition

• Add Disk and Create LVM Partition

• Extend Disk with LVM

• How to Delete Old Files

• FileSystem is Corruption

• Corruption in /etc/fstab

• Script to Delete Old Files

• Handouts

Section 7 - System Administration Troubleshooting

• Running Out of Memory

• Add Swap Space

• System Rebooted or Process Restarted

• Unable to get IP Address

• IP Assigned but not Reachable

• Having Trouble using vi Editor

• Cannot Run Certain Commands

• Cannot Change Password

• User Account has no Home Directory

• How to Change Every Instance of a Word in a File

• How to Use sed Command

• How to Kill a User Terminal or Process

• Recover Root Password

• SOS Report

• List of Users Logged in by Date

• System is Running Slow

Section 8 - System Recovery

• Recover Virtual System

• Recover Physical System

• Disaster Recovery

Section 9 - Bonus Section

• What is FileSystem

• File Ownership Commands (chown, chgrp)

• Files and Directory Permissions (chmod)

• System Logs Monitor (/var/log)

• Soft and Hard Links

• curl and ping commands

• Programs and Service Management

• Processes and Jobs (systemctl, ps, kill, top, crontab, at)

• New Network Commands

• Script to Delete Old Files

• Difference Between CentOS/Redhat 5, 6 and 7

Meet Your Teacher

Teacher Profile Image

Imran Afzal

Systems Manager / Instructor

Teacher

 

 

Hello, I'm Imran Afzal and here is my education and experience:

 

 

About Me:

Imran Afzal

 

Education:

Bachelors in Computer Information Systems (Baruch College, City University of New York)

Master of Business Administration (New York Institute of Technolgy)

 

Experience:

- Over 20 Years of IT Infrastructure experience

- 7 years of training experience in Linux, VMWare, Windows and many other IT technologies

- 5 years of IT Infrastructure management experience

 

Certification:

- Linux Systems Management (New York University, NY)

- UNIX Operating Systems

- Linux System Administration and System Internals<... See full profile

Related Skills

Technology Linux IT Security

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Your creative journey starts here.

  • Unlimited access to every class
  • Supportive online creative community
  • Learn offline with Skillshare’s app

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

phone

Transcripts

1. Course Promo Video: Hello, everyone. And welcome to my course Lennox troubleshooting course. This course is designed for people who are already in i t. Or people who actually trying to get into I. D. Who have the basic to somewhat at vast knowledge off legs already. Now they want to refine their skills in terms off how they could troubleshoot regular everyday issues to the advanced level. Trouble shoots. I have included pretty much a lot of things that actually a system administrator and engineer experiences in their life in their career life. So that's about my course. Now let me tell you about myself. My name is Enron absolute, and I have almost 17 years off experience in I t field, primarily in system administration, system engineering and systems management. I have bashes degree in computer information systems from Peru, College City, University of New York, and I have a Masters degree MBA from New York Institute of Technology. So that's what pretty much about me and thank you again for clicking into my course and enrolling in my course. So good luck to you 2. Course Syllabus: Hello, everyone, ever welcome to the course syllabus. This is where you have to spend a few minutes and then decide whether this is the right course for you. I'm going to cover exactly what I am or what I have included in this entire training. The first section is about the introduction and course overview. This is introduction, which I'm already going through. This is about what the horse course and tales of what are the things included the syllabus overview, which I'm going to right now with you. And after that, if you decide in roles, you could download the syllabus. Section two is about troubleshooting best practices, meaning how What are the fault of the policies that you should follow? What other standards that you should follow through the documentation and go through the ticketing process patient to work with users and groups. When people actually work in a group at you, you probably experience that other groups or other departments toe or finger pointing at you eat at each of them, then how you should act to avoid situations like that. Get online. Help understanding the issue before making a decision involved the vendor. If there is a need. Or if you cannot resolve at what point you have to pick up a phone and call your window the log monitoring and be honest and ask questions. The third section is about setting up a lab ill will cover up of about what is a workable box installing Oracle virtual box, creating for social machine and doing the Leninist installation. Now, of course, if you already have a Lennix machine like a lab Blinis machine where you could practise this training that you do not have to go through this entire section you could just simply skip through it and practice all those, um, all those lectures and all those troubleshooting commands that I will show you in your lab set up. But if you don't, that's fine. Just follow this section, and I'll show you exactly how you could run a little machine. Then we'll talk about the conceptual troubleshooting who is who meaning which server. When someone reports a problem, how do you know what show where they're talking about? Who is the source? Who was the target? Who is the client who's the server and what Pearl called they're using cannot access server cannot install a Lennox machine Lennox washing machine a running slow, then Section five system access troubleshooting Many time people have a problem when there cannot access a system or can a log into the system. So what are the topics we will cover is about Server is not reachable, cannot connect to a website, and application cannot ssh as root or a Pacific User Firewall issue. Terminal Clyde is not working. Cannot connect. Is using Putty be a war Shal box? By the way, all these topics that I'm covering is all based on real life examples, which I have experience in my life, which my students actually have experienced in and in their life or during taking my course . Section six is about file system troubleshooting can not see the into the fall. Cannot open a file or Rana script. Having trouble finding files and directories cannot create links. Cannot write to a file cannot delete copy, move, Rename of all cannot change file permission or a few other user files as you notice. I have included cannot word on every lecture because this course is all about troubleshooting, and then you cannot do certain things. That's where you have to come in and do the troubleshooting this base full or ADM or disc disc and create standard tradition. Continuing Section six ad disk and create standard petition when you run auto disc. How you could add a disk in Crete. L V m Petition Extend disc using LV and partition. How did the lead old files file system is corrupted than how you could fix it? Corruption at CFS Tab Scripts to delete all files and then, of course, in Section 60 have handouts where you could review some off the documentation that I have attached. Section seven is the biggest section, which is we're talking about system administration troubleshooting that could involve anything that you have to deal with your system, which is like running out of memory ads off space system rebooted ah, process restarted. How do you know? Unable to get an I p address networking issues I p assigned, but I cannot reach it again. Networking issues having trouble using V I editor cannot Ron. Certain commands cannot change Password moving on on the same section of system administration user account has no home directory. How do you troubleshoot how to change every instance, Off award in a file. How do you said command cassette Come as very powerful. So I have included in this as a part of the troubleshooting. How to kill a user terminal or process Recover Rule password If you for gotten about it S. O s report list off users logged in by date System is running slow. I have included so many commands in system running slow. When you're going to review this lecture, you will see I have included, like TCP Dump Top D of command Free Command, I o stat. So many commands that I cannot even list every one of them moving on to section eight. It's about system recovery Will talk about recover for troll system, recover for the physical system and disaster recovery Section nine, which is a last section. This is the bonus section. I have included many, many different lectures, but few of them that I have listed here that are about the followership logs softly Heartland coral pink commands program service never commands scripts to delete all files. The difference between Cento as 56 and seven and many more. I cannot include all of them in bonus section but I will be including many more again. This is my, um course syllabus. Please remember one thing. This course syllabus is not limited to what I have shown you just now. This will and I as I speak, I will be including many, many different lectures as I'm getting it. A feedback from my students. So hopefully you learn a lot from this from this course and Gluck to you. 3. Welcome to Troubleshooting Best Practice: Welcome to my section Number two. This is where we will talk about troubleshooting best practices like what is there the exact rules that we need to follow in order to have the best troubleshooting? There are a few list of things that I will go with you in this section, and those are not like a real troubleshooting that we will do. But there are basic concept that you should a basic format that everyone should follow to perform an effective troubleshooting. And those are one of them is full of policies in place, meaningful or any policies that you have for your company. Any standards that you have for your company. Follow that when you are going through the troubleshooting steps, whether it is opening up a ticket, notifying a certain person or whatever the policy they have, you have to follow that before you have to start trouble shooting anything and then wire hman. Then we'll talk about the documentation or tracking. Sorry, ticketing process. Documentation, meaning, if there is an issue heavy actually looked at any prior documentation, or are we going to document this existing issue? Or is there any ticketing process and nine out of 10. Every company has a ticketing system in their environment. Then we'll talk about the patients, the patient, that you really need to work with, users and groups. And how can we get that? Patients? That's the most important things when you're troubleshooting issues. If you get angry, waited during the troubleshooting process, trust me, you're not gonna get anything done. Then we'll talk about how you could get some online help. All line help is one of the biggest tool that I use it personally. And many, many other system administrators are engineers they use on a regular basis so they could go online and look for solutions. Will talk about understanding the issue before you make a decision. We'll talk about involving Wenders whenever you need help and the log monitor. There's so many laws that you have to monitor before you make. It's a decision or before you make a change in your environment and the last one be honest and ask question. You don't have to make up anything, and if you don't be afraid to ask any type of questions that you have, so these are the few things that all go were in this section. It is very important that you go over all of these, um, flies with me and these topics because that will really set your base to get starting on the troubleshooting lessons. 4. Follow Policies and Standards: follow policies and standards. Let's look at a were what other things that we should follow when you are working in a corporate environment, The first thing is communication. Communication is the most important things that you should do or notify the users or your boss or management that what is being done to the system or why you're troubleshooting or what happened, Why there is a failure. So troubleshooting Asari Communication is the key, so find out how you communicate. Is there a Pacific tool that you have to use to notify user? Or do you just simply have to have to send an email? These other things you have to follow then involved the right people involving the right people? Meaning, Do you have to notify your boss? Or do you have to notify your boss's boss You? Do you have to notify if you're working in a customer room environment? Do you have to notify the implementation managers or the engagement managers? Anybody who actually deal directly with the customers to do? How do you have to let them know that the customer system is down? Then open up a ticket if they have a ticketing platform and I said before nine out of 10 Every company has a ticketing platform where they open up a ticket if there's any issue, or you could open up a ticket at their if you are doing a maintenance. If you open, you open up a ticket if you are upgrading certain system, so you need to use a ticket for everything. So same thing for troubleshooting. If you're troubleshooting anything you need to find out if you need to open up a ticket. Sometimes if it is critical issue and impacting more than one customer or more than one stakeholder than you require to open up a ticket resolution techniques are mattered. What are the techniques that you need to follow the resolution method? Do you have to go through a certain procedure toe access system? Um, council system? Milo. Do you have to notify someone? Is there Pacific password So these other resolution techniques or math? Third, Um, do we have to go from A to Z the format? Or you could just jump in to the to the machine and find out what happened to trust our troubleshooting. You have to know the matter, maintain a schedule like. Is your company following the maintenance schedule like they only do. Maintenance is on the beacon. Or are they doing? Maintenance is only on the week. Sometimes people don't like to do ah, maintenance on Friday or on the weekend. So these are the things you need to find out when you're doing maintenance or even troubleshooting. Let's say the reason I'm bringing this up is because if you are troubleshooting an issue and during the troubleshooting you are, you're being told by the window or you just to find out from an article that you need to upgrade in order to fix this issue. The upgrade, of course, requires a maintenance window, that maintenance window. If you are troubleshooting an issue on the weekend and the only maintenance takes places during the week, then you need to know these things approval process. Who approves the process If you need to, um, apply a pash, or if you need to troubleshoot something that is related to an upgrade, you need to know what the poor processes. Sorry, I'm Vendela ahead. So these are the few things that you need to follow in terms off following policies and standards 5. Documentation Or Ticketing Process: next one we have in line is the documentation or ticketing process. That is one of my favorite part because I strongly believe anything that is document did correctly. It will always help you down the road. Meaning if I have an issue today and I document that issue, that issue can re occur maybe a year from now or 10 years from now. You can always go back to that ticket or always go back to the document and see exactly what happened. It is just the same way if you are Ah, lawyer. And you are actually, um, fighting a case. You lawyers do that many times that they go back to certain ah, incident or certain word X that took place in the past. And they bring it up as an example. You know, in 1988 this gentleman what took place because of that, That that How do they know that? Because there is a documentation off every trial that took place. Same thing, same format we wanted to follow here. We have to have a documentation off every troubleshooting or every issue the Viet, Whether you do a documentation or like a raw document on a ward format or you're doing a ticketing process. So look at for look, for any existing documentation your company has. And I'm telling you, every company has documentation if they do not have any kind of proper documentation than this is your time to shine star creating documents, stock rating, fancy documents. Put a process together. How on issue takes place. So if an issue comes in, then how do you troubleshoot? Who do we notify? All that comes in a documentation. If they have a ticketing system, put it. Put that together in a taking system. They probably have a Vicky, a lot of companies to have Wikipedia's and internal ones look for the documentation. And if they don't go ahead and posted your article in there ticketing system, as he discussed, um, nine out of 10 people do have ticketing system postmortem or incident report. Um, many big companies. Every time there's an issue, they would require you to put a post mourn or an incident report together. An incident report is something like, which will give you a brief summary off what exactly happened and what steps that were taken to resolve the issue. If they don't. If your company does not have any of these documents again, start creating one incident report. You can find it online as a templates that you could put together so you could follow that root cause analysis. This is also some of the things that people follow their root cause analysis. Maybe not. Not at the time when issue happened after the fact when issue took place. So they everybody come together on a call and they try to find out what exactly happened and what can be done to prevent issues like that. So please go through this route cause analysis with your boss. If they do not have a process in place like that, tell them this is something that you want to come out with. That every time there's an issue especially critical issue, you wanted to create a call. And that call includes all the team members ever involved during the troubleshooting and yourself, your manager and someone else who could document all that put together records and what happened and what can be done to actually mitigate that issue. So you need to find that out if they have that in place. If not again. There are many tools online that you could look into. And to find out if there are any tools that could provide you the format of root cause analysis, Document vendor could recommendation. So if there are any ah, recommendation from the document meeting you troubleshooting issue. And the vendor says, Hey, you're you're actually working on version two Dato and you need toe upgraded to $2 5 in order to fix this issue, then you need to document that. And then, of course, present that to your manager or whoever they're pulling, whatever the approval procedure is, then training. Of course, the training comes the last. The reason because you went through the whole, um, incident, you went through the whole troubleshooting. You fix the issue, you documented the issue. Now the training comes in for those people who were not involved in this rubbishing or who are your juniors or subordinates or even your peers, you need to sit together with them and have a discussion that what exactly happened and what you did and what should be avoided that you did that actually going to make the whole prop process more efficient. So this is why I focus more on documentation and take this system because it actually provides ah, huge ton off value to your troubleshooting and, of course, to your documentation skills as well. 6. Patience To Work with the Users Group: patients to work with users and groups. The first thing is that, of course, when there is an issue, please do not panic. I have seen many incident in my life in my career, off all the system administration that work that I did. The people get panic, and when they get panic, nothing can be done the right way. Things can go haywire, so don't do that. Don't get panicked. You need to stay calm. The things do get break, they do the do break. That's fine as perfectly All right. And that is why you are here. The company have you to fix those issues. So stay calm, bring everybody together, then involve others. As I was saying that just in my last sentence involved others in your group to seek help if you know, noticed that your system is working fine and you being told the system is down or system is not working fine and or your, um, or the user cannot connect to the database or cannot connect to the Web server. Bring the people who are actually directly responsible for that. If that's a database, bring the database guys online. Bring everybody together. If you have If you if you need help from your superiors or for people been there for a while or you manager, do not hesitate. As for their help, ask that What can be done is this is something that I've seen. Do you think that is something that you have experience in the past? Work patiently with other groups? I know when you start putting together a big group of people, there is always finger pointing. Hey, this is not a systems issue. This is data basis. You know, this is a networking issue. Oh, no, this is application related issue. Everybody will solve pointing fingers. It's OK. It's It's fine. Most of the time, fingers are being pointed always on the system side. And the reason they point fingers at system sizes because we the system seem actually per wide. The platform for database Toronto for applications to run for operating system to run. So we are the main providers for the entire platform. So that's why they always come back and say it because of the resource or compute Resource is not working fine. So it's OK. You could just take that, um, professionally and come back with a good, reasonable arguments that why do you think that it is not our issue? And the only reason you could say that is if you have a solid proof, explain the situation when others get panic or annoyed. Yes, because you're you're not panic. Okay, Perfect. By What about if the other person is annoyed and on on the call or in the bridge? Then you have to stake Panic 10 sorry. You have to stay calm. Of course. Then tell the person it is perfectly fine to tell the other person. Please become Let's get this thing resolved together. If you stay calm, do not think off. If I say that, maybe he will get offended. No, People don't get offended if you just tell them nicely. Just don't say Hey, relax. You keep your talking too much. Don't say that. So just say please stay calm. Let's work this thing together and let's find out where the issue is. And when they see you working on the issues so calmly, they will automatically get calm. Step. Sorry. Set up a conference call to bring everyone together. Of course, when you need to have the people together, there has to be a platform to bring them together. Some people use a Skype or some kind off video. Um, application. Some people just do. Ah ah, phone bridge calls. Some people actually get physically together on a conference room. That's fine. Whatever your medium is, you could utilize that to bring everybody together. Hand over to someone with more experience, meaning. If you think there's a situation and there's a troubleshooting that you're doing that is above your expertise, then do not take it personal. And please give it to someone who has more experience. When I say that, it means, let's say, if you are a system administrator, like I could tell tell you about myself if I'm a system administrator and there's something comes up that involves scripting a script that cause an issue, and I'm looking at a script and that script is probably written in PERL now, I do not have much experience in Pearl. I could read it, but I really don't understand what exactly it is doing at certain certain things. So what I would do, I will give it to this someone who has more experience with pearl or E one, my junior, if the person has been hard to the company, um, two months ago and I've been with the company's six years again, don't get personal. The person who came into six months ago, he probably had more experience from Pearl. Just tell him. Hey, take this called. You have more experience on Pearl. Tried troubleshooting it. Then do not let others derail you from the issue. Yes, this happens many times what I mean about what that is. People with a lot of people get involved in a call and they start talking and they start stepping on each of the toes. They actually start talking something that is not relevant to the entire conversation if the system is drowned or crashed or something. Yes. Start talking something else. Oh, you know what that happened? Something like that when I was, um, working on a database issue, and that database had an issue that I had never seen it because Hey, Paul, do you know why that had the databases you had? Because it has some, um, table extension problems. See these other things? I'm already taking you off of the subject, and I don't want to take you the office, the subject and to keep them everybody on the same subject. Tell them Hey, guys, please. Can we please concentrate on this issue? It is perfectly fine to say that and again going back to my main topic. Stay patient. 7. Get Online Help: getting online help. Well, for me, this is one off the more sufficient tool to get your issue resolved because nine out of 10 the issue that you're having someone else had the same issue. So go online and search for it. So before we do that and if you have never done it, you select a preferred search engine. Meaning are you going to use Give Google, yahoo or whatever that is. Just stick with one look for Pacific error in messages. When you sticking up a message on search, do not type like my server is down. So where you gonna get you? Probably gonna get tons of article and that's going to go nowhere. Basically picked exact error message that you're getting and put it in there and then you will see that you're gonna get so many related articles out there that is only Pacific to your search. Or maybe it's gonna go mawr and mawr and more narrow down if you try to search for Pacific error. If you do not have an Arab, then put your search specific to your environment. Kneeling meaning, say server is down in Lenox Environment Severin down in Lenox Red hat server is down in Lenox. Red hats aversion. Seven servers down in Lenox, right? Had 7.5. See how much? Narrowing it down. That's how you're going to get the exact same problem. And if someone has the same issue, sign up for Lynas committed forums. There are so many community forums out there, I will recommend you to go sign up. Um, not on Lee, because you wanted to get helped and troubleshoot your issues, but also help others as well. And you know, as as they say, what goes around comes around. If you help as much many people out there, you will be get help. And it's just a car month thing that I believe are asked Question if you cannot find your answer, meaning if you are searching for something, you can't find exact answer and there are forums there that you could put in and you could put your question on, um, if you have a support with the vendor than a perfect that you go there. If not some people just wait. If it's not critical, that just post a question online and they just wait for the answer and I tell you, you'll be amazed how many answers you're gonna get. People actually jump on the question and answer that, Um, then moving on. Be aware of security issues, though, so that's Ah, that's a other side of reality. Um, getting all the help is very good, but there's a dark side off it as well, and that is a security risk risk. Do not let anyone log into your system if someone is willing to help you. And they said, Hey, why not let me log in and see what's going on? You don't know the person. Of course, I'm sure you know that this is a basic ABC. You probably not gonna let them anybody come in. Other thing is hide your I p address or host name. If you are copping a string from your log, most likely it will have ah, host name to what? Or i p address to it. Just dark it out, Or just simply take it out and then search for it, or then send a message to someone to look for it. Do not search online from the server, which is having issue meaning. If you're sober, is having issue and you're getting online from that server. Don't do that. Go from a server. Your own laptop, Not the ones that are actually this over to a production environment server. Do not send any documents that has company information, which I mean, like, sometimes you, um you have Ah, no pad or word pad that you want to share with People. Do not send that. I'm gonna recommend that sometimes those documents. If you go to detail of that document, you'll see the company name and when it was created, your name and a whole bunch of information Do not download a file or script and run in your environment. You probably going to see helpful articles. Hey, this issue could be resolved. If you don't load this file and run it a lot of time, you'll find these type of things in windows. Not as much a new next. But of course. Um, keep an eye on it, be aware off it, do not download anything or any script, or even if you think that script will help you resolve the issue. Don't do that. If you're working in the corporate environment and the last thing I have, make sure to add a thank you note to a helpful article. If you found that and one of the article help you resolve the issue. That is perfect. Please do thank the person who actually put that article together or actually help someone else resolve the issue. Send one more. Thank you, too, to him or her saying that you did result my issue as well. To said it is just to put a smile on his or her face, all right. 8. Understanding the Issue Before Making a Decision: understanding the issue before making a decision. Ah, many times we do make that mistake without knowing the exact our message of without knowing . Ah, the exact problem will just come to a decision or we just implemented change. And next thing you know, that was not the issue. So just make sure ask yourself these questions. Who is the source meaning from where the issue is happening? Who is the target? What is the I P address or host? Name of the target? Same thing. What is the I P R R ah Host? Name off the source. What is a port number Whenever there is a problem? I know there's always a source and target and port numbers and wall, because if it's a communication issue from one server to another than most likely, that's the issue. But if it's a issue just with its own server, then you still need to know whether you are on the right server, whether what communication is being used, what kind off application issue it's having, who will be impacted. This is another thing that you need to ask yourself is if you are making this change, all right, if it's some Hassi decision and you're making this change. Who is going to be impacted? Is it a test environment that you get a word back or nothing gonna be? Nobody's gonna be noticed. Okay, Go right ahead. Make a chain find out what will happen. If not, do will change back. Nobody's gonna be noticing. But if it's a production environment, just be careful. Who do you need to notify? You covered that already. Make sure your boss knows about it. What you're doing, because he's the one at the end who actually is gonna cover your back. He's gonna stand behind you is gonna say, OK, that's fine. It this happened because I was aware off it. If you have not notified your boss, he cannot help you. And things could go go wrong. Trace the issue again to trace the issue. There's so many ways you could trace the issue from one system to another from logs and whole bunch of stuff. So again, try to understand the issue before making your decision. I know sometime people say is Ah, look, I'm very smart, and I know I found out this issue right away, and they say that during the call. Hey, I fixed it or they just implemented. And then next thing you know, they feel bad. Oh, I shouldn't have said that because that's not the issue. Then what should I do now? Well, that's why guys again, I'm saying, Please make sure you understand the issue thoroughly. 9. Involve Vendors if Needed: Inbal vendors if needed. This is when that situation gets more critical. You're trying to resolve an issue and you cannot get a result. Then you have to actually escalated to the higher experts who could actually who actually deal with these things almost every day. Call for critical issues. Have someone from your team reach out toe winders. What it means is, if you are troubleshooting the issue while you are in the middle of a call with people troubleshooting and see what's going on, you probably do not have enough time to hang up and pick up another phone and call the window and find out what happened. Because when you call the Wender, they will ask you bunch of stuff last for the logs, so it will take some time. So if you are on another call already troubleshooting, ask someone and from your team to help you out To open up a ticket with the vendor, upload logs and allow lenders to look through the logs, they will probably not gonna tell you right away. Hate. The system is down. I know what the issue is because again, as I said previously in my last light and with the windows as well. They actually looked through the logs. They actually understand issue before they make a decision or before they tell you what is wrong with it. They're not going to tell you right off the bat. I I know this issue, and this is what happened with, um Thompson Company or X Y Z company as well. And this is what we did know. They would never say that because they know every company is different. Every system is different. It's the same where you have to, um, react the same way as well. Allow access to log in the system. Yes, of course. They will ask you to walk them through, shared the screen. Or even, like sometimes people do have remote log in access. Uh, vendors who have a devil again. They will work with you along side and see what the issue is Set up a call between the vendors to a wide finger pointing. What it means is, if you have ah one, render that say you have red hat and then there is ah, database involved and you have SQL Microsoft team involved. Then the best thing, if if they both are on a different calls and they're saying, Hey, this is not our issue or does not our issue. Then what do you do? The best thing you do is you merge the cost together or set up one new conference call and tell them to join the call. And they always do that. Offenders are not afraid to do that. They are open to it and they will join the call right away. Or, if you have a call already going on internal, you could open it up to your Wender as well and have them come in and take a look. Don't be afraid. The vendors coming in and you have a security risk. No, Wenders are already. They already got your con contract. They already got your confidence. So don't worry about sharing information with them. Record all render ticket notes and numbers because you need that when you have. When you are putting together the incident report or a post mortem report or any type of documentation you're putting together after the fact that your resolve issues 10. Log Monitor: log monitor. This is also one of the most effective tool or a way to troubleshoot issue long monitor. Think if it away. As if you have. Um if you go to a hospital, you have a problem or you or you just go to the hospital. Is it someone and you see, at the end of the end side off the bed there is a clipboard and a clipboard has some papers attached to it. Every time a doctor comes in, they actually look at the law clip and their write something on it. And, uh, and anesthesiology, I or ah, Medicaid, Education guy or someone comes or a nurse comes to your room and give you medicine. They actually write that down everything in the log. Have you noticed why they do that? Because the reason to do that if something goes wrong or if you start feeling pain, they would know exactly what was given to you by whom, At one time, at what time? Or if there's a non opposite reaction to it. So these are the things that all captured in the log. Well, nowadays, that probably clipboard thing is gone. Now they have all computerized system. Everything is recording the in the computer, but there is still and always going to be the log. Same way. Similar fashion and systems environment. Infrastructure vibrant. We have logs we need to monitor those logs. We need to check those logs for any errors or fate. ALS or ah, information or warnings that comes in those little logs are systems logs, application logs, hardware logs, networking logs, these air the type of logs that are out there depending on the issues you are having. You need to look at those logs and trace those logs. What happened again? Going back to my scenario. If you're having if your system is having issue communicating to database your stew, need to check your systems log and the database log and see where the disconnect er's. That's call tracing the logs. For example. Web server um, going to the application server applications that we're going to the database server. This is an example I picked for the environment that is dealing with the retail observers. So are anything that has ah, Web server interface. When you goto dubbed upto dot google dot com, they have observer in front in the middle layer. They have application server, which has the engine running and in the back. And they have a database server. Every server that you see has a log. So you will trace those logs, copy the long error and search it online. Um, those loggers, if you see a Pacific our message, see if you can find anything online regarding that Save the logs before system reboot because there are many logs that actually disappear when this system is rebooted. So but so the fact that you come back after the troubleshooting system is resolved, everybody's happy. Now. You need to do a root cause analysis and how you're going to do it. And you have the logs, right? But if the logs are gone, then you have no way of finding it. So make sure you save the logs by a different name, so the system reboot doesn't delete 11. Be Honest and Ask Questions: Okay. The last one of the newest we have is about being honest and ask question. What it means is, if you made a mistake, just admitted Yes. Tell everybody. Yes. You did something to the system or you do. You were doing something or you're performing maintenance. And then you accidentally rebooted the system or you accidentally, um, did something on the configuration file that cause the issue. So please admit it. People actually appreciate the honesty. They will tell you That's fine. You understand me? Six happened. Then what's the course of faction? They'll ask you and they will appreciate you down down the road. Then don't make up for if you have not find the problem. If you think that you are troubleshooting in the issue and you have not come to a conclusion and all we're already past or to our past just don't say anything just to make the other person feel better in terms off, like you have to lie. Hey, you know what? I found the issue. This is the issue about ah, one of those http Configuration file has this type of problem and you have no clue. You're saying that just be honest about it. Tell them. Hey, listen, it's been two hours. I understand. I'm trying my best. I'm gonna involve I'm gonna escalate it if there's a need to it. So just simply don't make up the stuff. Don't be afraid to ask questions. Recovered that already. If you need to ask question, ask your boss. Ask your subordinates. Ask your peers what it is stands for. If you know if there's an acronym in there, you need to know what that acronym stands for. Asked them That is fine. Sometimes you know a new person that is new to the system. There's so much application systems related things in there that you probably don't understand. That is okay. You asked them. I don't think, Hey, if I asked acronym for um even, let's say, um Http, right, it's It's some time. It it has, ah, Apache to it, and you say, Hey, I'm looking for a party dot log, but there's no party. The law. There's a CDPD law, so there are things when it might confuse you. But it's OK. You can ask question what they're stands for, how the issue was reported. You could tell them Hey, I was just sitting and I saw this alert coming in or someone else reported to me. Don't say that. Hey, I was the one who found that issue. Why do you think this? It's related to Lennox server or links related issue. Um, how the issue how the issue is resolved. So that's one of the things that you have to tell. Um, I have seen people in the past when the issue is result on its own and they just say, Oh, yes, it's resolved because we did something resolved. No, there are issues. There are situations when somehow magically issues gets results and you would never find out. So So just just be honest about that. Ah, tell tell people Tell the users eight issue got resolved itself. You have no clue what Holly got resolved, but you will definitely look into it to find out what was the issue and how a guy results. It's just that simple. And then you move on with your life. All right, OK, 12. We