Devops что это в программировании

Гайд по DevOps для начинающих

В чем важность DevOps, что он означает для ИТ-специалистов, описание методов, фреймворков и инструментов.

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

Что такое DevOps

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

Слово «DevOps» является объединением слов «разработка» (development) и «операции» (operations). DevOps помогает увеличить скорость доставки приложений и услуг. Это позволяет организациям эффективно обслуживать своих клиентов и становиться более конкурентоспособными на рынке. Проще говоря, DevOps — это согласованность между разработкой и ИТ-операциями с более эффективным взаимодействием и сотрудничеством.

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

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

Вызовы для команды разработчиков

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

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

Проблемы, с которыми сталкивается операционная группа

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

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

Как DevOps решает проблемы разработки и операций

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

• Снизить процент отказов при выпуске новых релизов
• Увеличить частоту развертывания
• Достичь более быстрого среднего времени на восстановление в случае выхода нового релиза приложения.
• Сократить время на исправления

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

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

Противостояние DevOps, Agile и традиционного IT

DevOps часто обсуждается в связи с другими ИТ-практиками, в частности, гибкой и водопадной ИТ-инфраструктурой.

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

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

Традиционные процессы	Процессы в DevOps
После размещения заказа на новые серверы команда разработчиков работает над тестированием. Оперативная группа работает над обширной документацией, необходимой на предприятиях для развертывания инфраструктуры.	После размещения заказа на новые серверы, команды разработчиков и операторов совместно работают над процессами и документооборотом для установки новых серверов. Это позволяет лучше понять требования к инфраструктуре.
Искажена информация о восстановлении после отказа, избыточности, расположении центров обработки данных и требованиях к хранилищам, так как отсутствуют входные данные от команды разработчиков, которая обладает глубокими знаниями в области применения.	Подробная информация о преодолении отказа, избыточности, аварийном восстановлении, расположении центров данных и требованиях к хранилищам известна и корректна благодаря вкладу команды разработчиков.
Оперативная группа не имеет представления о прогрессе команды разработчиков. Также она разрабатывает план мониторинга на основе собственных представлений.	Оперативная группа полностью осведомлена о прогрессе, достигнутом командой разработчиков. Она также взаимодействует с командой разработчиков, и они совместно разрабатывают план мониторинга, который удовлетворяет IT и потребности бизнеса. Они также используют инструменты мониторинга производительности приложений (APM).
Нагрузочный тест, проводимый перед запуском приложения, приводит к сбою приложения, что задерживает его запуск.	Нагрузочный тест, проводимый перед запуском приложения, приводит к снижению производительности. Команда разработчиков быстро устраняет узкие места, и приложение запускается вовремя.

Жизненный цикл DevOps

DevOps подразумевает принятие определенных общепринятых практик.

Непрерывное планирование

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

Совместное развитие

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

Непрерывное тестирование

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

Непрерывные выпуск и развертывание

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

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

Непрерывный мониторинг

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

Постоянная обратная связь и оптимизация

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

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

DevOps может способствовать созданию среды, в которой разработчики и операторы работают как одна команда для достижения общих целей. Важной вехой в этом процессе является внедрение непрерывной интеграции и непрерывной доставки (CI/CD). Эти методики позволят командам быстрее выводить программное обеспечение на рынок с меньшим количеством ошибок.

Важными преимуществами DevOps являются:

• Предсказуемость: DevOps предлагает значительно более низкую частоту отказов при выпуске новых релизов.
• Поддерживаемость: DevOps обеспечивает легкое восстановление в случае сбоев в новом релизе или отключения приложения.
• Воспроизводимость: Система контроля версий сборки или кода позволяет восстанавливать более ранние версии по мере необходимости.
• Более высокое качество: Решение проблем с инфраструктурой улучшает качество разработки приложений.
• Время выхода на рынок: Оптимизация доставки программного обеспечения сокращает время выхода на рынок на 50%.
• Снижение риска: Обеспечение безопасности в жизненном цикле программного обеспечения снижает количество дефектов на протяжении всего жизненного цикла.
• Экономическая эффективность: Стремление к экономической эффективности при разработке программного обеспечения нравится высшему руководству.
• Устойчивость: Программная система более стабильна, безопасна, а изменения можно проверять.
• Более крупная кодовая база разбивается на управляемые части: DevOps основан на гибких методах разработки, которые позволяют разбивать большую кодовую базу на более мелкие и управляемые части.

Принципы DevOps

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

Разрабатывайте и тестируйте в среде, похожей на производственную

Суть заключается в том, чтобы позволить командам разработчиков и специалистов по контролю качества (QA) разрабатывать и тестировать системы, которые ведут себя как производственные системы, чтобы они могли видеть, как приложение ведет себя и работает задолго до того, как оно будет готово к развертыванию.

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

Развертывание с воспроизводимыми, надежными процессами

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

Мониторинг и проверка качества работы

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

Усовершенствование циклов обратной связи

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

• Планирование: Kanboard, Wekan и другие альтернативы Trello; GitLab, Tuleap, Redmine и другие альтернативы JIRA; Mattermost, Roit.im, IRC и другие альтернативы Slack.
• Написание кода: Git, Gerrit, Bugzilla; Jenkins и другие инструменты с открытым исходным кодом для CI/CD
• Сборка: Apache Maven, Gradle, Apache Ant, Packer
• Тесты: JUnit, Cucumber, Selenium, Apache JMeter

• Выпуск, развертывание, операции: Kubernetes, Nomad, Jenkins, Zuul, Spinnaker, Ansible, Apache ZooKeeper, etcd, Netflix Archaius, Terraform
• Мониторинг: Grafana, Prometheus, Nagios, InfluxDB, Fluentd, и другие, покрытые в этом руководстве

В заключение

DevOps — это все более популярная методология, целью которой является объединение разработчиков и операторов в единое целое. Она уникальна, отличается от традиционных IT-операций и дополняет Agile (но не является столь же гибкой).

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:

DevOps

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

«IT-специалист с нуля» наш лучший курс для старта в IT

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

Название произошло от двух сокращений: Dev — development (разработка) и Ops — operations (поддержка). Раньше это были две разные сферы. Идея DevOps в том, чтобы приблизить эти сферы друг к другу и наладить между ними эффективную коммуникацию.

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

Для чего нужен DevOps-подход

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

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

Чем занимается DevOps-инженер

Профессия DevOps Engineer — востребованная и престижная, но разные организации могут понимать обязанности такого специалиста по-разному. Вот чем может заниматься DevOps-инженер на работе:

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

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

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

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

Практики и инструменты методологии DevOps

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

• непрерывная интеграция, поставка и развертывание, или CI/CD;
• непрерывное тестирование;
• непрерывный мониторинг;
• микросервисы;
• инфраструктура как код, или IaC.

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

CI/CD. Иногда ее разделяют на два пункта — непрерывная интеграция (CI) и непрерывные поставка и развертывание (CD).

• CI относится к обновлению и сборке кода. В DevOps-подходе разработчик не обновляет код вручную и не собирает его своими руками. Он отправляет его в специальный репозиторий, где тот сам собирается и интегрируется в другие части кода, а нужные участки обновляются. Это помогает разработчику меньше задумываться об интеграции и больше — о самом продукте.
• CD — это продолжение CI, то, что происходит с кодом уже после сборки. Подход подразумевает, что продукт автоматически разворачивается в какой-то тестовой среде для проверки. После тестирования он так же автоматически отправляется на рабочий сервер, где разворачивается и начинает работать.

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

Непрерывное тестирование. Этот процесс связан с предыдущими двумя. Тестирование в инфраструктуре тоже проводится непрерывно, так, чтобы снизить временные затраты сотрудников. Обычно оно устроено так: после развертывания на тестовом сервере программа проверяется автоматически. Запускаются юнит-тесты. Если программа их не пройдет, ее автоматически отправляют на доработку.

Только после прохождения юнит-тестов продукт уйдет на функциональное тестирование — «со взгляда пользователя». Его уже могут проводить люди, а не скрипты.

DevOps-инженер — связующее звено между всеми этапами создания продукта. Станьте незаменимым специалистом
за 6 месяцев.

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

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

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

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

Инфраструктура как код. Подход сокращенно называют IaC — Infrastructure as Code. Чтобы реализовать идеи выше, нужно множество инфраструктурных решений: использование контейнеров, виртуальных систем, оркестраторов и так далее. Суть IaC в том, что управлять всей этой инфраструктурой лучше программно, с помощью кода, а не вручную. Так настройки и контроль проводятся быстрее, точнее и лишены человеческого фактора. Для IaC тоже существуют специальные решения. На практике это выглядит так: вместо того чтобы вручную настраивать среду, DevOps-инженер создает конфигурационные файлы, которые в нужный момент запускаются из консоли — достаточно пары строчек с командами. Среда и окружение настраиваются автоматически согласно этим файлам.

Технологии для DevOps

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

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

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

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

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

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

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

CI/CD-системы. Это программные решения, которые позволяют реализовать принцип непрерывного развертывания и доставки. Они помогают автоматически передавать код, получать на него обратную связь и в целом контролировать процессы. Примеры — Jenkins или GitLab.

Облачные серверы. Для реализации CI/CD также используются другие решения, не настолько специализированные. Например, DevOps-инженеры часто работают с облачными провайдерами серверов, такими как Azure или AWS. Эти компании предоставляют виртуальные серверы, работу с которыми легче автоматизировать. А это опять же важно для непрерывного развертывания и доставки.

Системы конфигурации. Для управления инфраструктурой используются специальные программные решения. Таких систем довольно много: Ansible, Chef, Puppet и другие. Еще есть Vagrant — она нужна для создания и конфигурирования виртуальных систем. Эти программы помогают создавать скрипты для конфигураций и запускать их на всех серверах — так автоматизируются рутинные однотипные действия. Это пример того, как реализуют принцип IaC.

Системы мониторинга. Наконец, для непрерывного отслеживания тоже нужны специальные решения. Обычно это комплексные системы, которые автоматизируют процесс мониторинга. Они автоматически запускают проверки состояния серверов, собирают нужную информацию, генерируют отчеты и отправляют специалистам. Примеры таких систем — Prometheus, Zabbix или Nagios, а также Icinga, созданная на его основе. Еще есть Cactu для построения графиков и Grafana — инструмент для визуализации результатов мониторинга в виде интерактивного дашборда.

Что еще нужно знать DevOps-инженеру

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

Языки программирования. Считается, что хороший DevOps-инженер должен знать хотя бы один язык программирования. Лучше, чтобы это был язык общего назначения, причем такой, который удобно использовать для автоматизации: Python, Golang и так далее. Возможны и другие варианты.

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

Операционные системы и сети. Чтобы успешно работать с Bash, писать скрипты и настраивать окружение, нужно понимать, как работают эти системы. Поэтому девопсам нужно знать Linux и разбираться в устройстве сетей.

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

Как начать работать с DevOps

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

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

Кто такой девопс и что он делает

Это как системный администратор и программист в одном лице.

Как обычно пишут программы

Традиционный цикл разработки программ выглядит так:

1. Программисты пишут код небольшими порциями.
2. Когда очередная версия программы готова, она отдаётся в отдел тестирования.
3. Тестировщики пишут тесты и ищут ошибки в коде. Если нашли — отдают программистам, и всё начинается с первого пункта.
4. Если ошибок нет, код отправляется на сборку, чтобы включить его в новую версию программы.
5. После добавления этого кода в новую версию код снова тестируют — всё ли нормально, дружит ли новый код со старым и нет ли каких конфликтов. Если есть — код отдаётся обратно программистам.
6. Если всё в порядке, код идёт в бой, например, выкатывается на сайт.

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

Минусы поэтапной разработки

Всё дело в том, что с таким подходом есть чёткое разделение зон ответственности. Допустим, у нас простая разработка, которая разделена по отделам так:

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

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

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

DevOps-подход к разработке

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

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

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

Кто такие девопсы и что они делают

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

Вот что может делать девопс-инженер:

• настраивать серверы и автоматически управлять их конфигурациями;
• создавать и настраивать виртуальные контейнеры для быстрого запуска нужного софта. Чаще всего для этого используют Docker;
• управлять этими контейнерами из одного места и автоматизировать всю их работу;
• настроить автоматическое тестирование кода;
• сделать так, чтобы код после тестов автоматически попадал в готовую сборку;
• собирать данные для мониторинга работы всей системы. Если какой-то сервис или процесс сломается, девопс сразу должен это увидеть и отреагировать.

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

Что нужно уметь

Чтобы стать девопсом, нужно освоить много разного:

• принципы и теорию разработки ПО;
• инструменты автоматизации работы с кодом — Git, Jenkins;
• системное администрирование на уровне мидла или выше;
• виртуальные контейнеры и работу с ними — Docker и Kubernetes;
• базы данных — реляционные и нереляционные;
• веб-серверы;
• Python или другой язык для написания рабочих скриптов;
• системы управления конфигурацией серверов — Ansible;
• сбор данных по нагрузке и ошибкам во всех системах.

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

Деньги

По данным Хабр Карьеры, в первом полугодии 2021 года средняя зарплата девопс-инженера — 171 тысяча в месяц. Джуниоры получают в среднем 82 тысячи, а сеньоры — 230 тысяч.

Что дальше

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

Введение в DevOps: основные концепции, культура, история и преимущества

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

Шаника Викрамасингх

(Shanika Wickramasinghe)

Об авторе

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

Источник

Переводчик

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

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

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

Содержание

Что такое DevOps

Раньше в IT были отдельные команды разработки (developers, Dev-команда) и сопровождения, или поддержки (operations, Ops-команда). У этих команд были разные руководители, обязанности и цели. Во многих компаниях они даже работали на разных этажах и почти не пересекались.

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

Успехи DevOps помогли сломать эту стену. Теперь эти команды:

• работают сообща;
• разделяют обязанности;
• вместе отвечают за каждую часть ПО на протяжении его жизненного цикла.

Сегодня DevOps широко используется в IT-индустрии. Этой методологии доверяют даже техногиганты вроде Amazon, Google, Netflix и BMC Software. И всё чаще компании задумываются, как распространить принципы DevOps на всю организацию, то есть применять их не только в IT.

Откуда взялся DevOps

До 2000 года большинство IT-компаний применяли линейный подход к разработке ПО — каскадную модель, или «водопад» (waterfall).

При таком подходе:

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

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

С появлением методологии Agile отрасль перешла к итеративной разработке ПО с более частыми релизами. Заработавшие в этой модели непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) позволили быстрее и чаще выпускать ПО для пользователей.

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

Культура DevOps

Чтобы перейти к культуре DevOps, организациям придётся:

• отказаться от традиционных методов работы и управления;
• пересмотреть привычный образ мышления.

По этой методологии Dev- и Ops-команды должны работать сообща и часто общаться друг с другом.

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

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

DevOps-практики

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

А теперь подробнее об этих практиках и инструментах.

Непрерывная интеграция
(Continuous Integration, CI)

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

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

Эта практика помогает быстрее выявлять ошибки и повышает качество ПО.

Непрерывная поставка и развёртывание
(Continuous Delivery и Continuous Deployment)

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

Все эти задачи помогают выполнять Jenkins, Bamboo, Travis, TeamCity и другие CI- и CD-утилиты.

(Подробнее о разнице между CI и CD читайте тут.)

Непрерывное тестирование
(Continuous Testing)

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

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

Таким образом, код будет развёрнут в среде контроля качества (QA environment) для функционального тестирования, только если успешно пройдёт все модульные тесты.

Примечание переводчика

Функциональные тесты (ФТ) проверяют работу приложения снаружи, как если бы это делал пользователь, а модульные тесты (МТ, юнит-тесты) — изнутри, с точки зрения разработчика.

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

Согласно ISTQB, модульное тестирование может проверять и функциональность — в том случае, если компонент (модуль, программу, функцию, объект, класс и так далее) можно тестировать отдельно от других.

В числе популярных инструментов для непрерывного тестирования — Selenium, Travis и Appium.

Непрерывное наблюдение
(Continuous Monitoring)

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

Большинство компаний следят за такими показателями:

• использование CPU и памяти;
• использование дискового пространства;
• действия клиентов;
• политики безопасности.

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

Популярные инструменты непрерывного мониторинга: Nagios, Sensu, Prometheus.

Инфраструктура как код
(Infrastructure as Code, IaC)

Инфраструктура как код (Infrastructure as Code, IaC) — это модель, при которой инфраструктура — виртуальные машины, балансировщики нагрузки, сети и так далее — настраивается и управляется программно, а не вручную. Такая инфраструктура стала необходимым компонентом DevOps в организациях, которые специально перешли на облачные платформы.

Например, Amazon Web Services (AWS) предоставляет API для программного взаимодействия со своей облачной инфраструктурой. Использование программного кода для определения конфигурации помогает сделать процесс стандартным и быстро развёртывать ресурсы в облаке.

Микросервисы
(Microservices)

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

Микросервисная архитектура — распространённое решение в DevOps-культуре. И это не случайно. Она:

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

Топологии DevOps

Способы применения DevOps сильно зависят от конкретной организации. По словам Мэттью Скелтона (Matthew Skelton) и Мануэля Пайса (Manuel Pais), чтобы внедрение DevOps проходило успешно, компании применяют разные типы топологий или командных структур. Скелтон и Пайс выделяют девять типов топологий.

Сотрудничество Dev- и Ops-команд

Это идеальная командная структура для DevOps. В ней Dev- и Ops-группы тесно взаимодействуют друг с другом:

• Разработчики серьёзно относятся к задачам команд поддержки и прислушиваются к Ops-коллегам, если это необходимо.
• Члены команд поддержки отлично понимают, чем занимаются разработчики.

Распределённые операционные обязанности

Такая топология применяется в Facebook и Netflix. Она состоит из команд разработчиков, в которые вплетены команды поддержки. Dev и Ops при этом почти не различаются.

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

Ops в качестве «инфраструктуры как услуги»

Эта топология подходит для организаций с различными/несколькими службами, расположенными на облачных платформах, но с традиционным IT-отделом, реструктурировать который не планируется. При таком подходе Ops-группа — это, по сути, «инфраструктура как услуга» ( Infrastructure as a Service , IaaS).

DevOps как внешний сервис

Некоторые организации не обладают достаточным опытом или не могут себе позволить организацию отдельной Ops-команды. В таком случае они могут поручить управление операционными аспектами ПО внешнему провайдеру.

DevOps-команды «по требованию»

Dev- и Ops-команды временно объединяются, чтобы достичь какой-то конкретной цели. Как только задача выполнена, команду распускают.

Команда DevOps advocacy

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

SRE-команда

Эту топологию придумали в Google. В такой структуре есть группа, которая занимается «проектированием надёжности сайта» (Site Reliability Engineering, SRE). Разработчики доказывают сотрудникам этой команды, что их ПО соответствует стандартам. SRE могут откатить изменения, если не согласны с ними.

Сотрудничество на основе контейнеров

При контейнеризации требования к развёртыванию и времени выполнения переносятся на слой контейнеров. Это убирает часть взаимозависимостей между Dev- и Ops-командами.

Такая структура подходит для организаций с хорошо развитой инженерной культурой.

Сотрудничество Dev и DBA

С такой топологией экспериментировали некоторые организации, у которых есть приложения, подключённые к крупным централизованным базам данных. Суть структуры в том, что как в DBA (DataBase Administrator), так и в Dev-командах определены взаимосвязанные роли для сотрудников, отвечающих за базы данных. Тем самым преодолевается разрыв между этими двумя группами.

Ключевые преимущества DevOps

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

• налаживание связей между командами;
• повышение эффективности и продуктивности организации;
• увеличение скорости выпуска ПО;
• повышение лояльности клиентов (они же теперь получают ПО высокого качества);
• уверенность в том, что система доступна и надёжна, — благодаря тому, что угрозы и ошибки быстро находят и исправляют;
• содействие инновациям благодаря обмену идеями между различными командами

На этом видео Дэвид Риццо (David Rizzo), вице-президент по разработке ПО в BMC Software, и Дэвид Кеннеди, архитектор решений, рассказывают о том, как внедрили DevOps в Compuware, чтобы подстегнуть инновации, уменьшить число ошибок и уменьшить показатель MTTR .

DevOps выходит за рамки бизнес-модели

DevOps — довольно абстрактное понятие, поэтому его сложно объяснить в паре предложений. Как я уже говорила, DevOps — это не только бизнес-модель. Это целый культурный сдвиг, который должен связать и автоматизировать разработку ПО и процессы развития и поддержки продукта в один унифицированный рабочий процесс. При этом нужно фокусироваться на скорости выпуска и высоком качестве ПО, которое соответствует всем требованиям клиентов.

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

При правильном применении культура DevOps может дать компаниям огромные возможности для успешного выпуска ПО.

Читайте также:

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

MTTR (от англ. mean time to repair) — это среднее время от обнаружения неполадок до восстановления работы системы после их исправления.