Transcription
DevOps — это методология автоматизации технологических процессов.
DevOps — это не человек. Это набор практик development operations.
Ты, вероятно, слышал, что став DevOps инженером, ты будешь выкатывать релизы. Ну да и нет. Давай разберёмся, кто такой реально этот ваш DevOps инженер, что он должен уметь делать и за что ему платят столько денег. В конце вообще посмотрим, а сколько ему платят денег на самом деле.
Ты будешь делать всё. Представь себе человека с руками — вот это DevOps инженер. Ну, может быть, это, конечно, шутка, но не совсем.
Что хотелось бы вынести в дисклеймер под такую плашку: душнило. По канону называть человека девопсом неправильно, ведь DevOps — это некий набор практик. Но язык меняется, и появляются новые позиции на рынке. Сейчас принято называть человека, который занимается внедрением всех этих практик и методологий, DevOps инженером.
Сейчас будем говорить именно про специалиста, которого все привыкли называть девопсом.
Вся работа DevOps инженера высокоуровневого сводится к одному: есть некий CCD процесс — это процесс непрерывной автоматической доставки кода на серверы. И мы обеспечиваем этот процесс и поддерживаем его тем или иным способом.
Теперь про сам этот процесс. Мне очень не хочется ударяться, как в интернете уже полно видео про это. Но если кратко и в общих чертах, то процесс разработки, как это завещали отцы DevOps, выглядит так.
Вот эту картинку я думаю все уже видели кучу раз, но вот что она значит. У нас есть отдельные этапы, которые перетекают друг в друга. Вот разработка — здесь у нас разработчики пишут код, и он вливается, это ещё называется интегрируется в общую кодовую базу.
Здесь у нас тестирование — это когда запускаются автоматические тесты, проверяют код на ошибки и баги. Здесь у нас есть сборка приложения — мы собираем некий конечный артефакт, файл, архив.
Казалось бы, что там сложного — автоматизировать запуск новой версии кода на сервере, но в реальности тебя ждёт большое количество подводных камней.
Различия между окружениями: что-то у тебя работает в среде разработки, но по-другому запускается в демо окружении. Странные решения в приложениях или костыли из разряда "так исторически сложилось" — всё это так или иначе накладывает ограничения на твою работу.
Теперь мне хотелось бы поговорить о том, какие бывают DevOps инженеры. В каждой компании может быть своё понимание DevOps, и оно может отличаться даже между командами внутри одной компании.
Они могут разниться даже с общей концепцией DevOps, но так уж стало принято. В мире DevOps инженер — это очень универсальная позиция.
Я хочу выделить здесь две крайности, между которыми, конечно же, есть и промежуточные значения. Опять же, всё зависит от компании и твоего проекта.
Первое и самое распространённое, особенно на рынке СНГ, как мне кажется, это DevOps админ, который делает всё. Ты немножко админ, немножко сетевик, программист, архитектор, безопасник и даже немного бухгалтер.
Ты будешь поддерживать виртуальные машины, серверы, устанавливать софт, писать пайплайн для доставки кода, решать какие-то проблемы в приложениях, делать мониторинг, писать что-то своё, потому что иногда на программировать небольшой сервис или скрипт проще и эффективнее, чем внедрять что-то готовое.
Иногда, но не всегда, ты будешь делать траблшутинг. Кстати, про траблшутинг у меня уже на канале есть клёвое видео, оно в описании, ссылочка будет.
По сути, это будет некий микс DevOps инженера и системного администратора или SRE. Но такова жизнь.
Какие же есть плюсы такой работы? У тебя очень большой пул задач. Я не про то, что задач много — это понятно. У нас всегда много задач. Я про то, что они очень разнообразные. Ты делаешь и то, и это, и пятое, и десятое.
Ты практикуешься во многих сферах, знакомишься с новыми технологиями, и мне кажется, это отличный способ быстро набраться опыта и сделать карьеру интереснее. Если ты делаешь клёвые правильные штуки, и твоя работа приносит результаты коллегам и бизнесу, тебя любят. Это очень приятно.
Работая в команде с более опытными коллегами, ты получаешь реально уникальный шанс учиться у лучших.
Конечно же, здесь есть и минусы. У тебя большой пул задач — да, это и плюс, и минус. Это тяжёлый груз, и это может довольно быстро привести к профессиональному выгоранию.
Со временем, при увеличении твоего опыта, ты будешь видеть всё больше и больше элементов в твоей зоне ответственности, которые можно как-то поменять, усовершенствовать или внедрить что-нибудь новое.
Из-за подобного очень быстро разрастается кластер, и времени на это всё не хватает. Ты начинаешь перерабатывать — это тоже верный путь к выгоранию. Либо ты начинаешь демотивироваться из-за того, что кластер не уменьшается, усиливается синдром самозванца: мол, я делаю свою работу плохо.
Короче говоря, это тоже минус. Опять-таки, из-за большого пула задач может получиться так, что ты будешь развиваться везде по чуть-чуть, и у тебя просто не будет времени и возможности углубиться в какую-то конкретную область.
Противоположная сторона — это когда ты занимаешься чем-то одним, например, только CCD пайплайном или перекладыванием YAML файлов, тюнингом, пишешь скрипты, делаешь Helm чарты и добиваешься того, чтобы код автоматически собирался, тестировался и доставлялся на окружение.
В такой модели инфраструктуру тебе делают системные администраторы по твоим заявкам, а мониторинги настраивают специальные люди, а правила в фаерволе крутят сетевики.
Такое может встретиться в крупных компаниях, где есть большой штат айтишников, там, где каждый занимается своим делом. Есть отдельная команда, занимающаяся инфраструктурой, серверами, виртуалками, облаками.
Есть отдельные ребята, которые настраивают сеть, отдельные безопасники, которые настраивают фаервол, коде, отдельные инженеры мониторинга и, конечно же, DevOps, которые занимаются пайплайнами и релизами.
На самом деле это больше похоже на реальное описание DevOps инженера. Тут есть плюс: ты получаешь большой, но, конечно, узконаправленный опыт, и ты сможешь глубоко развиваться в каком-то одном направлении.
А вот из минусов, и первое, что я даже успел испытать на себе, это то, что из-за более узкого пула задач тебе это может быстро наскучить. Постоянно одно и то же — всё приедается. Это реально верный путь, опять-таки, к выгоранию.
Второе, как мы знаем, когда не практикуешь, теряешь навыки. Ты можешь начать забывать то, что раньше умел хорошо делать.
Сильно пугаться этого не стоит. Тут действуют правила велосипеда: один раз научившись работать с условным Ablo, ты сможешь быстро вернуться в строй, если годик с ним не будешь работать.
Также, если выбранная технология устареет, перестанет поддерживаться или не будет соответствовать изменяющимся требованиям, проекту DevOps инженер может столкнуться с проблемами.
Недостаток опыта в других технологиях может затруднить переход к новым инструментам или методологиям. Такой подход, как мне кажется, лучше подходит более опытным инженерам, которые стремятся к глубокому развитию в определённой области, готовым к риску потери универсальности в обмен на большую экспертизу.
Давай подытожим общие плюсы и минусы профессии DevOps инженера. За свои уникальные навыки и компетенции, что отражается в высоких зарплатах, и об этом мы будем говорить дальше.
Многие компании предлагают гибкий график и удалённую работу. DevOps инженеру, как и разработчикам в целом, не нужно находиться в офисе.
Про удалённую работу у меня, кстати, тоже на канале есть видео, ссылка будет в описании. Наша работа включает в себя большой пласт технологий и инструментов: программирование, управление инфраструктурой, автоматизацию.
Поэтому я смело отношу разнообразие задач всё-таки в плюсы. Также работа DevOps инженера требует и развивает такие качества, как адаптивность, умение решать сложные задачи, коммуникативные навыки и способность к самообучению.
Это не только делает профессию интересной, но и способствует общему развитию личности.
Навыки DevOps инженера актуальны и востребованы на рынке, что обеспечивает высокую вероятность получить работу, если ты, конечно, сильный инженер.
Минусы, конечно, тут тоже есть. Дежурство или так называемые онколы. Можно сказать, что ты работаешь 24 на 7.
Так или иначе, у вас будут или поочерёдные дежурства с коллегами, когда в случае инцидента именно дежурный подключается первым, или постоянное дежурство, это когда вас мало, инциденты редкие, и чередоваться смысла нет.
Уведомления об инцидентах приходят ключевым сотрудникам, и они пробуют сразу решить проблему сами. Если что-то случается с инфраструктурой или с каким-то окружением, ну, конечно, именно DevOps инженер, скорее всего, первым будет это фиксить.
Кто лучше всех знает, как перезапустить пайплайн и какие параметры в него нужно передать для дебага?
Ну, конечно же, ты. В качестве ещё одного минуса я отмечу высокий порог входа, но про это немного дальше.
Также из-за огромного количества инструментов и большой разности задач и подходов в разных компаниях ты можешь начать считать, что ты совершенно никчёмный инженер и ничего крутого не умеешь делать. Это синдром самозванца.
А вот одновременный плюс и минус: тебе необходимо постоянно следить за новыми технологиями и инструментами. Если ты хочешь быть крутым инженером, то у тебя не будет времени, чтобы расслабиться.
Многие программисты уже давно умеют писать Docker файлы и деплоймент для Кубера, запускать виртуалки в облаке и устанавливать на них софт, траблшутить Linux, вообще нарисовать за тебя пайплайн, писать конфигурацию какого-нибудь сервиса.
Так, это что получается? Они у нас работу забирают? Зачем тогда компаниям платить нам деньги?
На самом деле всё не так просто. В небольших проектах действительно роль DevOps инженера обычно берут на себя разработчики. Либо они будут искать себе контрактов — это типа когда задача есть, тогда и работаешь.
Поэтому смотрим на более крупные компании, где есть и нужен full-time DevOps инженер, либо рассматриваем part-time позиции.
Но чтобы успокоить, сложность инфраструктуры всё-таки увеличивается со временем. Проекты растут в кратном масштабе, потребность в профессионалах, способных строить это, управлять и поддерживать, остаётся всегда высокой.
Также вопросы безопасности становятся всё более актуальными, требуя постоянного мониторинга, анализа новых уязвимостей, улучшения инфраструктуры. И это тоже входит в нашу область.
Тут как раз речь про так называемое направление DevOps.
Ну и, конечно, появление новых технологий, таких как искусственный интеллект и машинное обучение, открывает новые возможности для DevOps инженеров в плане управления, развёртывания и мониторинга таких сложных систем.
Какой вывод из всего этого можно сделать? Вкатиться в DevOps становится сложнее. Тебе нужно очень много знать и желательно иметь интересный релевантный опыт.
Нужно иметь большую насмотренность. Я уверен, что грамотные специалисты с большим кругозором, вовлечённостью и хорошими софт-скиллами всегда будут нужны.
Постоянно развиваемся, смотрим на новые технологии, не теряем хватку, а языковые модели используем для помощи себе.
Тот же ChatGPT, особенно четвёртый, пишет реально классный инфраструктурный код. Он помогает быстро разобраться с какой-то проблемой, чаще даже быстрее, чем поискать в Гугле или на Stack Overflow.
Теперь немного про то, чем приходится заниматься повседневно. Кстати, в моём Telegram канале я иногда делаю посты, где как раз рассказываю об интересных и не очень интересных задачах, которые я решаю на работе.
В основные задачи DevOps инженеров входит, например, управление инфраструктурой проекта.
Там создать, единообразно настроить несколько виртуальных машин, обновить версию на балансировщика, поднять новый сервис для анализа кода, настроить бэкапы баз данных, оптимизировать расходы на инфраструктуру, ресурсы, облачных провайдеров или аренда серверов в дата-центрах.
Автоматизация процессов разработки, например, написать CI/CD пайплайн для сборки и доставки нового микросервиса или внедрить в этот пайплайн новый этап для тестирования.
Сокращение времени доставки фич — это так называемый Time to Market. Мы оптимизируем пути доставки и тестирования кода, уменьшаем влияние человеческого фактора и вероятность ошибок.
Например, внедрить blue-green deployment или канареечный деплоймент, настроить автоматический бэкап баз данных, сбор обратной связи — это, например, установка нового агента мониторинга и настройка дашбордов с метриками из него.
Или, например, развернуть и настроить систему централизованного сбора логов, например, ELK.
Создание и поддержка окружений: стенды разработки, тестирования, продакшн, демо стенды.
Создание динамических окружений — это когда по кнопке или созданию реквеста в GitHub у тебя в инфраструктуре разворачивается для разработчиков или тестировщиков отдельное окружение, и оно также по кнопке потом удаляется.
Документация, например, описать чек-лист добавления нового сервиса в рабочий процесс или обновить документацию после выхода новой версии.
Переходя к теме скиллов, хотелось бы ещё рассказать про формы развития профессиональных навыков у специалистов.
Вообще они как бы перетекают из одного в другое по мере твоего развития. Так называемые I-shaped, T-shaped, π-shaped специалисты и так далее.
Там на самом деле есть почти все буквы алфавита, но это не так важно. По картинке видно, что вертикальная черта — это глубина знаний в какой-то области, а горизонтальная — это ширина и разнообразие твоих знаний.
I-shaped специалист может разбираться глубоко в какой-то одной технологии, но совершенно не знает, как работать с другой. Ему это может быть даже неинтересно. Это плохо, так делать не надо.
Следует постоянно развиваться, изучать смежные технологии, чтобы развивать, так сказать, горизонтальную черту в букве T.
T-shaped специалист продолжает глубоко разбираться с одной технологией, но помимо этого он имеет неплохие знания и навыки в других. Такие специалисты намного более ценны.
Это делает их более способными к командной работе. Они могут легче адаптироваться к изменениям в проекте или команде.
Мораль: опять-таки, не забывай смотреть по сторонам и хотя бы поверхностно изучать смежные технологии, разбираться с какими инструментами работают коллеги, как вообще всё устроено. Это очень важно.
Почему я ставлю софт-скилы раньше хардов? Потому что про них тоже нельзя забывать. Можно быть 100 раз крутым инженером, но если ты не умеешь работать в команде, то хорошая работа тебе не светит.
Не бояться ответственности. Что это значит? Нужно принимать решения и быть готовым нести за них ответственность.
Сюда же можно добавить любопытство. Я уже говорил про то, что нужно смотреть по сторонам и изучать новое, держать руку на пульсе и следить за новыми трендами и технологиями.
Это очень полезный навык, но, как мне кажется, его довольно сложно выработать, потому что, как будто бы, оно приходит само. Если тебе интересна эта сфера, ты так или иначе будешь искать новые интересности в ней.
Очень круто быть адаптивным и не токсичным. DevOps инженеры не работают никогда одни. Даже если ты единственный DevOps в команде, то обычно ты взаимодействуешь с коллегами и тестировщиками.
Если ты умеешь адаптироваться к новой обстановке и новым технологиям и не душнил, ты крутой инженер, и тебя любят.
Теперь пройдёмся по техническим скиллам. Вот базово что нужно знать начинающему DevOps инженеру.
Первое — это программирование. Здесь для начала достаточно самого базового уровня. Нужно уметь читать чужой код хотя бы примерно. Для начала хотя бы не бояться лезть в этот код.
Ну, то есть у вас есть какое-то приложение, оно не запускается, выдаёт ошибку. В ошибке есть ссылка на строку в определённом классе. Вы лезете туда, видите там дичь, идёте к разработчику, просите эту дичь устранить или даже сами устраняете.
Ну и нужно уметь написать какой-нибудь скрипт для упрощения своей работы или автоматизации чего-либо. Например, автоматизировать создание бэкапа или отправку его в сетевое хранилище.
В современном мире приложения в основном запускаются на серверах и виртуальных машинах, на которых, скорее всего, установлен Linux, какой-нибудь Ubuntu или CentOS.
Ты должен понимать, как оно устроено, как работает, знать основные команды, уметь искать проблемы в системе.
Самое неприятное, но очень важное — это сеть. Хотя бы нужно базово понимать, как устроен интернет, как взаимодействуют устройства между собой, что такое IP адрес, MAC адрес, маска подсети, как работает DNS, чем отличается TCP и UDP, HTTP коды ответов.
Это, скажем так, была инженерная часть. Теперь именно DevOps часть.
Подход Infrastructure as Code — это когда состояние инфраструктуры описывается в виде кода. Нужно понимать, почему вообще появился такой подход и какие технологии нам помогают решить эту проблему.
Например, Ansible, с помощью которого мы можем настраивать серверы и виртуальные машины, управлять конфигурациями, даже делать деплой каких-нибудь сервисов.
Про CI/CD нужно понимать в целом весь цикл разработки: от написания кода до доставки его на окружение.
Надо уметь написать какой-нибудь простенький пайплайн для сборки, тестирования, доставки приложения.
И про контейнеризацию. Для начала следует хотя бы понимать, что это вообще такое, чем отличается от виртуальных машин и, главное, какую проблему решают контейнеры.
С нуля прийти в DevOps довольно сложно. Нужно иметь уже какой-то опыт. Если ты совсем без опыта, то надо быть прям очень выделяющимся специалистом.
Либо волком. Считается, что обычно в DevOps приходят либо системные администраторы, которые хотят больше разбираться, что там написано в коде, больше автоматизировать доставку этого кода, либо разработчики, которые хотят понимать, как их код запускается и где он запускается, или что там вообще не работает и почему я должен так долго ждать, пока мне системный админ всё починит.
На моей памяти я больше всего встречал людей, которые в DevOps приходят из системного администрирования, причём почему-то так получается, что именно из сетевого администрирования.
Также в DevOps можно на самом деле прийти и из автоматизированного тестирования, потому что там ты уже понимаешь, что автоматизация — это наше всё.
Для начала про то, за что нам платят деньги. Мы ответственны за то, что наш сборочный конвейер работает стабильно и быстро.
Внезапно сломавшийся доступ между агентом и продакшеном может сильно навредить. А в случае варианта "и Швец, и жнец", когда мы делаем всё, DevOps инженер отвечает не только за автоматизацию доставки кода, но и за инфраструктуру продукта.
По сути, это, конечно, задача SRE, но мы живём в реальном мире, где чаще DevOps инженер больше похож на админа.
Компании готовы платить за стабильность работы продукта, а мы в ответе за это.
Автоматизация сборочного конвейера обычно делается для более быстрой доставки новых фич пользователю. Чем быстрее, чаще и стабильнее доставляются функции пользователю, тем больше платит клиент.
На маленьких масштабах или не продуктовых компаниях это может быть не так заметно, но в крупных, особенно в пересчёте на год или на два, цифры для бизнеса могут быть космическими.
DevOps инженеры могут внедрять новейшие технологии и практики, которые напрямую влияют на конкурентоспособность продуктов компании.
Инновации могут улучшить производительность, уменьшить затраты и открыть новые бизнес-возможности. Что делает роль DevOps инженера важной позицией.
Чтобы посмотреть, сколько нам вообще платят, предлагаю зайти сейчас на HeadHunter и посмотреть, что там предлагают по вакансиям на момент выхода этого видео.
Сразу скажу, что в HeadHunter вакансии начинаются от middle уровня, но в целом мы сейчас что-нибудь увидим.
Так, сначала выберем правильные фильтры: выберем тут специальность DevOps, зарплату поставим от 150, здесь выберем удалёнку, middle уровень вакансии.
И что нам предлагают? Окей, SRE от 150 до 400. То есть тут, скорее всего, пойдут и middle, и до senior позиций.
DevOps инженер — это DataOps, скорее всего, заниматься с данными. Инженер платформы в МегаФон от 200 до 208, развивать новые направления по работе с инфраструктурным кодом — звучит довольно интересно.
Системный администратор Citrix звучит неинтересно — администрировать чисто удалённые виртуальные рабочие столы. Не, спасибо.
Эксперт по мониторингу — это вот как раз про то, что я говорил, что бывают отдельные специалисты, которые занимаются мониторингом, отдельные специалисты, которые занимаются конкретно Citrix.
Ставки: DevOps инженер от 200. Но самое главное, что это, как я уже говорил, поддерживает администрировать различные окружения, консультировать коллег.
Инженер аналитик в Спортмастере — непонятно, как это сюда попало, но это именно поддержка. Окей, от 120 — что-то маловато.
Зато полная удалёнка. Администратор базы данных до 210 — уметь всякие Hadoop, Kubernetes. Ну, немножечко сомнительно, если честно, как будто бы мало денег.
Так вот у нас Best Doctor — DS инженер от 250 до 300, полная удалёнка. Нет указаний про Россию, вероятно, можно и за рубежом поработать. Поднимать сервисы в Kubernetes кластерах — звучит интересно.
Если мы здесь добавим себе фильтр senior по уровню вакансии, то у нас уже появляется Яндекс, который предлагает релокации, но с самостоятельным переездом.
И тут уже зарплаты идут от 300 до 400. Вот уже тут с переездом в Кипр.
Infrastructure инженер звучит довольно интересно — 4.500-5.000 евро в месяц. Вот тоже — от 4.500 евро в месяц. То есть как будто бы в среднем вакансии идут от 200.000 даже на middle уровне.
Думаю, на junior уровне мы можем смотреть что-то от 150.000 рублей в месяц.
А давай посмотрим статейку на Хабре с зарплатами специалистов во второй половине двадцать третьего года.
Здесь был график, который показывает зарплаты специалистов по эксплуатации. А мы как раз специалисты по эксплуатации.
В целом первые места у нас занимает инженер по доступности сервисов и DevOps инженер. Это у нас решки. Это DevOps.
Медиана у нас идёт 200-220.000, минималка тут совсем грустная, а по максимальной границе они указывают 400.000 рублей в месяц.
Вот такая получается ситуация. А на этом всё.
Надеюсь, теперь у вас есть более чёткое представление о том, что делает DevOps инженер и почему эта роль так важна в современной разработке.
Не забудьте подписаться на канал, чтобы не пропускать новые видео, и обязательно переходите в Telegram канал и чат. Там много чего интересного.
Спасибо за просмотр и до новых встреч!