March 20, 2013 at 16:26If you are going to ask a question
This article will be “boiling”.
Probably, every engineer once has a moment when his level allows not only solving technical problems, but also answering other people's questions.
Someone works in technical support, and this is his duty, someone becomes a wise teacher, and someone is an unfortunate incarnation of Mother Teresa, forced to constantly answer a variety of questions.
There are ideal questioners. They form very precise clear questions that are nice to answer.
But basically the situation is very deplorable.
I would like this article to be read by green guys with burning eyes, who are going to become super-networkers, and specialists suggesting telepathic opportunities for the defendant, and mature engineers with increased FAQ, who respond with monosyllabic phrases, considering that everything is completely obvious .
As a TAC vendor engineer, I have to grind a few cases from customers per day. And as the author of a series of articles on networks, I got a lot of people in my contacts who really want to know everything, but constantly something prevents me from sorting it out. Therefore, various precedents were more than enough.
The main problems, of course, can be categorized, broken down by type, etc., but let me set them out in a free style.
Here are a couple of examples:
Both questions sound completely harmless. But if you think about it, then the information in themselves is practically useless, especially considering that there are no additional explanations. But there are dozens of possible reasons for both problems.
If the conversation goes in IM or by phone, the person begins to confusely explain on the fingers what he means.
If someone just needs my advice, I usually ask you to collect your thoughts and formulate a clear, clear question, send a configuration, logs, possibly debugging information and a network diagram.
If this is a customer with an uncritical case, you have to write a template letter and confirm with a call. And then wait for an answer.
In general, a lot of time is spent on all this, both mine and the questioner.
How to ask a question (not a universal option, but a good example to start with):
Or:
You may not even realize how much this simplifies the life of an engineer. He will only have to contact you, clarify a couple of details for complete confidence and that’s all: proceed to search for an answer.
Of course, there are exceptions
Well, is it worth saying that you yourself must clearly understand what you want to ask, or at least the problem that you are solving.
It should not be like this:
Friends, colleagues, how can one formulate thoughts in this way?
No need to try to describe the network diagram in words - it is better to see once than hear a hundred times. Otherwise, at the first iteration, I will ask for a more detailed diagram and configuration, and they will send me a configuration with a comment: "I wrote everything to you in the previous letter."
At the second iteration, I will ask through which interfaces the devices are connected, what addressing there and there, etc.
And the number of such iterations depends on the persistence of the initiator. At some point, discontent with each other will grow to the size of the sacred mountain of Fuji. Well, who needs it?
It is not necessary to send the schemes drawn in the paint, even if they are quite detailed:
Everything is there and even it is clear, it is clear that the person tried, but why?
If you do not have MS Visio, use the free equivalent. For example, Dia is great for drawing network diagrams.
Here is an example of a good, clear diagram (Visio):
Generate data for analysis in a rational and structured way.
First, depending on the problem, prepare the following data:
Secondly, files must be named according to their meaning. If there are a lot of them, then create a folder structure. For example:
Logs and diagnostic files are often several megabytes in size. Please pack them in archives - these are text files, and they are compressed by orders of magnitude.
After a series of articles about networks, a lot of people rushed to me with questions. And I experienced the flaws of bounty on myself.
At first, I was even pleased to answer them, to describe, in as much detail as possible, the principles and their mistakes, so that the guys would develop in depth and not grab everything superficially. But the hammer hit the other way.
It turns out that many people are too lazy to look at Yandex or xgu to find the answer to an elementary question - it's easier to ask it to someone who knows for sure.
Or why rummage in the documentation, collect test labs in GNS to figure out how the technology works, if you can ask someone else?
And when the same questions are asked many times, it starts to bother.
All this applies both to me personally and to work in technical support. Despite the fact that TAC solves only technical problems, engineers are often asked how this or that technology works.
Now I answer many questions very briefly, or even simply by reference, because I understand two things: I don’t have enough for everyone, and the most effective way of learning is self-education.
Phrases of the following plan from people who are not friends can be considered the height of arrogance, and you just answered them 3-4 questions:
To work in TP, another example is to ask a thousand other questions within the framework of one question, often related to protocols, and not to equipment.
If the green ones can idolize and think that the older colleague knows absolutely everything, then the elders sometimes go to the other extreme, believing that they communicate with a fool who does not know anything and cannot understand them.
In fact, it is generally quite pleasant to work with customers. Usually they have a combination of only 1-2 factors.
But just the guys who want to learn, know more, usually have absolutely all of these qualities and even a part of those that are not described. Of course, I understand - this desire is not particularly annoying with your questions, but believe me, this is definitely not an easier task for you.
And there is also universal advice: try writing your question in a letter and start solving it, describing the steps in detail. So you will either find the answer to it, or understand the question deeper.
Future and present my colleagues, communicating, be correct, consistent and logical. Let's save time and nerves.
* Despite the fact that some examples are taken from life, please consider all coincidences as random.
PS A small cartoon on this subject.
Probably, every engineer once has a moment when his level allows not only solving technical problems, but also answering other people's questions.
Someone works in technical support, and this is his duty, someone becomes a wise teacher, and someone is an unfortunate incarnation of Mother Teresa, forced to constantly answer a variety of questions.
There are ideal questioners. They form very precise clear questions that are nice to answer.
But basically the situation is very deplorable.
I would like this article to be read by green guys with burning eyes, who are going to become super-networkers, and specialists suggesting telepathic opportunities for the defendant, and mature engineers with increased FAQ, who respond with monosyllabic phrases, considering that everything is completely obvious .
As a TAC vendor engineer, I have to grind a few cases from customers per day. And as the author of a series of articles on networks, I got a lot of people in my contacts who really want to know everything, but constantly something prevents me from sorting it out. Therefore, various precedents were more than enough.
The main problems, of course, can be categorized, broken down by type, etc., but let me set them out in a free style.
The main problem for everyone is the wording of the question
Here are a couple of examples:
“I put together a lab for the multcast - but something is not working. Can you tell me why this can be? ”
“Cannot organize the communication channel between the RNC and the base station through the MAN account.”
Both questions sound completely harmless. But if you think about it, then the information in themselves is practically useless, especially considering that there are no additional explanations. But there are dozens of possible reasons for both problems.
If the conversation goes in IM or by phone, the person begins to confusely explain on the fingers what he means.
If someone just needs my advice, I usually ask you to collect your thoughts and formulate a clear, clear question, send a configuration, logs, possibly debugging information and a network diagram.
If this is a customer with an uncritical case, you have to write a template letter and confirm with a call. And then wait for an answer.
In general, a lot of time is spent on all this, both mine and the questioner.
How to ask a question (not a universal option, but a good example to start with):
We have the following scheme: _________________
I want to implement the following functionality: ______________
When trying to configure the equipment, this problem arises: _____________
Here is the configuration: _________________
Here are the logs at the time of the accident: _______________
Or:
We have the following scheme: ___________ We use the following
services: ____________
On February 29, router A lost BGP connectivity with its neighbor B (and other symptoms)
Exact time: ______________
What did before, what did after: _______________
Here are the logs at the time of the accident and a week before: ____________
You may not even realize how much this simplifies the life of an engineer. He will only have to contact you, clarify a couple of details for complete confidence and that’s all: proceed to search for an answer.
Of course, there are exceptions
“Listen, on my grid there is a million-dollar question, let's discuss in the evening? I have a bottle of cognac ”
“On the night of February 15, something unknown happened on the Chelyabinsk MEN ring. Here are the logs, configuration, network diagram. Please help me. ”
Well, is it worth saying that you yourself must clearly understand what you want to ask, or at least the problem that you are solving.
It should not be like this:
"Hello. I configure IPSec on HP. I can’t understand anything. Could you explain what an IP address is? ”
Network diagrams
“The line (local area network) goes to HP switch 2026 (48). From the switch, a cable goes directly to the MSR 20-21 router in Ethernet0 / 0. So did I connect for verification? With this configuration, the router sees only one network in which it is located. I don’t know how to register gethei for him. This I think would solve the problem that other networks do not see it. And generally speaking. ”
Friends, colleagues, how can one formulate thoughts in this way?
No need to try to describe the network diagram in words - it is better to see once than hear a hundred times. Otherwise, at the first iteration, I will ask for a more detailed diagram and configuration, and they will send me a configuration with a comment: "I wrote everything to you in the previous letter."
At the second iteration, I will ask through which interfaces the devices are connected, what addressing there and there, etc.
And the number of such iterations depends on the persistence of the initiator. At some point, discontent with each other will grow to the size of the sacred mountain of Fuji. Well, who needs it?
It is not necessary to send the schemes drawn in the paint, even if they are quite detailed:
Everything is there and even it is clear, it is clear that the person tried, but why?
If you do not have MS Visio, use the free equivalent. For example, Dia is great for drawing network diagrams.
Here is an example of a good, clear diagram (Visio):
Diagnostic files
Generate data for analysis in a rational and structured way.
First, depending on the problem, prepare the following data:
- Detailed description with symptoms and time of incident
- Detailed network diagram
- Configuration of all affected devices
- Logs for the desired period
Secondly, files must be named according to their meaning. If there are a lot of them, then create a folder structure. For example:
Logs and diagnostic files are often several megabytes in size. Please pack them in archives - these are text files, and they are compressed by orders of magnitude.
Do not abuse responsiveness
After a series of articles about networks, a lot of people rushed to me with questions. And I experienced the flaws of bounty on myself.
At first, I was even pleased to answer them, to describe, in as much detail as possible, the principles and their mistakes, so that the guys would develop in depth and not grab everything superficially. But the hammer hit the other way.
It turns out that many people are too lazy to look at Yandex or xgu to find the answer to an elementary question - it's easier to ask it to someone who knows for sure.
Or why rummage in the documentation, collect test labs in GNS to figure out how the technology works, if you can ask someone else?
And when the same questions are asked many times, it starts to bother.
All this applies both to me personally and to work in technical support. Despite the fact that TAC solves only technical problems, engineers are often asked how this or that technology works.
Now I answer many questions very briefly, or even simply by reference, because I understand two things: I don’t have enough for everyone, and the most effective way of learning is self-education.
Phrases of the following plan from people who are not friends can be considered the height of arrogance, and you just answered them 3-4 questions:
"Hi. Help is urgently needed. I’ll turn on the timber viewer now. ”
To work in TP, another example is to ask a thousand other questions within the framework of one question, often related to protocols, and not to equipment.
Extremes
If the green ones can idolize and think that the older colleague knows absolutely everything, then the elders sometimes go to the other extreme, believing that they communicate with a fool who does not know anything and cannot understand them.
In fact, it is generally quite pleasant to work with customers. Usually they have a combination of only 1-2 factors.
But just the guys who want to learn, know more, usually have absolutely all of these qualities and even a part of those that are not described. Of course, I understand - this desire is not particularly annoying with your questions, but believe me, this is definitely not an easier task for you.
And there is also universal advice: try writing your question in a letter and start solving it, describing the steps in detail. So you will either find the answer to it, or understand the question deeper.
Future and present my colleagues, communicating, be correct, consistent and logical. Let's save time and nerves.
* Despite the fact that some examples are taken from life, please consider all coincidences as random.
PS A small cartoon on this subject.