Discussion on:
View:
Show:
When it comes to networking and hardware dramas, I usually employ the OSI 7 Layer Model. I start off at Layer 1, check that there is power and things are physically connected. Then I go to Layer 2 and make sure that NIC / switch lights are on etc, then Layer 3 where I check IP address, default gateway, sub mask, next hop etc. Then carry on until I'm up at the application itself.
Do you really do that? Or are you just saying that. I don't think going from the bottom upwards is the most efficient way. For instance, responding to a call where internet isn't working. Check the NIC lights first, because it's the quickest, then check the internet browser, check for other network connectivity. Then perhaps do an ipconfig /all.
That's what I would do in the real world, using the OSI layers is slow and painful.
That's what I would do in the real world, using the OSI layers is slow and painful.
on the situation.
With wisdom comes the ability to apply the best approach to each situation.
With experience and knowledge comes the ability to know the solution before the question is asked.
And if you're really good, you've put systems in place that don't break so often, and there's redundancy so every little fire is not a three-alarm-blaze.
With wisdom comes the ability to apply the best approach to each situation.
With experience and knowledge comes the ability to know the solution before the question is asked.
And if you're really good, you've put systems in place that don't break so often, and there's redundancy so every little fire is not a three-alarm-blaze.
---Quote: robo_dev----
"With wisdom comes the ability to apply the best approach to each situation.
With experience and knowledge comes the ability to know the solution before the question is asked.
And if you're really good, you've put systems in place that don't break so often, and there's redundancy so every little fire is not a three-alarm-blaze."
----end quote----
Do so many people have such little sense of humour that this gets top rated comment? Cmon people, lighten up.
"With wisdom comes the ability to apply the best approach to each situation.
With experience and knowledge comes the ability to know the solution before the question is asked.
And if you're really good, you've put systems in place that don't break so often, and there's redundancy so every little fire is not a three-alarm-blaze."
----end quote----
Do so many people have such little sense of humour that this gets top rated comment? Cmon people, lighten up.
That every response in this string of threads needs to be composed and read with humor being an integral part of the thought. But it would be wrong to presuppose that everyone's sense of humor is equal in expression or appreciation and thereby ensuring an equal validity of their technical arguments. I like robo_dev's entry. It's common-sensical. Doing things right ensures that you have more times to go out and party like a madman (or sit and watch a movie with the spouse and kids) while the yobbos in our profession are back in the office putting out three-alarm-blazes because they lacked the foresight or wisdom to shepherd their systems properly.
You have a problem that happens once or twice a month, say it's a major software component crashing because of running out of memory. Do you ...
a) spend weeks producing trace after trace after log after dump to convince the vendor / developer it IS a problem, or
b) schedule a regular reboot, to make sure the symptom doesn't occur again (especially during month-end) ?
a) spend weeks producing trace after trace after log after dump to convince the vendor / developer it IS a problem, or
b) schedule a regular reboot, to make sure the symptom doesn't occur again (especially during month-end) ?
I worked with a vendor whose application would regularly crash a server due to memroy leaks.
The quick fix: once a week, showing up at the office at 2am, rebooting the server, then going home.
The business fix: recommending we didn't pay the annual "maintenance" fee on the application. The support we received was next to useless anyway and we never received bug fixes, so what was the point?
The real fix: finding the problem in the vendors code, giving it to them, and sleeping like a baby.
The quick fix: once a week, showing up at the office at 2am, rebooting the server, then going home.
The business fix: recommending we didn't pay the annual "maintenance" fee on the application. The support we received was next to useless anyway and we never received bug fixes, so what was the point?
The real fix: finding the problem in the vendors code, giving it to them, and sleeping like a baby.
Since there was no resolution, from your perspective, a reboot was the only viable option. A scheduled task to reboot at 2am once a week would have been a simple fix in your circumstance.
I resorted to method (b) on a Win2k3 server that suffered repeated memory leaks. Having tried several fixes, the regular reboot has proved a drastic but effective solution. I'd like to know the cause, but what I like even more is systems that dont crash.
A regularly scheduled reboot saves money and produces the desired result. I might schedule down time, clone the system and run it on independent hardware in order to duplicate and demonstrate the issue to developers concurrently. In the end, keeping the organization running is going to be top priority.
like this first you have to identify it....
So I see very little value in this article..
Most of your real world approaches are the fumblings of incompetents, which almost certainly indicates where many of the probelms we have originate...
So I see very little value in this article..
Most of your real world approaches are the fumblings of incompetents, which almost certainly indicates where many of the probelms we have originate...
It is blatantly obvious that this article was intended as a joke. In fact, after reading through the first few comments, I'm beginning to think I'm the last IT guy (software developer, actually) with a sense of humor.
The solutions presented are jokes, and when asking for solutions in the comments he was asking for more jokes. Am I seriously the only one who can see this?
The solutions presented are jokes, and when asking for solutions in the comments he was asking for more jokes. Am I seriously the only one who can see this?
I was beginning to think either I was the only one who saw this as a joke and was laughing or was this suppose to be a serious article. I love the article laughed thru the whole thing. People have got to remember "Life is too short, you just got to laugh once in a while and not take everything so seriously"
Sure it's humor but I am not too surprised that some are responding seriously because people really do employ these approaches to solving problems.
I had a good long laugh over this one, and so did my son, who's not a bad IT kid in his own right. I do know a few other IT folks who would enjoy this instead of debate it to kingdom come. Seems like a few people here had too much of the business school/large corporation koolaid.
It is blatantly obvious that this is a joke. Some people either don't have a sense of humor, or they recently learned text-book troubleshooting methods, and want to let everyone know it.
People need to lighten up, or they will always be smashing their head against the monitor (method 1 iirc).
People need to lighten up, or they will always be smashing their head against the monitor (method 1 iirc).
No you're not, I literally laughed out loud reading this, I even sent the link to all my IT buddies!
Brilliant article, though. Thanks for the comic relief, Jack. Now where's my hammer? I've got a Sharepoint server waiting for me in my office...
Brilliant article, though. Thanks for the comic relief, Jack. Now where's my hammer? I've got a Sharepoint server waiting for me in my office...
I'm with GUMM and FRAMEY... start with simple, obvious solutions and then work your way up in complexity/time/money as needed.
There is no one approach that can be used when it comes to problem solving.
Outside of the ACTUAL problem and trying to figure it out, I think experience is key. When I say experience, I mean business experience. And by that I mean, knowing the environment that your working in. For instance, you have an application that won't connect to a SQL database that it is supposed to. Someone who is new will go through all the steps necessary to identify the problem, and also try to learn how the various "bits" fit together. Where as using your peers to accelerate the resolution (IE someone who has been around the block a couple of times) may tell you in two seconds flat that the database was moved recently and the logins for that DB were not sychronised. In that one scenario, your aware of the problem, what potentially caused it, what the impact is to the business owner, and would have a general idea on what is required to fix the problem. Not only that, its a fast forward way to learn the environment you are supporting.
Having said that.. its wise to pay attention to the bleedingly obvious, as well as launching into the complex problem solving path
Outside of the ACTUAL problem and trying to figure it out, I think experience is key. When I say experience, I mean business experience. And by that I mean, knowing the environment that your working in. For instance, you have an application that won't connect to a SQL database that it is supposed to. Someone who is new will go through all the steps necessary to identify the problem, and also try to learn how the various "bits" fit together. Where as using your peers to accelerate the resolution (IE someone who has been around the block a couple of times) may tell you in two seconds flat that the database was moved recently and the logins for that DB were not sychronised. In that one scenario, your aware of the problem, what potentially caused it, what the impact is to the business owner, and would have a general idea on what is required to fix the problem. Not only that, its a fast forward way to learn the environment you are supporting.
Having said that.. its wise to pay attention to the bleedingly obvious, as well as launching into the complex problem solving path
There are countless times I have been in a situation where a program, server, workstation, whatever, is not working properly...and at first glance the problem may appear to be a HUGE problem. Certainly the customer thinks the symptoms are HUGE, but I am talking about the actual problem itself causing the symptoms.
So now we deploy #3 and set up the virtual white board in our mind and think of all the possibilities under the sun what could be the problem...Then scap all that and think of the most simplest, dumbest, idiotic problem (and answer) and 9 out of 10 times that fits the bill.
I think I'll base all future tips on the British comedy The IT Crowd. "Have you tried turning it off and on again?"
So now we deploy #3 and set up the virtual white board in our mind and think of all the possibilities under the sun what could be the problem...Then scap all that and think of the most simplest, dumbest, idiotic problem (and answer) and 9 out of 10 times that fits the bill.
I think I'll base all future tips on the British comedy The IT Crowd. "Have you tried turning it off and on again?"
All "methods" described speak volumes on lack of knowledge and experience of the so-called IT Pro - The Sheldon Cooper Labyrinth being the closest thing to a real method. The description of the Sheldon Cooper Labyrinth makes a mockery of an academic approach that sadly shows the inability of the author and greater part of the industry to understand the value of applying a structured approach.
Sad day for South Africa if a person deemed to be an "IT Pro" considers, no, embraces the "methods" described in this article.
Sad day for South Africa if a person deemed to be an "IT Pro" considers, no, embraces the "methods" described in this article.
For crying out loud, it's a joke people! Are you guys all so stressed out that you fail to see this?
Mr. Wallen (who, I can tell you by having read a preponderance of his other articles, is NOT "unable to understand the value of applying a structured approach") has written a light-hearted article about various approaches to IT problem-solving. Most are familiar in the 'real world'; and individual case circumstances would generally dictate which, if any, of the above approaches was used. My question to you is: Why do you prefer to interpret his REFERRING to them as "*embracing* the 'methods' described in this article."? His descriptions of #s 3 and 8, for example, summarized each as 'not effective'. That's an 'embrace' to you?! And one that calls for a frank reassessment of South Africa's self-image?!
Hahahahahahahaha!
This was a blog soliciting IT war-stories (general or specific)---did you read the last paragraph? Your comment's gratuitious, mean-spirited hyperbole (brought in behind your BS rationale that he '*embraces* the methods...' by humorously referring to them) indicates what an epic troll you must be.
Cute title, though.
Hahahahahahahaha!
This was a blog soliciting IT war-stories (general or specific)---did you read the last paragraph? Your comment's gratuitious, mean-spirited hyperbole (brought in behind your BS rationale that he '*embraces* the methods...' by humorously referring to them) indicates what an epic troll you must be.
Cute title, though.
I cannot say I totally disagree with your response to the "Oscar the Grouch", but ouch! Can't we all just get along? Lol
Many times, a little careful thought about the problem, a whole lot of googling, support forum hunting, etc. is worth every second spent on it.
Learn from other's mistakes! Let others be the guinea pigs!
Learn from other's mistakes! Let others be the guinea pigs!
Why bother to hire me, an IT professional with 20 years experience and a list of certifications the length of my arm, when some random forum or blog post will "solve" your problem.
God save me from the customers and employers who will trust some random posting on the Internet.
I have a VERY short list of websites and blogs that I'll trust to provide me with answers. Then I'll research the answer provided.
God save me from the customers and employers who will trust some random posting on the Internet.
I have a VERY short list of websites and blogs that I'll trust to provide me with answers. Then I'll research the answer provided.
Seeing as this is "mostly" tongue in check...
You left out my number one "threat" when IT provided equipment fails to "Enable" me to do my job expeditiously...
The Fire Axe and/or Sledge Hammer...
You left out my number one "threat" when IT provided equipment fails to "Enable" me to do my job expeditiously...
The Fire Axe and/or Sledge Hammer...
Can we make a poll for which "tool" IT pros would favour for the job?
I vote sledge hammer - there's nothing more satisfying than the conclusive crunch of finality. Problem solved...
I vote sledge hammer - there's nothing more satisfying than the conclusive crunch of finality. Problem solved...
I cast a vote for the Dremel Moto-Tool....because I'm going to 'interrogate' it first. Muahahahahaha!
Thermite, (that was fun in the USMC)
Excavator (Punch some holes in it, then run over it with the tracks)
Humvee (If you don't have the others, it will have to do...)
Excavator (Punch some holes in it, then run over it with the tracks)
Humvee (If you don't have the others, it will have to do...)
Finally, someone sees the humor in this... My faith in the IT community's sense of humor has been restored.
Seems to me, #1 and #5 are the closest things to the Sledge hammer approach, (with #5 the absolute closest! It could safely be renamed the Sledge Hammer approach!)
Many years ago I had a system that was horrible to work with. For one particular issue, I listed 4 fixes in order of most likely to fix the problem. Fix #4 was listed as "Lift sledgehammer, and forcifully apply to server. Repeat until problem goes away."
It was a joke to relieve the stress of managing a bad system, but it became the code for systems that could not be saved. Server dying? Apply fix #4. Problem solved.
It was a joke to relieve the stress of managing a bad system, but it became the code for systems that could not be saved. Server dying? Apply fix #4. Problem solved.
I prefer to "dispose" of the client. No complaints after that...
-insert evil laugh-
-insert evil laugh-
... should allow Jack's number 1 solution (the Headbutt) to fix it. No need for fire axe or sledge hammer then.
Back in the day... when we all used CRT monitors, I had one which just would not reliably power on... until I mounted a small hammer over it. From that day onward, until it was disposed of, the monitor worked like a champ.
This is the honest truth... It's called the perversity of inanimate objects...
This is the honest truth... It's called the perversity of inanimate objects...
Of course the tongue was in the cheek while the fingers typed; lighten up, people.
My first task, when I can get away with it, is to clear the room of people who aren't going to help me solve the problem - which, to be brutal, means users and bosses. The user standing over you (understandably) in a panic because (s)he can't work needs to relate exactly what happened, then leave me in peace to employ roughly a combination of 2, 3 and 6.
My first task, when I can get away with it, is to clear the room of people who aren't going to help me solve the problem - which, to be brutal, means users and bosses. The user standing over you (understandably) in a panic because (s)he can't work needs to relate exactly what happened, then leave me in peace to employ roughly a combination of 2, 3 and 6.
As a Network Specialist, I am fully in favor of the above mentioned Layer-7 OSI troubleshooting approach. First, the lower layers are most often very quickly eliminated as problem source (or instead, are so obvious because a malfunction at those layers have a general impact). They need only trivial investigations (like ping etc). Narrowing-down the problem area while moving upwards through the OSI layers can often be achieved by comparing different applicatons flowing between the same client-server locations. When having confined the problem to the uppermost, application layer, I then pass control to the application and/or server team. In short,the above mentioned 10 approaches are not really of value in a network troubleshooting case, especially not if you need to restore the failing connections while the CIO is at your back;
Obviously the Author never worked in a service department.
Simple checks often work the best.
Check if the network cable hasn't been removed if the user has no internet.
Check if the power cable hasn't been unplugged by an eager beaver cleaner.
Have the user reboot the computer ( at least 5 minutes of thinking time gained )
Of course if that all fails revert to option 1
Server problems are in a different league
Simple checks often work the best.
Check if the network cable hasn't been removed if the user has no internet.
Check if the power cable hasn't been unplugged by an eager beaver cleaner.
Have the user reboot the computer ( at least 5 minutes of thinking time gained
)Of course if that all fails revert to option 1
Server problems are in a different league
I understand this is a little tongue in cheek, but us old IT pros find problems by intuition based on long experience.
I have solved many problems that my younger counterparts have given up on. Often to me the answer just leaps out, I have no idea where from. When I achieve that I punch the air and shout "Yes, the old man has still got it"
I have solved many problems that my younger counterparts have given up on. Often to me the answer just leaps out, I have no idea where from. When I achieve that I punch the air and shout "Yes, the old man has still got it"
This article is very amusing, since I've used nuances of ALL the methods at different times, on different systems. BUT... missing is... the DEJA VU EFFECT, which the previous poster has experienced! After many years dealing with the essential truth of "Anything can happen, at any time, for any reason, with any result", I began to see that every support issue looks... like one I figured out before! ...yes, the answer "just leaps out" of the cavernous, cluttered storage area in my brain that keeps all that schmaa... one time, training on a new job, I helped the system veteran solve an Exchange issue - figuring out why the OWA logins were requesting a domain name to be entered at login. I dredged up a similar config answer from my Novell networking background and we solved the issue with a strategically placed forward-slash... It happens so often it's just another "tool" in the "toolbox". Hoarding can be positive, in IT!
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
