If you are going to ask a question
This article will be from the category of "boiling."
Probably, every engineer once comes such a moment when his level allows not only to solve technical problems, but also to answer questions from other people.
Someone works in technical support, and this is his duty, someone becomes a wise teacher, and someone is an unfortunate incarnation of Mother Teresa, who has to constantly answer a variety of questions.
There are ideal questioners. They form very precise, clear questions that are pleasant to answer.
But basically the situation is very deplorable.
I would like this article to be read by both green guys with burning eyes who are going to become super-networkers, and specialists suggesting telepathic capabilities of the respondent, and mature engineers with elevated CDs who respond with monosyllabic phrases, believing that everything is completely obvious .
')
As a TAC vendor engineer, I have to grind several cases from customers per day. And as the author of a series of articles on networks, I had a lot of contacts in my contacts who really want to know everything, but constantly something prevents me from understanding. Therefore, there were various precedents with interest.
The main problems, of course, can be categorized, broken down by type, etc., but let me set them loosely.
Here are a couple of examples:
Both questions sound quite harmless. But if you think about it, the information in themselves they are almost useless, especially considering that there is no additional explanation. But there are dozens of possible reasons for both problems.
If the conversation goes on IM or by phone, the person begins to explain in his own confused words on his fingers what he meant.
If someone just needs my advice, I usually ask you to collect your thoughts and formulate a clear question, send the configuration, logs, possibly debugging information and a network diagram.
If this is a customer with a non-critical case, you have to write a template letter and confirm with a call. And then wait for an answer.
In general, all this is spent on a mass of time, both mine and questioner.
How to ask a question correctly (not a universal option, but a good example to start with):
Or:
You can not even imagine how much it will simplify the life of an engineer. He will only have to contact you, clarify a couple of details for complete confidence and that's all: start searching 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 task that you are solving.
There should not be such:
Friends, colleagues, how can you formulate thoughts like this?
No need to try to describe the scheme of the network with words - it is better to see once than hear a hundred times. Otherwise, at the first iteration I will request a more detailed scheme and configuration, and I will be sent 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 is there and there, etc.
And the number of such iterations depends on the persistence of the initiator. At some point, dissatisfaction with each other will grow to the size of the sacred mountain of Fuji. Well, who needs it?
You do not need to send diagrams drawn in the paint, even if they are quite detailed:
Everything is, and even is clear, it is clear that the person tried, but why so?
If you do not have MS Visio, use the free analog. For example, Dia is great for drawing network diagrams.
Here is an example of a good, clear scheme (Visio):
Generate data for analysis rationally and structured.
First, depending on the problem, prepare the following data:
Secondly, the files must be named according to their meaning. If a lot of them, then create a folder structure. For example:
Logs and diagnostic files are often several megabytes in size. Please pack them into archives - these are text files and they are shrinking by orders of magnitude.
After a series of articles about the network, a lot of people rushed to me with questions. And I myself have experienced the disadvantages of the bounty.
At first, I was even pleased to answer them, to describe how the principles and their mistakes were as detailed as possible, so that the guys would go deeper and not grasp 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 rummaging through documentation, collecting test labs in GNS, to figure out how technology works, if you can ask someone else?
And when the same questions are asked many times, it becomes annoying.
All this applies both to me personally and to the work in technical support. Despite the fact that TAC solves only technical problems, engineers often ask 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 to learn is self-study.
You can regard phrases of the next plan from people who are not friends as the height of arrogance, and you simply answered 3-4 questions to them:
To work in a TP, another example is to ask a thousand other questions, often related to protocols, rather than equipment, within one question.
If the completely green ones can idolize and think that the older colleague knows absolutely everything, the aksakals sometimes go to the other extreme, believing that they are talking to a fool who knows nothing and cannot understand them.
In fact, it’s 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 more to know, usually have absolutely all of these qualities and still some undescribed. Of course, I understand - this desire is not to strain your questions, but believe me, you definitely don’t do this task easier.
And there is also universal advice: try to write your question in a letter and start solving it, describing in detail the steps. So you either find the answer to it, or understand the deeper question.
My future and present 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 matches as random.
PS A little cartoon on this topic.
Probably, every engineer once comes such a moment when his level allows not only to solve technical problems, but also to answer questions from other people.
Someone works in technical support, and this is his duty, someone becomes a wise teacher, and someone is an unfortunate incarnation of Mother Teresa, who has to constantly answer a variety of questions.
There are ideal questioners. They form very precise, clear questions that are pleasant to answer.
But basically the situation is very deplorable.
I would like this article to be read by both green guys with burning eyes who are going to become super-networkers, and specialists suggesting telepathic capabilities of the respondent, and mature engineers with elevated CDs who respond with monosyllabic phrases, believing that everything is completely obvious .
')
As a TAC vendor engineer, I have to grind several cases from customers per day. And as the author of a series of articles on networks, I had a lot of contacts in my contacts who really want to know everything, but constantly something prevents me from understanding. Therefore, there were various precedents with interest.
The main problems, of course, can be categorized, broken down by type, etc., but let me set them loosely.
The main problem for everyone is the question wording.
Here are a couple of examples:
“I collected a lab for cartoon art - but something is not working. Can you tell me why this could be? ”
“It is not possible to organize a communication channel between the RNC and the base station via MAN MAN”.
Both questions sound quite harmless. But if you think about it, the information in themselves they are almost useless, especially considering that there is no additional explanation. But there are dozens of possible reasons for both problems.
If the conversation goes on IM or by phone, the person begins to explain in his own confused words on his fingers what he meant.
If someone just needs my advice, I usually ask you to collect your thoughts and formulate a clear question, send the configuration, logs, possibly debugging information and a network diagram.
If this is a customer with a non-critical case, you have to write a template letter and confirm with a call. And then wait for an answer.
In general, all this is spent on a mass of time, both mine and questioner.
How to ask a question correctly (not a universal option, but a good example to start with):
We have the following scheme: _________________
I want to implement the following functionality: ______________
When you try to configure the equipment, the following problem occurs: _____________
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: ____________
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 can not even imagine how much it will simplify the life of an engineer. He will only have to contact you, clarify a couple of details for complete confidence and that's all: start searching for an answer.
Of course there are exceptions.
“Listen, I have a million question on my grid, let's discuss it in the evening? With me a bottle of brandy ”
“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 task that you are solving.
There should not be such:
"Hello. I configure IPSec on HP. I can not 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, the cable goes straight to the MSR 20-21 router on Ethernet0 / 0. Did I connect to check? With this configuration, the router sees only one network in which it is located. I do not know how to prescribe an elementary gethevey for him. I think this would solve the problem that other networks do not see it. And generally speaking. "
Friends, colleagues, how can you formulate thoughts like this?
No need to try to describe the scheme of the network with words - it is better to see once than hear a hundred times. Otherwise, at the first iteration I will request a more detailed scheme and configuration, and I will be sent 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 is there and there, etc.
And the number of such iterations depends on the persistence of the initiator. At some point, dissatisfaction with each other will grow to the size of the sacred mountain of Fuji. Well, who needs it?
You do not need to send diagrams drawn in the paint, even if they are quite detailed:
Everything is, and even is clear, it is clear that the person tried, but why so?
If you do not have MS Visio, use the free analog. For example, Dia is great for drawing network diagrams.
Here is an example of a good, clear scheme (Visio):
Diagnostic files
Generate data for analysis rationally and structured.
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 required period
Secondly, the files must be named according to their meaning. If a lot of them, then create a folder structure. For example:
Logs and diagnostic files are often several megabytes in size. Please pack them into archives - these are text files and they are shrinking by orders of magnitude.
Do not abuse the responsiveness
After a series of articles about the network, a lot of people rushed to me with questions. And I myself have experienced the disadvantages of the bounty.
At first, I was even pleased to answer them, to describe how the principles and their mistakes were as detailed as possible, so that the guys would go deeper and not grasp 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 rummaging through documentation, collecting test labs in GNS, to figure out how technology works, if you can ask someone else?
And when the same questions are asked many times, it becomes annoying.
All this applies both to me personally and to the work in technical support. Despite the fact that TAC solves only technical problems, engineers often ask 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 to learn is self-study.
You can regard phrases of the next plan from people who are not friends as the height of arrogance, and you simply answered 3-4 questions to them:
"Hello. Urgently need help. Now I will turn on the timviewer. ”
To work in a TP, another example is to ask a thousand other questions, often related to protocols, rather than equipment, within one question.
Extremes
If the completely green ones can idolize and think that the older colleague knows absolutely everything, the aksakals sometimes go to the other extreme, believing that they are talking to a fool who knows nothing and cannot understand them.
In fact, it’s 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 more to know, usually have absolutely all of these qualities and still some undescribed. Of course, I understand - this desire is not to strain your questions, but believe me, you definitely don’t do this task easier.
And there is also universal advice: try to write your question in a letter and start solving it, describing in detail the steps. So you either find the answer to it, or understand the deeper question.
My future and present 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 matches as random.
PS A little cartoon on this topic.
Source: https://habr.com/ru/post/173469/
All Articles