Build engineer кто это

Кто такие 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’ы такие разные

Мы двигаемся дальше и вновь наличие большого круга обязанностей и недостаток квалифицированных кадров толкает нас на жесткую специализацию, как грибы после дождя, появляются различные Operations:

TechOps — системные администраторы эникеи aka HelpDesk Engineer
LiveOps — системные администраторы, преимущественно отвечающие за продуктивные среды
CloudOps — системные администраторы специализирующиеся на публичных «облаках» Azure, AWS, GCP, etc.
PlatOps/InfraOps/SysOps — системные администраторы инфраструктуры.
NetOps — сетевые администраторы
SecOps — системные администраторы специализирующиеся на информационной безопасности — PCI compliance, CIS compliance, patching, etc.

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

Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officier.

Так ли это в вашей компании? — Сомневаюсь. В большинстве случаев это или IT, или R&D.

Недостаток средств и возможности влияния хотя бы на одно из этих трех направлений деятельности произведет смещение веса проблем в сторону где эти изменения проще применить, как например применение технических ограничений на релизы в связи с «грязным» кодом по данным систем статического анализатора. То есть когда PMO устанавливает жесткий срок на выпуск функционала, R&D не может выдать качественный результат в эти сроки и выдает его как может, оставив рефакторинг на потом, DevOps относящийся к IT, техническими средствами блокирует релиз. Недостаток полномочий на изменение ситуации, в случае с ответственными сотрудниками ведет к проявлению гиперответственности за то, на что они не могут повлиять, тем паче если эти сотрудники понимают и видят ошибки, и как их исправить — «Счастье в неведении», и как следствие к выгоранию и потери этих сотрудников.

Рынок DevOps ресурсов

Давайте рассмотрим несколько вакансий на позицию DevOps от разных компаний.

Владеете Zabbix и знаете, что такое Prometheus;
Iptables;
Аспирант BASH;
Профессор Ansible;
Гуру Linux;
Умеете пользоваться дебагом и совместно с разработчиками находить проблемы приложений (php/java/python);
Роутинг не вызывает у Вас истерик;
Уделяете значительное внимание безопасности системы;
Бекапите “всё и вся“, а также успешно восстанавливаете это “всё и вся“;
Умеете настроить систему так, чтобы выжать из минимума — максимум;
Настраиваете репликации перед сном на Postgres и MySQL;
Настройка и корректировка CI/CD для Вас — это необходимость как завтрак/обед/ужин.
Имеете опыт работы с AWS;
Готовы развиваться вместе с компанией;

с 1 по 6 — системный администратор
7 — немного сетевого администрирования, что тоже укладывается в сисадмина, уровня Middle
8 — немного безопасности, что обязательно для сисадмина уровня Middle
9-11 — Middle System Administrator
12 — В зависимости от поставленных задач либо Middle System Administrator, либо Build Engineer
13 — Виртуализация — Middle System Administrator, либо так называемый CloudOps, расширенные знания именно сервисов конкретной хостинг площадки, для эффективного использования денежных средств и снижения нагрузки на обслуживание

Резюмируя по данной вакансии можно сказать, что ребятам достаточно Middle/Senior System Administrator.

Кстати, не стоит сильно разделять админов на Linux/Windows. Я конечно понимаю, что сервисы и системы этих двух миров различаются, но основа у всех одна и любой уважающий себя админ знаком как с одним, так и с другим, и даже если не знаком, то для грамотного админа не составит труда ознакомится с этим.

Рассмотрим иную вакансию:

Опыт построения высоконагруженных систем;
Отличные знания ОС Linuх, общесистемного ПО и веб-стека (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
Опыт работы с системами виртуализации (KVM, VMWare, LXC/Docker);
Владение скриптовыми языками;
Понимание принципов работы сетей сетевых протоколов;
Понимание принципов построения отказоустойчивых систем;
Самостоятельность и инициативность;

1 — Senior System Administrator
2 — В зависимости от смысла вкладываемого в этот стэк — Middle/Senior System Administrator
3 — Опыт работы, в том числе, может означать — «Кластер не подымал, но создавал и управлял виртуалками, был один Docker хост, доступ к контейнерам натил» — Middle System Administrator
4 — Junior System Administrator — да, админ не умеющий писать элементарные скрипты автоматизации, вне зависимости от языка, не админ — эникей.
5 — Middle System Administrator
6 — Senior System Administrator

Резюмируя — Middle/Senior System Administrator

Опыт работы devops;
Опыт в использовании одного или нескольких продуктов для формирования CI/CD процессов. Gitlab CI будет преимуществом;
Работа с контейнерами и виртуализацией; Если использовали docker – хорошо, а если k8s – отлично!
Опыт работы в agile-команде;
Знание любого языка программирования;

1 — Хм… Что ребята имеют в виду? =) Скорее всего они сами не знают что за этим скрывается
2 — Build Engineer
3 — Middle System Administrator
4 — Софт-скил, рассматривать пока не будем, хотя Agile еще одна вещь, которую интерпретируют так, как удобно.
5 — Слишком пространно — это может быть скриптовый язык, либо компилируемый. Интересно, а писал в школе на Pascal и Basic их устроит? =)

Хотелось бы также оставить ремарку относительно 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.

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

до 3-х лет — Junior
до 6-ти лет — Middle
более 6-ти — Senior

Сайт поиска сотрудников предлагает:
System Adminsitrators:

Junior — 2 года — 50к руб.
Middle — 5 лет — 70к руб.
Senior — 11 лет — 100к руб.

Junior — 2 года — 100к руб.
Middle — 3 года — 160к руб.
Senior — 6 лет — 220к руб.

По стажу «DevOps»’ов использовался стаж, хоть как то затрагивающий SDLC.

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

Процесс обучения DevOps инженеров также ограничен лишь набором специфичных работ, утилит, не дает общего понимания процессов и их зависимостей. Это конечно хорошо, когда человек может используя Terraform задеплоить AWS EKS, в связке с Fluentd сайд-каром в этом кластере и AWS ELK стеком для системы логирования за 10 минут, используя лишь одну команду в консоли, но если он не будет понимать сам принцип обработки логов и для чего они нужны, не знать как собирать метрики по ним и отслеживать деградацию сервиса, то это будет все тот же эникей, умеющий использовать некоторые утилиты.

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

Так кто же они? DevOps’ы или жадные системные администраторы? =)

Как дальше жить?

Работодателям — точнее формулировать требования и искать именно тех кто нужен, а не разбрасываться лейблами. Вы не знаете чем занимаются DevOps — они вам не нужны в таком случае.

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

Вы отправили слишком много запросов, поэтому ваш компьютер был заблокирован.

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

Кто такой DevOps и как им стать: план обучения

Как стать DevOps-инженером? В этой статье мы разобрались, что должен знать DevOps-специалист, делимся инструментами и планом обучения.

Кто такой DevOps-инженер, чем занимается и как им стать — рассказывает Василий Озёров, руководитель международной команды Fevlake и SVP of Infrastructure в Airpush Inc.

Что такое DevOps?
Что должен знать DevOps-инженер?
Как стать специалистом в DevOps?
Заключение

В этой статье я постараюсь рассказать о том, что требуется ИТ-специалисту, чтобы стать DevOps-инженером. Но сначала несколько слов о себе, чтобы познакомиться поближе. Меня зовут Василий, работаю SVP of Infrastructure в одной из рекламных компаний, владею собственным бизнесом и на досуге пишу в свой канал Хмельной DevOps.

С Unix системами я познакомился в далеком 2005 году, ещё будучи учеником лицея. О да, те незабываемые ночи, проведенные за установкой FreeBSD и компиляцией KDE из исходников. К слову, именно благодаря этому я и нашел свою первую работу, где разрабатывал небольшие проекты на QT/C++, занимался настройкой Cisco, а также поднимал почтовые сервера.

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

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

Что такое DevOps?

DevOps — это сокращение от Development Operations, и, на самом деле, это не название профессии. Это культура, методика, если угодно. DevOps-движение возникло в 2008 году и было призвано решить накопившиеся проблемы. Очень много компаний видели проблему во взаимодействиях команд разработки и эксплуатации.

Разработчики считали, что если код запустился у них локально, то нет проблем — можно запускать в продакшен. Если всё же проблемы возникали, то со стороны команды эксплуатации звучало: «Да это проблемы с кодом, пусть разработчики разбираются». Из-за такого подхода релизы продуктов постоянно затягивались и зачастую страдало качество конечного продукта. Сильно накладывало отпечаток ещё и то, что за один релиз выкатывалось очень много изменений и было очень трудно разобраться, что же породило проблемы на продакшене.

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

Build Engineer — человек, отвечающий за сборку кода. Подтягивание зависимостей, разбор конфликтов в коде — это все про него.
Release Engineer — отвечает за доставку кода от разработки в продакшн. Какая ветка пойдет в тестирование, какой билд попадет на продакшн, релиз-инженер занимается именно этим.
Automation Engineer — инженер по автоматизации. Автоматизирует все, что движется. А что не движется, двигает и тоже автоматизирует. Автоматическая сборка при пуше в гит, прогон тестов, деплой на staging, деплой в продакшн — это все его задачи. Ключевая роль в DevOps подходе.

В целом можно выделить ещё несколько ролей. Например, Security Engineer, который будет отвечать за прогон security-тестов и изучение уязвимостей в используемых компонентах.

В реальном мире все (или почти все) эти роли по отдельности обычно совмещает какой-нибудь другой человек. К примеру, роль билд-инженера можно отдать в руки разработчика. Да и автоматизация настройки серверов обычно отдается системным администраторам. А DevOps-специалисту остаётся проработать и автоматизировать процесс сборки и доставки кода от разработчика в продакшн.

Что должен знать DevOps-инженер?

Строго говоря, никаких специальных требований к DevOps-студенту не предъявляется, но вход в профессию будет намного легче, если вы с порога обладаете некоторыми навыками.

Senior System Administrator

Или хотя бы Middle. Идея в том, что вы должны на хорошем уровне разбираться в среде, в которой будут работать ваши приложения. Как они стартуют (init, systemd), что делать, если вы видите ошибку too many open files, использовать или не использовать swap. Все это очень сильно пригодится, когда вы будете запускать реальные проекты.

Пройдите базовый курс по Linux.
Я учился по сайту lissyara.su, речь тут идет больше о FreeBSD, но, изучив все статьи, получится хорошо расширить свой кругозор по часто используемом софту.
Самое главное во время обучения devops — с головой окунуться в происходящее. Этому очень способствуют тематические форумы и телеграмм-каналы.

Networking — CCNA

Очень важная вещь, хотя про это забывают многие разработчики. Я считаю, что нельзя писать онлайн-сервисы, не понимая, как работает сеть. Никто не говорит, что надо заучивать семь уровней модели OSI, но точно потребуется знать, как работает IP, TCP/UDP и, конечно, протокол уровня приложения — например, HTTP, HTTP/2. Это сохранит вам кучу нервов выискивая причины ошибки Connection Refused.

Запишитесь на курс CCNA.
Установите себе GNS 3 и прокачивайтесь в настройке сетевого оборудования.

Junior Developer

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

Многие могут не согласиться со мной, аргументируя это тем, что код должен писать разработчик. Но, простите, если вы не понимаете, как создаётся программный продукт, то как вы будете автоматизировать его сборку, тестирование и депплой? Сможете ли вы заметить узкое место в архитектурном решении до того, как оно попадет на продакшн?

Чтобы ответить на эти вопросы, devops должен немного углубиться в основные понятия. С чего начать:

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

Junior DBA

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

Самое простое — это пройти какой-нибудь курс, например от Enterprise DB.
Если курс не хочется,то открываем документацию по PostgreSQL, устанавливаем базу, создаем таблички и изучаем основные команды, такие как select , insert , join . Смотрим на execution plan запроса, создаем индексы, а также бэкапим, восстанавливаем и настраиваем репликацию.

Судя по моей личной статистике, чаще всего в DevOps приходят люди из эксплуатации, поскольку у разработчиков обычно не прокачан первый скилл из списка. Но я знаю два случая из жизни, когда senior developers становились DevOps, потому что им надоело, как работает эксплуатация. И, к слову, помимо технических навыков вам точно потребуются некоторые софт скилы. Как минимум вы будете очень много общаться со всеми заинтересованными сторонами. Также вы будете продвигать новые идеи и технологии, что потребует от вас умения ясно и четко доносить свои мысли и умение спорить. Про стрессоустойчивость писать не буду, но терпение вам точно понадобится, поскольку внедрить новую крутую технологию зачастую невозможно в течение одного дня.

Как стать DevOps-инженером?

Вообще DevOps-инженер — это больше про опыт, нежели про знание конкретного софта. Девопс-ребята постоянно учатся, изучают и тестируют новые проекты и технологии. Они должны постоянно задавать себе вопрос: улучшит ли эта технология наш проект? Что лучше выбрать в качестве языка: Ruby, Python, Go или написать на чистых плюсах? А как мы будем доставлять изменения в продакшен, чтобы не поломать работающие системы?

Главное, что надо понимать, — DevOps-специалист обладает действительно хорошим кругозором. Чтобы его расширить необходимо постоянно заниматься самообучением. Ниже я привел примерные шаги, которые помогут вам вырасти из, например, системного администратора в DevOps-инженера. Запомните: список всего лишь указывает направление, оттачивать навыки придётся вам самим.

Сразу напишем небольшое приложение. Язык выбираем абсолютно любой. Приложение будет отдавать информацию о пользователях через HTTP. По сути, простенькое API.
Теперь давайте добавим работу с базой: пусть наши пользователи хранятся в базе. Идеально структуру базы хранить рядом с кодом и научиться прогонять миграции при новых изменениях. Таким образом ваше приложение само синхронизирует базу до нужной структуры.
Регистрируемся на GitHub/Bitbucket и закидываем весь исходный код нашего приложения туда.
На своей машине поднимаем Jenkins/TeamCity и настраиваем автоматическую сборку приложения из нашего репозитория по кнопке.
Усложняем задачу. Настроим webhooks на GitHub/Bitbucket, которые будут автоматически запускать сборку на Jenkins/TeamCity.
Добавим тестов в Jenkins: как минимум можно прогонять линтер по нашему коду или набросать unit-тесты.
Переключимся на настройку dev окружения. Берём в руки Ansible, Chef, Puppet или SaltStack и настраиваем виртуалку с нуля: создаем пользователей, устанавливаем необходимые библиотеки и зависимости.
Подводим все это дело под Vagrant: виртуалка должна автоматически подниматься и настраиваться. Это важный этап в девопс.
Подключаем vagrant к Jenkins с помощью соответствующего плагина: при пуше в Git наше приложение собирается, и поднимается виртуальное окружение с помощью Vagrant + Configuration System Management.
Ищем best practices по деплою приложений на языке, который вы выбрали. Можно заворачивать всё в deb-пакеты, можно деплоить Ruby с помощью Capistrano. Главное — выбрать решение.
Выбор сделан, реализуем его и конфигурируем Jenkins, чтобы после пуша в репозиторий, Jenkins, помимо сборки приложения и развертывания окружения, выкладывал и запускал наш код.
Добавляем смоук-тесты: после запуска Jenkins должен запросить список пользователей у нашего API и убедиться, что получает ответ.
Добавляем мониторинг нашего проекта: изучаем time series базы, настраиваем prometheus, grafana, автоматически подключаем новый инстанс нашего приложения к мониторингу.
Улучшаем мониторинг: интегрируемся со Slack и PagerDuty, чтобы получать нотификации.
Читаем про Docker, пишем Dockerfile и оборачиваем наше приложение.
Изучаем увлекательные статьи про настройку систем оркестрации Swarm, Kubernetes, Rancher Cattle. Следуем рекомендациям и поднимаем кластер.
Меняем Jenkins: собираем Docker-образ, прогоняем тесты, запускаем собранный докер на кластере Kubernetes, проводим smoke-тесты, вводим наше приложение в балансировку.

Разобрались, как стать DevOps-инженером? Смотрите также, какие инструменты используются в DevOps.

Главной целью всех этих шагов является получение опыта работы с различными технологиями. Я уже говорил, что самое главное для DevOps-специалиста — это кругозор, так что берем эти же 17 пунктов и в каждом из них меняем технологию на новую. Писали приложение на Go? Теперь пишем на Ruby. Использовали Jenkins? Берём TeamCity. Поднимали Kubernetes? Настраиваем swarm. Таким нехитрым образом через несколько месяцев вы заранее сможете понять, что лучше использовать в конкретной ситуации, а это — самое главное качество грамотного и успешного DevOps.

Заключение

Да, стать DevOps-инженером с нуля не так-то просто, серебряной пули не существует. Не существует её и в любой другой области. Всегда придётся изучать, читать, пробовать. Но после 10-ой итерации вы войдёте во вкус. Вы не будете пропускать ни одной интересной софтинки, станете изучать и пробовать всё новое и неизведанное. А новое и неизведанное — это всегда круто. Кто бы там что ни говорил, дерзайте!

Что нужно знать чтобы стать начинающим системным инженером (devops)?

Подскажите пожалуйста какими навыками нужно обладать чтобы можно было устроиться джуниором на вышеописанную специальность. Какую литературу стоить почитать? Какого рода вещи нужно попробовать написать самому, чтобы было что показать на собеседовании. Особо важно мнение людей, работающих по этой специальности.
Нашёл описание вакансии, но тут далеко не джуниор и честно говоря сложно самостоятельно подобрать список литературы: rabota.ngs.ru/vacancy/Sistemniy_inzhener_DevOps?id.
Заранее благодарен за развёрнутые ответы.

Вопрос задан более трёх лет назад
38583 просмотра

Комментировать
Решения вопроса 1

Singaporian

Михаил @Singaporian

DevOps — не профессия. Это название культуры доставки кода от разработчика (dev) через тестировщиков и до сисадмина(ops) и обратная связь по этой цепочке.

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

Build Engineer — инженер, который управляет зависимостями, сборками, конфликтами кода.
Release Engineer — инженер, который управляет репозиторием кода (кто куда и по каким правилам мерджится и откуда бренчуется). Пожалуй, это самая сложная задача в больших проектах. Особенно с нестрогим Agile или в Waterfall.
Automation Engineer — инженер, который занимается автоматизацией рутинных задач. Обычно деплоймент, автотесты, etc. Все эти buzz-слова типа Docker — его инструментарий.
Site Reliability Engineer — инженер, который поддерживает ops (апгрейды, расширение железа)
Configuration Manager — непонятная мне специальность. Жуткое порождение HR-специалистов, давящих на громкое название позиции. Можно было бы пойти дальше и назвать специальность ZooKeeper Vice President

Почти всегда все эти роли совмещают один-два человека. Ну это зависит от качества кода.
Назовем эту компанию BRAE/CM для краткости.
Задача BRAE/CM состоит в том, чтобы программный код, который выходит из под пера программистов, оставался на контроле программистов и сисадминов одновременно. Программисты, равно как и сисадмины, благодаря DevOps-подходу, имеют возможность и даже обязаны обслуживать код на протяжении всего жизненного цикла от планирования архитектуры до мусорки.
То есть сисадмины начинают рулить еще до того, как код попадет к ним — на ранних стадиях, а программисты продолжают рулить своими задачами уже после того, как код от них ушел к сисадминам — на поздних стадиях. И все это прозрачно друг для друга и все проблемы и решения ходят туда сюда и не спотыкаются о бюрократия в стиле «ничего не знаю, мы код уже закоммитили, у меня тут свои проблемы, у них сломалось — пусть сами и чинят».

Так вот эта работа — завершающая стадия системного администратора и начинающая стадия разработчика. Поэтому не бывает Junior BRAE/CM.
BRAE/CM бывает всегда только Senior в системном администрировании и всегда Junior в программировании.

Еще один момент. В домашних условиях можно выучить инструменты на базовом уровне. Но не поварившись в одной кастрюле с реальными разработчиками, смысл всей этой кухни не понять. Так что сразу забейте. Но если хотите, могу описать пошаговый длинный путь как стать RE/CM:

Сразу оговорюсь по языкам.
У каждого языка свое предназначение. Java чаще используется в корпоративном секторе. Там много серверов и сложные бизнес-приложения. Поэтому Java-мир очень чувствителен к таким понятиям, как «технинческий долг» и «управление процессом разработки». И именно поэтому именно там все основные вакансии DevOps и именно там будет самый интересный опыт.
Кроме Java, традиционно сильная DevOps-культура у Ruby. Практически все остальные языки не имеют столь развитой и популярной инфраструктуры в в данном контексте и потому вам скорее всего будут неинтересны.
Другими словами, если в среде разработчиков выбор языка — тема для холивара и эмоций с миллионами сравнительных анализов с противоположными результатами, то для специалистов по DevOps выбор очевиден и прозрачен. Java — это одновременно самые интересные задачи, самый богатый toolset, самый большой выбор вакансий и самые высокие зарплаты.

Каждый последующий пункт, кроме особо длинного первого, будет выливаться в неделю-две достаточно плотного труда. Если не прокрастенировать и уделять этому по несколько часов вечером.

Итак, что делать:
1) Почитать книги Head First по Java. Пройти курсы Java на EDX.
2) Освоить SVN. Есть прекрасные тьюториалы. (GIT освоим позже)
3) Поставить VirtualBox (не VMWare. )
4) Написать простенькое приложение. Код коммитить в SVN. Собирать его при помощи maven.
5) Поднять на отдельной виртуалке Jenkins. Он должен брать код приложения на SVN и запускать свой локальный maven для сборки.
6) Написать модульные тесты (unit tests) своего кода. Пусть maven и их прогоняет.
7) Поднять где-нибудь Nexus. Усложнить задачу maven, чтобы он теперь складывал все в Nexus. Если maven’у потребуются внешние библиотеки, он тоже не сам должен ходить в интернет, а через Nexus (Central repo).
8) Настроить на своем десктопе vagrant так, чтобы он с нуля создавал виртуалки VirtualBox.
9) Создать виртуалку DEV через vagrant. При этом ansible должен на ней что-нибудь настроить (например установить JDK)
10) Научиться деплоить jar/war из Nexus на виртуалку DEV чем-нибудь. Чем — не посоветую, так как сам работаю с очень сложным IBM uDeploy, а это точно не для новичка. Посмотрите в сторону Rundeck или чего-то такого. Может самим Jenkins’ом задеплойте.
11) Напишите интеграционные АВТОтесты. На чем хотите (как вариант: Selenium).

Усложняем систему.
12) Донастраиваем Jenkins: собирает maven-проект; выкладывает на Nexus; дергает vagrant/ansible для создания виртуалки SIT (system integration test); деплоит приложение на SIT; прогоняет автотесты на SIT; удаляет виртуалку после успешного завершения автотестов.
13) Прикручиваем SonarQube в Jenkins для статического анализа кода. Исправляем косяки своего кода, согласно полученным от SQ рекомендациям.
14) Прикручиваем мониторинг Sensu.
15) Пишем нагрузочные тесты на чем-нибудь. В идеале потрогать два инструмента: jMeter и Gatling.
16) Как и в 12-м шаге прикручиваем в Jenkins автоматизацию создания виртуалки SLT (Stress/Load test) и прогона на ней тестов. Только уже лоад-тестов(обязательно) и стресс-тестов(опционально) соответственно.
17) Дописываем в свое приложение какой-нибудь функционал, чтобы использовалась база.
18) Придется познакомиться с LiquiBase. Деплой SQL руками делать запрещено.
19) Перейти на Docker (то есть теперь приложение выкладывать не напрямую в ОС, а внутрь докера)

20) Денек на то, чтобы почитать про Agile, Scrum, Waterfall и прочие организационные порядки.

А теперь немного уходим в управление проектом:
21) Поставить Atlassian Jira. Разобраться, чем отличаются Epic, Story, Task, Sub-Task. Создать себе подобной этой структуре фронт работ (делать его не придется, просто нафантазируйте).
22) Поставить Atlassian Stash и связать его с Jira.
23) Переехать со своего SVN на GIT, предоставленный Stash’ем.
24) Пройти Git-тьюториал какой-нибудь. Инструмент очень нетривиальный.
25) Взять любую таску в работу. При этом в начале работы сделать новый Git branch из тикета Jira.
26) По завершению работы запустить всю построенную ранее цепочку, но уже для своего брэнча.
Дайте попробую угадать: вам пришлось скопировать все джобы и переписывать в них ветки?
27) Сделать джобы нормально. Чтобы одни и те же можно было использовать для любых веток — по аналогии с принципом программирования «reuse code». У Вас будет reuse job 🙂
28) Сделать pull request, самому сделать code review и самому себя же за-approve’ить. После этого сделать merge своей ветки в master.
29) Сделать сборку брэнча автоматической по git-hook (или SCM pool)

30) А теперь высший пилотаж: к чертям Docker, Copistrano и прочую buzz-word-hipsters-галиматью. Теперь вы с этим знакомы и сможете применить, но пришло время выгрызать этот детский сад калёным железом. Теперь вы доставляете код только как .deb-пакеты. Это значит, что вы:
a) разбиваете control-файл на несколько пакетов, возможно с lib*,
b) оверрайдите все ~20 dh_ в файле rules так, чтобы все это соответствовало вашим наработкам в предыдущих пунктах.
c) раскидываете файлы по .install
d) самое тяжелое: готовите .preinst, .postinst, .prerm, .postrm файлы СОГЛАСНО ИХ ПРИМЕРАМ .ex, сгенерированным dh_make — то есть с разбиемнием на update/configure/broken-install и что там еще есть. Это означает, что при переустановке, при апгрейде, при даунгрейде, при удалении и при пурдже, у вас будут разные сценарии, каждый из которых должен быть проработан досканально. На этом этапе вы также познакомитесь с понятием «регрессионные тесты».

Ну как бы базовый вариант вот. Но это далеко не весь инструментарий и путь. Это так, для начала.
Кроме этого неплохо бы познакомиться с Puppet (это не очень подходит для DevOps, скорее для рядовых админов с кучей серверов, но это очень популярный инструмент ввиду того, что никто не понимает, что такое DevOps и вас скорее всего заставят управлять сотней серверов, вместо релиз инжиниринга). А так же нужно познакомиться с операционными системами NixOS (обязательно) и CentOS/Debian (опционально, но я бы палкой бил тех, кто не знает эти OS). Кроме того, надо базово ориентирваться в PostgreSQL.

Внимание, важный момент, который должен быть вшит на уровень подсознания у DevOps-ориентированного инженера: вы все время пробуете новые инструменты. Вы всегда будете находить что-то очень отличное. Знаете Nexus как свои пять пальцев и он решает почти все проблемы? Отлично! Теперь выкидываете Nexus и ставите Artifactory. Знаете хорошо CentOS? Круто! Теперь пробуете все это проделать на Windows или Debian. Потому что только когда вы сможете сравнивать инструменты, ваша работа будет ювелирной. А DevOps бывает либо ювелирным, либо он не DevOps. Вы должны быть языко-независимым, платформо-независимым и инструменто-независимым.

Что будет дальше? Дальше вы начнете работать с микросервисами (сотни одинаковых контейнеров в облаке, которые должны как-то работать друг с другом без ручной конфигурации). Тогда познакомитесь со всякими Consul, ZooKepper и кучей инструментов AWS/OpenStack.