Если Вы Собираетесь Задать Вопрос

Эта статья будет из категории «вареное».

Наверное, у каждого инженера в какой-то момент наступает момент, когда его уровень позволяет ему не только решать технические задачи, но и отвечать на вопросы других людей.

Кто-то работает в технической поддержке, и это его обязанность, кто-то становится мудрым учителем, а кто-то – невезучим воплощением Матери Терезы, вынужденным постоянно отвечать на самые разные вопросы.

Есть идеальные спрашивающие.

Они формируют очень точные, ясные вопросы, на которые приятно отвечать.

Но в принципе ситуация очень плачевная.

Мне бы хотелось, чтобы эту статью прочитали и зеленоглазые ребята с горящими глазами, которые собираются стать суперсетевиками, и специалисты, предполагающие, что у респондента есть телепатические способности, и зрелые инженеры с повышенным пульсом, отвечающие односложными фразами, полагая, что все совершенно очевидно.

Как инженеру TAC поставщика, мне приходится обрабатывать несколько обращений от клиентов в день.

И как у автора серии статей в сетях, у меня в контактах много людей, которые очень хотят все знать, но всегда что-то мешает разобраться.

Поэтому разных прецедентов было предостаточно.

Основные проблемы, конечно, можно классифицировать, разбить по типам и т. д., но позвольте мне изложить их в свободном стиле.



Основная проблема для всех – это формулировка вопроса

Вот несколько примеров:
«Собрал лабораторию для актерского состава мультфильма — но что-то не получается.

Можете ли вы сказать мне, почему это может бытьЭ»

«Невозможно установить канал связи между контроллером RNC и базовой станцией через цепочку MAN».

Оба вопроса звучат вполне безобидно.

Но если вдуматься, содержащаяся в них информация практически бесполезна, особенно если учесть, что дополнительных пояснений нет. Но существуют десятки возможных причин обеих проблем.

Если общение происходит через IM или по телефону, человек начинает путано объяснять на пальцах, что он имел в виду.

Если кому-то просто нужен мой совет, я обычно прошу собраться с мыслями и сформулировать четкий, ясный вопрос, прислать конфигурацию, логи, возможно, отладочную информацию и схему сети.

Если это клиент с некритическим случаем, вам придется написать шаблонное письмо и подтвердить звонком.

А потом жди ответа.

В общем, на все это уходит очень много времени, как моего, так и спрашивающего.

Как правильно задать вопрос (не универсальный вариант, но хороший пример для начала):

Имеем следующую схему: _________________ Я хочу реализовать следующий функционал: ______________ При попытке настройки оборудования возникает следующая проблема: _____________ Вот конфигурация: _________________ Вот журналы на момент аварии: _______________
Или:
Имеем следующую схему: ___________ Мы пользуемся следующими услугами: ____________ 29 февраля маршрутизатор A потерял соединение BGP со своим соседом B (и другие симптомы).

Точное время: ______________ Что вы делали до, что вы делали после: _______________ Вот журналы на момент аварии и за неделю до: ____________

Вы можете даже не осознавать, насколько это облегчит жизнь инженеру.

Ему достаточно связаться с вами, уточнить пару деталей, чтобы быть полностью уверенным, и все: начинать поиск ответа.

Конечно, есть исключения

«Слушай, в моей сети есть вопрос на миллион долларов, давай обсудим его сегодня вечером? У меня есть бутылка коньяка».

«В ночь на 15 февраля на челябинском ринге MEN произошло нечто неизвестное.

Вот логи, конфигурация, схема сети.

Помогите мне разобраться, пожалуйста»

Ну и разумеется, вы сами должны четко понимать, о чем хотите спросить или хотя бы проблему, которую решаете.

Не должно быть так:

«Здравствуйте.

Настройка IPSec на HP. Ничего не могу понять.

Не могли бы вы объяснить, что такое IP-адресЭ»



Сетевые диаграммы

«Линия (локальная сеть) выходит на коммутатор HP 2026 (48).

Кабель идет от коммутатора напрямую к маршрутизатору MSR 20-21 в Ethernet0/0. Я подключился таким образом, чтобы проверить? При такой конфигурации роутер видит только одну сеть, в которой он находится.

Я не знаю, как просто оформить на это отпуск.

Это, я думаю, решило бы проблему того, что другие сети его не видят. И вообще.

»

Друзья, коллеги, как можно так формулировать мысли? Не нужно пытаться описать схему сети словами – лучше один раз увидеть, чем сто раз услышать.

В противном случае на первой итерации я запросю более подробную схему и конфигурацию, и мне пришлют конфигурацию с комментарием: «Я вам все написал в предыдущем письме».

На второй итерации я спрошу через какие интерфейсы подключаются устройства, какая там адресация и т.д. И количество таких итераций зависит от настойчивости инициатора.

В какой-то момент недовольство друг другом вырастет до размеров священной горы Фудзи.

Ну кому это нужно? Не нужно присылать схемы, нарисованные в Paint, даже если они достаточно подробные:

Если вы собираетесь задать вопрос

Все есть и даже понятно, видно, что человек старался, но зачем это делать? Если у вас нет MS Visio, используйте бесплатную версию.

Например, Dia отлично подходит для рисования сетевых диаграмм.

Вот пример хорошей и понятной диаграммы (Visio):

Если вы собираетесь задать вопрос



Диагностические файлы

Создавайте данные для анализа рациональным и структурированным образом.

Сначала, в зависимости от проблемы, подготовьте следующие данные:

  1. Подробное описание с указанием симптомов и времени происшествия.

  2. Подробная схема сети
  3. Конфигурация всех затронутых устройств
  4. Журналы за необходимый период
Во-вторых, файлы должны быть названы в соответствии с их значением.

Если их много, то создайте структуру папок.

Например:

Если вы собираетесь задать вопрос

Размер журналов и диагностических файлов часто составляет несколько мегабайт. Пожалуйста, запакуйте их в архивы - это текстовые файлы, и они сжаты на порядки.



Не злоупотребляйте отзывчивостью

После серии статей о сетях ко мне бросилось много людей с вопросами.

И я сам испытал на себе недостатки щедрости.

Поначалу мне даже было приятно им отвечать, максимально подробно описывать принципы и свои ошибки, чтобы ребята развивались глубже, а не воспринимали все поверхностно.

Но молот ударил в другую сторону.

Оказывается, многим лень заглядывать в Яндекс или xgu, чтобы найти ответ на элементарный вопрос — проще задать его тому, кто знает наверняка.

Или зачем рыться в документации, собирать тестовые лаборатории в GNS, чтобы разобраться, как работает технология, если можно спросить у кого-то другого? А когда одни и те же вопросы задаются много раз, это начинает надоедать.

Все это касается как меня лично, так и моей работы в техподдержке.

Хотя TAC решает только технические проблемы, инженеров часто спрашивают, как работает та или иная технология.

Сейчас на многие вопросы отвечаю очень кратко, а то и просто ссылкой, потому что понимаю две вещи: меня на всех не хватит, и самый эффективный способ обучения – это самообучение.

Верхом наглости можно считать следующие фразы от людей, которые не являются друзьями, а вы им просто ответили на 3-4 вопроса:

«Здравствуйте.

Срочно нужна помощь.

Сейчас включу просмотр команды».

Для работы в ТП другой пример — задать тысячу других вопросов в рамках одного вопроса, часто связанного с протоколами, а не с оборудованием.



Крайности

Если совсем зеленые люди могут боготворить и думать, что старший коллега знает абсолютно все, то старшие иногда впадают в другую крайность, полагая, что общаются с дураком, который ничего не знает и не может их понять.

На самом деле, с клиентами, как правило, очень приятно работать.

Обычно они имеют сочетание всего 1-2 факторов.

Но как раз парни, которые хотят учиться, знать больше, обычно обладают абсолютно всеми этими качествами и еще некоторыми, которые не описаны.

Я, конечно, понимаю желание не слишком утомлять вас своими вопросами, но поверьте, вы точно не облегчите задачу.

Есть и универсальный совет: попробуйте написать свой вопрос в письме и приступайте к его решению, подробно описывая шаги.

Так вы либо найдете ответ на него, либо поймете вопрос глубже.

Мои будущие и нынешние коллеги в общении будьте корректны, последовательны и логичны.

Сэкономим время и нервы.

*Несмотря на то, что некоторые примеры взяты из реальной жизни, просим считать все совпадения случайными.

P.S. Маленький мультфильм об этой теме.

Теги: #Сетевые технологии #техподдержка #вопросы #инженер #телеком

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.