Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение
Целевая аудитория
Вы разработчик, который хочет повернуть свою карьеру в сторону более совершенной модели DevOps? Вы являетесь классическим Ops-инженером и хотели бы получить представление о том, что означит DevOps? Или же вы не являетесь ни тем, ни другим и, потратив некоторое время на работу в области ИТ-технологий, хотите поменять работу и понятия не имеете, с чего начать?
Если да, то читайте дальше, чтобы узнать, как можно стать инженером DevOps среднего уровня за шесть месяцев! Наконец, если вы уже много лет занимаетесь DevOps, то все равно сможете почерпнуть много полезного из этого цикла статей и узнать, где находится отрасль интеграции и автоматизации в данный момент и куда она стремится в своем развитии.
Что это вообще такое?
Во-первых, что такое DevOps? Вы можете погуглить определения и пробраться через всю эту словесную шелуху, но знайте, что большинство из определений просто мешанина слов, облеченная в обтекаемую форму. Поэтому я приведу вам выжимку из всех этих определений: DevOps — это такой способ поставки программного обеспечения, при котором головная боль и ответственность делится между всеми причастными. Вот и все.
Хорошо, но что же все-таки означает это сокращение? Оно означает, что традиционно разработчики Developers (люди, создающие программное обеспечение) в своей работе руководствовались стимулами, которые значительно отличались от стимулов Operations (операционистов, или людей, которые управляют программным обеспечением). Например, как разработчик, я хочу как можно быстрее создать как можно больше новых функций. В конце концов, это моя работа, и именно этого требуют клиенты! Однако, если я человек Ops, то мне нужно как можно меньше новых функций, потому что каждая новая функция — это изменение, а любое изменение чревато неполадками. В результате такого рассогласования стимулов и родился DevOps.
DevOps пытается объединить разработку и операции (интеграцию и автоматизацию) в одну группу. Идея заключается в том, что теперь одна группа будет разделять как боль, так и ответственность (и, вероятно, вознаграждение) за создание, развертывание и получение дохода от программного обеспечения, ориентированного на клиента.
Пуристы скажут вам, что нет такой вещи, как ”инженер DevOps». «DevOps — это культура, а не роль”, — скажут они вам. Конечно, с технической точки зрения они правы, но, как это часто бывает, этот термин вышел за пределы своего первоначального значения. Так вот, инженер DevOps – это что-то вроде “системного инженера 2.0». Другими словами, это тот, кто понимает жизненный цикл разработки программного обеспечения и создает инструменты и процессы разработки программного обеспечения для решения классических операционных задач.
DevOps в конечном счете означает создание цифровых конвейеров, которые берут код с ноутбука разработчика и превращают его в доход от использования конечного продукта, вот в чем все дело. Обратите внимание на то, что выбор карьеры DevOps достаточно высоко компенсируется финансовым вознаграждением, причем почти каждая компания либо “делает DevOps”, либо претендует на это. Независимо от того, где находятся эти компании, общие возможности трудоустройства в качестве DevOps довольно высоки и подразумевают «веселую» и значимую занятость на долгие годы вперед.
Однако будьте осторожны с компаниями, нанимающими “команду DevOps » или «отдел DevOps». Строго говоря, такие вещи не должны существовать, потому что в конечном счете DevOps — это все же культура и способ доставки программного обеспечения, а не укомплектование новой команды или создание отдела с модным названием.
Отказ от ответственности
А теперь давайте на минутку отставим в сторону стакан «Кул-Эйда» и подумаем о следующем. Вы слышали старую пословицу «младших инженеров DevOps не бывает?”. Если нет, то знайте, что это популярный троп на Reddit и StackOverflow. Но что он значит?
По-простому эта фраза означает, что требуется много лет опыта в сочетании с твердым пониманием инструментов, чтобы в конечном итоге стать действительно эффективным практиком Senior DevOps. И, к сожалению, здесь нет кратчайшего пути для достижения цели. Таким образом, это не попытка обмануть систему — я не думаю, что на самом деле можно притвориться старшим инженером DevOps с несколькими месяцами опыта в этой отрасли. Достижение четкого понимания быстро меняющихся инструментов и методологий требует многолетнего опыта, и от этого никуда не деться. Однако существует почти согласованное (модное, если хотите) меню инструментов и концепций, которые используют большинство компаний, и именно об этом пойдет речь.
Опять же, инструменты отличаются от навыков, поэтому, пока вы изучаете инструменты, убедитесь, что вы не пренебрегаете своими навыками (опросы, создание сетей, письменное общение, устранение неполадок и т. д.). Главное, не упускайте из виду то, что мы хотим найти – способ создания полностью автоматизированного цифрового конвейера, который берет идеи и превращает их в приносящие доход фрагменты кода. Это единственный и самый важный вывод из всей этой статьи!
Хватит болтовни, когда я смогу начать?
Ниже приведена дорожная карта «Фундаментальные знания DevOps». Освоив все, что там изображено, можете смело и честно называть себя инженером DevOps! Или облачным инженером, если вам не нравится название “DevOps”.
Эта карта отображает мое (и, вероятно, большинства людей, работающих в этом пространстве) представление о том, что должен знать компетентный инженер DevOps. Тем не менее, это только мнение, и, конечно, будут несогласные с ним. Это нормально! Мы здесь не стремимся к совершенству, мы стремимся к прочному фундаменту, на котором реально можно строить.
Вы должны пройти этот путь постепенно, слой за слоем. Начать (и продолжать!) следует с фундаментальных основ, изучив сначала элементы, обозначенные синим цветом — Linux, Python и AWS. Затем, если позволит время или спрос на рынке труда, займитесь фиолетовыми вещами — Golang и Google Cloud.
Честно говоря, основополагающий верхний слой — это то, что вам придется изучать бесконечно. OS Linux очень сложна, и на ее освоение уходят годы. Python требует постоянной практики, чтобы оставаться в курсе событий. AWS развивается так быстро, что то, что вы знаете сегодня, через год составит лишь часть общего портфеля знаний. Как только изучите основы, переходите к реальному набору навыков. Обратите внимание, что всего существует 6 синих колонок (Конфигурирование, Версия, Пакетирование, Развертывание, Запуск, Мониторинг), по одной на месяц изучения.
Вы, конечно, заметили отсутствие в нашем шестимесячном конвейере важного этапа – тестирования. Я намеренно не включил его в дорожную карту, потому что написание модуля, интеграция и приемо-сдаточные тесты даются нелегко и традиционно ложатся на плечи разработчиков. И пропуск этапа «тестирование» объясняется тем, что цель этой дорожной карты как можно быстрее освоить базовые навыки и инструменты. Отсутствие опыта тестирования, по мнению автора, является лишь незначительным препятствием для правильного использования DevOps.
Кроме того, помните, что мы не изучаем здесь целую кучу несвязанного технического лепета, а стремимся к пониманию инструментов, которые в единой связке создают понятную историю. Эта история представляет собой сквозную автоматизацию процесса — цифровой конвейер, который перемещает биты подобно сборочной линии. Вы же не хотите изучать кучу инструментов и постоянно останавливаться! Инструментарий DevOps меняется быстро, а концепции — гораздо реже. Поэтому вы должны стремиться к использованию инструментов в качестве обучающих прокси для концепций более высокого уровня.
Ладно, давайте копнем немного глубже!
Фундаментальные знания
Под верхней ступенькой с надписью Foundation вы видите навыки, которыми должен овладеть каждый инженер DevOps. Эти навыки – уверенное обращение с тремя «столпами» отрасли, коими являются: операционная система, язык программирования и публичное облако. Эти вещи не являются тем, с чем можно по-быстрому ознакомиться и пойти дальше. Эти навыки нужно постоянно совершенствовать и оттачивать мастерство обращения с ними, чтобы находится в авангарде отрасли и актуализировать окружающую вас профессиональную среду. Давайте пройдемся по ним по очереди.
Linux это то, где все работает. Можете ли вы быть потрясающим практиком DevOps, полностью оставаясь в рамках экосистемы Microsoft? Конечно, можете! Нет такого закона, который предписывал бы использовать только Linux. Однако учтите – не смотря на то, что все вещи Linux можно проделать и в Windows, там это происходит гораздо болезненней и с меньшими функциональными возможностями. На данный момент можно смело предположить, что без знания Linux невозможно стать настоящим профессионалом DevOps, поэтому Linux это то, что вы должны изучать и изучать.
Честно говоря, лучший способ сделать это — просто установить Linux (Fedora или Ubuntu) дома и пользоваться им как можно больше. Конечно, вы переломаете кучу вещей, будете застревать в рабочих процессах, вам придется все исправлять, зато вы узнаете Linux!
Кстати, в Северной Америке более распространены варианты RedHat, поэтому имеет смысл начать с Fedora или CentOS. Если вы задаетесь вопросом, следует ли вам приобрести KDE или Gnome edition, выберите KDE. Это то, чем пользуется сам Линус Торвальдс.
Python в наши дни является доминирующим бэк-энд языком. С ним легко начать работу, он широко используется. Python очень распространен в сфере искусственного интеллекта и машинного обучения, поэтому, если вы когда-нибудь захотите перейти в еще одну горячую сферу деятельности, то будете полностью к этому готовы.
Amazon Web Services: опять же, невозможно стать опытным профессионалом DevOps без твердого понимания того, как работает публичное облако. И если вы хотите узнать об этом как можно больше, изучите Amazon Web Services. Это ведущий игрок в данной области услуг, который предлагает самый богатый набор рабочих инструментов.
Можно ли вместо этого начать с Google Cloud или Azure? Конечно, можно! Но помня последний финансовый кризис, следует учесть, что AWS — это самый безопасный вариант, по крайней мере, в 2018 году, так как позволяет бесплатно зарегистрировать аккаунт и приступить к изучению возможностей облачных сервисов. Кроме того, AWS console предоставляет пользователю простое и понятное меню для выбора. Хорошая новость заключается в том, что для этого вам не нужно знать все технологии Amazon.
Начните со следующего: VPC, EC2, IAM, S3, CloudWatch, ELB (Elastic Load Balancing под прикрытием EC2) и Security Group. Этих вещей достаточно, чтобы начать работу, и каждое современное, облачное предприятие достаточно активно использует эти инструменты. Собственный учебный сайт AWS — хорошее место для начала работы.
Я рекомендую вам ежедневно уделять 20-30 минут изучению и практике с языком Python, операционной системой Linux и облачным сервисом AWS в дополнение к другим вещам, которые вам придется изучить. В целом, я считаю, что тратить по часу в день пять раз в неделю достаточно, чтобы понять происходящие в отрасли DevOps процессы в течение 6 месяцев или даже меньше. Существует в общей сложности 6 основных составляющих, каждая из которых соответствует месяцу обучения. Это все, что вам понадобится для приобретения базовых знаний.
В последующих статьях мы рассмотрим следующий уровень сложности: как полностью автоматизировать настройку, версию, пакетирование, развертывание, запуск и мониторинг программного обеспечения.
Немного рекламы 🙂
Почему системные администраторы должны становиться DevOps-инженерами
Для обучения в жизни нет лучшего времени, чем сегодня.
На дворе 2019 год, и тема DevOps сейчас актуальна, как никогда. Говорят, что дни системных администраторов прошли, как миновала эпоха мейнфреймов. Но так ли это на самом деле?
Как это часто бывает в IT, ситуация изменилась. Появилась методология DevOps, но она не может существовать без человека с навыками системного администратора, то есть без Ops.
До того как DevOps-подход приобрёл свой современный облик, я относил себя к категории Ops. И я хорошо знаю, что испытывает сисадмин, когда понимает, сколько же всего он пока не умеет и как мало времени у него на то, чтобы этому научиться.
Но действительно ли всё так страшно? Я бы сказал, что не нужно воспринимать недостаток знаний как какую-то большую проблему. Это скорее профессиональный вызов.
Web-scale-продукты основаны на Linux или другом программном обеспечении с открытым исходным кодом, а на рынке можно найти всё меньше специалистов, способных их обслуживать. Спрос уже превысил количество профессионалов в этой области. У системного администратора уже не получится просто продолжать работать, не повышая свой уровень квалификации. Он должен иметь навыки автоматизации, чтобы управлять множеством серверов/узлов, и хорошо понимать принципы их работы, чтобы решать возникающие проблемы.
Прежде чем стать членом команды DevOps, вам предстоит проделать довольно долгий, но интересный путь, изучая новые технологии и разнообразные инструменты, необходимые для того, чтобы обслуживать систему согласно стандартам DevOps.
Итак, как же системному администратору перейти от привычного подхода в работе к новой концепции DevOps? Всё как обычно: вначале необходимо изменить мышление. Совсем непросто отказаться от подхода, которому вы следовали последние десять или двадцать лет, и начать всё делать по-новому, но это необходимо.
В первую очередь важно понять, что DevOps — это не конкретная должность в компании, а набор определённых практик. Эти практики подразумевают распределение изолированных систем, снижение вреда от багов и ошибок, частое и своевременное обновление ПО, налаженное взаимодействие между разработчиками (Dev) и администраторами (Ops), а также постоянное тестирование не только кода, но и всей структуры в рамках процесса непрерывной интеграции и доставки (CI/CD).
Наряду с изменением образа мышления нужно научиться поддерживать инфраструктуру и обеспечивать её стабильную работу, надёжность и доступность для непрерывной интеграции и доставки приложений, сервисов и ПО.
Чего вам может не хватать как специалисту по Ops, так это навыков программирования. Сейчас написание сценариев (скриптов), которыми системные администраторы пользуются для автоматизированной установки патчей на сервере, управления файлами и учётными записями, для устранения неполадок и составления документации, уже считается устаревшим. В относительно простых случаях сценарии по-прежнему применяются, но концепция DevOps подразумевает решение крупномасштабных задач, будь то внедрение, тестирование, работа со сборками или развёртывание.
Таким образом, если вы хотите научиться автоматизации, нужно хотя бы немного освоить программирование, пусть вы и не разработчик, поскольку на данном этапе своего развития автоматизация инфраструктуры в DevOps требует этого навыка.
Что делать? Чтобы оставаться востребованным специалистом, нужно приобрести актуальные навыки — освоить как минимум один язык программирования, например Python. Человеку, который профессионально занимается администрированием, это может показаться сложным, поскольку он привык думать, что программируют только разработчики. Совсем необязательно становиться экспертом, однако знание одного из языков программирования (это может быть Python, Bash или даже Powershell), безусловно, станет преимуществом.
Чтобы научиться программировать, нужно какое-то время. Будьте внимательны и терпеливы — это поможет вам сохранять понимание ситуации при общении с разработчиками из команды DevOps и заказчиками. Полчаса в день, час или больше — изучение языка программирования должно стать вашей главной целью.
Системные администраторы и специалисты DevOps решают похожие задачи, однако, есть и существенное различие. Считается, что системный администратор не может делать всё то, что может инженер DevOps. Дескать, сисадмин больше сосредоточен на конфигурировании, обслуживании и обеспечении работоспособности серверных систем, а вот инженер DevOps тянет весь этот воз и ещё маленькую тележку.
Но насколько верно это утверждение?
Системный администратор: один в поле воин
Несмотря на отмеченные в этой статье различия и сходства, я всё же считаю, что между системным администрированием и DevOps существенной разницы нет. Системные администраторы всегда выполняли те же функции, что и специалисты DevOps, просто раньше никто не называл это DevOps. Считаю, что нет смысла специально выискивать различия, особенно если это не связано с какой-то задачей. Не стоит забывать и о том, что, в отличие от системного администратора, DevOps — это не должность, а концепция.
Нужно отметить ещё одну важную вещь, без которой разговор и об администрировании, и о DevOps будет неполным. Системное администрирование в привычном понимании предполагает наличие у специалиста конкретного набора навыков и ориентацию на обслуживание различных типов инфраструктур. Не в том смысле, что это универсальный сотрудник, а в том, что есть ряд задач, выполняемых всеми администраторами.
Например, им приходится время от времени выступать в роли эдакого технического разнорабочего, то есть делать буквально всё подряд. И если такой администратор один на всю организацию, то он будет выполнять вообще всю техническую работу. Это может быть что угодно: от обслуживания принтеров и копировальных машин до выполнения задач, связанных с сетью, таких как настройка маршрутизаторов и коммутаторов и управление ими или настройка брандмауэра.
Он также будет отвечать за обновление аппаратного обеспечения, проверку и анализ журналов, аудит безопасности, установку патчей на сервере, устранение неполадок, анализ первопричин и автоматизацию — как правило, посредством сценариев PowerShell, Python или Bash. Один из примеров использования сценариев — это управление учётными записями пользователей и групп. Создание учётных записей пользователей и назначение разрешений — задача чрезвычайно утомительная, поскольку пользователи появляются и исчезают почти каждый день. Автоматизация посредством сценариев позволяет высвободить время для решения более важных инфраструктурных задач, например для обновления коммутаторов и серверов и выполнения других проектов, влияющих на прибыльность компании, в которой администратор работает (хотя и принято считать, что IT-отдел не приносит доход напрямую).
Задача системного администратора — не тратить время впустую и экономить деньги компании любыми возможными способами. Иногда системные администраторы работают как члены большой команды, объединяющей, к примеру, администраторов Linux, Windows, баз данных, хранилищ и так далее. Рабочий график тоже бывает разным. Например, смена в одной временной зоне в конце дня передаёт дела следующей смене в другой временной зоне, чтобы процессы не останавливались (follow-the-sun); или у сотрудников обычный рабочий день с 9 утра до 5 вечера; или же это работа в круглосуточном дата-центре.
Системные администраторы со временем научились мыслить стратегически и сочетать важные дела с рутинными задачами. У команд и отделов, в которых они работают, обычно не хватает ресурсов, но при этом все стараются выполнять ежедневные задачи в полном объёме.
DevOps: разработка и обслуживание едины
DevOps — это своего рода философия процессов разработки и обслуживания. Такой подход в мире IT стал поистине новаторским.
Под эгидой DevOps на одной стороне трудится команда разработчиков программного обеспечения, а на другой — команда специалистов по обслуживанию. Частенько к ним присоединяются специалисты по управлению продуктом, тестировщики и проектировщики пользовательского интерфейса. Объединив усилия, эти специалисты оптимизируют рабочие операции, чтобы быстро выкатывать новые приложения и обновлять код с целью поддержки и улучшения эффективности работы всей компании.
В основе DevOps — контроль за разработкой и функционированием ПО на протяжении всего жизненного цикла. Специалисты по обслуживанию должны поддерживать разработчиков, а перед разработчиками стоит задача разбираться не только в API, используемых в системах. Они должны понимать, что находится «под капотом» (то есть как функционирует аппаратное обеспечение и операционные системы), чтобы лучше справляться с ошибками, решать проблемы и взаимодействовать со специалистами по обслуживанию.
Системные администраторы могут перейти в команду DevOps, если они хотят изучать новейшие технологии и открыты для инновационных идей и решений. Как я уже говорил, им необязательно становиться полноценными программистами, но освоение языков программирования, таких как Ruby, Python или Go, поможет им стать очень полезными членами команды. Хотя системные администраторы традиционно выполняют всю работу самостоятельно и часто воспринимаются как одиночки, в DevOps их ждёт совершенно противоположный опыт, когда все участники процесса взаимодействуют друг с другом.
Тема автоматизации становится всё более актуальной. Как системные администраторы, так и специалисты DevOps заинтересованы в оперативном масштабировании, снижении количества ошибок, а также в быстром поиске и устранении существующих ошибок. Таким образом, автоматизация — это понятие, где две области сходятся. Системные администраторы отвечают за такие облачные сервисы, как AWS, Azure и Google Cloud Platform. Они должны понимать принципы непрерывной интеграции и доставки и то, как использовать в работе инструменты типа Jenkins.
Кроме того, системные администраторы должны применять такие средства настройки и управления, как Ansible, необходимые для параллельного развёртывания десяти или двадцати серверов.
Основное понятие — инфраструктура как код. Программное обеспечение во всём. По сути, чтобы профессия системного администратора не потеряла актуальности, нужно лишь немного сменить акцент. Системные администраторы занимаются обслуживанием и должны уметь эффективно взаимодействовать с разработчиками, и наоборот. Как говорится, одна голова хорошо, а две — лучше.
И последняя деталь в этом механизме — это Git. Работа с Git — одна из традиционных каждодневных обязанностей системного администратора. Эта система управления версиями широко используется разработчиками, специалистами DevOps, Аgile-командами и многими другими. Если ваша работа связана с жизненным циклом ПО, то совершенно точно вы будете работать с Git.
Git содержит в себе массу возможностей. Скорее всего, вы никогда не выучите все команды Git, но точно поймёте, почему этот инструмент считается главным в коммуникации и совместной работе над программным обеспечением. Основательное знание Git очень важно, если вы работаете в команде DevOps.
Кто такой DevOps-инженер? 12 ответов на часто задаваемые вопросы
Авторизуйтесь
Кто такой DevOps-инженер? 12 ответов на часто задаваемые вопросы
Рассказать о DevOps-инженере в двух словах невозможно: кто-то говорит, что такого специалиста не существует, а кто-то убеждён, что это тот же сисадмин, но под другим углом. Не профессия, а загадка. Для большей ясности мы опросили экспертов, которые развёрнуто ответили на распространённые вопросы об этой специальности.
Что такое DevOps?
Development Operations — это методология разработки, которая направлена на эффективное взаимодействие разработчиков с другими IT-специалистами. Например, программисты и тестировщики отвечают за Development, а администраторы — за Operations. И вот когда специалист вовлечён не только в непосредственную разработку, но также в процесс деплоя и эксплуатации системы — это DevOps.
DevOps — это не набор инструментов и платформ, это, скорее, концепция, набор практик и правил, позволяющий ликвидировать разрыв между разработчиками сервиса и сотрудниками, отвечающими за обслуживание и эксплуатацию приложения.
Зачем это нужно?
Участники команды работают сообща и приобретают целостное видение работы всей системы. Это способствует эффективному взаимодействию и, как следствие, улучшению качества продукта.
Стоит сразу обозначить, что, говоря о DevOps, мы имеем в виду не должность. Это не отдельная профессия, а методология и следование набору определённых практик и стратегий, направленных на то, чтобы в конечном счёте результат (реализованный в коде и выполняющий в продуктивной среде функционал) соответствовал ряду бизнес-требований. Бизнесу нужна высокая скорость разработки, стабильность в процессе эксплуатации, при внесении изменений и масштабировании, минимизация затрат, возможность избежать найма дополнительных специалистов.
Это перспективная отрасль?
Ещё бы. Дополнительные навыки и понимание всего процесса сделают вас востребованным сотрудником. Эта специальность появилась на рынке IT относительно недавно и почти сразу же стала одной из самых популярных и востребованных. Но стоит отметить, что многие работодатели, выставляя подобную вакансию, путают DevOps-специалиста с представителями других профессий или просто ищут 2 в 1. Как итог, спрос сейчас превышает предложение.
Хорошо, а кто такой DevOps-инженер?
Devops-инженер как человек с выделенной ролью — это администратор, область деятельности которого лежит немного в стороне по отношению к разработке продукта/продуктов. Он занимается настройкой инструментов и систем, которые позволяют более часто и качественно доносить фичи разработанных продуктов до клиентов. Devops-инженеры — это такие строители дорог, по которым бегут грузовики, нагруженные продуктами, которые создали другие инженеры. В большинстве случаев Devops-инженер — это роль, которую на себя может взять любой член команды. В крупных компаниях, где за счёт создания выделенной роли можно сэкономить, Devops-инженеры проектируют и поддерживают системы доставки изменений для многих команд, стандартизируя эти процессы.
Какие проблемы он решает?
«Магия» DevOps приходит на помощь, когда на проекте есть проблемы со стабильностью, масштабированием, работой под нагрузкой или с выкладкой на продакшн, а также, например, если процесс выпуска продукта занимает слишком много времени.
В чём разница между DevOps-инженером и системным администратором?
Главное отличие сисадмина от DevOps-инженера, конечно же, не в инструментарии и не в знаниях. Я считаю, что это отличие в подходе к работе. У сисадмина есть определённый, неизменный список задач, которые он выполняет ежедневно. Возможно, ещё план по развитию или автоматизации инфраструктуры. У DevOps-инженера, как части команды, таких ограничений нет. Список задач может быть крайне диверсифицированным: вчера я писал код, сегодня тестирую приложение, завтра буду делать то, что будет актуально на тот момент для команды, например, разрабатывать новую фичу, траблшутить проблему с сетью в тестовой среде или настраивать CI/CD процесс.
Какова его роль в команде?
Разработчик пишет код, тестировщик — тесты, системный администратор занимается эксплуатацией всего, а DevOps-инженер «дружит» между собой результаты их работы. Он делает волшебную кнопку, на которую кликает разработчик после написания очередного куска кода, и далее написанный код попадает в тестовую среду, проходит все стадии тестирования и уходит в прод. Главная задача DevOps-инженера — минимизировать взаимодействие между командами разработки и эксплуатации. В REG.RU часто DevOps-инженерами становятся бывшие системные администраторы, которым небезразличны боли разработчиков.
С какими инструментами работает этот специалист?
Из основных инструментов DevOps-инженера я бы отметил:
Учитывая широкую зону интересов, DevOps’у приходиться пользоваться множеством инструментов и постоянно пробовать для себя что-то новое:
Что входит в обязанности DevOps-инженера?
DevOps-инженер — специалист, обеспечивающий автоматизацию процесса разработки продукта. В это понятие входит широкий спектр задач:
Куда можно устроиться, будучи таким специалистом?
В любую крупную компанию, которая занимается разработкой, внедрением и администрированием. Дефицит DevOps-инженеров наблюдается там, где разрабатывается большое количество сервисов в рамках B2C: это мобильные операторы, банки, интернет-провайдеры, etc. К потенциальным работодателям также относятся Google, Facebook, Amazon и прочие гиганты.
Что с порогом вхождения?
Если вы только начинаете свой путь в IT, будет нелегко, поскольку багаж необходимых знаний солидный. Гораздо проще перейти в DevOps, будучи разработчиком или системным администраторам, — в этом случае останется освоить примерно половину того, что требуется.
С чего начать, чтобы стать DevOps engineer?
Начните с полезных статей:
Посмотрите видео на канале ADV-IT, где подробно расписано, что учить и в каком порядке:
Получите более уверенные знания из нескольких книг:
Философия DevOps. Искусство управления IT
IT-принцип «agile» стал мантрой цифровой эпохи. С ростом проектов, переходом от монолитных приложений к системе микросервисов, увеличением и накоплением продуктов возникают вопросы, которые требуют совершенно иного подхода. Теперь наибольший интерес вызывает находящаяся на стыке разработки и операционного управления методология DevOps.
DevOps — это не просто набор техник, это философия. Разработчики, зацикленные на пользователях, должны уделять внимание поддержке и ее запросам. Сисадмины должны сообщать о проблемах продукта и вносить свой вклад в улучшение процесса работы. Но налаживание связей внутри компании — это лишь первый шаг. Чтобы продукт стал простым и удобным, придётся вложить время и ресурсы в его доработку. Конфигурация через центральную службу, внедрение простым копированием, отсутствие внешних зависимостей, обдуманные метрики вместо мусора в логах – вот лишь часть задач, которые придется решать на этом пути.
Книга «Философия DevOps» познакомит вас с техническими, культурными и управленческими аспектами devops-культуры и позволит организовать работу так, чтобы вы получали удовольствие от разработки, поддержки и использования программного обеспечения.
Continuous delivery. Практика непрерывных апдейтов
Эта книга поможет всем, кто собирается перейти на непрерывную поставку программного обеспечения. Руководители проектов ознакомятся с основными процессами, преимуществами и техническими требованиями. Разработчики, администраторы и архитекторы получат необходимые навыки организации работы, а также узнают, как непрерывная поставка внедряется в архитектуру программного обеспечения и структуру ИТ-организации.
Эберхард Вольф познакомит вас с популярными передовыми технологиями, облегчающими труд разработчиков: Docker, Chef, Vagrant, Jenkins, Graphite, ELK stack, JBehave и Gatling. Вы пройдёте через все этапы сборки, непрерывной интеграции, нагрузочного тестирования, развёртывания и контроля.
Руководство по DevOps. Как добиться гибкости, надёжности и безопасности мирового уровня в технологических компаниях
Профессиональное движение DevOps зародилось в 2009 году. Его цель – настроить тесные рабочие отношения между разработчиками программного обеспечения и отделами IT-эксплуатации. Внедрение практик DevOps в повседневную жизнь организации позволяет значительно ускорить выполнение запланированных работ, увеличить частоту релизов, одновременно повышая безопасность, надёжность и устойчивость производственной среды. Эта книга представляет собой наиболее полное и исчерпывающее руководство по DevOps, написанное ведущими мировыми специалистами.
И помните, что от этого специалиста требуется тщательная проработка целого ряда вопросов.
Дополнительные ответы экспертов
DevOps-инженер компании-разработчика российского офисного ПО МойОфис
Если вкратце, то DevOps-инженер — это связующее звено между инфраструктурой и разработчиками, упрощающее работу каждой из команд. DevOps-инженер понимает и специфику разработки, и специфику администрирования и тестирования. Основная его задача — автоматизация и упрощение процессов выпуска продукта.
Я бы сказал, что чёткого разделения между системным и DevOps-инженером нет — и те и другие отвечают за работу продукта на производстве. Однако акцент работы первого может быть смещён в сторону поддержки работоспособности продукта уже в готовом окружении, в то время как DevOps-инженер больше ориентирован на подготовку этого самого окружения.
Каждый день DevOps-инженер оперирует большим количеством инструментов. Их можно условно разделить на разные группы — к примеру, те, что связаны со средой непрерывного развёртывания (CI/CD-tools), с автоматической конфигурацией, мониторингом, облачной инфраструктурой и др. При выборе каждой технологии специалист обязан чётко осознавать, как внедрение того или иного решения повлияет на процессы в команде. Такие сотрудники должны обладать широким кругозором: это очень востребованная в наше время профессия, и настоящие профи ценятся на вес золота.
директор по развитию DBI
Основные задачи системного администратора в команде — это обеспечение работы сетевых и аппаратных ресурсов. Практически всегда в этот список входит ещё и поддержка программных ресурсов и решение некоторых вопросов информационной безопасности, например, настройка фаерволов, VPN-соединения, управление доступами к ресурсам и установка антивирусов.
Именно системным администраторам делегируется необходимость общения с конечными пользователями. Не работает почта? Сломалась клавиатура? Все эти вопросы к системному администратору. Часто системные администраторы помогают разработчикам в настройке сети, серверов. Непосредственно в процессе разработки системные администраторы участия не принимают.
А вот работа DevOps-инженера ориентирована как раз на интеграцию процессов разработки, тестирования, развёртывания и поддержки программных продуктов и сервисов, подразумевает тесное взаимодействие с разработчиками и вовлечённость в проект. В «крупную клетку» задачи DevOps-инженера включают:
Таким образом, основная задача DevOps-инженера — сделать всё для того, чтобы заказчик получил работающий релиз программного обеспечения в срок.
DevOps Engineer, TL, DataArt
Начнём с того, что DevOps — подход, а не инженер. Роль DevOps в проекте основополагающая. Проект и всё, что с ним связано, базируется на DevOps-процессах. DevOps — это связать вместе разные части всей экосистемы (Dev, QA, Ops, Sec) и автоматизировано обеспечить SDLC.
Основываясь на DevOps-подходе и инженерах, которые его обеспечивают, проект получает гибкость, автоматизацию, непрерывность и отказоустойчивость, управление костами, ресурсами и т. д.
Чем DevOps отличается от сисадмина? Практически всем. Сисадмин отвечает за конкретные задачи: управление доступом пользователей, настройка сетевой составляющей инфраструктуры, почтовые/DNS-серверы, VMS, обновления ОС и т. д. В сложной экосистеме и процессах, связанных с проектом и SDLC, это малая часть задач, относящихся к Ops.
Основными обязанностями ДевОпс можно назвать следующие основополагающие процессы в жизнедеятельности продукта:
Каждый пункт можно разложить на десятки подзадач. Счёт технологий идёт на сотни. База выглядит вот так:
