Do you desire to learn about Linux troubleshooting? If so, this video is for you.
We're excited to announce our new Get Hired Interview Program. This program will be available
on Monday, November 15th. You can get this program now at our introductory pre-launch discount at 50%
off by entering the coupon code, gethired. The link is in the description below.
Hi, my name is Michael Gibbs and I'm the founder and CEO of Go Cloud Architects,
and we're an organization that's dedicated towards building high performance cloud computing and
networking careers. Personally, I've been working in technology for over 25 years, and I've been
helping others get their first tech job or get promoted in tech for over two decades. And when
someone calls and says, "Mike, I got cloud hired," it's my absolute favorite thing in the world.
Today, we're going to talk about troubleshooting. And why are we going to talk
about troubleshooting? Because no matter how well designed your systems are, at some point they're
going to break. And that's just part of life. And the better your methodology is to find things that
are broken and fix them, the faster you'll come to a resolution, which will mean less downtime
for the customer, have more satisfied customers, and systems that have higher availability, meaning
they're up and available and doing what they're supposed to when they're supposed to do it.
So let's talk about troubleshooting. Troubleshooting is a systematic process. And
realistically, what's going on is the engineer is going to narrow down and identify the root cause
of whatever's causing this undesired behavior. And when you're going to find out what's wrong
to really identify what's broken, it's so critical to have a systematic approach.
And this is going to be for a number of reasons, and we're going to talk about these reasons.
The first reason it's so important to have a methodology
is it's going to save you from keeping to try the same thing again and again. I'm sure you've
seen someone that tries to troubleshoot, and they repeat the same thing that didn't work
again and again and again. And if you don't have a systematic approach,
you're not only going to not remember what you've done, you're going to be in this loop of try,
try, try, and it's going to take you so much longer. So having a systematic approach will
save you time, but it's going to make it so much easier to collaborate. Remember, when it comes to
this world, this is a team sport. Troubleshooting is not a one person thing. It is a team.
And if you're like me, where you're a cloud architect, you're going to be part of the
process more from a leadership perspective. And it's going to be the engineering team,
specifically the cloud engineers, that are going to be doing this, and the operations people,
the SysOps people, that are going to be the main troubleshooters. But the point is, is
everybody on the team is part of the troubleshooting process,
and having a systematic methodology makes it so much easier to collaborate.
The third reason the methodology is so important is it just makes it possible to make headway,
especially when you're not a subject matter expert. And by being methodical
and having a process, you'll be able to solve the customer problems better
and faster than if you didn't have a methodology.
So when they talk about troubleshooting, they often take this methodology and
call it a divide and conquer approach. And here's the reason.
You're trying to narrow or isolate certain parts of the system, so you can really narrow
down the scope of what's doing. So if you can look at the individual components and
see what's working and what's not, you'll be able to better identify what's broken. Now,
I always tell my students, you can't be an expert on everything. I mean, it's just not possible.
And when it comes to troubleshooting, you may need a lot of people. You may need some Linux people,
you may need some network people, you may need some security people. You may need a lot of
people. So this is going to be a team sport, and it's going to be a divide and conquer approach.
So troubleshooting is a process, and I hate to say it, but it's a repetitive process.
You're going to try something. You're going to try it again. But let's talk about what I mean
by that. So the first thing you're going to do when something is broken is you're going
to generate a hypothesis. What do you think is the root cause? Now, once you have a hypothesis,
you don't know if it's correct or not, so you're going to have to test that. So that's the second
thing you're going to do. First, generate hypothesis. Second, test that hypothesis.
Now, if your hypothesis is wrong or disproven, keep a record of it so you
know that's not where it's broken, and you can share that record with others if needed.
If your hypothesis is proven, meaning your hypothesis or your guess was correct, just
fix the issue and then test the system. And if so,
and the system is fixed, troubleshooting is over. See, this process is very important.
Now in the cloud, it's going to be a little more challenging than in the traditional data center,
because in the cloud, it's going be very common where you're not going to have full access to all
parts of the puzzle. For example, if you need access to a switch, you're not going to have
that access in the cloud environment. So it's going to be a team sport, and you may even have
to call the cloud provider. But see, here's the thing, since you don't have access to everything,
what you're going to do first is you're going to test everything for which you have control.
So test everything that you can do for which you have control. And then once it becomes
a [inaudible 00:05:10] issue, go out and reach out to support, but be responsible
about it. Make sure that you've done your due diligence first, before reaching out to others.
So let's give you an example. Let's say you've got a virtual machine running in a cloud, and it's not
accessible. What's going on? Do you not have the network connectivity to the cloud, to be able
to manage it? Is that server down? Is the router at the cloud provider center down? Is the switch
port, which is plugged into the physical server for which the virtual machine is housed, down?
Is there a power outage at the cloud provider? So you're not going to be able to see this. You'll be
able to run some ping and some traceroutes and tests to get to there, but at some point you're
going to have to engage the cloud provider as well, because you don't have access to everything
when you're a user. So just, again, keep in mind that this troubleshooting process is a team sport.
So when we're going to gather information, remember, in many cases, we're going to
be getting it from another team. So really, it's important to be consistent and thorough.
And there's some common questions you're going to ask during any time you need to escalate
things. And these are really important things to know about. In fact, first, is everything doing
what it's supposed to? If so, that's great. If not, what do you expect to be happening?
And is that different from what's actually happening? These three questions go together.
Realistically, what are you trying to do? That's really important, because is
it doing what it's supposed to or not? Maybe you don't know. But what are you trying to do?
The next thing is what are your expectations? And if it's working
according to expectations, all right, great. But if it's not, that's why we're troubleshooting.
And then what is actually happening? So keep these three things in mind, especially if you're
going to escalate and reach out to other people to help you with the troubleshooting process.
And when you call your Linux vendor for support or you call your cloud provider for support, keep
track of the things that really matter. There's certain questions they're always going to ask you.
For example, they're going to ask you what [inaudible 00:07:09] version and kernel
version you are using. Why? Because maybe it's a known issue. They're going to ask
you about the relevant software and drivers that you're using, because maybe it's a known issue.
See, here's the thing. When it comes to troubleshooting, it's an iterative
process of asking the right questions, testing hypotheses, and really doing your research.
See, there you have it. Here is a brief introduction to Linux troubleshooting
in a cloud environment. Thank you so much for watching this video,
and I look forward to seeing you in another video very soon. Take care.
It was so nice having you join us for this video today. Let me tell you about some free
services we do for the cloud community. Twice per week, we have a free how to get your first
cloud architect job webinar, where we tell you all the things you need to do and know to get
your first cloud architect job. In addition to that, once per week, we actually have
a free question and answer session live on YouTube, where you can come and ask us any
questions you want about building your career related to cloud computing or networking. And
we'll answer them in real time for you, because we want to get you to your goals.
Several more times per week, we have guests from industry, industry experts that I have
known for decades, that are movers and shakers that have changed the world, that can give you
information so you can build the best career. I invite them periodically. They are on my show.
If there's a chance to do some free training on our channel, we'll do it live because we want
you all to have the best skills for the best career. So please subscribe and hit the bell.
I look forward to seeing you, and I look forward to assisting you in your technology career.
Thank you so much. This is Michael Gibbs Go Cloud Architects.