Стать инженером devops в 2021 году: подробное руководство

БЕСПЛАТНЫЕ КУРСЫ DEVOPS

Название курса	Школа	Срок обучения
	Нетология	1 вебинар
Знакомимся с профессией DevOps-инженера	SkillBox	1 вебинар
Как стать DevOps-инженером	SkillBox	1 вебинар
	DevOps School	5 занятий

КТО ТАКОЙ DEVOPS-ИНЖЕНЕР? – Перейти на сайт

Информация о курсе

Посмотрев вебинар от Нетологии, у вас сформируется точное представление о том, чем занимается DevOps-инженер и какие его основные обязанности.

Чему вы научитесь:

• Узнаете принципы и методологии DevOps;
• Разберетесь в инструментах и технологиях;
• Узнаете, как начать карьеру в DevOps.

Преимущества:

• Можно посмотреть в любое время;
• Очень интересно рассказывается о профессии;
• Сложные термины простым языком.

Недостатки:

Нужна обязательная предварительная регистрация.

ЗНАКОМИМСЯ С ПРОФЕССИЕЙ DEVOPS-ИНЖЕНЕРА 

Информация о курсе

Вебинар длится более 2 часов. Авторы подробно рассказывают о том, чем занимается DevOps инженер и какие обязанности возлагаются на его плечи. Также на вебинаре рассказывается о сборке контейнера с приложением и локальном запуске. Впрочем, смотрите сами!

Чему вы научитесь:

• Узнаете о задачах DevOps-специалиста;
• Научитесь сборке контейнера с приложением;
• Научитесь локальному запуску с помощью Docker-compose.

Преимущества:

• Можно посмотреть в любое время;
• Затрагивается много интересных тем;
• Не требуется регистрация.

Недостатки:

Много воды.

КАК СТАТЬ DEVOPS-ИНЖЕНЕРОМ 

Информация о курсе

Еще один бесплатный курс от SkillBox, посвященный вводу в профессию DevOps-инженера. Если вы пока еще думаете над тем, стоит ли пробовать себя в данной сфере, то я настоятельно советую посмотреть данный ролик.

Чему вы научитесь:

• Узнаете, кто такой DevOps-инженер;
• Узнаете базовые задачи DevOps-инженера;
• Узнаете о том, какими инструментами должен владеть специалист.

Преимущества:

• Не требуется регистрация;
• Открытый доступ;
• Много полезной информации о карьере.

Недостатки:

Нет плана вебинара на официальном сайте.

DEVOPS СТАРТ! – Перейти на сайт

Информация о курсе

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

Чему вы научитесь:

• Философии и основным понятиям DevOps;
• Настройке рабочей среды;
• Методологии разработки ПО;
• Работе с ОС Linux;
• Контейнеризации и работе с Docker;
• Работе с системами управления;
• Подходам к управлению инфраструктурой.

Преимущества:

• Очень много полезной информации;
• Идеально подходит для новичков;
• Обратная связь от преподавателей.

Недостатки:

• Ограниченное количество мест;
• Нет информации о записи лекций.

Где можно получить профессию DevOps-инженер?

Учитывая специфику работы DevOps-инженера, начинать обучение можно в любом ВУЗе или даже колледже по следующим направлениям: информационные технологии и коммуникации; информатика и вычислительная техника, программирование и т.д.

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

Конечно, при выборе ВУЗа, не последнее место занимает престиж образовательного учреждения (особенно, если планируется трудоустройство за рубежом или в солидную компанию). Но, в любом случае, к базовому образованию придется добавлять множество специализированных курсов подготовки/переподготовки и повышения квалификации.

Отметим, что российская Высшая школа эффективно реагирует на запросы общества в сфере образования, и поэтому сложностей с выбором места обучения у будущих DevOps-специалистов не возникнет. На сегодняшний день в России функционирует 221 ВУЗ, на базе которых можно получить качественное IT-образование.

Но прежде всего стоит обратить внимание на такие ВУЗы, как:

• Санкт-Петербургский госуниверситет промышленных технологий и дизайна;
• Российский технологический университет МИРЭА;
• Национальный исследовательский университет МЭИ;
• ВШЭ;
• МГУ.

Государственный специализированный институт искусств

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	291 000,00 ₽
Бакалавриат	Очная	521 000,00 ₽

Тип	Форма	Стоимость
Бакалавриат	Очная	521 000,00 ₽
Бакалавриат	Очная	521 000,00 ₽

Московская государственная художественно-промышленная академия им. С. Г. Строганова

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	350 000,00 ₽

Тип	Форма	Стоимость
Бакалавриат	Очная	350 000,00 ₽

Национальный университет «Высшая школа экономики»

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	350 000,00 ₽

Программная инженерия

Тип	Форма	Стоимость
Бакалавриат	Очная	350 000,00 ₽

Московский городской педагогический университет

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	295 000,00 ₽

Национальный исследовательский университет «МИЭТ»

Зеленоград

Тип	Форма	Стоимость
Бакалавриат	Очная	273 000,00 ₽

Информационная безопасность

Тип	Форма	Стоимость
Бакалавриат	Очная	195 000,00 ₽

Программная инженерия

Тип	Форма	Стоимость
Бакалавриат	Заочная	84 000,00 ₽
Бакалавриат	Очная	195 000,00 ₽

Российская академия народного хозяйства и государственной службы при Президенте Российской Федерации

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	270 000,00 ₽

Российский экономический университет имени Г.В. Плеханова

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	270 000,00 ₽
Бакалавриат	Очно-заочная	105 000,00 ₽

Информационная безопасность

Тип	Форма	Стоимость
Бакалавриат	Очная	240 000,00 ₽

Арктический государственный институт искусств и культуры

Якутск

Московский государственный технический университет имени Н.Э. Баумана

Москва

Тип	Форма	Стоимость
Бакалавриат	Очная	225 850,00 ₽

Программная инженерия

Московский государственный университет дизайна и технологии

Москва

Почему используют DevOps?

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

Другие важные причины:

1. Прогнозирование: DevOps предлагает значительно более низкий процент неработающих новых релизов.
2. Воспроизводимость: возможность сделать откат до ранних версий в любое время.
3. Поддержка: Легкий процесс восстановления в случае сбоя новой версии или прекращение работы текущей системы.
4. Срок внедрения: DevOps сокращает время выхода на рынок до 50%, благодаря упрощенной поставке программного обеспечения. Это особенно актуально для цифровых и мобильных приложений.
5. Лучшее качество: DevOps помогает команде улучшить качество разработки приложений, поскольку он работает над проблемами инфраструктуры.
6. Меньше риска: DevOps включает аспекты безопасности в жизненный цикл поставки программного обеспечения. Таким образом, уменьшается количество дефектов в течение жизненного цикла.
7. Устойчивость: Операционное состояние системы программного обеспечения более стабильно и безопасно. Также ведется аудит любых изменений.
8. Экономия затрат: DevOps сокращает затраты на разработку программного обеспечения, а это именно то, чего добивается руководство любой IT-компании.
9. Разбивка большой кодовой базы на маленькие кусочки: DevOps основан на методе гибкого программирования. Следовательно, это позволяет разбивать большие кодовые базы на более мелкие и управляемые части.

Когда необходимо внедрять DevOps?

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

Когда не стоит внедрять DevOps?

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

Инструменты DevOps

terraform_ru — Русскоязычный чат Hashicorp Terraform

pro_ansible — Чат для взаимопомощи по Ansible

puppet_ru — Гуру управления конфигурациями с помощь Puppet

saltstack — Русскоязычное сообщество SaltStack

Docker_ru — Русскоговорящее сообщество по экосистеме Docker (чат)

RU.Docker — Официальное Русское Сообщество (чат)

ru_gitlab — Русскоговорящая группа по GitLab

ru_jenkins — Русскоговорящая группа по Jenkins

werf_ru — Open Source CLI-утилита для упрощения и ускорения доставки приложений в Kubernetes.

ru_nexus_sonatype — Установка nexus sonatype используя ansible

ru_artifactory — Русскоговорящая группа

SRE для небольших компаний и компаний без разработки

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

При этом необязательно нанимать на роль SRE отдельного человека, можно сделать роль переходной, а можно вырастить человека внутри команды. Последний вариант подходит для стартапов. Исключение — жёсткие требования по росту (например, со стороны инвесторов). Когда компания планирует расти в десятки раз, тогда нужен человек, ответственный за то, что при заданном росте ничего не сломается.

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

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

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

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

Но на первом плане — качественное базовое образование в IT.

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

• Устраиваются начинающим DevOps-инженером, который выполняет самые простые задачи, на последних курсах учебы в вузе или сразу после окончания учебы и растут на рабочем месте.
• Получив высшее образование, ищут узкоспециализированные курсы.
• Ищут компании, которые предлагают обучение молодым специалистам.

В любом случае, без университетского образования в сфере IT не обойтись.

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

Еще один недостаток российской системы образования — необходимость иметь высокие баллы ЕГЭ, чтобы пройти конкурс в престижное учебное заведение.

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

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

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

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

По окончании учебы выпускники немецких вузов имеют право устроиться на работу в Германии.

Советуем изучить: Подбор программ обучения в вузах Германии

DevOps-инженер — это новая, но уже очень востребованная и важная профессия в сфере IT. Спрос на рынке труда на этих специалистов высок, а их зарплаты очень привлекательны. Эта профессия требует глубоких знаний и постоянного самообучения, но прежде всего — крепкого качественного образования. Вузы Германии могут похвалиться не только традиционно высоким качеством обучения и новаторскими методами преподавания, но и всесторонней поддержкой своих студентов: хорошей учебной базой, практикой, стажировками, которые помогают сформировать настоящего конкурентоспособного специалиста. И все это бесплатно. Для поступления в немецкий вуз вам не нужно иметь высокие баллы ЕГЭ; потребуются высокие академические успехи, хороший немецкий язык и правильно оформленный пакет документов. По всем организационным вопросам вы можете проконсультироваться со специалистом.

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

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-файла конфигурации.

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

Новостные каналы

Mops DevOps — Kubernetes, DevOps, Docker, CI/CD, SRE и многое другое

Записки админа — Linux и администрировании серверов

OrangeDevOps — Канал для сисадминов и devops. Ссылки на интересные материалы.

DevOps&SRE Library — Библиотека книг и статей по теме DevOps и SRE.

DevOps Deflope News — Новостной канал

ДевОпс Инженер — ДевОпс, какой он есть

Флант (анонсы) — Анонсы статей от наших инженеров, видео с докладами, обновлений по Open Source-проектам.

Приятно провести время

Мир IT c Антоном Павленко — IT новости, статьи и видео

Технологический Болт Генона — До Декарта никогда не существовало рационализма

ДЕВОПСИНА — Юморим и поднимаем неудобные айтишные темы

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

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

Итак:

• с 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. Я конечно понимаю, что сервисы и системы этих двух миров различаются, но основа у всех одна и любой уважающий себя админ знаком как с одним, так и с другим, и даже если не знаком, то для грамотного админа не составит труда ознакомится с этим.

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

Разбираем:

• 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

Еще одна:

Посмотрим:

• 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 им будет достаточно.

Кто стоит у истоков DevOps?

Главная книжка по DevOps — «The Phoenix Project». Это такой роман, где главный герой с помощью DevOps побеждает. Сначала у них все очень просто — плохо, затем он придумывает DevOps, и у них становится все хорошо.

На обложке книги есть главные герои. Давайте рассмотрим их внимательнее:

Кого нет на обложке, но в самой книге они на задних ролях? Разработчиков! Вся книжка про то, как Ops-сисадмины придумали DevOps и с помощью него победили.

Второе доказательство: книжка «Руководство по DevOps» (DevOps Handbook). Давайте посмотрим, кто ее написал:

• Джен Ким (Gene Kim). Он написал «The Phoenix Project», то есть с ним все понятно.
• Патрик Дебуа (Patrick Debois). Он был Systems Architect, то есть сисадмином.
• Джез Хамбл (Jez Humble). Работал Deputy Director of Delivery Architecture, то есть сисадмином.
• Джон Уиллис (John Willis). Был VP of Services из компании Opscode, а Opscode — это инструмент для сисадминов.

То есть «Руководство по DevOps» придумано сисадминами.

Может, у нас более продвинутые люди? Уж они-то знают, зачем нужен DevOps и кто такие DevOps-специалисты. Открываем статью на Хабре и видим высказывание Кирилла Сергеева:

Хм, то есть Кирилл утверждает, что разработчики заинтересовались сисадминством? Интересно! Как вы думаете, кем работает этот Кирилл Сергеев? DevOps Engineer в компании EPAM! Ах вон оно что, теперь понятно, это сисадмины хотят, чтобы разработчики заинтересовались сисадминством, чтобы свалить на них часть своей работы!

Спустимся и посмотрим комментарии к этой статье:

Есть еще русскоязычный чат по DevOps в Telegram:

Вот что мы знаем: DevOps — это как сисадмины, только умеют в автоматизацию и знают английский.

Откуда же взялся этот ребрендинг? Откуда появились “DevOps-инженеры”?

Как вы и могли догадаться, это маркетинговый трюк рекрутеров. Им надо нанимать сисадминов, но сисадмины больше не хотят называться сисадминами! Поэтому рекрутеры придумали новую должность: “DevOps-инженер”.

LinkedIn выдает около 15 тыс. результатов по запросу DevOps в США. Если вы думаете, что в Питере не так, то нет — около 1300 открытых вакансий DevOps-инженеров на HeadHunter по состоянию на октябрь 2019 года.

Вот откуда ноги-то растут! Ну ладно, может быть всё не так плохо, и этим «ДевОпс-инженерам» всё-таки есть дело до задач, целей и головных болей разработчиков? Еще есть такой отчет под названием Accelerate: State of DevOps. Любой DevOps-специалист начнет вам рассказывать, как там все правильно. Пока давайте немного про версию 2018 года, а о выпуске 2019 года чуть позже.

Что измеряет State of DevOps? То, как мы деплоим код, куда код девается после того, как мы его написали, какие outages у серверов, лежат ли сервера, degraded service. То есть всё-всё-всё про DevOps. Главное измерение — это new work, то есть сколько мы тратим, создавая новые фичи. Как же он измеряется?

Никаких outages, degradation, server migrations! То есть все метрики в State of DevOps — это метрики сисадминов, и к нам, разработчикам, не имеют никакого отношения, потому что у нас есть три вида работы: фигачим новые фичи, фиксим баги или делаем рефакторинг. Ну то есть суммируя: DevOps — это в лучшем случае ребрендиг сисадминства, а, может быть, даже и попытка сисадминов переложить часть своей работы на разработчиков!

На этом, господа присяжные, я считаю доказанным, что DevOps — это заговор сисадминов против разработчиков. Но я-то разработчик, и что для меня этот new work, что для меня является сделанной работой? Где я провожу эту границу между Dev и Ops в DevOps?

Перейдем к докладу «The world needs full stack craftsmen», с которым Антон Кекс выступал на JPoint 2019. Если в двух словах, то доклад про Software Craftsmanship. Антон рассказывал о том, что значит быть full stack разработчиком, но затем он говорит что-то в духе:

Дальше он говорил про deployment, потому что иначе злой админ позвонит вам в середине ночи. Но у нас же DevOps! Разработчики же деплоят! То есть в докладе еще одно доказательство, что в теме про Software Craftsmanship никаким DevOps и не пахнет. Мы должны сделать так, чтобы системные администраторы не звонили ночью, и заботиться о том, чтобы код был в продакшене.

Далее Антон рассматривал Manifest of Software Craftsmanship:

Что-нибудь про DevOps, production, delivery? Ничего.

Что же считается хорошей разработкой по Software Craftsmanship?

Заключение

В конце хотелось бы ещё раз подчеркнуть основные мысли, которые я попытался донести в данной статье. Первое с чего необходимо начать внедрение DevOps — это понимание и принятие принципов и философии данной методологии всеми участниками команды. Пока это не так, не стоит набрасываться на практическую реализацию, как бы ни был велик соблазн или поджимали сроки. В конечном итоге такой подход сделает только хуже. Следует помнить об MVP не только в отношении продукта, но и процессов. Не все из них необходимы сразу. А при правильном подходе их внедрение на более поздних этапах может быть даже более эффективным. Главное — это держать руку на пульсе развития DevOps в своём проекте и контролировать процессы.