Devops что это такое простыми словами

DevOps (акроним от англ. development и operations ; по-русски обычно произносится как «дево́пс») — технология (методология) активного взаимодействия специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга для обеспечения качества продукта. Предназначена для эффективной организации создания и обновления программных продуктов и услуг. Основана на идее тесной взаимозависимости разработки и эксплуатации программного обеспечения.

Содержание

Общее обозначение [ править | править код ]

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

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

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

DevOps-движение возникло в 2009 году и было призвано решить проблемы взаимодействия команд разработки и эксплуатации программных продуктов, в том же году в Бельгии была организована серия конференций «DevOps Days» [1] [2] . Затем «DevOps-дни» проходили в различных городах и странах мира.

Набор инструментов [ править | править код ]

Поскольку DevOps — это командная работа (между сотрудниками, занимающимися разработкой, операциями и тестированием), нет единого инструмента «DevOps»: это скорее набор (или «инструментальная цепочка DevOps»), состоящий из нескольких инструментов. Как правило, инструменты DevOps вписываются в одну или несколько из этих категорий, что отражает ключевые аспекты разработки и доставки программного обеспечения: [3]

1. Code — разработка и анализ кода, инструменты контроля версий, слияние кода;
2. Build — инструменты непрерывной интеграции, статус сборки;
3. Test — инструменты непрерывного тестирования, которые обеспечивают обратную связь по бизнес-рискам;
4. Пакет — репозиторий артефактов, предварительная установка приложения;
5. Release — управление изменениями, официальное утверждение выпуска, автоматизация выпуска;
6. Конфигурация — Конфигурация и управление инфраструктурой, Инфраструктура как инструменты кода;
7. Мониторинг — мониторинг производительности приложений, опыт работы с конечным пользователем.

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

Такие инструменты, как Docker (контейнеризация), Jenkins (непрерывная интеграция), Puppet (инфраструктура как код) и Vagrant (платформа виртуализации) — и многие другие — часто используются и часто упоминаются в дискуссиях по инструментам DevOps [5] .

Сравнение с Agile и Continuous delivery [ править | править код ]

Agile и DevOps похожи, но Agile представляет собой изменение мышления и практики (что должно привести к организационным изменениям), а DevOps уделяет больше внимания внедрению организационных изменений для достижения своих целей. [6]

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

Continuous delivery [en] и DevOps похожи по своим значениям (и часто сочетаются), но они представляют собой две разные концепции:

DevOps применяется в более широких аспектах и сосредоточен вокруг:

1. Организационных изменений: в частности, для поддержки более тесного сотрудничества между различными типами работников, занимающихся поставкой программного обеспечения;
2. Разработчиков;
3. Операций;
4. Гарантии качества;
5. Управления;
6. Системного администрирования;
7. Администрирования базы данных;
8. Координаторов
9. Автоматизации процессов в поставке программного обеспечения. [7]

Continuous delivery — это подход к автоматизации аспекта поставки, который фокусируется на:

1. Объединении различных процессов;
2. Выполнении их быстрее и чаще.

Они имеют общие конечные цели и часто используются вместе для их достижения. DevOps и Continuous delivery используют гибкие методы: небольшие и быстрые изменения с целенаправленным результатом для конечного клиента.

Цели [ править | править код ]

Конкретные цели DevOps охватывают весь процесс поставки программного обеспечения. Они включают:

1. Сокращение времени для выхода на рынок;
2. Снижение частоты отказов новых релизов;
3. Сокращение времени выполнения исправлений;
4. Уменьшение количества времени на восстановления (в случае сбоя новой версии или иного отключения текущей системы).

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

Интеграция DevOps предназначена для доставки продукта, непрерывного тестирования, тестирования качества, разработки функций и обновлений обслуживания для повышения надежности и безопасности и обеспечения более быстрого цикла разработки и развертывания. [8]

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

Преимущества DevOps [ править | править код ]

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

Однако, исследование, выпущенное в январе 2017 года компанией «F5 Labs», на основе опроса почти 2200 ИТ-руководителей и специалистов отрасли, показало, что только один из пяти опрошенных полагает, что DevOps оказывает стратегическое влияние на их организацию, несмотря на рост использования. В том же исследовании было установлено, что только 17 % определили DevOps как ключевой инструмент. [9]

DevOps и архитектура [ править | править код ]

Чтобы эффективно использовать DevOps, прикладные программы должны соответствовать набору архитектурно значимых требований (ASR), таких как: возможность развертывания, изменяемость, тестируемость и возможности мониторинга.

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

Рассказывает Василий Озеров, SVP of Infrastructure

В этой статье я постараюсь рассказать о том, что требуется ИТ-специалисту, чтобы стать 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. Все это очень сильно пригодится, когда вы будете запускать реальные проекты.

«Росбанк», Москва, до 60 000 ₽ (до налогов)

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

Networking — CCNA

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

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

Junior Developer

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

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

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

Junior DBA

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

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

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

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

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

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

1. Сразу напишем небольшое приложение. Язык выбираем абсолютно любой. Приложение будет отдавать информацию о пользователях через HTTP. По сути, простенькое API.
2. Теперь давайте добавим работу с базой: пусть наши пользователи хранятся в базе. Идеально структуру базы хранить рядом с кодом и научиться прогонять миграции при новых изменениях. Таким образом ваше приложение само синхронизирует базу до нужной структуры.
3. Регистрируемся на github.com/bitbucket.org и закидываем весь исходный код нашего приложения туда.
4. На своей машине поднимаем jenkins/teamcity и настраиваем автоматическую сборку приложения из нашего репозитория по кнопке.
5. Усложняем задачу. Настроим webhooks на github/bitbucket, которые будут автоматически запускать сборку на jenkins/teamcity.
6. Добавим тестов в jenkins: как минимум можно прогонять lint по нашему коду или набросать unit тесты.
7. Переключимся на настройку dev окружения. Берем в руки ansible/chef/puppet/salt и настраиваем виртуалку с нуля: создаем пользователей, устанавливаем необходимые библиотеки и зависимости.
8. Подводим все это дело под vagrant: виртуалка должна автоматически подниматься и настраиваться.
9. Подключаем vagrant к jenkins с помощью соответствующего плагина: при пуше в git наше приложение собирается, и поднимается виртуальное окружение с помощью vagrant + configuration system management.
10. Ищем best practices по деплою приложений на языке, который вы выбрали. Можно заворачивать все в deb/rpm пакеты, можно деплоить ruby с помощью capistrano. Главное — выбрать решение.
11. Выбор сделан, реализуем его и конфигурируем jenkins, чтобы после пуша в репозиторий, jenkins, помимо сборки приложения и развертывания окружения, выкладывал и запускал наш код.
12. Добавляем смоук тесты: после запуска jenkins должен запросить список пользователей у нашего API и убедиться, что получает ответ.
13. Добавляем мониторинг нашего проекта: изучаем time series базы, настраиваем prometheus, grafana, автоматически подключаем новый инстанс нашего приложения к мониторингу.
14. Улучшаем мониторинг: интегрируемся со slack и pagerduty, чтобы получать нотификации.
15. Читаем про докер, пишем Dockerfile и оборачиваем наше приложение.
16. Изучаем увлекательные статьи про настройку систем оркестрации swarm, kubernetes, rancher cattle. Следуем рекомендациям и поднимаем кластер.
17. Меняем Jenkins: собираем docker образ, прогоняем тесты, запускаем собранный докер на кластере kubernetes, проводим smoke тесты, вводим наше приложение в балансировку.

Главной целью всех этих шагов является получение опыта работы с различными технологиями. Я уже говорил, что самое главное для DevOps инженера — это кругозор, так что берем эти же 17 пунктов и в каждом из них меняем технологию на новую. Писали приложение на golang? Теперь пишем на ruby. Использовали jenkins? Берем teamcity. Поднимали kubernetes? Настраиваем swarm. Таким нехитрым образом через несколько месяцев вы заранее сможете понять, что лучше использовать в конкретной ситуации, а это — самое главное качество грамотного и успешного DevOps.

Заключение

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

Эксклюзивные ИТ-новости, обзоры и интервью

Просто о сложном: что за зверь такой, DevOps?

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

Посему сегодня решил остановиться отдельно на непонятном многим феномене DevOps и чудесах высокоуровневой кооперации (в данном случае сфере ПО). В итоге получилась своего рода landing page для всех тех, кто не врубается в чрезвычайно полезную сущность DevOps. Единственное замечание перед тем, как подкат безжалостно засосет вас — я сделал акцент на медийном формате подачи, то есть собрал воедино пару видео-лекций об этой профессии, а также выложил парочку симпатичных презенташек по теме. Впрочем, перед этим дам и свое, предельно простое объяснение этой новомодной сущности буквально на пальцах.

Свой среди чужих, чужой среди своих

Сначала совсем краткое и отчасти формальное определение.

DevOps (акроним от англ. development и operations) — это методология разработки ПО, сфокусированная на предельно активном взаимодействии и интеграции в одной упряжке программистов, тестировщиков и админов, синхронизировано обслуживающих общий для них сервис/продукт. Главная цель этого — создание единого цикла взаимозависимости разработки, эксплуатации и деплоя программного обеспечения, дабы в конечном счете помогать организациям (сервисам, стартапам) быстрее и безболезненней создавать и обновлять их программные продукты и сервисы, эксплуатируемые в режиме реального времени или «в продакшене».

Теперь чуть проще — если сводить всё к мемам, то главный разрыв, который стремится преодолеть эта новая интегрирующая всё методология, это типичная головная боль больших и распределенных коллективов разработчиков — «проблема не на моей стороне»:

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

Но с точки зрения системы эта же ситуация «разумного эгоизма» маленького-человека-на-местах выглядит примерно так:

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

Графически в наиболее общем виде этот подход будет выглядеть примерно так:

В предельно идеальном случае (к которому есть смысл стремиться даже в нашем убогом не идеальном мире) это будет выглядеть примерно так (см. ниже):

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

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

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

Таким образом, суммируя: Девопс — это методология отношения к инфраструктуре как коду. Программеры и тестировщики — это «девы», а админы — это «чистые опсы». Собирая все вместе: ДевОпс — это когда программист (Дев) очень сильно вовлечен в процесс эксплуатации системы (Опс). Например, когда отдельные участники команды разработки систематически занимаются/участвуют в деплое приложения, настройке окружения, анализируют логи и т.д., кроме того активно работая в качестве суппорта на этапе локализации проблемы, постепенно приобретая целостное видение работы системы.

По своему опыту, в реальной жизни человек-DevOps это чаще всего такой продвинутый админ (иногда бывший программист или всё наоборот), который одновременно в курсе особенностей устройства продукта и всех ролей в коллективе, и «кому до всего есть дело». Конечно, человек для подобной роли нужен не только более технически квалифицированный. Но также и неравнодушный к самому продукту, дотошный и умеющий договариваться/объяснять, который хочет и может вникать во все подозрительные шевеления кода и непонятные взбрыки серверов, особенно, если делать это придется в нерабочее время, ликвидируя результаты чужих косяков.

Медиа-приложения к метологии DevOps

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

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

Ниже также выкладываю свежее подробное видео (русский язык), которое по идее должно поставить точку в понимании «как это работает в реальной жизни». Рекомендую его посмотреть всем, кого эта тема реально интересует:

Что мы там увидим:

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

У меня плеер от Microsoft работает паршиво, поэтому кому-то будет удобней скачать это видео себе на винт по этой прямой ссылке (200Mb, 53 минут) для спокойного просмотра в режиме оффлайн.

В заключение: если всё-таки не ясно кто это и что это, читаем этот текст + внешняя ссылка на дельную статью для тех разработчиков, кто любит думать о своем будущем: How ’DevOps’ is Killing the Developer.

Ключевики для нелюдей: методология внедрения DevOps, а также про то, кто такие девопсы и зачем они вообще нужны. Кто такие и для чего нужен devOp — это основная статья, которая приводит примеры, практики и паттерны их внедрения и использования, также применения и администрирования в стиле DevOps для синхронизации разных участков разработки (безопасность, надежность, гибкость и практичность этой системы и методологии). Роль организации и объединения больших коллективов благодаря девопам и их слугам системным администраторам (обсудим в чем их главное отличие, а также причем здесь Agile и Промышленный DevOps).