На рынке системной инженерии парадокс: сеньоров всегда не хватает, а джунов почти не берут. Курсы дают базу, но настоящий опыт специалист может получить только на практике. В материале разберем, стоит ли бояться ИИ, и почему умение общаться с командой важнее знания всех инструментов.Авторы и экспертыАлександр ТелевнойРуководитель департамента инфраструктуры компании «Криптонит»Артем ПузанковРуководитель отдела консалтинга безопасной разработки компании «Бастион»Об экспертах: Александр Телевной — руководитель департамента инфраструктуры компании «Криптонит». Управляет Cloud и On-premise инфраструктурой и специализируется на системной инженерии. Артем Пузанков — руководитель отдела консалтинга безопасной разработки компании «Бастион». Специализируется на построении и трансформации процессов безопасной разработки в крупных компаниях.
Границы между системным администрированием, DevOps и DevSecOps сегодня настолько размыты, что часто на сайтах поиска работы пишут: «Ищем DevOps-инженера со знанием безопасности». Отсюда разнятся и ожидания от специалиста. Одни думают, что DevOps будет чинить принтеры и одновременно обслуживать базы данных, другие — что это инженер, проектирующий и развивающий ИТ-инфраструктуру. Разбираемся, как устроены профессии, какие навыки нужны новичкам и как состояться в карьере.
От сисадмина к системному инженеру
Путь от системного администратора к системному инженеру проходит несколько карьерных ступеней. Классический сисадмин настраивает и обслуживает то, что уже работает. Системная инженерия как отдельная профессия появилась, когда облачные гиганты перестали просто покупать готовые решения от вендоров и начали активно развивать собственные продукты на базе облачных технологий и open-source-инструментов.
Карьера системного инженера появилась в момент, когда мы смогли не просто покупать готовые продукты у вендоров, а развивать собственные продукты внутри компании. Развитие DevOps напрямую связано с внедрением гибких подходов к управлению проектами: когда разработка стала итеративной, потребовалось ускорить циклы доставки кода. Так появилась роль, отвечающая за всю цепочку непрерывной интеграции и развёртывания (CI/CD): от автоматического статического анализа (linters) и тестов до выкатки на прод.
Со временем из DevOps выделилось направление DevSecOps. Безопасность встроили в конвейер CI/CD, чтобы выявлять уязвимости максимально рано.
Где заканчивается DevOps и начинается DevSecOps
Мы описываем работу DevSecOps в такой аллегории: «Я занимаюсь тем, что, пока машина ещё движется по конвейеру, проверяю ее функции безопасности: дёргаю ремни, тестирую подушки и тормозную систему».
Если перевести на инженерный язык, получится такое распределение ролей. Системный инженер: это наиболее масштабная и широкая позиция. Такой специалист занимается развитием систем, созданием их с нуля, а также поддержкой в продакшене (включая практики SRE — применение инженерного подхода к задачам системного администрирования). Он рассматривает инфраструктуру комплексно.
Основная задача DevOps — ускорение циклов разработки и доставки ПО. Этот специалист отвечает за автоматизацию всего CI/CD-пайплайна: от сборки кода до его доставки на прод.
DevSecOps же фокусируется на безопасности внутри пайплайна. Он внедряет инструменты безопасности, проводит проверки «с максимальным сдвигом влево» (как можно раньше), чтобы гарантировать безопасность приложения перед выкаткой в продакшн. Такой специалист не заменяет DevOps, а расширяет его.
Как попасть в профессию и какое направление выбрать
Есть два основных пути в DevOps: из системного администрирования и из разработки.
Первый вариант — начать с классического сисадминства: поработать с Linux, железом, облаком, мониторингом, а затем перейти к инструментам доставки кода. Второй путь, по мнению эксперта из «Криптонита», проще: разработчику легче понять, зачем нужны DevOps-инструменты, потому что они и создавались для ускорения разработки. Однако на российском рынке чаще всего DevOps-инженерами становятся именно системные администраторы.
Мы выделяем три технических столпа, без которых не стать сильным DevSecOps-специалистом: разработка (понимание безопасных конструкций кода), архитектура и Linux.
Но главное — софт-скиллы. Мы формулируем правило найма так: «Если человек хотя бы на 60% подходит по техническому стеку, остальные 40% мы доучим. Но если человек по софт-скиллам показывает какие-то проблемы или не может профессионально вести диалог, — это красный флаг». Умение общаться с командой, держать удар во время инцидентов и спокойно разбираться в проблемах важнее, чем идеальное знание инструмента.
Обучение, рынок труда и ИИ
На рынке сложилась парадоксальная ситуация: сеньоров и лидов всегда не хватает, а джунов почти не берут. Компании не готовы вкладываться в обучение начинающих, поэтому молодые специалисты вынуждены расти самостоятельно.
Курсы могут дать хорошую базу, но настоящий опыт приходит только с практикой. Мы советуем использовать бесплатные мощности облачных провайдеров, разворачивать инструменты на виртуальных машинах и учиться на реальных задачах.
Особое место в обучении и работе занимает искусственный интеллект. Нейросети отлично справляются с анализом больших объемов данных: если мы берем модель, обученную на нормальном режиме работы системы, она может пометить, что 99% событий нормальные, и сократить количество изучаемой информации в 100 раз.
Но доверять ИИ управление системами нельзя. Эксперт приводит пример: нейросеть однажды удалила продуктовую базу данных, и отвечать пришлось инженеру, поэтому в контуре с чувствительными данными используют только локальные модели, обученные на собственных датасетах.
ИИ хорошо помогает в задачах ASOC/ASPM (платформы для автоматизации и управления безопасностью разработки приложений): например, быстро оценить, является ли уязвимость действительной или ложным срабатыванием. Но финальное решение всегда остается за человеком.
Компании сейчас активно продают ИИ-инструменты, но не заменяют ими людей. Если компаниям выгодно продавать лопаты, значит, золото копать на текущий момент ещё нет смысла. Если бы ИИ мог хорошо писать софт, провайдеры ИИ уже открыли бы свои аутсорс-компании и заработали больше. Но они продают лопаты.
Подводим итог: гуглить не поможет
Работа системного инженера или DevSecOps-специалиста складывается из постоянного решения нетривиальных задач. Приводим два показательных примера из практики.
Кейс № 1. Кириллическая буква, которая положила прод
Возникла проблема: конфигурационный параметр порта с русской буквой «О» не применялся, хотя визуально всё выглядело корректно. Инженеры потратили два дня, прежде чем случайно обнаружили причину: одна из букв в названии параметра была набрана в кириллической раскладке, а не в латинской. Для системы это были два совершенно разных идентификатора, но человеческий глаз разницу не улавливал и только посимвольный анализ позволил установить, что параметр не применялся из-за того, что одна буква была кириллической, а не латинской.
Подобные ошибки можно назвать классикой эксплуатации. И, как отмечает эксперт, именно такие задачи делают профессию по-настоящему увлекательной.
Кейс № 2. Несколько дней расследования из-за перегрева SFP-модуля
Другой случай — сетевая ошибка, проявлявшаяся только на одном специфичном окружении. Симптомы были настолько неочевидными, что инженеры несколько дней перебирали гипотезы. В итоге выяснилось, что в коммутаторе перегрелся SFP-модуль (оптический трансивер). Физическая неисправность давала настолько нетипичную картину на уровне приложений, что заподозрить аппаратную причину удалось далеко не сразу.
Такие эпизоды как раз и раскрывают суть профессии. Каждый заказчик — это уникальный набор технологий и процессов. Даже типовая задача в разных средах может решаться принципиально по-разному.
Даже специалист уровня сеньор может впервые столкнуться с конкретной конфигурацией. Поиск в интернете и на Stack Overflow не даст готового ответа. Приходится погружаться в самые основы, чтобы понять причину проблемы.
Именно поэтому в профессии ценятся не столько заученные команды, сколько умение выстраивать гипотезы, методично их проверять и сохранять концентрацию, когда бизнес требует немедленного решения, потому что каждая минута простоя оборачивается значительными убытками.