Part 3: Storytime

Analogies are great. I love analogies. Properly done, they’re a great way to frame something new in a context that’s already familiar to someone else. And so that’s what this Part will be about: a variety of analogies, or stories, at least some of which I hope will “speak” to you. In them, I’ll frame out some of the concepts covered elsewhere in this book, in an attempt to give you more context and real-world applicability.

",{"_272":273,"_43":44,"_47":48,"_45":46,"_65":66,"_274":275,"_313":270},"previewContent","

\n \n
- \n Introduction\n
- \n Acknowledgements\n
\n
\n Part 1: The Short Version\n
- \n How do You Find a Wolf in Siberia?\n
- \n Before You Start: Be Cool, and Get a Notebook\n
- \n Understand the Symptoms\n
- \n Understand the Scope\n
- \n Replicate the Problem\n
- \n Prerequisite: Know the System\n
- \n Test\n
- \n The Scientific Method and Troubleshooting\n
- \n “What Changed?”\n
- \n Control Your Variables\n
\n
\n Part 2: The Dozen Parts of a Troubleshooting Mind\n
- \n 00. Eschews Belief; Hungers for Facts\n
- \n 01. Is Proactive: Has a Knowledge Base\n
- \n 02. Knows the Symptoms in Depth\n
- \n 03. Knows its Tools\n
- \n 04. Knows When “Wrong” is Right\n
- \n 05. Knows that “Know the System” Doesn’t Mean Expertise\n
- \n 06. Can Follow the Chain\n
- \n 07. States Better Theories\n
- \n 08. Brainstorms the Problem Domain\n
- \n 09. Can Troubleshoot Stuff That’s Not Totally Broke\n
- \n 10. Seeks Commonalities\n
- \n 11. Is Calm; Projects Calm\n
\n
\n Part 3: Storytime\n
- \n POP! The Weasley Outlet\n
- \n It’s What You Project\n
- \n The Non-Leaky Hose\n
- \n The Leaky Network Server\n
- \n The Water Heater\n
- \n Electrifying!\n
- \n Spoiled\n
- \n What Could it Be?\n
- \n In Closing\n
\n

Introduction

“Hi there, this is [redacted], how can I help you?”

\n\n

“Seems my television isn’t working. It’s just displaying a bright blue screen.”

\n\n

“Okay, I’ll try and help you with that! Can you check and make sure it’s plugged in?”

\n\n

Pause. “Into the wall?”

\n\n

“That’s right, there should be a cord coming out of the electrical socket in the wall.”

\n\n

“Yeah, I know what electricity is. Did I mention that it’s showing a bright blue screen? Like, it’s clearly powered up.”

\n\n

“Sure, but we need to check the electrical cord.”

\n\n

“I’ll go now, thanks.”

\n\n

Click. Redial.

\n\n

“Hi there, this is [redacted], how can I help you?”

\n\n

“Seems my television isn’t working. It’s just displaying a bright blue screen.”

\n\n

“Okay, I’ll try and help you with that! Can you turn off all the circuit breakers in your house, and then turn them back on?”

\n\n

Click.

\n\n

We’ve all had calls like that, and I sure hope you’ve not been the circuit-breaker technician on one of them! Troubleshooting things sometimes seems like a mysterious dark art, available only to those with special aptitudes. Kind of like a wizard. And it’s true that really experienced people can make troubleshooting seem like magic, because they’ve done it so many times that they run through a lot of steps in their heads. There are also natural “logical thinkers” who pick up troubleshooting a little quicker, and it’s a little easier for them. But anyone can learn to be a better troubleshooter, and that’s what this book is all about.

\n\n

Troubleshooting is not an art. It’s a science. Art stuff—painting, singing, whatever—usually does require some innate talent, along with tons of practice. Troubleshooting, technically, requires neither talent nor practice, although practice does make it go faster and smoother over time. Troubleshooting is something anyone can potentially do, so long as they possess three important personality traits:

\n\n

\nPatience. You can troubleshoot quickly, but only with practice. Troubleshooting is methodical, which means you can’t skip steps, which means sometimes it takes a while. That can make it hard to remain patient when someone is screaming at you about whatever you’re troubleshooting, but you need to remain calm and logical—almost Vulcan-like—in order to stay in the Zen Zone of Troubleshooting Nirvana.
\nBravery. Most of us don’t like to fail, especially in front of other people. But troubleshooting is all about coming up with a theory, and then either proving or disproving it, and you’re going to be disproving a lot more theories than you prove. So you’re going to look like you’re “failing” a lot. It’s part of the process, and you can’t skip it—you have to be brave enough to get through it.
\nObsessiveness. Troubleshooting requires a very consistent, methodical approach. You gotta do it the same way, every time, although sometimes you’ll develop the odd shortcut or two. But you need to obsess about the methodology, and the process. You can’t skip things. You often have to document a lot, and you need to be compulsive about that to make it all work out.

\n\n

If all that sounds like it could be you, then you’re in the right place.

\n\n

I wrote this book because, aside from the materials at Troubleshooters.com (which don’t really “speak” to me, personally), I wasn’t finding a lot of good books on “how to troubleshoot.” I think that troubleshooting is one of those skills that, once you develop it, truly elevates you above the rest of the pack. It’s been a core mover-and-shaker in my own career, and a someone who loves teaching, it’s something I wanted to try and express in my own words and share.

\n\n

I always welcome feedback. You can use the “Hit Me Up” (HMU) link on my own site, DonJones.com.

\n\n

Acknowledgements

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

Part 1: The Short Version

Start here: in just 10 short “chapters,” I’ll walk you through the basic methodology, and give you some great tips for staying efficient and on-track.

\n\n

In Part 2, we’ll dig into some of these a bit more, and provide some broader context and background, but for now let’s focus on the core tenets.

\n\n

How do You Find a Wolf in Siberia?

Siberia is a vast, not-quite-entirely-charted territory. It has an enormous variety of terrains, and in the winter can be quite challenging to exist in. So how do you find one lone wolf in all that space?

\n\n

Simple: you build a wolf-proof fence down the middle of it, and then just figure out, through some kind of test (maybe a Star Trek-style sensor sweep) which side the wolf is on. Once you know, you repeat the process, building a wolf-proof fence down the middle of that side, and figuring out which side the wolf is on. You repeat until you’ve boxed the critter in and can see him with your own eyes. The wolf-proof part is important, because it keeps him boxed in–once you eliminate a chunk of land, yo udon’t need to go back and consider that chunk again.

\n\n\n\n

Now, this isn’t the only troubleshooting approach in the world. There are others. But for me, this is the one that’s the most broadly applicable, and useful, in almost any situation. The “wolf-proof fence” is simply a test that you run, which can eliminate one or more root causes of whatever problem you’re dealing with. In reality, your “fence” might not eliminate exactly half the root causes at once, as the analogy implies, but the goal is to definitively eliminate one or more causes with each test you run.

\n\n

Suppose you have two cars, and one morning, one won’t start. So as a test, you try to start the other car, and it does start. What possible problem causes have you eliminated? None. No realistic ones, anyway. Your first car could still have a variety of problems: it could be out of case, have a dead battery, have a bad wire someplace, or any number of likely causes. But your test didn’t eliminate any of those, and so your test was useless. A waste of time–you didn’t build a wolf-proof fence.

\n\n

That’s the kind of “troubleshooting” I see far too many people engage in, particularly in my field of information technology. They waste effort, sometimes because they simply get flustered and are in a hurry, other times because they don’t actually know anything about the system they’re trying to test. Either way, they try more or less random stuff, or they try stuff that’s worked before without knowing why it worked before. They burn a lot of time, sometimes feel bad about not being able to solve the problem, and perhaps worry about the security of their job.

\n\n

My methodology is simple, and it isn’t unique; it is–perhaps using different words–the same troubleshooting methodology you’ll see taught in plenty of places. But it’s incredibly effective.

\n\n

Understand the symptoms.
Understand the scope.
Replicate the problem.
Divide and conquer.

\n\n

Along the way, you’ll need to avoid some common red herrings, like relying too much on belief and not entirely on facts, conducting inconclusive tests, and changing too many variables at one time. There are some semi-red-herrings, too, like asking, “what changed?” You’ll need to pick up a little “disguised scientific method,” and really train yourself to be consistent and objective. But you can do it.

\n\n

Ready?

\n\n

Before You Start: Be Cool, and Get a Notebook

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

Understand the Symptoms

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

Understand the Scope

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

Replicate the Problem

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

Prerequisite: Know the System

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

Test

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

The Scientific Method and Troubleshooting

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

“What Changed?”

A lot of times–a very lot of times–when something that was working is not not working, folks will ask, “what changed?”

\n\n

“What changed” is not troubleshooting. You are not proposing a theory (other than, “something changed,” which is pretty obvious), and you can’t usually run any tests to tell you what changed. Sometimes, “what changed” can cue some good troubleshooting.

\n\n\n\n

That’s a statement of what changed, but it’s also a valid, testable hypothesis. You may have internally asked yourself “what changed?” but you didn’t actually spend a lot of time trying to answer that question. Instead, you worked through what you knew about the system’s workings, and stated a theory that you can now test.

\n\n

With more complex systems, people can spend more time figuring out “what changed,” and attempting to on-change it, than they might have spent just troubleshooting the actual problem. “What changed” is a shortcut; an alternative to troubleshooting, and when it’s a question quickly answered and quickly resolved, it’s a good shortcut. But it’s still not troubleshooting; it’s an alternate way of solving the problem. On the plus side, it often requires less knowledge of how the problem system actually works, which is a reason I suspect people kind of default to “what changed” in the first place: they don’t know enough about how the system works to actually troubleshoot it, and so the “what changed” shortcut becomes their primary mechanism for resolving the problem.

\n\n

I don’t mean to come off as being anti-“what changed.” I’m not. It can be a useful mechanism, especially–again–when it’s a true shortcut that’s quickly answered and quickly resolved. I just want you to recognize that being able to answer “what changed?” does not make you a good troubleshooter, and troubleshooting is the more valuable skill. Here’s why: sometimes, “what changed” was something intentional. Yes, it make have broken something, but simply “undoing” the change isn’t an option. In those cases, the shortcut isn’t as useful for solving the problem. Troubleshooting still would be.

\n\n

Control Your Variables

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

Part 2: The Dozen Parts of a Troubleshooting Mind

In this Part, we’ll go into more depth, with more examples, and more ways of mentally approaching troubleshooting. The idea is to get you to a place where you’re always in that logical, scientific mental space, making you a more effective troubleshooter whenever the need arises.

\n\n

I’ve noticed, and you probably have to, that some people just seem to have a brain built for troubleshooting. They don’t. They’ve built a brain for troubleshooting by focusing on a dozen key characteristics, and you can do the same thing. Their brains automatically divide and conquer using wolf-proof fences, and you can train your own mind to do the same.

\n\n

Bear in mind that this Part isn’t meant to be procedural; the procedure is still the one you read about in Part 1. This Part is a more nuanced look at portions of that procedure, with an eye toward making you more effective over the long-haul. Becoming a better troubleshooter is going to take some time, so this Part will also offer some advice about where to best spend that time.

\n\n

As a note to my Agile Leanpub readers, I’m very much still playing with this section. I’d expect a lot of “churn” in the following chapters, and I certainly welcome your feedback via the “Email the Author” link on the book’s Leanpub home page, or use the “HMU” link on DonJones.com.

\n\n

00. Eschews Belief; Hungers for Facts

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

01. Is Proactive: Has a Knowledge Base

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

02. Knows the Symptoms in Depth

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

03. Knows its Tools

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

04. Knows When “Wrong” is Right

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

05. Knows that “Know the System” Doesn’t Mean Expertise

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

06. Can Follow the Chain

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

07. States Better Theories

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

08. Brainstorms the Problem Domain

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

09. Can Troubleshoot Stuff That’s Not Totally Broke

Some of the most frustrating things to troubleshoot are the things that aren’t actually broken, but just aren’t “acting right.” This is especially true when complex systems have some kind of bottleneck, or weak point, that is causing the poor behavior. In these cases, many less-experienced troubleshooters will just start grasping at straws, attempting to change every possible thing they can to see if anything “helps.” This isn’t a good approach, and it can often lead to making the problem worse, or creating all-new problems.

\n\n

Start by stating a theory: “My car is fine at low speeds, but the engine starts to make odd noises when I speed up. I think the fuel line may not be delivering enough fuel for faster speeds.” It’s important that your theory state either a possible cause, or at least a condition you can monitor. In this case, the theory is that the fuel line is not supplying enough fuel.

\n\n

Next, try to make the theoretical problem worse. So, in this example, you might carefully and professionally try to make the car go even faster, while obviously obeying all laws and being absolutely safe. If going faster makes the problem worse, then you may be on to something. It still might not be the fuel line, but you’ve at least confirmed that the problem is speed-related. You’ve built something of a wolf-proof fence; you know that whatever the problem is, it’s related to the speed of the car. Ergo, any system that doesn’t really change as the car gets faster, like the radio, is no longer suspect.

\n\n

You do need to be careful, because it’s easy to “make things worse” and actually make multiple things worse. That doesn’t help narrow things down. For example, “my computer is behaving slowly, and I think I might be out of memory.” Removing some memory will “make the problem worse,” but that’s always going to be the case. You may have simply introduced a whole new problem that’s unrelated to the one you set out to solve. So before you “press down” on some situation to try and “make it worse,” make sure you understand all the potential outcomes of what you’re about to do.

\n\n

10. Seeks Commonalities

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

11. Is Calm; Projects Calm

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

Part 3: Storytime

\n\n

POP! The Weasley Outlet

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

It’s What You Project

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

The Non-Leaky Hose

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

The Leaky Network Server

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

The Water Heater

This is a good story of troubleshooting a system you know nothing about.

\n\n

I have a cabin up near the Dixie National Forest in Utah. Like many homes, it’s got a hot water heater. Like many cabins in the area, this one’s hot water heater was old. Like, probably 12 years. The water in the area is iron-rich to say the least, and even with filters, it puts a lot of wear on a water heater. And also like many cabins in the area, we shut it down entirely for the winter (I hate snow), meaning we cut off the water supply, open low-level cold and hot water drains, and so on. We try to empty as much water as possible to avoid a burst pipe. Because the electricity is a little iffy in the winter, and because the water heater is electric, we shut off and drain as much water as possible from it as part of shutdown.

\n\n

And then Spring arrives! We make our first trip to the cabin, close the low-level drains (or have our own private Bellagio fountain show), close the water heater drain valve, and open the main water supply. We bleed the air from the lines throughout the cabin by opening each faucet until the water runs steady. I then cut the water heater’s circuit breaker back on, and we go about our opening procedures.

\n\n

An hour or so later… no hot water. Huh. Well, that’s not totally unusual. We’d discovered in a previous year that each of the two heater elements had its own little plastic circuit breaker pop-button thing, so I trundled to the basement to pop ‘em back in. No sizzling noise, like you could usually faintly hear as the heaters kicked in. An hour later, no hot water.

\n\n

Uh oh. This was on top of a caved-in skylight, by the way, so we were really sweating our chances. And I know zip about hot water heater repair. But, I mean, how hard can it be? It’s electricity going to a couple of things that’re pretty much what you’d have on an electric stove, right?

\n\n

So I downloaded the thing’s manual, which had a section on troubleshooting. First step, check the breaker. Done. Second step, check the voltage on the elements using a multimeter. Easy. 220v all the way. Third step, shut the circuit breaker off and check the resistance across the element, using the same multimeter. Infinite resistance–the element was burned out.

\n\n

This is not, apparently, an unusual problem, because Home Depot sells a Hot Water Heater Repair Kit containing two new elements and a thermostat. While Loving Spouse drives down the mountain to buy one, I start re-draining the heater, after shutting off its water inlet valve on top. When the new Kit arrives, we unscrew the old water heater element and

\n\n\n\n

the water was gushing out at us! “Holy

\n\n\n\n

, get a bucket!” I’d just drained the damn thing, where was all this water coming from? Well, it was sure draining fast now through the 2” hole in the side where the element used to go. Oh, and the element didn’t come out. Not all of it. What came out was a 2” long stub, while the ones in the new Kit were like 8” long. The stub was all corroded. Hmm.

\n\n

So we did the bucket brigade until the water got below the level of the hole. Now, at this point, you have to do some logical thinking.

\n\n

If the top element was corroded, odds are the bottom one is, too. This must be why the Kit comes with two of them.
If this tank is still full of water, then the drain valve in the bottom is probably clogged with goo and corroded metal parts, so it never really drained.
We need a new water heater.
We can’t get a new heater now, and it’s nighttime, and we need a shower. A hot one, this time, with less cussing.

\n\n

Buckets at the ready, we removed the lower element. This one was bad, but not as bad; I’m guessing the bottom one only comes on if the water is really cold and you’re using it fast, kind of as a backup to the top one. More bucket-ing. Install two new elements. Open water inlet valve

\n\n\n\n

just tighten the elements down!!!” Okay, no leaks. Now, at this point, again, some logic:

\n\n

Water is coming in the top.
Water should flow naturally to the bottom, because gravity.
Top is full with air with nowhere to go, which is going to compress as the water enters.
At some point, the compressed air may be strong enough to prevent new water from coming in. I know our water pressure is about 50psi, and it doesn’t take much to get air to 50psi.
If I turn this thing back on and both elements aren’t underwater, they may explode or something. It can’t be good.
I need to let the air out the top.

\n\n

I don’t know these things, but I strongly suspect them, and logic would suggest that I’m right. Now maybe the air isn’t ever going to get to 50psi or so and stop the water from coming in, but it feels risky.

\n\n

Flashlight in hand, I poke around the top of the heater until I see what is very obviously a pressure-release valve. That is, it’s a valve, and it’s on the top of the tank. It’s not there for good looks. I open it, and air commences rushing out. Water is going to soon follow it; I get a bucket ready. Sure enough, water starts spurting out. I close the valve. The heater is full of water. Circuit breaker on… and success. I hear The Sizzle, and a bit later we enjoy a nice shower.

\n\n

And a couple of days later, we replace the heater. This time, we get an old pool cleaning host and a big funnel to catch the water and route it to the basement drain, because removing the elements is the only way to get enough water out to lift the damn thing off its base.

\n\n

The point here is that I’d never done this before. I still don’t know a lot about the inner workings of a water heater, although I’m imagining now that they’re less magical than I’d suspected. I got a manual, followed some basic steps, watched a YouTube video on using the multimeter to take the measurements, and figured it out. I also learned a good bit about caring for the new water heater so that this doesn’t happen again. I stuck with logic. I followed a procedure. I thought about why I was doing these things, and used those facts to draw conclusions. That’s the Troubleshooting Mind. Even wet.

\n\n

Electrifying!

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

Spoiled

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

What Could it Be?

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/troubleshooting.

\n\n\n

In Closing

Well, that’s it. Hopefully, you’ve now got some confidence that you can troubleshoot like a pro–even if you’re not one. It just takes some patience, and above all else, a solid commitment to a methodology.

\n\n

Good luck!

\n\n

\n\n","tocStructure",[276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312],{"_79":73,"_43":70,"_71":-5,"_74":75,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":70,"_71":-5,"_74":75,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":85,"_71":-5,"_74":86,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":73,"_43":89,"_71":-5,"_74":90,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":93,"_71":-5,"_74":94,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":97,"_71":-5,"_74":98,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":101,"_71":-5,"_74":102,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":105,"_71":-5,"_74":106,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":109,"_71":-5,"_74":110,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":113,"_71":-5,"_74":114,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":117,"_71":-5,"_74":118,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":121,"_71":-5,"_74":122,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":125,"_71":-5,"_74":126,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":129,"_71":-5,"_74":130,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":73,"_43":133,"_71":-5,"_74":134,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":137,"_71":-5,"_74":138,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":141,"_71":-5,"_74":142,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":145,"_71":-5,"_74":146,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":149,"_71":-5,"_74":150,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":153,"_71":-5,"_74":154,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":157,"_71":-5,"_74":158,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":161,"_71":-5,"_74":162,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":165,"_71":-5,"_74":166,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":169,"_71":-5,"_74":170,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":173,"_71":-5,"_74":174,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":177,"_71":-5,"_74":178,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":181,"_71":-5,"_74":182,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":73,"_43":185,"_71":-5,"_74":186,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":189,"_71":-5,"_74":190,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":193,"_71":-5,"_74":194,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":197,"_71":-5,"_74":198,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":201,"_71":-5,"_74":202,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":205,"_71":-5,"_74":206,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":209,"_71":-5,"_74":210,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":213,"_71":-5,"_74":214,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":217,"_71":-5,"_74":218,"_72":73,"_227":-5,"_228":-5,"_83":-5},{"_79":80,"_43":221,"_71":-5,"_74":222,"_72":73,"_227":-5,"_228":-5,"_83":-5},"publicChapterContent","nextChapter","sections",[304,305,306,307,308,309,310,311,312],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

Part 3: Storytime

Table of Contents

Introduction

Acknowledgements

Part 1: The Short Version

How do You Find a Wolf in Siberia?

Before You Start: Be Cool, and Get a Notebook

Understand the Symptoms

Understand the Scope

Replicate the Problem

Prerequisite: Know the System

Test

The Scientific Method and Troubleshooting

“What Changed?”

Control Your Variables

Part 2: The Dozen Parts of a Troubleshooting Mind

00. Eschews Belief; Hungers for Facts

01. Is Proactive: Has a Knowledge Base

02. Knows the Symptoms in Depth

03. Knows its Tools

04. Knows When “Wrong” is Right

05. Knows that “Know the System” Doesn’t Mean Expertise

06. Can Follow the Chain

07. States Better Theories

08. Brainstorms the Problem Domain

09. Can Troubleshoot Stuff That’s Not Totally Broke

10. Seeks Commonalities

11. Is Calm; Projects Calm

Part 3: Storytime

POP! The Weasley Outlet

It’s What You Project

The Non-Leaky Hose

The Leaky Network Server

The Water Heater

Electrifying!

Spoiled

What Could it Be?

In Closing