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

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

История Игоря, VoIP-инженера

Игорь работает в департаменте Ops чуть больше года. Он стал одним из первых наших менти, когда эта идея только-только появилась. В первую очередь Игорь занимается задачами по VoIP, во вторую — остальными задачами команды. 

Как узнал о работе с ментором

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

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

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

Про прошлый опыт и чего не хватало

Мой бэкграунд — это 15 лет админства. Начинал с техподдержки, а потом ушёл занимался серверами, инфраструктурой и телефонией. 

В последней моей компании на телефонию было завязано вообще всё, потому что сфера деятельности была связана с продажами. В целом там использовались те же самые технологии, что мы сейчас используем у себя: FreeSWITCH, SIP-телефоны и GSM-шлюзы. В Quadcode всё реализовано немного по-другому и на больших масштабах, но необходимая база у меня была. 

При этом мой прошлый опыт в основном связан с Windows. Здесь мы его не используем: всё работает на Linux. Я давно хотел получить полноценный опыт работы с этой ОС. В прошлом я уже использовал её, но есть большая разница между тем, когда у тебя 5 стабильных Linux-машин, и 2500 серверов, с которыми постоянно что-то происходит. 

Соответственно, поддержка ментора мне требовалась в основном по двум направлениям:

1. Разобраться, как устроена работа с телефонией конкретно в этой компании.

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

Про задачи для обучения

Первоначально мне нужно было выучить часть, отвечающую за телефонию. Цели на конец испытательного срока были очень конкретными:

1. Перетащить телефонию в Docker-контейнер.

2. Перетащить Int-часть телефонии на новый хостер. Int — это мини-копия прода, в этой среде мы проводим интеграционное тестирование и верификацию перед публикацией релиза. Нужно было получить новый хостер, настроить его, перетащить туда контейнеры и убедиться, что всё работает. 

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

Дальше мне предстояло заниматься задачами более широкого опсового спектра. При планировании спринта все в команде сами выбирают, что брать в работу. Разумеется, у задач есть приоритеты, и важно в первую очередь закрывать наиболее критичные, но других ограничений нет. И никаких отдельных задач «для новичков» тоже нет. Так что с менторской помощью я занимался тем же, что и остальные, вот примеры:

• Создать новый хост с базой PostgreSQL.

• Собрать образ KeyDB с регистрацией в Сonsul.

• Миграция микросервиса с LXC в OpenStack.

• Обновление PostgreSQL до последней возможной версии.

• Дежурство: выдать доступы, принять/принести MR в балансиры, добавить место на сервере, убить зависший запрос в базе и т. д.

Как был устроен процесс, и чем помогали менторы

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

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

Пример того, что мы обсуждали с менторами: 

• Я делаю задачу, но моя конфигурация не работает, помоги разобраться.

• Помоги с Consul, я пока не понимаю, что сделал не так. И почему он не настроен везде.

• В какой канал в Slack написать, чтобы согласовать перезагрузку сервера данного микросервиса.

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

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

Менторство — это и про технологии и то, как у нас всё устроено. В основном менторы помогали со следующими вещами:

1. Проверяли, что я не делаю бесполезную работу или не свернул совсем не туда. 

2. Отвечали на технические вопросы и подсказывали, что почитать и куда посмотреть. Обычно это была личная помощь или ссылки на внутреннюю документацию — в ней есть ответы на многие вопросы, но «со стороны» найти нужную статью бывает сложно. 

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

Про результаты

Первые три месяца я вместе с ментором разбирался с телефонией, следующие три — с другими задачами. По итогу на седьмой месяц работы я закрывал 95% задач самостоятельно и обращался к команде только по точечным вопросам. Как мне кажется, это и есть главный результат: ты можешь полноценно выполнять свои задачи, не дёргая коллег. 

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

История Наиля, Linux-администратора

Наиль присоединился к команде в сентябре 2022 года и сейчас проходит испытательный срок. До Quadcode он уже работал системным администратором в двух компаниях.

Как узнал о работе с ментором

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

На интервью меня спрашивали, какие задачи я раньше выполнял, какие нет, с чем работал, а с чем — нет. В дальнейшем это помогло нам понять, где нужно расширять знания. Вопросы в основном были общего плана. Например, какими командами можно посмотреть нагрузку на сервере, свободную память и что в целом делать, если на сервере возникла проблема. Или какие модули Ansible я использовал и как в нём можно использовать ad-hoc команды. 

Как устроен процесс, и чем помогает ментор

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

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

После выбора задачи: 

1. Мы созванивались с ментором и обсуждали её. Ментор рекомендовал, что можно посмотреть или почитать, а я задавал вопросы, если они появлялись сразу.

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

Запланированных регулярных встреч в первое время у нас не было: появилась задача — созвонились, появились большие вопросы — созвонились. Если вопросы были небольшими, то мы обсуждали их в чате. 

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

Приведу пару примеров моих первых задач:

• Перенести приложение c bare metal сервера в OpenStack. 

• Покрыть хосты секьюрити-компонентами.

• Разобраться, почему некоторые записи не падают в graylog. 

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

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

Недавно у меня появился конкретный список задач, которые желательно закрыть в ближайшие три месяца. Под него мы договорились о регулярных встречах два раза в неделю для health check. Встречаемся утром по вторникам и пятницам, чтобы отслеживать прогресс, и чтобы я мог задать объёмные вопросы. Регулярные встречи также помогают понять, если я что-то делаю не так: сам я могу это не заметить или не знать. Если вдруг появляется срочный и конкретный вопрос, мы по-прежнему обсуждаем его на отдельном звонке, либо в чате. 

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

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

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

Промежуточные выводы

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

Мне кажется, что важно иметь человека, который помогает с онбордингом. Поначалу ты не знаком с командой: не знаешь, что принято, а что нет. Когда есть ментор, гораздо проще вливаться, потому что у тебя есть проводник. Гораздо проще пойти к нему, чем отвлекать всех. А постепенно начинаешь общаться со всеми коллегами и самостоятельно закрывать задачи.