Наверное, у каждого инженера наступает когда-то такой момент, когда его уровень позволяет не только решать технические задачи, но и отвечать на вопросы других людей.
Кто-то работает в тех.поддержке, и это его обязанность, кто-то становится мудрым учителем, а кто-то неудачливым воплощением матери Терезы, вынужденным постоянно отвечать на самые разные вопросы.
Идеальные вопрошающие бывают. Они формируют очень точные чёткие вопросы, на которые приятно отвечать.
Но в основном ситуация весьма плачевная.
Я бы хотел, чтобы эту статью прочитали и зелёные ребята с горящими глазами, которые собираются стать супер-сетевиками, и спецы, предполагающие наличие телепатических возможностей у ответчика, и зрелые инженеры с повышенным ЧСВ, которые отвечают односложными фразами, считая, что всё совершенно очевидно.
Как инженеру TAC вендора, мне приходится перемалывать по несколько кейсов от заказчиков в день. А как у автора цикла статей по сетям у меня появилось в контактах много людей, которым очень хочется всё знать, но постоянно что-то мешает разобраться. Поэтому различных прецедентов было с лихвой.
Основные проблемы, конечно, можно категоризировать, разбить по видам и т.д., но позвольте мне в вольном стиле их изложить.
Главная проблема для всех – формулировка вопроса
“Я собрал лабу для мульткаста – но что-то не работает. Не подскажешь, почему такое может быть?”
“Не удаётся организовать канал связи между контроллером RNC и базовой станцией через четь MAN”.
Оба вопроса звучат вполне безобидно. Но если вдуматься, то информацию в себе они несут практически бесполезную, особенно учитывая, что никаких дополнительных пояснений нет. Зато есть десятки возможных причин для обеих проблем.
Если общение идёт в IM или по телефону, человек начинает путанно объяснять на пальцах, что он имел ввиду.
Если кому-то просто нужен мой совет, я обычно прошу собраться с мыслями и сформулировать чёткий ясный вопрос, выслать конфигурацию, логи, возможно, отладочную информацию и схему сети.
Если это заказчик с некритическим кейсом, приходится писать шаблонное письмо и подтверждать звонком. А потом ждать ответа.
В общем на всё на это тратится масса времени, как моего, так и вопрошающего.
Как правильно задать вопрос (не универсальный вариант, но хороший пример для начала):
Имеем такую схему: _________________
Хочу реализовать следующий функционал: ______________
При попытке настроить оборудование возникает вот такая проблема: _____________
Вот конфигурация: _________________
Вот логи на момент аварии: _______________
Либо:
Имеем следующую схему: ___________
Используем такие сервисы: ____________
29 февраля маршрутизатор А потерял связность по BGP со своим соседом В (и прочие симптомы)
Точное время: ______________
Что делали до, что делали после: _______________
Вот логи на момент аварии и за неделю до: ____________
Вы можете даже не представлять, насколько это упростит жизнь инженеру. Ему останется только связаться с вами, уточнить пару деталей для полной уверенности и всё: приступать к поиску ответа.
Конечно, есть и исключения
“Слушай, по моей сетке есть вопрос на миллион, давай вечером обсудим? С меня бутылочка коньяка”
“В ночь на 15 февраля случилось неведомое нечто на челябинском MEN-кольце. Вот логи, конфигурация, схема сети. Помогите разобраться, пожалуйста”
Ну и стоит ли говорить, что вы должны сами чётко понимать, что вы хотите спросить или хотя бы задачу, которую вы решаете.
Не должно быть такого:
“Здравствуйте. Настраиваю IPSec на HP. Ничего не могу понять. Не могли бы вы объяснить что такое IP-адрес?”
Схемы сети
“Линия (локальная сеть) идет в HP switch 2026 (48). От свича идет кабель прямо в роутер MSR 20-21 в Ethernet0/0. Так ли соединил я для проверки? При такой конфигурауии роутер видит только одна сеть в которой он находится. Не знаю как элементарно прописать гетевэй для него. Это я думаю решило бы проблемму что другие сети его не видят. И вообще. ”
Друзья, коллеги, как можно так формулировать мысли?
Не нужно пытаться описать схему сети словами – лучше один раз увидеть, чем сто раз услышать. Иначе на первой итерации я запрошу более подробную схему и конфигурацию, а мне пришлют конфигурацию с комментарием: “я же вам в предыдущем письме всё написал”.
На второй итерации я спрошу через какие интерфейсы подключены устройства, какая адресация там-то и там-то и т.д.
И количество таких итераций зависит от упорства инициатора. В какой-то момент недовольство друг другом вырастет до размеров священной горы Фудзи. Ну и кому оно нужно?
Не нужно присылать схемы рисованные в пэинте, даже если они достаточно подробные:
Всё есть и даже понятно, видно, что человек старался, но зачем так?
Если у вас нет MS Visio, воспользуйтесь бесплатным аналогом. Например, Dia прекрасно подходит для рисования схем сети.
Вот пример хорошей, понятной схемы (Visio):
Диагностические файлы
Формируйте данные для анализа рационально и структурировано.
Во-первых, в зависимости от проблемы подготовьте следующие данные:
- Подробное описание с симптомами и временем происшествия
- Подробную схему сети
- Конфигурацию всех затронутых устройств
- Логи за нужный период
Во-вторых, файлы нужно именовать сообразно их смыслу. Если их много, то создать структуру папок. Например:
Логи и диагностические файлы часто бывают размером в несколько мегабайтов. Пожалуйста, упаковывайте их в архивы – это текстовые файлы, и они ужимаются на порядки.
Не злоупотребляйте отзывчивостью
После цикла статей про сети очень много людей бросились ко мне с вопросами. И я на себе испытал недостатки от щедрот.
Сначала мне даже было приятно отвечать на них, описывать, как можно подробнее принципы и их ошибки, чтобы ребята развивались в глубину, а не хватали всё поверхностно. Но молоток ударил в другую сторону.
Оказывается, что многим людям лень заглянуть в яндекс или на xgu, чтобы найти ответ на элементарный вопрос – проще же задать его тому, кто точно знает.
Или зачем рыться в документации, собирать тестовые лабы в GNS, чтобы разобраться как работает технология, если можно спросить кого-то другого?
Да и когда одни и те же вопросы задаются по много раз, это начинает надоедать.
Всё это касается как меня лично, так и работы в тех.поддержке. Несмотря на то, что TAC решает только технические проблемы, часто инженеров спрашивают, как работает та или иная технология.
Сейчас на многие вопросы я отвечаю очень кратко, или даже просто ссылкой, потому что понимаю две вещи: меня на всех не хватит, и самый результативный способ обучения – самообучение.
Верхом наглости можно считать фразы следующего плана от людей, которые не являются друзьями, а ты просто ответил им на 3-4 вопроса:
“Привет. Срочно нужна помощь. Сейчас тимвьювер включу”.
Для работы в ТП другой пример – в рамках одного вопроса задавать тысячу других вопросов, часто относящихся к протоколам, а не оборудованию.
Крайности
Если совсем зелёные могут боготворить и думать, что более старший коллега знает абсолютно всё, то аксакалы порой ударяются в другую крайность, считая, что общаются с глупцом, который ничего не знает и не может их понять.
На самом деле с заказчиками в основном вполне приятно работать. Обычно у них встречается сочетание только 1-2 факторов.
А вот просто ребята, которые хотят учиться, больше знать, обычно обладают абсолютно всеми этими качествами и ещё частью неописанных. Я, конечно, понимаю — это желание не особо напрягать своими вопросами, но поверьте, задачу этим легче вы точно не делаете.
Будущие и настоящие мои коллеги, общаясь, будьте корректны, последовательны и логичны. Давайте экономить время и нервы.
*Несмотря на то, что некоторые примеры взяты из жизни, прошу считать все совпадения случайными.
P.S. Небольшой шарж на эту тему.
ссылка на оригинал статьи http://habrahabr.ru/post/173469/
Добавить комментарий