gitinsky

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

В джуны DevOps приходят из интернов, с соседних проектов (с аналогичной позиции, на которой что-то не сложилось) или со смежных направлений, когда человек занимался, например тестированием, разработкой или системной аналитикой, но осознанно идет на понижение, чтобы попасть на другую должность. Другой вариант — сисадмин какой-то компании, где со временем написали некий сервис и ему пришлось пощупать его изнутри.

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

Каких джунов мы ищем

Общаясь с потенциальным коллегой, я всегда смотрю не столько на технические знания, сколько на софт скиллы и способность принять нашу культуру. Важна готовность решать проблемы и правильный подход к ним. А еще базовое знание Linux (можно даже без остальных инструментов DevOps).

Желание справляться с трудностями

Мне нравятся люди, которые еще на этапе собеседования высказывают готовность решать проблемы. Особенность нашей работы такова, что на проекте придется чаще всего оставаться с этими проблемами один на один. Готов ли человек к этому?

На мой взгляд, если джун придет и скажет: “У меня не получилось”, то получит удивленный взгляд. Если ты джун, изучи проблему, собери кейсы, построй теорию (а может и не одну) и с этим уже иди к старшим коллегам, чтобы узнать, куда копать дальше. Это шанс продемонстрировать активность в решении проблемы. И если человек делает так, ему хочется помочь. Мы любим именно таких джунов — они быстро растут и развиваются.

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

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

Готовность к переработкам

Да, говорят, что переработки — это плохо — ненормированный график, нарушение баланса работы и личной жизни и т.п. Но это лишь часть картины. Зато мы можем себе позволить работать всего несколько часов в день, используя в том числе и рабочее время для выполнения каких-то личных дел. Например, могу сходить в МФЦ в обед. Если в этот момент не было инцидента, никаких вопросов.

Умение диагностировать проблемы

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

В последнее время на рынке труда много специалистов после курсов DevOps. Но на 99% все курсы, которые сейчас есть в интернете, построены вокруг изучения только лишь базовых инструментов — как собирать Docker или настраивать CI/CD. Там не дают фундаментальных знаний о том, как, допустим, дебажить проблемы в ОС Linux (вероятно, курсы предполагают, что эти знания у кандидатов уже есть).

На мой взгляд, без разницы, знаешь ты конкретный инструмент или нет. Когда нужно, инструмент можно выучить буквально за неделю: посмотрел видеоурок, поэкспериментировал на домашнем стенде. Но если ты не можешь пользоваться базовым набором подходов в ОС Linux, ты просто не справишься с задачей. Будешь бегать и трясти всех вокруг в поисках помощи, требуя выдать четкую инструкцию, как действовать. Такой джун в команде не нужен.

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

Путь обучения

При таком отборе обучение сводится к тому, чтобы “набить руку” на решении клиентских проблем. У нас в компании есть определенный набор инструментов — всего позиций 20. Когда, ковыряясь в проектах, джун проходит весь этот инструментарий хотя бы один раз — поработает со всем, что нужно большому проекту под ключ — это заявка на мидла.

Что это за инструменты:

• бекапы

• мониторинг

• логирование

• аллерты

• disaster recovery

• CI/CD

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

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

Залог успеха этого процесса — правильный руководитель и грамотная организация команд.

Навыки руководителя

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

Как правило, самое главное препятствие — это неумение ставить цели. Постановка цели по SMART (Specific — конкретная; Measurable — измеримая; Achievable — достижимая; Relevant — значимая; Time bound — ограниченная во времени) — вроде бы элементарная везде распиаренная штука, но многие не умеют ей пользоваться — не обозначают конечный результат, когда распределяют задачи.

Например, я прошу мидла сделать задачку уровня тимлида — расписать решение проблемы. Он пишет: “Сделать то-то, сделать то-то”. Все здорово, но как я принесу это бизнесу? В чем для него ценность? После обсуждения выясняется, что в результате выполнения всех пунктов будет работать метрика, указывающая, что сервис сбоит. И это действительно ценность — вот, что надо было писать с самого начала. Но перевернуть мышление в эту парадигму, научить технаря говорить на языке результатов, что по сути равно языку бизнес менеджеров, очень сложно. Так что тимлиды, которые умеют с джунами говорить на техническом языке, а с бизнесом — на бизнесовом, которые умеют декомпозировать сложные задачи на простые шаги и понимают, кто из ребят сможет с ними справиться, — на вес золота.

Есть четыре уровня делегирования:

• Первый — когда человек готов работать только по подробной инструкции. Если подобный подход выявляется на собеседовании или испытательном сроке, мы расстаемся с таким человеком. Увы, такие джуны быстро не вырастут. А еще хуже, когда такие качества проявляются у руководителя.

• Второй — когда он может работать по частично доступной информации (додумать или найти источник информации, где то в конфигурации, у команды разработки, недостающие участки и просто погуглить и решить задачу).

• Третий — когда можно сообщить о проблемном месте, а он может сам найти источник проблемы, сформулировать способы решения. По сути это снова про навыки диагностики проблем. Это кунг-фу необходимо тимлиду.

• Четвертый — когда ты просто указываешь специалисту проблемную область, даже особо не вникая, что сломано. Это самый сложный уровень. Искать и выявлять проблемы. Люди, которые им владеют, очень быстро вырастают до позиции технических директоров.

Здесь я вспомнил об этих уровнях скорее в контексте руководителей. Для работы с джунами (да и в целом для работы в нашей компании) нужно быть хотя бы на третьем. Только так можно вычленять из общего потока кандидатов джунов с навыками диагностики проблем и нагружать их соответствующими задачами.

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

Организация команд

Тандемы

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

Идею тандемов я подсмотрел очень давно — еще в начале нулевых — в какой-то книжке.  Забавно, что знания из той книги пригодились спустя столько времени. Позже я столкнулся с этими идеями в книге по менеджменту “Это так не работает”. Там это называлось “микрокоманды”. Была высказана мысль, что даже если у тебя есть команда из условно 10 человек, в ней все равно лучше выделить микрокоманды, и они будут работать эффективнее. Либо так или иначе они образуются сами.

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

На собеседовании я смотрю на специалиста и сразу стараюсь понять, кто мог бы быть у него в паре. Т.е. это речь не столько о “подойдет по стеку или нет” (понятно, что человек должен пройти по хардам для текущего проекта), сколько о комплексном видении и хард, и софт скиллов. Причем, я не обязательно подбираю джуна под сениора или ищу, чтобы сениор больше общался с клиентом, показывая пример джуну. Вполне возможна ситуация, когда за счет прокачанных софт скиллов джун, слабый в техничке, и с клиентом договорится, и к коллегам сходит, чтобы ему подсказали грамотное решение. Суть именно в комплексном взгляде. Важно, чтобы тандем — эдакий паззл внутри коллектива — собрался и заработал.

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

Самостоятельность во главе угла

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

Тут важна инициативность в деталях, вплоть до того, что коллегам стоит понимать, как планировать ночные работы и согласовывать их с клиентом (даже если коллеги — чистые технари). Если у клиента принято просто написать в Telegram — это один разговор. Если же надо обязательно подготовить обращение к ответственному лицу и собрать аппрувы — другой. Надо пройти правильным путем, и главное, чтобы я не контролировал эти процессы.

Чтобы был шанс отпустить ситуацию, я объясняю, как сделать правильно, и фигурально выражаясь, “отворачиваюсь”. Если в итоге я вижу, что задача выполнена — хорошо. Моя цель, как тимлида, достигнута. Но так происходит не всегда, чаще инженер совершает ошибки так или иначе. Главный секрет при постановке задачи всегда объяснять преследуемые цели и критерии “когда мы считаем что задача готова, что должно быть готово” используя метод SMART .

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

В целом у нас в коллективе довольно простая атмосфера. На это во многом влияет личная харизма, и я стараюсь это поддерживать. Младшие всегда могут прийти к старшим, да и я выступаю эдаким играющим тренером и равными правами по отношению к остальным участникам коллектива. Мотивировать всех участников к инициативе. Т.е. нет проблем с тем, чтобы сократить количество грабель, на которые наступать. И со временем количество ошибок действительно уменьшается В среднем инженеры уходят в эдакое “самостоятельное плавание” примерно через 4-8 месяцев после начала работы. С этого момента их уже можно почти не контролировать, лишь иногда задавать правильные вопросы. Например, инженер приносит мне план разобрать старый кластер баз данных у клиента. А я спрашиваю, а где план отката и когда ты будешь делать бекапы? Если это не было заложено изначально, инженер идет и переделывает план. Так последовательными итерациями мы приходим к полностью самостоятельному решению.

Джуны всем нужны

Опыт показывает, что джуны — это не так страшно, если уметь их правильно отбирать и готовить. При нормально построенном наставничестве джун до сениора может вырасти за 5 лет. Google считает, что на этот процесс уходит чуть больше — порядка 6-8 лет (корпорация привязывается к циклу жизни продукта и считает, что специалист до уровня сениор должен прожить весь этот цикл в одной или нескольких компаниях).

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

История этой фотографии: в 2020 году набрал команду ребят в коллективе. И был один парень, который «я же джун, у меня не получается, нужно чтобы мне кто‑то помог с задачей».

Подумал, как же отучить от такого. Сходил в большой садоводческий магазин и купил 2 драцены. Принес в офис, поставил и подписал стикеры «джун Федя» и «джун Витя».

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

P. S. Ни одна драцена и ни один джун не пострадали.

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

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

“Подъем по тревоге” ночью или в выходные происходит не часто (один-два раза в месяц). Только если отваливается проект, по которому ответственный я, или кто-то из инженеров моей группы, который не смог принять вызов.

Как и у многих хостинговых компаний на рынке, у нас сложилась “многоярусная” система реагирования на проблемы с инфраструктурой. Первый уровень - это младшие дежурные, которые сидят посменно: по 12 часов в режиме 24/7. Когда-то и я начинал с такого, но в другой компании.

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

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

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

10:00. Утренний скрам

Штатный подъем — тремя часами позже. Умываюсь и иду на дейлик в 10:00 по Москве, где мы отчитываемся о наших задачах. Как правило, по задачам у нас две встречи: ровно в десять мы отчитываемся, что делали вчера — в данном случае в пятницу, что произошло за выходные, что будем делать сегодня и в какой последовательности.

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

Стараемся быть предельно краткими — ничего не обсуждаем, просто ставим приоритеты и синхронизируем статусы. В общей сложности на опрос 20 с лишним человек уходит 18-20 минут.

10:20. Разбор полетов

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

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

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

Чаще всего, кстати, при приемке срабатывает проверка “на дурака” - что в задаче действительно выполнены все пункты, именно так, как просил клиент, а не как додумал DevOps-инженер. В анализе задач всегда приходится включать здравый смысл. В нашей сфере задача вполне может быть решена (допустим, попросили добавить какой-то флаг PHP — ты добавил), а проблема клиента — нет. Это частая история. Иногда даже приходится применять решение, противоречащее best practice, потому что именно оно, а не что-то другое, решает задачу клиента.

11:00. Архитектурный созвон

Расходимся мы около 11 часов. После этого по понедельникам я созваниваюсь с архитекторами — это 3-4 человека по всей команде. Зачастую присутствуют и проджекты, которые ведут данные проекты.

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

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

12:30. Анализ логов

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

Скорее всего роль сыграли изменения от разработки клиента. Моя задача: описать случившееся и отчитаться об общем даунтайме, если он был. Сегодня инцидент имел место, но система просто перешла в режим деградации, на продукте это никак не сказалось. Готовый отчет я направляю разработчику, который ведет проект со стороны клиента, а также прикладываю к задаче в нашем таск-трекере (в зависимости от того, каким инструментом пользуется клиент).

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

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

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

14:00. Ворох задач

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

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

В своей работе мы в основном опираемся на подход инфраструктура как код (Iaac). Основные инструменты — Ansible и Terraform, так что 80% времени мы работаем с заготовками Ansible. У нас есть копилка плейбуков для Ansible, которые модифицируются всеми командами. Это общий котел с заготовками, откуда мы периодически вынимаем и добавляем нужное. Но вопросы в чате все равно возникают часто.

Иногда дело доходит и до собеседований. Как именно я собеседую — на что и почему смотрю — я расскажу отдельно. Это довольно обширная тема.

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

19:00. Вечер трудного дня

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

Кажется, что мой график не нормирован. Но на самом деле это только одна сторона медали. Вторая сторона, что я могу работать всего 4 часа за день. У нас свободное отношение к присутствию на рабочем месте (если не случился инцидент, конечно). Надо жену в магазин отвезти посреди дня — пожалуйста. В МФЦ документы подать — тоже без проблем.

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

Вне дома я люблю слушать аудиокниги. В последнее время мне нравится "боярка". Порой книги настолько увлекают, что я даже пытаюсь растянуть дорогу на машине, чтобы послушать подольше. Сейчас слушаю “Идеальный мир для лекаря”.

Вечером, уже дома, могу посмотреть кино с женой или сажусь за свой пет-проект. Просто изучать технологии мне уже не так неинтересно, а под конкретную задачу — вполне. В рамках пет-проекта я собираю опенсорсный сервис мониторинга — эдакий “швейцарский нож” девопсов. Пытаюсь найти для него кирпичики: смотрю чужие проекты и сервисы, экспериментирую с ними. Там бывают интересные задачки — можно случайно залипнуть и “очнуться” в 3 часа ночи, понимая, что уже как 3 часа ты должен спать =D.

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

Хочу запросить обратную связь у коллег-айтишников. Что интересного у вас в течение дня происходит?