python devops что такое
Про DevOps для тех, кто изучает Python
Ни за что не поверите, но оказывается IT это не только программисты. Индустрия очень стремительно разрастается и кроме разработчиков существуют project manager’ы, бизнес-аналитики, product owner’ы, scrum-мастера, тестировщики и DevOps’ы. Последние двое тесно связаны с программистами и принимают непосредственное участие в разработке ПО. К тестировщикам мы ещё вернёмся позже, а сегодня же попробуем разобраться, что скрывается за загадочным названием DevOps и как это всё связано с нашим любимым языком программирования Python.
Источник: vk.com/pylounge
Предположим программист написал код программы, всё здорово. Однако, просто файлика с исходным кодом недостаточно, чтобы люди могли пользоваться программой. Она должна быть загружена на сервер, этот сервер (возможно облачный) должен быть определённым образом настроен, должна быть установлена база данных, прикручены утилиты и необходимые технологии, которые необходимы нашему файлику с кодом. При этом, если запущенный сервер по какой-то причине вырубится, его надо запустить заново в максимально кратчайшие сроки, потому что пользователи не смогут работать с программкой, а бизнес начнёт терять деньги.
Кроме того, было бы круто, если команда программистов написала новый кусочек кода, этот кусочек «сам» сразу протестировался, и, если с ним всё хорошо, автоматически добавился в рабочий проект. Некоторая автоматическая проверка, доставка и интеграция кода (CI/CD).
Вот всем вышеперечисленным и занимается DevOps. DevOps инженер делает всё, чтобы код, написанный программистами, можно было использовать на практике. Собирает код, настраивает оборудование, разворачивает и поддерживает проекты. Если в вашей работе нужны такие страшные вещи, как Docker, Ansible, Kubernetes или AWS, то вам определённо к этим ребятам.
К слову у Лекса с канала АйТиБорода есть два классных интервью с матёрыми DevOps’ами. Прикрепляю.
Давайте теперь разберёмся, что и на каком уровне должен DevOps инженер касаемо языка Python, а затем пройдёмся по общим знаниям, навыкам и технологиям, которыми должен владеть DevOps для успешной работы.
Казалось бы, причём тут вообще Python? Как вы уже поняли DevOps подразумевает работу с циклом доставки, включая планирование, разработку, тестирование, развертывание, запуск и мониторинг ПО.
Это работа, в которой без автоматизации не обойтись. DevOps’ам часто приходится писать скрипты и утилиты, а значит требуется простой и удобный скриптовый язык с низким порогом вхождения. Смекаете?
Python отличный кандидат, главный любимец и негласный стандарт для большинства DevOps’ов. К тому же многие инструменты, например, Ansible, написаны на Python. Кроме Python иногда используют Ruby или Go, но всё-таки реже.
Надо понимать, что DevOps – не Python-программист и ему не надо обладать невероятно глубокими познаниями в языке и соответствующими best practice’сами. Достаточно базовых, но уверенных знаний и навыков программирования.
Надо разобраться с:
Переменными, типами и структурами данных (list, dict, set).
Стандартными конструкциями, к которым относится if и циклы
Функции, декораторы функций и области видимости
Пакеты, модули, импорты
ООП и классы на базовом уровне
пакетный менеджер pip и модулю для работы с виртуальным окружением venv
и немного асинхронности asyncio и многопоточности/многопроцессности в лице multithreading/multiprocessing также не помешает
Из библиотек и модулей особое внимание стоит уделить:
Для работы с командной строкой: sys и subprocess
Модули, которые позволяют работать с операционной системой: os
Часто приходится работать с датой и временем поэтому datetime и time
Регулярные выражения мощный подручный инструмент – re
Selenium, requests, lxml для тестирования
Библиотека для написания юнит-тестов pytest
Ну и logging или Loguru для ведения логов.
Есть кстати отличная книжка Python for DevOps, рекомендую ознакомиться.
Python for DevOps: Learn Ruthlessly Effective Automation
Переходим к общим знаниям и технологиям. Я приведу здесь необходимый минимальный набор, потому что сами понимаете, в DevOps, как и в разработке расти можно бесконечно.
Обязательно надо разбираться в операционных системах, в частности Linux. Причём обладать надо действительно уверенными знаниями, понимать, как он устроен, уметь работать с командной строкой, знать команды, утилиты и т.д. Linux – это «Отче наш» для DevOps. Советую разобраться с каким-нибудь одним дистрибутивом семейства Debian, например, сам Debian или Ubuntu Server, и с одним дистрибутивом семейства RedHat, например, CentOS.
Из этого плавно вытекает умение писать скрипты на Bash в Linux и PowerShell в Windows.
Людям, планирующим начать изучение Linux рекомендую канал Kirill Semaev. Лучший, по моему мнению, канал в RU сегменте по данной тематике.
Весь мир уходит в облачные платформы, поэтому необходимо ознакомиться с одним из облачных сервисов Amazon Web Service, Google Platform или Azure. Я рекомендую начать с AWS.
К слову у нас на канале есть видео, посвящённое MS Azure. Также оставлю здесь.
Далее следует освоить ряд таких инструментов как: Docker для работы с контейнерами, Kubernetes для оркестрации, управления контейнерами, обязательно систему контроля версий Git, Ansible в качестве системы управления конфигурациями, ну и Jenkins, как основной инструмент непрерывной интеграции ПО.
Кроме того, надо в целом понимать, процесс CI/CD, что такое API, базы данных, ну и, конечно без английского языка ловить нечего.
А теперь вопрос от зрителей. Некий Юрий Дудь спрашивает, что там по зарплатам?
Тут, как это обычно бывает, всё зависит от компаний. Бывает компания нанимает DevOps’сов непосредственно к себе в штат, есть люди, работающие на аутсорсе, но в целом по российскому рынку наблюдается следующая картина:
Junior DevOps может рассчитывать на 50-90 000 р.
Middle DevOps в среднем 100 000 – 180 000 р.
Senior DevOps получает от 200 000 и потолок ограничивается масштабами компании.
Скриншот с сайта hh.ru на момент 08.08.2021
Требования к знаниям растут соответствующем образом.
Безусловно знать надо много, изучать придётся ещё больше, но это справедливо для абсолютно любой профессиональной деятельно. Если вы любите работать с технологиями и хотите получать солидные деньги, но при этом перспектива писать код по 8 часов в день вас не прельщает, или вы уже работаете системным администратором, но хотите чего-то больше, то DevOps это отличный вариант для устройства успешной карьеры.
Кто такой DevOps и как им стать: план обучения
Кто такой DevOps-инженер, чем занимается и как им стать — рассказывает Василий Озёров, руководитель международной команды Fevlake и SVP of Infrastructure в Airpush Inc.
В этой статье я постараюсь рассказать о том, что требуется ИТ-специалисту, чтобы стать DevOps-инженером. Но сначала несколько слов о себе, чтобы познакомиться поближе. Меня зовут Василий, работаю SVP of Infrastructure в одной из рекламных компаний, владею собственным бизнесом и на досуге пишу в свой канал Хмельной DevOps.
С Unix системами я познакомился в далеком 2005 году, ещё будучи учеником лицея. О да, те незабываемые ночи, проведенные за установкой FreeBSD и компиляцией KDE из исходников. К слову, именно благодаря этому я и нашел свою первую работу, где разрабатывал небольшие проекты на QT/C++, занимался настройкой Cisco, а также поднимал почтовые сервера.
И вот, наконец, я попал в геймдев компанию, где и начал свою карьеру DevOps-специалиста. Активное взаимодействие разработчиков и команды эксплуатации погрузили меня в доселе невиданный мир. До этого момента путь кода от разработчика на продакшн виделся мне огромной черной бездной, в которой было невозможно ничего разглядеть.
Но, окунувшись в неё с головой, я понял, что все не так уж и страшно. Я увидел, как приложения собираются, как тестируются, как уходят в продакшн, где их видит весь интернет. Давайте приподнимем завесу тайны и посмотрим, как же стать успешным DevOps-инженером.
Что такое DevOps?
DevOps — это сокращение от Development Operations, и, на самом деле, это не название профессии. Это культура, методика, если угодно. DevOps-движение возникло в 2008 году и было призвано решить накопившиеся проблемы. Очень много компаний видели проблему во взаимодействиях команд разработки и эксплуатации.
Разработчики считали, что если код запустился у них локально, то нет проблем — можно запускать в продакшен. Если всё же проблемы возникали, то со стороны команды эксплуатации звучало: «Да это проблемы с кодом, пусть разработчики разбираются». Из-за такого подхода релизы продуктов постоянно затягивались и зачастую страдало качество конечного продукта. Сильно накладывало отпечаток ещё и то, что за один релиз выкатывалось очень много изменений и было очень трудно разобраться, что же породило проблемы на продакшене.
DevOps был призван решить эти проблемы. Он должен был стать связующим звеном между командой разработки и командой эксплуатации. Условно, в DevOps культуре можно выделить несколько ролей, которые очень хорошо соотносятся с профессиями:
В целом можно выделить ещё несколько ролей. Например, Security Engineer, который будет отвечать за прогон security-тестов и изучение уязвимостей в используемых компонентах.
В реальном мире все (или почти все) эти роли по отдельности обычно совмещает какой-нибудь другой человек. К примеру, роль билд-инженера можно отдать в руки разработчика. Да и автоматизация настройки серверов обычно отдается системным администраторам. А DevOps-специалисту остаётся проработать и автоматизировать процесс сборки и доставки кода от разработчика в продакшн.
Что должен знать DevOps-инженер?
Строго говоря, никаких специальных требований к DevOps-студенту не предъявляется, но вход в профессию будет намного легче, если вы с порога обладаете некоторыми навыками.
Senior System Administrator
Или хотя бы Middle. Идея в том, что вы должны на хорошем уровне разбираться в среде, в которой будут работать ваши приложения. Как они стартуют (init, systemd), что делать, если вы видите ошибку too many open files, использовать или не использовать swap. Все это очень сильно пригодится, когда вы будете запускать реальные проекты.
Networking — CCNA
Очень важная вещь, хотя про это забывают многие разработчики. Я считаю, что нельзя писать онлайн-сервисы, не понимая, как работает сеть. Никто не говорит, что надо заучивать семь уровней модели OSI, но точно потребуется знать, как работает IP, TCP/UDP и, конечно, протокол уровня приложения — например, HTTP, HTTP/2. Это сохранит вам кучу нервов выискивая причины ошибки Connection Refused.
Junior Developer
Да-да. Вы должны представлять, как пишется код, что такое ООП, что такое потоки и ещё кучу разных вещей. В общем, чем больше у вас знаний в этом пункте, тем легче вам будет собрать и выкатить приложение.
Многие могут не согласиться со мной, аргументируя это тем, что код должен писать разработчик. Но, простите, если вы не понимаете, как создаётся программный продукт, то как вы будете автоматизировать его сборку, тестирование и депплой? Сможете ли вы заметить узкое место в архитектурном решении до того, как оно попадет на продакшн?
Чтобы ответить на эти вопросы, все же необходимо немного углубиться в основные понятия. С чего начать:
Junior DBA
На самом деле это входит в предыдущий пункт, но я все же решил его вынести отдельно. Поскольку все текущие проекты в любом случае используют базы данных, было бы неплохо уметь писать SQL запросы, использовать explain и понимать, как работают и зачем нужны index‘ы. Ну и до кучи посмотреть на популярные NoSQL решения.
Судя по моей личной статистике, чаще всего в DevOps приходят люди из эксплуатации, поскольку у разработчиков обычно не прокачан первый скилл из списка. Но я знаю два случая из жизни, когда senior developers становились DevOps, потому что им надоело, как работает эксплуатация. И, к слову, помимо технических навыков вам точно потребуются некоторые софт скилы. Как минимум вы будете очень много общаться со всеми заинтересованными сторонами. Также вы будете продвигать новые идеи и технологии, что потребует от вас умения ясно и четко доносить свои мысли и умение спорить. Про стрессоустойчивость писать не буду, но терпение вам точно понадобится, поскольку внедрить новую крутую технологию зачастую невозможно в течение одного дня.
Как стать DevOps-инженером?
Вообще DevOps-инженер — это больше про опыт, нежели про знание конкретного софта. Девопс-ребята постоянно учатся, изучают и тестируют новые проекты и технологии. Они должны постоянно задавать себе вопрос: улучшит ли эта технология наш проект? Что лучше выбрать в качестве языка: Ruby, Python, Go или написать на чистых плюсах? А как мы будем доставлять изменения в продакшен, чтобы не поломать работающие системы?
Главное, что надо понимать, — DevOps-специалист обладает действительно хорошим кругозором. Чтобы его расширить необходимо постоянно заниматься самообучением. Ниже я привел примерные шаги, которые помогут вам вырасти из, например, системного администратора в DevOps-инженера. Запомните: список всего лишь указывает направление, оттачивать навыки придётся вам самим.
Главной целью всех этих шагов является получение опыта работы с различными технологиями. Я уже говорил, что самое главное для DevOps-специалиста — это кругозор, так что берем эти же 17 пунктов и в каждом из них меняем технологию на новую. Писали приложение на Go? Теперь пишем на Ruby. Использовали Jenkins? Берём TeamCity. Поднимали Kubernetes? Настраиваем swarm. Таким нехитрым образом через несколько месяцев вы заранее сможете понять, что лучше использовать в конкретной ситуации, а это — самое главное качество грамотного и успешного DevOps.
Заключение
Да, стать DevOps-инженером с нуля не так-то просто, серебряной пули не существует. Не существует её и в любой другой области. Всегда придётся изучать, читать, пробовать. Но после 10-ой итерации вы войдёте во вкус. Вы не будете пропускать ни одной интересной софтинки, станете изучать и пробовать всё новое и неизведанное. А новое и неизведанное — это всегда круто. Кто бы там что ни говорил, дерзайте!
Кто такой DevOps-инженер, что он делает, сколько зарабатывает и как им стать
DevOps-инженеры — это многопрофильные специалисты, которые умеют автоматизировать процессы и знают, как работают разработчики, QA и менеджеры. Они умеют программировать, быстро осваивают сложные инструменты и не теряются перед незнакомой задачей. DevOps-инженеров мало — им готовы платить по 200–300 тысяч рублей, но вакансий всё равно много.
Дмитрий Кузьмин рассказывает, чем конкретно занимается DevOps и что нужно изучить, чтобы претендовать на такую должность. Бонусом — важные ссылки на книги, видео, каналы и профессиональное сообщество.
Чем занимается DevOps-инженер
В ситуации с DevOps важно не путать термины. Дело в том, что DevOps — это не какое-то конкретное направление деятельности, а профессиональная философия. Это методология, которая помогает разработчикам, тестировщикам и системным администраторам работать быстрее и эффективнее за счёт автоматизации и бесшовности.
Соответственно, DevOps-инженер — это специалист, который внедряет эту методологию в процесс работы:
Всё, что написано выше, происходит в близких к идеальным проектах. В реальном же мире приходится стартовать в проекте, где планирование пропустили, с архитектурой ошиблись, а об автоматизации задумались, когда все проекты встали. И разобраться во всех этих проблемах, решить их и сделать так, чтобы всё работало — ключевой навык DevOps-специалиста.
На рынке кадров есть путаница. Иногда бизнес ищет DevOps-инженеров на позицию системного инженера, билд-инженера или кого-то ещё. Обязанности в зависимости от размера компании и направления тоже меняются — где-то ищут человека на консалтинг, где-то просят всё автоматизировать, а где-то требуют выполнять расширенные функции системного администратора, умеющего программировать.
Что нужно для старта в профессии
Вход в профессию требует предварительной подготовки. Просто прийти на курсы с нуля, ничего не понимая в IT, и выучиться до уровня junior не получится. Нужен технический бэкграунд:
Что должен знать DevOps
Хороший DevOps-инженер — это многопрофильный специалист с очень большим кругозором. Для успешной работы вам придётся разобраться сразу в нескольких IT-направлениях.
Разработка
DevOps напишет скрипт, который поможет разработчикам устанавливать код на сервер. Сделает программу, которая «на лету» тестирует отзывчивость баз данных. Напишет приложение для контроля за версионностью. Наконец, просто заметит потенциальную проблему в разработке, которая может появиться на сервере.
Сильный DevOps-специалист знает несколько языков, подходящих для автоматизации. Разбирается в них не досконально, но быстро напишет небольшую программу или прочитает чужой код. Если раньше с разработкой не сталкивались, начните с Python — у него простой синтаксис, на нём легко работать с облачными технологиями, есть много документации и библиотек.
Операционные системы
Знать все возможности каждой версии каждой системы невозможно — на такое обучение можно потратить тысячи часов и толку не будет. Вместо этого хороший DevOps понимает общие принципы работы на любой ОС. Хотя, судя по упоминаниям в вакансиях, большинство сейчас работают в Linux.
Хороший инженер понимает, в какой системе лучше разворачивать проект, какими инструментами пользоваться и какие потенциальные ошибки могут появиться в процессе внедрения или эксплуатации.
Облака
Рынок облачных технологий растёт в среднем на 20-25% в год — такая инфраструктура позволяет автоматизировать операции тестирования кода, сборки приложений из компонентов, доставки обновлений до пользователей. Хороший DevOps разбирается как в полностью облачных, так и в гибридных решениях.
В стандартных же требованиях к инженерам обычно значится GCP, AWS и Azure.
Сюда можно отнести и владение инструментами CI/CD. Обычно для непрерывной интеграции используется Jenkins, но стоит попробовать и аналоги. Их много, например, Buddy, TeamCity и Gitlab CI. Полезным будем изучить Terraform — это декларативный инструмент, помогающий удалённо поднимать и настраивать инфраструктуру в облаках. И Packer, который нужен для автоматического создания образов ОС.
Системы оркестрации и микросервисы
У микросервисной архитектуры есть много преимуществ — стабильность, возможность быстрого масштабирования, упрощение и повторные использования. DevOps понимает, как работают микросервисы, и может предупредить потенциальные проблемы.
Досконально знает Docker и Kubernetes. Понимает, как работают контейнеры, как строить систему так, чтобы можно было отключать часть из них без последствий для общей системы в целом. Например, умеет построить Kubernetes-кластер при помощи Ansible
Что ещё попробовать будущему DevOps
Перечислять инструменты, которые могут пригодиться в работе DevOps-инженеру, можно бесконечно. Кто-то работает над оркестрацией проектов, другие большую часть времени занимаются автоматизацией развёртывания и тестирования, третьи повышают эффективность в управлении конфигурациями. В процессе будет понятно, куда копать и какие проекты пригодятся.
Вот ещё небольшой минимум, который поможет на старте:
Почему стоит начать изучать DevOps сейчас
На рынке DevOps-инженеров — кадровый голод. Это условно подтверждается количеством и качеством вакансий:
Обратите внимание на зарплатные требования соискателей
Не меньше востребован DevOps и в мире — если вы собрались на релокацию в США или Европу, то только на портале Glassdoor таких специалистов ищут больше 34 тысяч компаний. Из частых требований — опыт 1–3 года, умение работать с «облаками» и не бояться консалтинговых функций.
На фрилансе предложений в разы меньше — DevOps-инженеров в основном ищут в штат и на полный день.
Найти подходящий проект на фрилансе сложно, но можно
Условный карьерный путь DevOps-инженера можно представить примерно так:
DevOps — это сложно. Нужно сочетать в себе навыки сразу нескольких профессий. Стать человеком, который готов предложить улучшение там, где другие IT-специалисты даже не думают о чем-то другом. За это много платят, но и объем знаний потребуется большой.
Сколько зарабатывают DevOps
Средняя медианная зарплата по данным за второй квартал 2019 года у девопсов находится в вилке между 90 и 160 тысячами рублей. Есть предложения дешевле — в основном 60–70 тысяч.
Постоянно есть предложения до 200 тысяч, встречаются вакансии с зарплатой до 330 тысяч рублей.
Среди специалистов по эксплуатации DevOps оплачивается выше остальных. Источник: Хабр.Карьера
DevOps-инженеры, в том числе начинающие, сейчас требуются в крупные банки, корпорации, облачные сервисы, торговые системы и другие организации, которые заботятся о поддержании своих IT-решений.
Отличным кандидатом на младшую вакансию с зарплатой в 60–90 тысяч станет начинающий системный администратор с опытом около года и профильным дипломом.
Такой статистики нет, но по ощущениям, людям, у которых есть опыт в Linux, платят больше
Что смотреть и читать для роста в профессии
Чтобы погрузиться в мир DevOps, попробуйте сразу несколько источников информации:
Где учиться на DevOps
Получить структурированные знания можно на курсе «DevOps-инженер» в Нетологии. Вы научитесь полному циклу методологии:
Кто такие DevOps?
На данный момент это чуть ли не самая дорогая позиция на рынке. Суета вокруг «DevOps» инженеров превосходит все мыслимые пределы, а тем хуже с Senior DevOps инженерами.
Я работаю руководителем отдела интеграции и автоматизации, угадайте английскую расшифровку — DevOps Manager. Отражает ли именно английская расшифровка нашу повседневную деятельность — вряд ли, а вот русский вариант в данном случае более точен. По роду моей деятельности, естественно, что мне, необходимо собеседовать будущих членов моей команды и, за прошедший год, через меня прошло человек 50, а еще столько же срезалось на прескрине с моими сотрудниками.
Мы все еще находимся в поиске коллег, потому как за лейблом DevOps прячется очень большая прослойка разного рода инженеров.
Все написанное ниже является моим личным мнением, вы не обязаны соглашаться с ним, однако допускаю, что внесет оттенок в ваше отношение к теме. Несмотря на риск попасть в немилость, я публикую свое мнение, поскольку считаю что ему есть место быть.
Компании по-разному понимают кто такие DevOps инженеры и ради быстрого найма ресурса вешают этот лейбл всем. Ситуация достаточно странная, поскольку компании готовы платить нереальные вознаграждения этим людям, получая за них, в большинстве случаев, админа-тулзиста.
Так кто же такие DevOps инженеры?
Давайте начнем с истории появления — Development Operations появился как еще один шаг к оптимизации взаимодействия в малых командах для повышения скорости производства продукта, как ожидаемое следствие. Идея заключалась в том, чтобы усилить команду разработки знаниями о процедурах и подходах в управлении продуктовой средой. Иными словами, разработчик должен понимать и знать как его продукт работает в тех или иных условиях, должен понимать как деплоить его продукт, какие характеристики среды подкрутить, чтобы повысить производительность. Так, в течение некоторого времени, появились разработчики с DevOps подходом. DevOps разработчики писали скрипты сборки и упаковки для упрощения своей деятельности и работоспособности продуктивной среды. Однако, сложность архитектуры решений и взаимное влияние компонентов инфраструктуры с течением времени начало ухудшать рабочие показатели сред, с каждой итерацией требовались все более глубокие понимания тех или иных компонентов, снижая продуктивность самого разработчика из-за дополнительных затрат на понимание компонентов и тюнинга систем под конкретную задачу. Собственная стоимость разработчика росла, стоимость продукта вместе с ним, резко подскочили требования к новым разработчикам в команде, ведь им необходимо было также покрывать обязанности «звезды» разработки и, естественно, «звезды» становились все менее доступны. Также стоит отметить, что, по моему опыту, мало кому из разработчиков интересна специфика обработки пакетов ядром операционной системы, правила маршрутизации пакетов, аспекты безопасности хоста. Логичным шагом было привлечь администратора, который именно с этим знаком и возложить подобного формата обязанности именно на него, что, благодаря его опыту, позволило достичь тех же показателей меньшей стоимостью в сравнении со стоимостью «звезды» разработки. Таких администраторов помещали в команду и основной его задачей было управление тестовыми и продуктивными средами, на правилах конкретно взятой команды, с ресурсами выделенными именно этой команде. Так, собственно, и появились DevOps в представлении большинства.
Частично или полностью, со временем, данные системные администраторы начали понимать потребности именно этой конкретной команды в области разработки, как упростить жизнь разработчикам и тестировщикам, как выкатить обновление и не остаться ночевать в пятницу в офисе, исправляя ошибки деплоя. Время шло, теперь «звездами» становились системные администраторы, понимающие чего хотят разработчики. С целью минимизации импакта начали подтягиваться утилиты управления, все вспомнили старые и надежные методы изоляции уровня ОС, которые позволяли минимизировать требования по безопасности, управлению сетевой части, да и конфигурации хоста в целом и, как следствие снизить требования к новым «звездам».
Появилась «замечательная» вещь — docker. Почему замечательная? Да только лишь потому, что создание изоляции в chroot или jail, равно как OpenVZ, требовало нетривиальных знаний ОС, в контру утилите позволяющей элементарно создать изолированную среду приложения на неком хосте со всем необходимым внутри и передать бразды правления разработке вновь, а системному администратору управлять только лишь одним хостом, обеспечивая его безопасность и высокую доступность — логичное упрощение. Но прогресс не стоит на месте и системы вновь становятся все сложнее и сложнее, компонентов все больше и больше, один хост уже не удовлетворяет потребностям системы и необходимо строить кластеры, мы вновь возвращаемся к системным администраторам, которые способны построить данные системы.
Цикл за циклом, появляются различные системы упрощающие разработку и/или администрирование, появляются системы оркестрации, которые, ровно до тех пор, пока не требуется отойти от стандартного процесса, просты в использовании. Микросервисная архитектура также появилась с целью упрощения всего описанного выше — меньше взаимосвязей, проще в управлении. В своем опыте я не застал полностью микросервисную архитектуру, я бы сказал 50 на 50 — 50 процентов микросервисов, черные коробки, пришло на вход, вышло обработанное, другие 50 — разодранный монолит, сервисы неспособные работать отдельно от других компонентов. Все это вновь наложило ограничения на уровень знаний как разработчиков, так администраторов.
Подобные «качели» уровня экспертных знаний того или иного ресурса продолжаются и по сей день. Но мы немного отвлеклись, есть немало моментов которые стоит осветить.
Build Engineer/Release Engineer
Весьма узкоспециализированные инженеры, появившиеся как средство стандартизации процессов сборки ПО и его релизов. В процессе введения повального Agile казалось бы они перестали быть востребованы, однако это далеко не так. Эта специализация появилась как средство стандартизации именно сборки и поставки ПО в промышленных масштабах, т.е. используя стандартные техники для всех продуктов компании. С появлением DevOps разработчиков частично утратили функции, поскольку именно разработчики стали подготавливать продукт к поставке, а учитывая изменяющуюся инфраструктуру и подход в максимально быстрой поставке без оглядки на качество со временем превратились именно в стопор изменений, поскольку следование стандартам качества неизбежно замедляет поставки. Так, постепенно, часть функционала Build/Release инженеров перекочевала на плечи системных администраторов.
Ops’ы такие разные
DevOps — (в теории) персона, не понаслышке понимающая все процессы цикла разработки — разработку, тестирование, понимающая архитектуру продукта, способная оценить риски безопасности, знакомая с подходами и средствами автоматизации, хотя бы на высоком уровне, помимо этого понимающая также пред и пост-релизную поддержку продукта. Персона способная выступать адвокатом как Operations, так Development, что позволяет выстроить благоприятное сотрудничество между этими двумя столпами. Понимающая процессы планирования работ командами и управления ожиданиями заказчика.
Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officier.
Так ли это в вашей компании? — Сомневаюсь. В большинстве случаев это или IT, или R&D.
Недостаток средств и возможности влияния хотя бы на одно из этих трех направлений деятельности произведет смещение веса проблем в сторону где эти изменения проще применить, как например применение технических ограничений на релизы в связи с «грязным» кодом по данным систем статического анализатора. То есть когда PMO устанавливает жесткий срок на выпуск функционала, R&D не может выдать качественный результат в эти сроки и выдает его как может, оставив рефакторинг на потом, DevOps относящийся к IT, техническими средствами блокирует релиз. Недостаток полномочий на изменение ситуации, в случае с ответственными сотрудниками ведет к проявлению гиперответственности за то, на что они не могут повлиять, тем паче если эти сотрудники понимают и видят ошибки, и как их исправить — «Счастье в неведении», и как следствие к выгоранию и потери этих сотрудников.
Рынок DevOps ресурсов
Давайте рассмотрим несколько вакансий на позицию DevOps от разных компаний.
Резюмируя по данной вакансии можно сказать, что ребятам достаточно Middle/Senior System Administrator.
Кстати, не стоит сильно разделять админов на Linux/Windows. Я конечно понимаю, что сервисы и системы этих двух миров различаются, но основа у всех одна и любой уважающий себя админ знаком как с одним, так и с другим, и даже если не знаком, то для грамотного админа не составит труда ознакомится с этим.
Рассмотрим иную вакансию:
Резюмируя — Middle/Senior System Administrator
Хотелось бы также оставить ремарку относительно 3 пункта, дабы укрепить понимание, почему этот пункт покрывается сисадмином. Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все. Для примера возьмем ‘build framework’ Make, коего фреймворком я, к слову, не считаю. Да, я знаю про моду пихать Make куда угодно, где нужно и не нужно — обернуть Maven в Make например, серьезно?
По сути Make просто обертка над shell, упрощающая именно команды компиляции, линковки, окружения компиляции, так же как и k8s.
Однажды, я собеседовал парня, который использовал k8s в своей работе поверх OpenStack, и он рассказывал как развертывал сервисы на нем, однако, когда я спросил именно про OpenStack, оказалось, что он администрируется, равно как и подымается системными администраторами. Вы правда думаете, что человек поднявший OpenStack вне зависимости от того какую платформу он использует позади него не способен использовать k8s?=)
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.
Резюмируем в очередной раз — Middle/Senior System Administrator им будет достаточно.
Сколько вешать в граммах
Разброс предлагаемых зарплат для указанных вакансий — 90к-200к
Теперь хотелось бы провести параллель между денежными вознаграждениями Системных Администраторов и DevOps Engineers.
В принципе, для упрощения можно грейды по опыту работы раскидать, хоть это и не будет точным, для целей статьи хватит.
Сайт поиска сотрудников предлагает:
System Adminsitrators:
По стажу «DevOps»’ов использовался стаж, хоть как то затрагивающий SDLC.
Из вышеозначенного следует, что на самом деле компаниям не нужны DevOps’ы, а также что они могли сэкономить не менее 50 процентов от изначально запланированных затрат, наняв именно Администратора, более того, они могли бы четче определить обязанности искомого человека и быстрее закрыть потребность. Не стоит также забывать, что четкое разделение ответственности позволяет снизить требования к персоналу, а также создать более благоприятную атмосферу в коллективе, ввиду отсутствия пересечений. В подавляющем большинстве вакансии пестрят утилитами и DevOps лейблами, однако не имеющие в основе действительно требования к DevOps Engineer, лишь запросы на тулзового администратора.
Процесс обучения DevOps инженеров также ограничен лишь набором специфичных работ, утилит, не дает общего понимания процессов и их зависимостей. Это конечно хорошо, когда человек может используя Terraform задеплоить AWS EKS, в связке с Fluentd сайд-каром в этом кластере и AWS ELK стеком для системы логирования за 10 минут, используя лишь одну команду в консоли, но если он не будет понимать сам принцип обработки логов и для чего они нужны, не знать как собирать метрики по ним и отслеживать деградацию сервиса, то это будет все тот же эникей, умеющий использовать некоторые утилиты.
Спрос, однако, порождает предложение, и мы видим крайне перегретый рынок позиции DevOps, где требования не соответствуют реальной роли, а лишь позволяют системным администраторам зарабатывать больше.
Так кто же они? DevOps’ы или жадные системные администраторы? =)
Как дальше жить?
Работодателям — точнее формулировать требования и искать именно тех кто нужен, а не разбрасываться лейблами. Вы не знаете чем занимаются DevOps — они вам не нужны в таком случае.
Работникам — Учиться. Постоянно совершенствовать свои знания, смотреть на общую картину процессов и отслеживать путь к поставленной цели. Можно стать кем захочешь, надо лишь постараться.