Привет, Хабр! Когда-то в двухтысячных годах на заре карьеры ИТ специалиста, Linux был не слишком популярным. Ребята, которые создавали Linux-решения, считались гиками — сидели по углам, делали какие-то сложные технические проекты, общались, как мне казалось, на собственном языке. Сейчас Linux-инженеры востребованы во всех ИТ-компаниях в России и за рубежом.

Меня зовут Виталий Попов, я директор департамента реализации инфраструктурных проектов в компании Softline. В этой статье расскажу о том, какие компетенции нужны Linux-инженерам и на каких проектах они особенно востребованы.

Почему они так нужны бизнесу

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

Но ещё до этого создание собственных инфраструктур на основе открытого кода было привлекательным, особенно для крупного бизнеса. Каждая вторая почтовая система включала в себя MTA на базе Sendmail или Postfix, 8 из 10 северов были на Apache, а не иметь Centos или Debian в качестве серверной операционки хотя бы на паре серверов считалось просто неприличным.

Лет десять назад у нас была небольшая сплочённая команда Linux-инженеров. Мы занимались специфическими задачами: когда заказчик, например, приходил и говорил, что не хочет приобретать лицензию. Ребята были гуру в своих узких направлениях, могли с нуля создать почтовое решение Postfix+Dovecot и службой каталога на Samba DC или система управления конфигурациями с применением Ansible. На рубеже 2018-19 годов стало видно, что такие запросы растут. Мы решили расширять команду, пошли искать специалистов — и наткнулись на то, что их нет. Крутые инженеры по многу лет сидели в своих компаниях, сманить их было невозможно. Причём чаще всего они работали у конечных заказчиков, им было непонятно, зачем переходить к интегратору.

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

Начали смотреть: почему это происходит? Конечно, кто-то говорил, что не хватило зарплаты, был даже случай, когда при увольнении парень сказал: «У вас неудобное кресло». Но, кажется, проблема была всё же не в мебели.  

Проблема первая — рутина

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

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

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

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

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

 Проблема вторая — нежелание расставаться с «детищем»

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

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

 Linux и карьера

В Softline у Linux-инженеров карьерный трек выглядит так: младшие инженеры (джуны), инженеры, ведущие инженеры, а дальше вилка — архитекторы или эксперты. Эксперты — это те, кого мы в шутку называем «инженеры-интроверты», те, кто знает досконально свою область и работает в ней. Архитекторы разбираются в разных решениях и могут презентовать их заказчикам, то есть технари с хорошо развитыми софт-скилами, которые иногда уходят в продажи.

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

Часто на собеседование на ведущие позиции приходят ребята, которые когда-то что-то покрутили в Linux и написали его себе в резюме. А начинаешь задавать им вопросы по самым основам — они плавают. В целом, ничего плохого в этом нет, но это уровень джуна. Я сам таким был, на первом месте работы, когда устраивался, меня спросили: «Что такое Ethernet?». Я сказал: «Лампочка на модеме». Тогда мне дали книжку и велели читать. Меня взяли не то, что джуном, скорее даже стажёром, и месяца три-четыре я ходил как студент с книжками, отвечал на вопросы. А сейчас — директор департамента. Это я к тому, что быть новичком — нормально. У нас в компании в том числе есть позиции для тех, кто только начинает карьеру. Но, конечно, приоритет отдаём опытным инженерам, потому что проектов становится всё больше, они сложные и инновационные.

Кстати, раз уж заговорил об основах, минимальный уровень для меня — это способность ответить на следующие вопросы:

1.      Разнообразные вопросы по инфраструктуре в целом: чем TCP отличается от UDP, какие есть типы RAID-массивов и процессов загрузки операционной системы?

2.      Кластер, и причем тут heartbeat?

3.      Bash, и какие операции с ним можно проводить?

4.      Как мониторить доступность сайта из shell?

Ещё компаниям нужны инженеры-универсалы: те, кто знает и Linux, и другие решения, а главное, понимает, как их компоновать. Это связано с тем, что далеко не все компании могут просто взять и целиком перейти на open source, чаще всего им нужны гибридные решения. Зачастую заказчики не готовы менять всю инфраструктуру на Linux-решения, в том числе open source, но есть области, где можно попробовать провести замену. Для примера — три самых распространённых сценария:

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

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

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

Кстати, о проектах

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

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

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

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

 Развитие в Linux

Специалисты по Linux будут востребованы ещё долгое время. Тем, кто только размышляет о том, чтобы пойти в это направление, я бы посоветовал не распыляться, а определиться в том, какая область интересует. Хочется, условно говоря, строить дом как застройщик или заботиться о нём как управляющая компания? Разрабатывать решения или поддерживать их? Интересно писать собственные операционки/решения или внедрять почтовые клиенты?

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

У вендоров своя специфика — глубокое погружение в один проект. Можно очень серьёзно прокачать компетенции в разработке, в серьёзном R&D. Для людей, которые заточены под изобретательство, у вендоров много перспектив. Но, как минус, если продукт надоел, сменить его не выйдет.

У интеграторов, наоборот, продуктов и решений много, можно познакомиться со всем, что развивается на рынке. За счёт того, что задач очень много, можно перейти в другое направление, не увольняясь из компании — и таким образом получить со временем разнообразный и крутой опыт в Linux-разработке.

Как руководитель, я вижу реальное положение дел в отрасли. У джунов всегда есть возможность войти в профессию. А за сильными специалистами по Linux идёт настоящая охота, поэтому вариантов карьерного и экспертного роста очень много.