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

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

Идеальные вопрошающие бывают. Они формируют очень точные чёткие вопросы, на которые приятно отвечать.

Но в основном ситуация весьма плачевная. Я бы хотел, чтобы эту статью прочитали и зелёные ребята с горящими глазами, которые собираются стать супер-сетевиками, и спецы, предполагающие наличие телепатических возможностей у ответчика, и зрелые инженеры с повышенным ЧСВ, которые отвечают односложными фразами, считая, что всё совершенно очевидно.

Как инженеру TAC вендора, мне приходится перемалывать по несколько кейсов от заказчиков в день. А как у автора цикла статей по сетям у меня появилось в контактах много людей, которым очень хочется всё знать, но постоянно что-то мешает разобраться. Поэтому различных прецедентов было с лихвой.

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

Оба вопроса звучат вполне безобидно. Но если вдуматься, то информацию в себе они несут практически бесполезную, особенно учитывая, что никаких дополнительных пояснений нет. Зато есть десятки возможных причин для обеих проблем. Если общение идёт в IM или по телефону, человек начинает путанно объяснять на пальцах, что он имел ввиду. Если кому-то просто нужен мой совет, я обычно прошу собраться с мыслями и сформулировать чёткий ясный вопрос, выслать конфигурацию, логи, возможно, отладочную информацию и схему сети. Если это заказчик с некритическим кейсом, приходится писать шаблонное письмо и подтверждать звонком. А потом ждать ответа.

В общем на всё на это тратится масса времени, как моего, так и вопрошающего. Как правильно задать вопрос (не универсальный вариант, но хороший пример для начала):

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

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

Друзья, коллеги, как можно так формулировать мысли? Не нужно пытаться описать схему сети словами – лучше один раз увидеть, чем сто раз услышать. Иначе на первой итерации я запрошу более подробную схему и конфигурацию, а мне пришлют конфигурацию с комментарием: “я же вам в предыдущем письме всё написал”. На второй итерации я спрошу через какие интерфейсы подключены устройства, какая адресация там-то и там-то и т.д. И количество таких итераций зависит от упорства инициатора. В какой-то момент недовольство друг другом вырастет до размеров священной горы Фудзи. Ну и кому оно нужно?

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

Всё есть и даже понятно, видно, что человек старался, но зачем так?

Если у вас нет MS Visio, воспользуйтесь бесплатным аналогом. Например, Dia прекрасно подходит для рисования схем сети.

Вот пример хорошей, понятной схемы (Visio):

1. Подробное описание с симптомами и временем происшествия
2. Подробную схему сети
3. Конфигурацию всех затронутых устройств
4. Логи за нужный период

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

После цикла статей про сети очень много людей бросились ко мне с вопросами. И я на себе испытал недостатки от щедрот. Сначала мне даже было приятно отвечать на них, описывать, как можно подробнее принципы и их ошибки, чтобы ребята развивались в глубину, а не хватали всё поверхностно. Но молоток ударил в другую сторону. Оказывается, что многим людям лень заглянуть в яндекс или на xgu, чтобы найти ответ на элементарный вопрос – проще же задать его тому, кто точно знает.

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

Да и когда одни и те же вопросы задаются по много раз, это начинает надоедать.

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

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

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

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

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

На самом деле с заказчиками в основном вполне приятно работать. Обычно у них встречается сочетание только 1-2 факторов. А вот просто ребята, которые хотят учиться, больше знать, обычно обладают абсолютно всеми этими качествами и ещё частью неописанных. Я, конечно, понимаю — это желание не особо напрягать своими вопросами, но поверьте, задачу этим легче вы точно не делаете.

А ещё есть универсальный совет: попробуйте написать свой вопрос в письме и начать его решать, описывая подробно шаги. Так вы либо найдёте ответ на него, либо поймёте глубже вопрос.

Будущие и настоящие мои коллеги, общаясь, будьте корректны, последовательны и логичны. Давайте экономить время и нервы.

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