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

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

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

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

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

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

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



Вот пара примеров:
“Я собрал лабу для мульткаста – но что-то не работает. Не подскажешь, почему такое может быть?”

“Не удаётся организовать канал связи между контроллером RNC и базовой станцией через четь MAN”.

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

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


Либо:
Имеем следующую схему: ___________
Используем такие сервисы: ____________
29 февраля маршрутизатор А потерял связность по BGP со своим соседом В (и прочие симптомы)
Точное время: ______________
Что делали до, что делали после: _______________
Вот логи на момент аварии и за неделю до: ____________


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

Конечно, есть и исключения
“Слушай, по моей сетке есть вопрос на миллион, давай вечером обсудим? С меня бутылочка коньяка”

“В ночь на 15 февраля случилось неведомое нечто на челябинском MEN-кольце. Вот логи, конфигурация, схема сети. Помогите разобраться, пожалуйста”

Ну и стоит ли говорить, что вы должны сами чётко понимать, что вы хотите спросить или хотя бы задачу, которую вы решаете.
Не должно быть такого:
“Здравствуйте. Настраиваю IPSec на HP. Ничего не могу понять. Не могли бы вы объяснить что такое IP-адрес?”


Схемы сети


“Линия (локальная сеть) идет в HP switch 2026 (48). От свича идет кабель прямо в роутер MSR 20-21 в Ethernet0/0. Так ли соединил я для проверки? При такой конфигурауии роутер видит только одна сеть в которой он находится. Не знаю как элементарно прописать гетевэй для него. Это я думаю решило бы проблемму что другие сети его не видят. И вообще. ”

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

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



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

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

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



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


Формируйте данные для анализа рационально и структурировано.
Во-первых, в зависимости от проблемы подготовьте следующие данные:
  1. Подробное описание с симптомами и временем происшествия
  2. Подробную схему сети
  3. Конфигурацию всех затронутых устройств
  4. Логи за нужный период

Во-вторых, файлы нужно именовать сообразно их смыслу. Если их много, то создать структуру папок. Например:



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

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


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

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

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

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

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

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

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

Крайности


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

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

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

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

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

P.S. Небольшой шарж на эту тему.
Теги:телекомытехподдержкаинженервопросы
Хабы: Сетевые технологии
+40
29,5k 98
Комментарии 105

Похожие публикации

Профессия Инженер по тестированию
18 марта 202160 000 ₽Яндекс.Практикум
Факультет DevOps
4 марта 2021270 000 ₽GeekBrains
Системный администратор
4 марта 202170 000 ₽GeekBrains
Тестировщик ПО
4 марта 202136 000 ₽GeekBrains

Лучшие публикации за сутки