Кто такой devops. обзор изнутри от виктора ведмича

Плюсы и минусы профессии

Плюсы:

• Интересная работа. В рамках специальности сложно достигнуть потолка знаний и навыков. Всегда есть куда расти и развиваться, осваивать что-то новое, сталкиваться с новыми вызовами.
• Востребованность и перспективность. Уже сейчас такие специалисты востребованы на рынке труда, а растущая популярность методики говорит о том, что такая тенденция будет сохраняться и в будущем.
• Хороший уровень зарплаты. Специалисты DevOps имеют приличный level заработной платы даже в рамках ИТ-профессий.
• Многопрофильность. Чтобы работать DevOps-инженером нужно иметь много знаний в разных областях, программировать на нескольких языках. Поэтому если вы хотите сменить специальность, это можно сделать достаточно легко.

Минусы:

• Большие нагрузки. Это сложная работа с высоким уровнем ответственности, нужно управлять командой, следить за большим количеством процессов. При этом, ответственность за ошибки – на вас.
• Ненормированный рабочий день. Форс-мажор с вашим продуктом или неожиданная ошибка могут проявить себя в любое время суток. Даже ночью. И такой специалист должен быть всегда готов к подобным вызовам.
• Нельзя расслабиться. Чтобы преуспеть в работе, нужно постоянно учить что-то новое.

Где учат DevOps?

Достаточное образование можно получить в одном из ведущих государственных вузов, например:

• МФТИ;
• HSE;
• МТУ им. Н.Э. Баумана;
• ВМК МГУ.

Однако вы можете стать инженером DevOps со степенью практически в любой ИТ-специальности — более важен опыт разработки или администрирования. Чтобы представление о профессии было более полным и потенциальный работодатель не сомневался в ваших знаниях, вы можете пройти онлайн-курсы.

Практически все современные образовательные площадки предлагают соответствующие или интенсивные программы, которые также будут полезны тем, кто уже занят:

1. Ящик навыков
2. Нетология
3. SkillFactory
4. Компьютерные мозги
5. ProductStar
6. Отус

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

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

По данным кадрового агентства ИТ Spice IT, лучшие компании, чей опыт работы высоко ценится на рынке, выглядят так:

• Западные: Google, Amazon, Facebook, Luxoft, EPAM, Ecommpay.
• Национальные: Сбербанк, Яндекс, Лаборатория Касперского, Mail.ru, Тинькофф, Райффайзенбанк, Флант и Экспресс 42.

Terraform

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

Terraform — идеальный инструмент по управлению ресурсами в облаке. Через него можно полностью управлять: сетями, фаерволами, роутерами, ip-адресами, балансировщиками, жесткими дисками, виртуальными машинами и многим другим. Также есть возможность создания шаблонов, так называемых модулей. Через них можно упростить работу с ресурсами в облаке, достаточно просто указать название модуля и передать нужные переменные, все остальное Terraform сделает сам. Для совместной работы группы DevOps-инженеров есть возможность хранить стейтменты (состояние работы Terraform) в удаленном хранилище от hashicorp или любом S3 совместимом.

В последних версиях этот инструмент пошел дальше и, благодаря большой базе разных провайдеров, позволяет работать с более высокими абстракциями, такими как Docker, ресурсы Kubernetes или настраивать Consul и управлять Mysql. В итоге на выходе у вас есть возможность описать всю вашу инфраструктуру до мельчайших деталей.

Управление исходным кодом

SVN

SVN – это централизованный инструмент контроля версий и исходного кода, разработанный Apache.

Он помогает разработчикам поддерживать разные версии исходного кода и вести полную историю всех изменений.

Git

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

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

Bitbucket

Bitbucket – это веб-хостинговая платформа, разработанная Atlassian.

Bitbucket также предлагает эффективную систему проверки кода и отслеживает все изменения в коде.

Его можно легко интегрировать с другими инструментами DevOps, такими как Jenkins, Bamboo.

GitHub

GitHub – это платформа для размещения кода, предназначенная для контроля версий и совместной работы.

Он предлагает все функции распределенного контроля версий и управления исходным кодом (SCM) в Git в дополнение к своим функциям.

Он предлагает функции контроля доступа и совместной работы, такие как отслеживание ошибок, создание функций и запросов, управление задачами и т.д.

Ant

Apache Ant – это инструмент для сборки и развертывания на основе Java с открытым исходным кодом.

Он поддерживает формат файла XML.

Он имеет несколько встроенных задач, позволяющих нам компилировать, собирать, тестировать и запускать приложения Java.

Maven

Maven – это инструмент для автоматизации сборки, который в основном используется для Java-проектов.

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

Grunt

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

Это хорошая альтернатива для таких инструментов, как Make или Ant.

Gradle

Gradle – это система автоматизации сборки с открытым исходным кодом, основанная на концепциях Apache Maven и Apache Ant.

Он поддерживает Groovy правильный язык программирования вместо XML-файла конфигурации.

Он предлагает поддержку добавочных сборок, автоматически определяя, какие части сборки обновлены.

Выдающиеся личности в профессии

Дэймон Эдвардс

В Твиттере:

Соучредитель Rundeck Inc., создатель Rundeck, популярного средства автоматизации Runbook с открытым исходным кодом. Дэймон провел последние 19 лет, работая как с технологической, так и с коммерческой составляющей ИТ-операций, и известен тем, что является лидером в переносе передовых технологий DevOps в крупные корпоративные организации. Дэймон часто выступает на конференциях и пишет статьи, посвященные темам DevOps, SRE и улучшению операционной деятельности.

Патрик Дебуа

В Твиттере:

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

Джез Хамбл

В Твиттере:

Сооснователь DevOps Research and Assessment, преподаватель Беркли. Всю карьеру посвятил программированию, IT-инфраструктуре, управлению продуктом в компаниях разного масштаба на трех континентах. Автор нескольких книг.

Так в чем разница между профессиями сисадмина, DevOps и SRE? Максимально коротко

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

Сисадмин настраивает инфраструктуру и заботится о том, насколько стабильно она работает. Если разработчики написали код, который все сломал, это не его забота.

DevOps-инженер заботится о скорости и качестве поставки кода. Он помогает разработчикам настроить процессы так, чтобы новые фичи выходили быстро и ничего не ломали. Если новый код все сломал, то это и его ответственность тоже.

SRE думает о выполнении SLA. Он тоже работает с инфраструктурой, но занимается не базовой настройкой, а тонкой — ищет возможности для оптимизации и точки отказа, улучшает архитектуру. Его не заботит скорость поставки кода, его заботит надежность. Если код потенциально может сломать продакшен, то SRE его не пропустит. 

Валентина, инженер в МТС:

Когда что-то случается, админ смотрит и говорит: «виноват приклад», то есть ПО, которое пишет команда разработки. На этом работа админа над проблемой заканчивается, а работа DevOps-инженера только начинается. В компаниях, где нет собственной разработки, DevOps-инженеров не бывает, а админы обычно есть.

У админа есть готовое ПО, на которое он не может влиять, если там что-то не так, а только костылить вокруг и углубляться в тонкие настройки, но зато у него есть много инструкций в интернете — installation guide и статьи от других админов, которые уже ставили это же ПО и набили шишки. Пример: админ читает в инструкции, что оптимальнее запускать ПО, например, c файловой системой xfs. 

У DevOps-инженера изначально ПО забаговано и не работает оптимально, и именно его задача довести это ПО до приличного уровня и описать те самые installation guide. Пример: DevOps-инженер должен определить, с какой файловой системой приложение работает лучше всего и максимально увеличить эти показатели. Для улучшений он может влиять на разработку и архитектуру ПО, если что-то не достаточно хорошо или не работает.

Василий, DevOps в Piano:

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

DevOps — это про дружбу разработки и админов (опсов), а SRE — это пожарник, который тушит прод после веселья первых двух.

Cultural norms

Job satisfaction

Ранние исследования, проведенные DevOps Research and Assessment (DORA), показали, что удовлетворенность работой является важным фактором, предопределяющим эффективность работы организации. Вовлеченность сотрудников, выполняющих осмысленную работу, повышает ценность бизнеса.

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

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

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

Learning culture

Исследование от команды DORA показывает, что любая организационная культура, которая ценит обучение, влияет на эффективность доставки софта следующими вещами:
повышением частоты деплоев сокращением времени для изменений, для восстановления сервиса и сокращением количества падений после изменений сильной командной культурой. Атмосфера обучения в вашей организации напрямую зависит от степени, с которой ваша организация относится к обучению, как к стратегии:

Видит ли ваша организация обучение как инвестицию в необходимый рост?
Обучение видится как необходимое зло, неохотно принимаемое во внимание?
Обучение полностью избегается?

Исследование, проведенное в других областях, например, в бухгалтерском деле, также показало, что атмосфера, поощряющая обучение, прогнозируемо повышает эффективность.

DevOps как концепция

Как DevOps меняет разработку ПО

Когда-то Agile существенно изменил процесс разработки в IT, а сегодня на индустрию так же сильно влияет DevOps. Первыми применять концепцию начали крупные корпорации, вроде Amazon и Facebook, которые стремились внедрять новые сервисы в свои продукты как можно быстрее. Сегодня DevOps практикуют компании по всему миру, что помогает им адаптироваться к современным IT-тенденциям: усложнению IT-инфраструктуры, переходу от физических платформ к виртуализации, необходимости частых обновлений приложений в ответ на запросы пользователей.

Несмотря на популярность DevOps, все еще не существует единой трактовки самого понятия. Чаще всего DevOps описывают как современную IT-методологию, когда фазы разработки и эксплуатации объединяются в один процесс для ускорения доставки ПО.

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

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

Практики DevOps

Новая концепция – это не ребрендинг широко известного подхода Agile. Гибкие методологии ускоряют процесс разработки продукта, а DevOps позволяет быстрее запускать новые релизы в рабочем окружении. Таким образом, DevOps дополняет Agile, позволяя ускорить процесс создания и обновления программного продукта, обеспечивая при этом его высокое качество. DevOps обозначает не только культуру взаимоотношений между командами разработки, тестирования и эксплуатации, но и конкретные технологические практики.

Непрерывная интеграция (Continuous Integration) – процесс, при котором разработчики ежедневно синхронизируют новую часть кода с основной веткой в системе контроля версий. Как правило, после сборки проекта запускаются автоматизированные тесты. Если будет обнаружена ошибка, то разработчик сразу получит оповещение и сможет приступить к исправлению дефекта.

Непрерывная доставка (Continuous Delivery) – практика, при которой проект после сборки попадает в тестовую среду, где проходит финальное тестирование перед установкой на серверах заказчика. В результате команда получает готовый к развертыванию релиз.

Непрерывное развертывание (Continuous Deployment) – процесс работы с релизом идет так же, как при непрерывной доставке. Но в данном случае изменения в исходном коде, как только проходят через этап QA, автоматически (без участия разработчиков) развертываются на рабочих серверах. В результате заказчик и пользователи получают обновления программы сразу после того, как они будут подготовлены.

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

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

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

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

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

Чего мы добились, используя принципы DevOps

Основное, чего мы добились для бизнеса, работая по принципам DevOps, — это тиражируемость технологических решений. Все решения, которые мы предоставляем, типовые, масштабируемые и построены на шаблонах. Для всех проектов общая концепция процесса CI/CD остается неизменной: выполняются коммит в git и автоматическая сборка (building) — деплой на тестовые серверы (deploying) — функциональное и прочие виды автотестирования (testing) — продвижение сборки в стабильные (promoting) — публикация на GUS (publishing) — распространение через FUS на инфраструктуре заказчика (delivering) — установка или обновление продукта на серверах (installing & updating).

IDEF0-схема типового процесса CI/CD

На каждом из этапов наш отдел помогает разработчикам и тестировщикам решить конкретные технические задачи:

• обеспечить хранение кода в системе GitLab (выделить им проект);
• разработать сборочную конфигурацию на базе одного из типовых шаблонов и обеспечить хранение собранных артефактов в системе Artifactory;
• реализовать конфигурации для деплоя артефактов на серверах тестировщиков и помочь им с подготовкой тестовых конфигураций;
• в случае успешного тестирования — продвинуть сборку, то есть переместить ее в хранилище протестированных артефактов в Artifactory, для чего также создается специальная конфигурация;
• при необходимости опубликовать сборку на корпоративном сервере Global Update, откуда она будет автоматически распространена на FUS-серверы для заказчиков;
• при помощи скриптов на базе SaltStack развернуть сборку на конкретном сервере.

Каждый этап контролируется через систему мониторинга Zabbix. Когда возникает сбой, разработчики пишут нам заявку, мы локализуем и исправляем проблему.

О первых шагах нашей команды в DevOps, о том, с какими проблемами мы столкнулись, как выстраивали процесс CI/CD и к чему пришли в итоге, можно почитать в статьях на Хабре:

• Миссия выполнима: как развить DevOps в компании со множеством проектов,
• Личный опыт: как выглядит наша система Continuous Integration,
• Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps.

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

Непрерывная интеграция

Jenkins

Jenkins является одним из самых популярных инструментов DevOps с открытым исходным кодом для поддержки непрерывной интеграции и доставки в DevOps.

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

Jenkins можно интегрировать с несколькими инструментами тестирования и развертывания.

Travis CI

Travis CI – это облачная распределенная платформа непрерывной интеграции, используемая для создания и тестирования проектов, размещенных на GitHub и Bitbucket.

Он настраивается путем добавления файла YAML.

Его можно протестировать бесплатно для проектов с открытым исходным кодом и на платной основе для частного проекта.

Bamboo

Bamboo является одним из популярных продуктов, разработанных Atlassian для поддержки непрерывной непрерывной интеграции.

Его большая часть функциональности предварительно встроена, что означает, что нам не нужно загружать различные плагины, такие как Jenkins.

Он также поддерживает плавную интеграцию с другими продуктами Atlassian, такими как JIRA и Bitbucket.

Топология команды DevOps

Какая структура или топология команды DevOps подходит для организации, зависит от многих вопросов, например:

• Каков набор выпускаемых и поддерживаемых продуктов – чем меньше продуктов, тем больше взаимосвязь Dev и Ops.
• Степень, сила и эффективность технического руководства — имеет ли Dev и Ops общую цель.
• Готова ли организация на трансформацию роли ИТ эксплуатации от «принеси-подай» во встроенной в бизнес процесс.
• Есть ли в организации лидеры, которые готовы указывать на проблемные области и сопровождать изменения.
• Чаще всего построение «команды мечты» потребует последовательной смены нескольких моделей.

Чем занимаются DevOpsы?

Сборка, выпуск, автоматизация, инженер по безопасности — разные профессии, часто принадлежащие одним и тем же людям. Их называют DevOps-инженерами.

Каждый DevOps должен обладать набором конкретных знаний и практик, с помощью которых решаются следующие задачи:

• сокращается время разработки программного обеспечения;
• обновления и патчи выходят быстрее.

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

Описание работы и навыки

Работа данных специалистов весьма разнообразна, а потому, для ее успешного выполнения, они должны обладать рядом навыков:

• Практический опыт в сетевой безопасности, базах данных, облачных системах
• Глубокие знания различных языков сценариев, системного и серверного администрирования, а также массового развертывания системы.
• Администрирование операционных систем, языков программирования, развертывания облачных платформ и сетевых протоколов.
• Подготовка релизов, конфигурации J2EE, создания инструментов для инженерной организации с целью оптимизации производительности.

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

• Изучение и сбор новых технологий и связанных с ними инструментов для внедрения в компанию, с целью развития среды гибкой разработки.
• Обеспечение прямой поддержки сервера во время различных операций, таких как развертывание и общее производство
• Сотрудничество с разработчиками
• Создание настраиваемых кодов, таких как JavaScript, Java, HTML, CSS и C, которые являются безопасными для защиты от проблем кибербезопасности.
• Разработка, внедрение и тестирование согласованных инфраструктур.
• Автоматизация развертывания приложений Linux, конфигурации системы и настроек безопасности
• Справедливое определение приоритетов запросов от операционных разработчиков и продуктовых команд, демонстрируя при этом чувство сопереживания
• Профессиональные инструменты: они должны использовать несколько жизненно важных инструментов каждый день.

Как стать инженером DevOps: требования и навыки

В современных реалиях ИТ-рынка большинство DevOps приходят в профессию из техобслуживания, развивая свои навыки в сфере разработки продуктов. Это связано с тем, что изначально 70-90% задач такого специалиста были связаны с поддержанием инфраструктуры — систем, баз данных, серверов, сетей, и только 10-30% требовали понимания разработки или автоматизации. В течение нескольких последних лет наметился тренд на повышение требований к соискателю: компании хотят видеть опыт не только в поддержке, но и практические навыки в программировании — это позволяет будущему сотруднику быстрее принимать решения и устранять ошибки в процессе реализации проекта.

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

Наконец, не менее важным для DevOps является также понимание инструментов контейнеризации.

Относительно новым, но уже обязательным, требованием можно считать базовые представления о работе в облаке и системах виртуализации.