Кто такой Senior: каковы в действительности критерии соответствия должности?

Вокруг статуса “Senior” в IT-среде ходит много разговоров. И однозначный перечень критерия соответствия должности мало кто может привести с легкостью и даже по запросу. О том, кто же все-таки такой Senior-инженер, мы решили поговорить с DevOps-инженером Владимиром Фролкиным.

– Владимир, расскажите, пожалуйста, как вы определяете, кто такой Senior-инженер? Какие ключевые характеристики вы считаете важными для этой роли?

– Мы только начали говорить по теме, а вы уже хотите получить ответ на главный вопрос. Никакой интриги. На самом деле этому вопросу уже много лет, а спорят о нём до сих пор. Я, скорее, могу рассуждать о статусе Senior-инженер в отношении DevOps-инженеров, но эти критерии могут быть применимы и к остальным IT-специалистам..

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

Иные считают, что это история про стаж. Проработал десять лет в DevOps? Ок, можешь повесить лычку “сеньора” и просить 300к в наносекунду. Нет и пяти лет опыта? Ну какой же ты сеньор - поработай побольше, дружок, и тогда может быть.

Есть и еще один взгляд на этот вопрос - “привязать” “сеньорство” к инструментам. Не чинил k8s под капотом – не Senior, PostgreSQL не поднимал – не Senior, с облаками не работал – не Senior, и т.д. Некоторые даже собирают свой набор инструментов, с которым им пришлось работать за годы опыта, и называют это магической базой, которая может отличаться от базы соседнего инженера полностью. Здесь, наверное, самое большое заблуждение, так как, например, DevOps как методология — это вообще не про инструменты, а про процессы. И это стоит понять и определить до того, как начинать определять градации (сеньор, мидл и т.д.).

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

– Много точек зрения, действительно. Тогда, как вы думаете, что именно делает инженера Senior, если отбросить эти субъективные метрики? Какие качества и навыки должны быть присущи настоящему Senior-инженеру?

– Проблема в том, что если у нас все критерии субъективны, то всё, что мы можем – оттолкнуться не от критериев, а от определения. Я где-то слышал историю про четырех сеньоров, которые собрались на стрим, и в течение 4-6 часов дискутировали, пытаясь прийти к тому, кто же такой Senior. И единственное, на чём они сошлись, это то, что Senior – это тот, кто получает зарплату Senior-инженера.

Или вот еще вариант – ты становишься Senior в тот момент, когда называешь себя “сеньором”, или кто-то называет тебя так. Например, твоя должность в компании может звучать именно так. То есть назвался груздем - полезай в кузов; назвался Senior – ну что ж, выполняй обязанности “сеньора” и получай его зарплату. Конечно, можно справедливо заметить, что назваться сеньором можно и спустя месяц после знакомства с профессией. Но на деле тебе никто не поверит, в том числе и ты сам себе, и зарплату соответствующую не предложит. То есть это легко проверяется на практике, можешь ли ты справиться с обязанностями, которые возложили на твои плечи, когда ты назвался сеньором. Можно, например, такую проверку устраивать раз в год. Сказать, что ты сеньор и получить равные задачи. Справился – ну значит так и есть, прокатило. По большому счету всем все равно, кем ты себя видишь, если справляешься с задачами, на которые подписался.

Интересно при этом, что если мы эту лычку переведем дословно, то senior – это просто старший. А старший или младший инженер – это зависит от компании, в которой ты работаешь. У всех критерии свои. Я уже не говорю о том, насколько разные роли вообще DevOps-инженер выполняет в разных компаниях.

– Понятно, что определение "сеньора" может сильно варьироваться в зависимости от компании и личного восприятия. А можете ли вы рассказать о конкретных примерах или ситуациях из своей практики, где вы или кто-то из ваших коллег проявлял качества, которые можно назвать "сеньорскими"?

– Да, помню интересный пример. Один мой друг Senior DevOps-инженер, работающий в этой должности не один год, поспорил с коллегой о том, что нужно знать DevOps-инженеру. Его коллега предложил пройти собеседование, организованное этим же коллегой. Был онлайн формат, и подключилось человек двадцать. Мой друг позвал и меня.

Собеседование началось. На третьем или четвертом вопросе стало понятно, что интервьюер вообще не понимал, в чем суть DevOps, и закидывал моего друга вопросами по инструментам из своей практики. Ожидаемо, мой друг не ответил на 70% вопросов, так как эти вопросы были из разряда "А что тебе выведет команда `lsof -o`", "На какой строчке конфигурации nginx нужно указать информацию о сертификате", или "Где Docker Swarm хранит состояние об узлах"?

Суть в том, что это абсолютно бестолковые вопросы, которые могут быть полезными только если это экзамен на получение сертификата по nginx, Docker Swarm или файл дескрипторам Linux. Даже самый опытный инженер может понятия не иметь, что там у nginx и Docker Swarm, потому что пользуется HAproxy и kubernetes. Плохой инженер концентрируется на инструментах, хороший – на технологиях, а DevOps-инженер в первую очередь на процессах.

Забавно, что после этого интервью, собеседующий вынес вердикт "Ну ты еле-еле дотягиваешь до джуниора". Ещё забавнее то, что это было сказано под улюлюканье некоторых других инженеров, которые кричали "Как так? Это же БАЗА!" в адрес человека, который построил не одну полноценную надежную инфраструктуру.

– Похоже, что понимание сути DevOps часто упускается за инструментами. А как вы думаете, какие именно процессы или подходы в DevOps наиболее важны для инженера, чтобы быть признанным Senior? Что должно быть в центре внимания?

– Я бы сказал, что вместе с технологиями важны практики DevOps. То есть, с одной стороны, необходимо понимать, как ты будешь строить инфраструктуру, какая она должна быть в идеальном мире, и стремиться к этому. Можно вспомнить принципы DevOps, один из которых – автоматизируй всё, что можешь (не ломая стабильность и надежность, конечно же). Все практики используешь, опираясь на эти принципы. И далее уже выбираешь подходящие инструменты. Несмотря на то, что инструменты – далеко не самое главное, умение найти правильные – тоже полезный навык. То есть схема такая: принцип > практика > инструмент.

Рассмотрим простой пример. Как я уже говорил, один из принципов - автоматизация. Чтобы автоматизировать интеграцию и доставку кода, мы используем практику CI/CD, можно сказать сердце DevOps. Придумали, как отправлять код пользователю, сделали схему. И наконец время подобрать инструмент для реализации. И здесь уже выбор огромный, и влияет на него несколько факторов: поддержка инструмента разработчиком (то есть саппорт), размер сообщества по инструменту, популярность, знание инструмента инженерами и т.д. Так мы можем определить, что нам подходит больше – GitLab CI, GitHub Actions, Jenkins и т.д. Чем более осознанно инженер подходит к таким вопросам, тем выше его уровень.

– Значит подход к принципам и практикам играет ключевую роль. Как вы считаете, насколько важны навыки управления командой для Senior DevOps-инженера? Должен ли он уметь координировать и наставлять менее опытных коллег или достаточно быть просто технически подкованным?

– Это хороший вопрос, и мнений я слышал по нему несколько. Но я считаю так: навыки управления командой безусловно полезны, тем более для Senior DevOps-инженера, но все же они не определяющие. Навыки управления командой и умение координировать критически важны для тимлида, то есть это менеджерская история. Просто зачастую тимлид является сеньор инженером, но не всегда. Если Junior, Middle, Senior – это скорее горизонтальная градация по хард скиллам, то Team Lead, Stream Lead и т.д. – это уже вертикальная расстановка, это конкретные должности в конкретной команде, когда определена зона ответственности и иерархия. Хотя наставлять менее опытных коллег, конечно важно. Это важно для Senior инженера.

– Интересный взгляд на роль менеджерских навыков. Как вы думаете, какие еще софт-скиллы важны для Senior DevOps-инженера? Какие личные качества помогают эффективнее выполнять обязанности на этой позиции?

– Пожалуй, как и с остальными уровнями. Тут отличий особо нет. Умение работать в команде, находить общий язык, какие-то менторские навыки (чтобы джунам помогать). Можно сказать, что чем выше уровень, тем ценнее софт-скиллы. Ну или "чем больше сила, тем больше ответственность".

– Важно ли для Senior DevOps-инженера постоянно обновлять свои знания и учиться новому? Как вы лично подходите к самообразованию и поддержанию своих навыков на актуальном уровне?

– Постоянно учиться новому в нашей сфере необходимо. Как только начинаешь тормозить, довольно быстро находишь себя отставшим от технологий. И, что критично, теряешь востребованность на рынке. Если смотреть на это глобально, с точки зрения жизни и здоровья, то в этом есть плюс – мозг постоянно тренируется, не даешь себе закостенеть. Но, с другой стороны, и стресс от этого есть, и риски выгореть выше. Особенно когда начинаешь сравнивать себя с профессионалами другой сферы. Если взять какого-нибудь крутого спасателя. Человек знает свое дело, держит себя в форме, может даже награды имеет. Но знания ему требуется обновлять условно раз в 5-10 лет, поэтому он хорошо знает правила, нормативы, ему не надо гнаться постоянно за чем-то новым. Хотя стоит отметить, что и в IT, чем выше твой уровень, тем меньше требуется разгоняться и учить что-то новое.

– Это действительно так. Как вы обычно выбираете, какие новые технологии или инструменты изучать? Есть ли у вас определенные критерии или источники информации, на которые вы опираетесь?

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

– Как вы считаете, какое влияние на карьерный рост и признание в команде имеет участие в открытых проектах или конференциях? Считаете ли вы это важным для развития Senior DevOps-инженера?

– Я не могу сказать, что участие в разных открытых проектах или конференциях сильно влияет на признание в команде. Но на карьерный рост влияет однозначно положительно. Это открывает новые дороги и возможности для твоей карьеры. А это важно. Ведь сотрудничать хотят с теми, кого видят, с кем знакомы. Чем выше визабилити, тем больше выбор как, с кем, где и над чем работать. Более того, известный факт, что когда мы что-то рассказываем кому-то и проговариваем, мы лучше начинаем это понимать сами. Я убедился на собственном опыте, когда давал лекцию в AGBU по DevOps. Если что-то не понимаешь до конца, попробуй объяснить это ближнему, который вообще не понимает ничего в твоей профессии. Пока будешь объяснять, сам выявишь пробелы в своих знаниях и сможешь лучше понимать в будущем.

– Отличный совет! И в завершение, что бы вы порекомендовали тем, кто только начинает свой путь в DevOps и стремится однажды стать Senior инженером? Какие шаги и подходы помогут на этом пути?

– Много учиться, но не забывать думать о себе – зачем тебе это нужно. И главное – наслаждаться жизнью.