Devops что это значит

Что такое DevOps и зачем он нужен разработчикам

Введение в методологию и советы по тому, как начать её применять

DevOps позволяет существенно ускорить процессы разработки и снизить их стоимость, а также оптимизировать все процессы от проектирования до поддержки работающего продукта. Алексей Шарапов, Head of DevOps в компании ЦРПТ и автор курса «DevOps для эксплуатации и разработки» в Яндекс.Практикуме, рассказал, в чем суть этой методологии и зачем ее изучать.

Что такое DevOps

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

Термин DevOps — это комбинация слов «разработка» (development) и «эксплуатация» (operations), которая отражает процесс интеграции этих дисциплин в единый непрерывный процесс. Разработчики и тестировщики отвечают за Development, а администраторы — за Operations.

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

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

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

Одна из практик DevOps — непрерывная интеграция и доставка (Continuous integration и Continuous delivery или CI/CD) — это методы, которые автоматизируют процесс выпуска программного обеспечения, начиная от сборки и вплоть до развертывания. CI/CD помогает свести к минимуму ошибки, повысить темпы сборки и качество разрабатываемого продукта за счет автоматизации.

Netflix — отличный пример того, как культура DevOps помогла подняться в топ технологических компаний. Сейчас сервис внедряет инновации с невероятно быстрой скоростью, потому что разработчики не ставят на первое место время безотказной работы: в стриминге нулевое время простоя не так важно, как в здравоохранении или банковской сфере. Кроме того, компания разработала инструмент Chaos Monkey, который случайным образом «убивает» процессы или серверы. Это нужно чтобы убедиться, что сервис переживет критическую ситуацию без неудобств для клиента.

Что DevOps дает команде

• Меньше ошибок. Одна из причин, почему случаются сбои при развертывании, связана с багами. В DevOps циклы разработки короче обычных, поэтому код выходит чаще. В результате искать ошибки становится проще, а значит, количество сбоев уменьшается.
• Сокращение времени выхода сервиса на рынок. Масштабируемые инфраструктуры — облачные платформы, инструменты для ускорения сборки, параллельные рабочие процессы, работа в одной среде — сильно сокращают время работы. Развертывать и запускать приложение стало в разы быстрее.
• Создание более гибких и отказоустойчивых систем. Это достигается за счет использования облачной инфраструктуры. Она дает возможность быстро масштабировать систему, использовать только нужное количество ресурсов и оперативно увеличивать мощности.
• Повышенная надежность и безопасность приложений. Среди DevOps-инструментов есть те, которые анализируют исходный код программного обеспечения, чтобы определить, есть ли в нем недостатки безопасности. Еще есть приложение, которое сканирование сервисы на наличие в них уязвимостей — OWASP (Open Web Application Security Project).

Как внедрить DevOps в свою работу

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

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

Читайте статьи о DevOps. Много полезного можно найти на Хабре — вот несколько примеров:

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

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

Что необходимо для начального уровня DevOps-разработки:

• владеть скилами разработки на распространённых языках, например, Python или Go
• понимать работу инструментов и оркестрации Kubernetes OpenShift, чтобы запускать приложения в облачной инфраструктуре
• использовать Docker для автоматизации развертывания и управлениями приложениями
• использовать Vagrant для автоматизации локальной разработки
• знать Ansible, чтобы понимать, что вообще происходит 🙂
• базово понимать Linux-системы

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

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

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

DevOps — это инженер, который следит, чтобы код собирался быстро и не было отказов. Также он строит вокруг всего этого правильную инфраструктуру, например, прописывает, откуда берутся артефакты и куда уходят docker images. Еще DevOps пишет правила деплоя в Kubernetes. В общем, он делает работу более гибкой, быстрой и удобной.

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

Что почитать и посмотреть

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

DevOps-решения: ускорить запуск продуктов и сэкономить. Можно узнать про подходы и инструменты, которые уже проверили на себе крупные стартапы и компании.

Джин Ким, Патрик Дебуа, Джон Уиллис и Джез Хамбл «Руководство по DevOps». Книга рассказывает о трех путях DevOps: принципе потока, принципе обратной связи и принципе непрерывного обучения. Она дает базовое понимание о методологии с помощью структурированной информации и практических примеров.

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

Марко Лукша «Kubernetes в действии». Это книга-проводник, которая учит использовать Kubernetes для развертывания распределенных контейнеризированных приложений. Она рассчитана на новичков и помогает разобраться с такими принципами работы контейнеров, как мониторинг, настройка и масштабирование.

Источник

Кто такие DevOps?

На данный момент это чуть ли не самая дорогая позиция на рынке. Суета вокруг «DevOps» инженеров превосходит все мыслимые пределы, а тем хуже с Senior DevOps инженерами.
Я работаю руководителем отдела интеграции и автоматизации, угадайте английскую расшифровку — DevOps Manager. Отражает ли именно английская расшифровка нашу повседневную деятельность — вряд ли, а вот русский вариант в данном случае более точен. По роду моей деятельности, естественно, что мне, необходимо собеседовать будущих членов моей команды и, за прошедший год, через меня прошло человек 50, а еще столько же срезалось на прескрине с моими сотрудниками.

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

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

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

Так кто же такие DevOps инженеры?

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

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

Появилась «замечательная» вещь — docker. Почему замечательная? Да только лишь потому, что создание изоляции в chroot или jail, равно как OpenVZ, требовало нетривиальных знаний ОС, в контру утилите позволяющей элементарно создать изолированную среду приложения на неком хосте со всем необходимым внутри и передать бразды правления разработке вновь, а системному администратору управлять только лишь одним хостом, обеспечивая его безопасность и высокую доступность — логичное упрощение. Но прогресс не стоит на месте и системы вновь становятся все сложнее и сложнее, компонентов все больше и больше, один хост уже не удовлетворяет потребностям системы и необходимо строить кластеры, мы вновь возвращаемся к системным администраторам, которые способны построить данные системы.

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

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

Build Engineer/Release Engineer

Весьма узкоспециализированные инженеры, появившиеся как средство стандартизации процессов сборки ПО и его релизов. В процессе введения повального Agile казалось бы они перестали быть востребованы, однако это далеко не так. Эта специализация появилась как средство стандартизации именно сборки и поставки ПО в промышленных масштабах, т.е. используя стандартные техники для всех продуктов компании. С появлением DevOps разработчиков частично утратили функции, поскольку именно разработчики стали подготавливать продукт к поставке, а учитывая изменяющуюся инфраструктуру и подход в максимально быстрой поставке без оглядки на качество со временем превратились именно в стопор изменений, поскольку следование стандартам качества неизбежно замедляет поставки. Так, постепенно, часть функционала Build/Release инженеров перекочевала на плечи системных администраторов.

Ops’ы такие разные

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

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

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

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

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

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

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

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

Мы готовы с Вами встретится, если Вы:

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

• с 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. Опыт построения высоконагруженных систем;
2. Отличные знания ОС Linuх, общесистемного ПО и веб-стека (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Опыт работы с системами виртуализации (KVM, VMWare, LXC/Docker);
4. Владение скриптовыми языками;
5. Понимание принципов работы сетей сетевых протоколов;
6. Понимание принципов построения отказоустойчивых систем;
7. Самостоятельность и инициативность;

• 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. Опыт работы devops;
2. Опыт в использовании одного или нескольких продуктов для формирования CI/CD процессов. Gitlab CI будет преимуществом;
3. Работа с контейнерами и виртуализацией; Если использовали docker – хорошо, а если k8s – отлично!
4. Опыт работы в agile-команде;
5. Знание любого языка программирования;

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

Хотелось бы также оставить ремарку относительно 3 пункта, дабы укрепить понимание, почему этот пункт покрывается сисадмином. Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все. Для примера возьмем ‘build framework’ Make, коего фреймворком я, к слову, не считаю. Да, я знаю про моду пихать Make куда угодно, где нужно и не нужно — обернуть Maven в Make например, серьезно?
По сути Make просто обертка над shell, упрощающая именно команды компиляции, линковки, окружения компиляции, так же как и k8s.

Однажды, я собеседовал парня, который использовал k8s в своей работе поверх OpenStack, и он рассказывал как развертывал сервисы на нем, однако, когда я спросил именно про OpenStack, оказалось, что он администрируется, равно как и подымается системными администраторами. Вы правда думаете, что человек поднявший OpenStack вне зависимости от того какую платформу он использует позади него не способен использовать k8s?=)
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.

Резюмируем в очередной раз — Middle/Senior System Administrator им будет достаточно.

Сколько вешать в граммах

Разброс предлагаемых зарплат для указанных вакансий — 90к-200к
Теперь хотелось бы провести параллель между денежными вознаграждениями Системных Администраторов и DevOps Engineers.

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник