Hello, world

Я DevOps-инженер, и я не существую.



Потому что DevOps — это методология или философия, но никак не специальность. Однако всем в ИТ привычнее закрыть на это глаза и считать, что единороги существуют. Не буду рушить эту по-детски милую и наивную рекрутерскую иллюзию. В компании, в которой я работаю, моя позиция называется Configuration Manager или Инженер Конфигурации Программного Обеспечения. Я думаю, что понятнее вам не стало, да? Окей, давайте по порядку.

Что такое DevOps?

Development+Operations=DevOps

Это если коротко.

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

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

Поэтому взять и выделить DevOps-специалиста с набором обязанностей для достижения Reduce time to market невозможно. Это коллективная работа. Так что чаще всего под DevOps-инженером понимают человека, который делает автоматизацию на проекте, настраивает окружения и мониторинг. Большим плюсом будет, если он будет «читать проповеди» о культуре взаимодействия, способствовать архитектурным и ретроспективным встречам между разработчиками и отделом эксплуатации. В общем, выступать DevOps-евангелистом.


devopstopologies.ru

В Романе «The Phoenix Project» легко и увлекательно рассказывается про этот наш DevOps. Прочёл на одном дыхании.

Начало пути

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

Если хочешь дальше работать ИТ-архитектором, то нужно иметь 1-2 года опыта работы разработчиком.

Абсолютно адекватное требование. Я бы даже сказал, лет 5 не помешает, но на тот момент я не знал об этом. Я учился на разработчика, и это не вызывало во мне энтузиазма, так что я не искал подобные позиции. И потому предложение пойти писать код, а потом возвращаться, меня не вдохновило. Забавно, конечно, что узнал я о требовании руководства на 5-м из 6-ти месяцев оплачиваемой стажировки.

Я начал подумывать переступить через своё не хочу и устроиться разработчиком, как до меня дошло спросить у друга Серёги, DevOps-инженера:

Я: Серёга, а что ты делаешь на работе?
СЕРЁГА (DEVOPS-ИНЖЕНЕР): Ну там, это.

Бинго! Это же то, что мне нужно. Не разработка, но ИТ, а значит, я в этом что-то понимаю или научусь понимать, я же сам себе ПК собрал. Главное — не писать код, упаси C#. Сергей как раз менял место работы в декабре и порекомендовал меня на замену, но… даже не позвонили. Тогда я начал самостоятельный поиск.

***

В январе пошёл снег, а я на первый собес, где мне отказали из-за слабого английского. Тогда Серёга снова порекомендовал меня, но на новом месте работы. Меня не стали рассматривать из-за отсутствия опыта. Потом ещё собес с отказом. И тут мне крайне повезло, что есть такая компания, как EPAM с вечерней DevOps-школой и трудоустройством по окончанию обучения. Это большая интернациональная компания, работы в которой навалом, а специалистов конфигурации ПО с мышлением DevOps в то время было ещё меньше чем сейчас. Возможно, что они первые в России открыли подобные курсы, тем более бесплатные.

В феврале прошёл отбор, и в конце месяца началось обучение. Занимались трижды в неделю по вечерам. Отбор в школу прошли 20 человек. ~15 были со стороны, а остальные уже работали в компании. Заявок всего было ~120. Подготовиться к отбору мне помогли курсы по Linux, DB и Python на степике и, конечно же, бакалавриат в ИТМО. А ещё Серёга учил меня, как работать в Jenkins, и вселил уверенность в свои силы.

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


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

***

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



И вот в мае Серёга, который тоже не сдавался (потому что я у него занимал деньги), в третий раз порекомендовал меня. В этот раз на новую позицию в T-Systems, где были готовы взять и обучить джуна, который понимает основы. А благодаря школе EPAM я получил нужный базис. Чутка успел подкачать английский, который всё равно был ужасен, но собеседовавший меня мой будущий People Manager, стиснув извилины, смог понять, что же я там плету, вставляя герундий туда, куда приличные люди не вставляют. Спасибо, Илья, что поверил в мой лингвистический и технический потенциал.

Забавно, что в день собеса мой будущий тимлид был в отпуске и ему меня «сосватали» не глядя.


Иван Степаныч радуется

Junior DevOps

17 мая 2017 года — мой первый рабочий день джуном. В команде я и тимлид. Через месяц приняли в команду третьего. Потом разрослись до 6 человек через год.

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

Вот базис начинающего специалиста: Jenkins, Linux Administration, Bash, Git. Потом желательно Docker, Kubernetes и/или OpenShift, Ansible, Python.

Само собой, знать сразу всё невозможно. Например, Docker мне на начальных этапах не был нужен, но понимание концепции от меня ожидали и спрашивали на собеседовании. Да и никто не говорит о глубоком опыте в Linux или, о ужас, попросить установить и настроить Jenkins. Так, уметь тыкать в интерфейс, понимать, как его можно использовать в первом приближении. Обучаешься в процессе решения рабочих задач.

А чем старше проект, тем меньше в нём того, что в желательной части и больше Bash. Всё обмотать длинными спагетти Bash-кода — излюбленная автоматизация столь близкого нам прошлого. Как говорится: «Знаешь Bash? Тогда… Иди работай!».



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

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



Здесь пригодился опыт в HTML, CSS, JavaScript, Python. Но если бы не умел, то и не стал бы делать. Так что на заметку можно взять только Python.

Middle DevOps

Прошло 10 месяцев, и меня повысили до «просто» инженера. Здесь важно понимать, что в каждой компании своё понимание того кто такой Junior (младший), Middle (средний) и Senior (старший). И разные зарплатные вилки на позиции. Слышал как-то, что в некую компанию взяли парня джуном за зарплату сеньора. Я понятия не имею, правда ли это, но не исключаю подобного.

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


Как себе представляет специалиста эксплуатации гуманитарий. P.S. Гуманитарии, я вас люблю

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

А ещё специфика способна сделать больно, если её создавали не вы. Но главное — вовремя вспомнить, что мы способны изменить мир, а изменить специфику — нет.

Шучу.

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

Senior DevOps

Через год, а именно в апреле 2019 года, я повысился до сеньора-помидора. Как говорится: «хочу салат — не вижу препятствий». Ещё говорят, что с большой силой приходит большая ответственность. Вообще, справедливо. Только в профессиональной стезе наоборот: сначала ответственность, а потом подтягивается сила и уверенность. То есть сначала нужно иметь смелость замахнуться на слона и уже потом, на пути, дорасти до его ушей.

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

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

Но мир IT изменчивый: сегодня ты пишешь код на Python, а завтра от соискателей требуют прогрессивный Go, поэтому глубинная прокачка всегда сменяется изучением новых инструментов.

Однако побыть сеньором мне не дали…

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


Это Гарольд нашёл меня

Вы ожидаете, что здесь будет раздел с названием Team Lead DevOps? А нет, повышение так не работает. Повышают не чаще раза в 9 месяцев, но это в моей компании. Где-то повышают раз в полгода, где-то в год. А вообще, спланировать график повышения невозможно наверняка, так как он зависит от твоих успехов и чуткости руководителей. Можно и за два года не получить повышение.

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

***

В октябре 2019 поехали в Германию, чтобы встретиться с коллегами из Польши и Немеции. Да, я взял на себя роль тимлида, но только лишь питерской команды. Ещё по двое коллег были из этих стран. И формально, тимлид всей команды был в Германии. К сожалению, по большей части формально.

В октябре мы поняли, какой жуткий рассинхрон у нас произошёл.

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

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

В команде из 10 человек задача более-менее посильная, но усложнённая языковым барьером и расстоянием между всеми. Да и не только ведь этим приходится заниматься.

***

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



Так вышло, что он не был DevOps специалистом изначально в проекте. Он начал как разработчик и затем постепенно перешёл в Инженеры Конфигурации ПО. И, вероятно, неожиданно сам для себя стал тимлидом в 2017 году. Так что выбрать DevOps-школу было верным для него решением.

Однако тогда я думал, что причиной послужила ситуация на проекте…

***

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

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

Новые обязанности выполнял я, откровенно говоря, не очень. Только отошёл от шока тимлидства в Санкт-Петербурге, как теперь ещё плюс две локации. К тому же полноценным руководителем я себя не ощущал: функции тимлида нигде не описаны, примера для подражания не было. На что опираться?

Поэтому как я могу руководить всеми? Да ещё более опытными иностранными коллегами. К своим я постепенно привык и освоился, а тут новая партия подъехала. И ладно бы партия стандартного калибра, так ведь один из снарядов такой бронебойной силы, что чуть отвернёшься, а у тебя чат 30-ю сообщениями завален от него и новая Bash-портянка готова. Bash — это хорошо, Bash — это здорово. Однако нужно понимать, когда нужно использовать Bash, а когда другой язык или инструмент.

***

В январе 2020 приехало повышение за июнь. Снова ожидаете Team Lead DevOps заголовка? А не будет его. Тимлид — это роль, а не должность. Так что вряд ли вам напишут в трудовую книжку руководительский подвиг в технической команде. Вам нужно в Project Manager'ы для этого идти.

Получается, что тимлидом может быть и джун. А меня повысили до…

Expert DevOps

Январь и февраль прошли. Вернулся немецкий тимлид. «Наконец-то!» —, подумал я. За это время у меня сложилась картина, что нужно делать, чтобы повысить нашу эффективность: как правильно создавать дорожную карту, распределять задачи, выстраивать коммуникации, обсуждать, проверять чужие решения.

А я уже представляю, как всё это ему рассказываю. Как он кивает головой, говорит: — «Sure», — и вокруг нас расцветает малина.

Но нифига.

Вернувшись в проект, тимлид не забирает на себя свои обязанности, типа проведение созвона для сбора статуса. Не интересуется задачами коллег. Не инициирует беседу, если видит что-то непонятное для себя. Ведет себя абсолютно пассивно. Я понимаю: первую неделю или две, но ведь уже апрель.

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

И под конец апреля выясняется, что текущий тимлид ещё зимой принял решение уйти в другой проект, где проходил практику от DevOps-школы. Только теперь на позицию специалиста эксплуатации.

Тут мне стало понятно почему он так легко отнёсся к «отжиму» обязанностей с моей стороны.

Наши дни

Как вы догадываетесь, с июня 2020 года я считаюсь тимлидом международной команды Инженеров Конфигурации Программного Обеспечения (написал с заглавных букв, потому что так красивее). Делает ли это меня экспертным экспертом? Да нифига.

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

Каковы мои дальнейшие возможности? Их несколько.

1. Ничего не менять с точки зрения позиции. Продолжать «лидить», параллельно изучая новые инструменты и углубляя знания. Рано или поздно дойти до позиции архитектора по DevOps профилю.
2. Перейти в другую команду и снять с себя роль тимлида. Сосредоточиться на изучении новых инструментов и прокачиваться как инженер. Рано или поздно дойти до позиции архитектора по DevOps профилю и роли тимлида.
3. Пойти в менеджерскую ветку. Мне предлагали рассмотреть роль Scrum-мастера. Неожиданно, правда? Однако сейчас такой возможности уже нет, ввиду организационной трансформации в компании в матричную структуру. Вообще, это не единственный способ перейти в менеджмент в T-Systems, однако подробности за рамками этой статьи.

Позиция руководителя мне привычна и вызывает больший отклик. Тактики, стратегии, психология и социология — one love. Однако здесь важно быть увлечённым проектом/продуктом. Что для меня задача не из простых. Чтобы вы понимали что я за человек: я мог бы открыть точки продажи кофе, пиццерии, производство пластиковых упаковок, свою криптобиржу, однако я не хочу делать то, что или деструктивно, или вредно, или бесполезно. Даже если это окупается моментально или приносит сверхприбыли.

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

Так что или 1-ый или 2-ой вариант. Желаю себе успехов на одном из них!

Послесловие и благодарности

Вообще, я бы хотел стать знаменитым певцом…


*Играет музыка*

Ну что поделать — всему своё время. Сначала научусь петь.

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

Кстати, есть ещё одна возможность стать DevOps-инженером быстро и безболезненно.

В сентябре планируем открыть набор в DevOps-школу в T-Systems. Точнее будет понятно в начале или середине августа. Участие бесплатное и с трудоустройством после успешного завершения. Из требований: Linux на уровне пользователя и английский. В программу обучения входят упомянутые и неупомянутые в статье инструменты: Kubernetes, OpenShift, Jenkins, GitLab, Ansible, стек для мониторинга и ещё немного других полезностей.

Я один из лекторов школы. Так что у тебя есть шанс попасть на мою вводную лекцию о таинственном однорогом звере.

За мой карьерный путь, наставничество и чуткость руководства благодарю моего бывшего тимлида питерской команды Сергея Жекписова (я капец как многому у тебя научился!), моего пипл менеджера Илью Семерханова, руководителя направления Дмитрия Жаркова и моих коллег, когда-либо работавших вместе со мной.

Сергей Ли, без тебя я бы и не начал этот путь. Ты знаешь мою благодарность, дружище.

Большое спасибо Иномджону Мирджамолову за первое прочтение и предложенные правки в данной статье, а также отделу коммуникаций T-Systems.

Моя текущая команда, вы суперские, мужики! Жму ваши виртуальные руки.