Краткая экскурсия по миру DevOps, в которой мы расскажем о топологиях, практиках, культуре и взаимодействии команд.
Шаника Викрамасингх
(Shanika Wickramasinghe)
Программист, специализируется на веб- и мобильной разработке. Пишет статьи, чтобы учиться самой и делиться знаниями с другими.
Екатерина Степанова
DevOps (development operations) — это популярная методология, которую применяют, чтобы повысить производительность компании — независимо от того, в какой отрасли она работает. С каждым днём всё больше компаний внедряют у себя эту модель.
Главная цель DevOps — обеспечить стабильную поставку ПО за счёт постоянной интеграции процессов разработки и эксплуатации. При этом процессы разработки и развёртывания ускоряются и требуют меньше ресурсов, а компании экономят деньги, производя более качественные программные продукты.
В этой вводной статье мы объясним основы методологии DevOps, расскажем об истории её появления, опишем лучшие практики, ключевые топологии и основные преимущества.
Что такое DevOps
Раньше в IT существовали отдельные команды разработки (developers) и сопровождения, или поддержки (operations). У них были разные руководители, обязанности, подходы и цели. Во многих компаниях они даже находились на разных этажах и почти не взаимодействовали.
Такая культура разрозненности мешала сотрудничать, а зону отчуждённости они преодолевали только в случае крайней необходимости. В общем, в то время работал принцип «отправь софт через сетку на другую сторону поля».
Успехи DevOps помогли сломать эту стену, и теперь сотрудники:
- работают сообща;
- разделяют обязанности;
- вместе отвечают за код и каждую часть ПО на протяжении его жизненного цикла.
Сегодня этому подходу доверяют даже техногиганты вроде Amazon, Google, Netflix и BMC Software. И всё чаще компании задумываются о том, как распространить эти принципы на всю организацию — то есть применять их не только в IT.
Инфографика: BMC / Skillbox Media
Откуда взялась DevOps-методология
До 2000 года большинство IT-компаний применяли линейный подход к разработке ПО — каскадную модель, или «водопад» (waterfall).
При таком подходе:
- уйма времени разработчиков уходила на написание и связывание между собой крупных фрагментов кода, а также на согласование инструментов разработки;
- тестировщики и специалисты по сопровождению работали разрозненно и тратили больше времени на проверку этого кода.
В итоге между релизами ПО возникали большие перерывы — порой по несколько лет. А сам код часто выходил с багами, которые приходилось устранять в многочисленных патчах между релизами.
С появлением методологии Agile отрасль перешла к итеративной разработке ПО с более частыми релизами. В этой модели заработали подходы непрерывной интеграции (continuous integration, CI) и поставки (continuous delivery, CD), которые позволили выпускать обновления быстрее и чаще.
DevOps-практики последовательно улучшали взаимодействие между командами разработки и сопровождения на каждом шаге жизненного цикла ПО. Так что можно с уверенностью сказать, что корни этого подхода — в Agile-методологии.
Инфографика: BMC / Skillbox Media
Культура DevOps
Чтобы перейти к новому подходу, организациям придётся:
- отказаться от традиционных методов работы и управления;
- пересмотреть привычный образ мышления и инструменты.
Согласно этой методологии разработчики и специалисты по сопровождению должны работать сообща и часто общаться между собой.
В некоторых организациях DevOps-инженеры занимаются как разработкой, так и сопровождением. Их роль охватывает многое: они разделяют обязанности с другими специалистами и считают себя ответственными за весь цикл разработки.
Эти инженеры стремятся повысить производительность и качество обслуживания, чтобы принести как можно больше пользы клиентам.
Практики и инструменты методологии DevOps
Конечно, в основе DevOps лежит не только общение и сотрудничество. Частые и качественные релизы становятся возможны благодаря множеству практик. Поскольку этот подход нацелен на высокую эффективность, он поощряет автоматизацию рутинных задач.
Инфографика: BMC / Skillbox Media
А теперь подробнее об этих практиках и инструментах.
Continuous integration, CI
Обычно разработчики вручную обновляли свой код, а затем вручную же его тестировали.
При непрерывной интеграции разработчики часто заливают изменения кода в центральный репозиторий. После внесения изменений происходит автоматическая сборка, и для неё запускаются автоматизированные тесты.
Эта практика помогает быстрее выявлять ошибки в коде и повышает качество ПО.
Continuous delivery и continuous deployment
После сборки весь изменённый код автоматически развёртывается в тестовой среде. Затем этот код прогоняют через автоматические тесты, и начинается развёртывание в производственной среде. Только неудачный тест может остановить запуск обновления. Так разработчики могут быстрее обнаруживать и исправлять ошибки.
Все эти задачи помогают выполнять Jenkins, Bamboo, Travis, TeamCity и другие CI- и CD-инструменты.
Continuous testing
Эта практика помогает как можно раньше выявлять возможные риски на всех стадиях разработки ПО — чтобы ошибки в коде не повлияли на конечных пользователей.
Например, когда код развёртывается на серверах сборки, запускаются автоматические модульные тесты для выявления любых ошибок. Если какие-то тесты не проходят, сборка отклоняется, а разработчик получает уведомление о том, что код нужно перепроверить.
Таким образом, код будет развёрнут в среде контроля качества (QA environment) для функционального тестирования, только если успешно пройдёт все модульные тесты.
Функциональные тесты (ФТ) проверяют работу приложения снаружи, как если бы это делал пользователь, а модульные тесты (МТ, юнит-тесты) — изнутри, с точки зрения разработчика.
ФТ помогают создать приложение, которое делает ровно то, чего хочет клиент. Они гарантируют, что вы никогда не сломаете логику работы. МТ помогают писать чистый код без ошибок — надёжный, производительный, не вызывающий утечек памяти, расширяемый и так далее.
Согласно ISTQB, модульное тестирование может проверять и функциональность — в случае, если компонент (модуль, программу, функцию, объект, класс и так далее) можно тестировать отдельно от других.
Популярные инструменты для тестирования — Selenium, Travis и Appium.
Continuous monitoring
Предполагается, что приложение, инфраструктура, промежуточное ПО и сети постоянно мониторятся на предмет производительности, ошибок, безопасности и соответствия требованиям.
Большинство компаний следят за такими показателями:
- использование CPU и памяти;
- использование дискового пространства;
- действия клиентов;
- политики безопасности.
При постоянном мониторинге вы всегда будете в курсе проблем на любом этапе — от написания кода до продакшена. Это поможет вам обеспечить высокую доступность продукта.
Популярные инструменты непрерывного мониторинга: Nagios, Sensu, Prometheus.
Инфраструктура как код (infrastructure as code, IaC)
Инфраструктура как код (infrastructure as code, IaC) — это модель, при которой инфраструктура — виртуальные машины, балансировщики нагрузки, сети и другие инструменты — настраивается и управляется программно, а не вручную. Такая инфраструктура стала необходимым компонентом в организациях, которые специально перешли на облачные платформы.
Например, Amazon Web Services (AWS) предоставляет API для программного взаимодействия со своей облачной инфраструктурой. Использование программного кода для определения конфигурации помогает сделать процесс стандартным и быстро развёртывать ресурсы в облаке.
Микросервисы (microservices)
В отличие от традиционного монолита, приложение в микросервисной архитектуре состоит из множества маленьких сервисов или компонентов. Каждый сервис отвечает за свою функциональность, а взаимодействуют они через легковесный интерфейс или код API.
Микросервисная архитектура — распространённое решение, и это неслучайно:
- Она помогает независимо управлять ресурсами в рамках различных компонентов.
- Повышает доступность системы, так как в ней нет единой точки отказа: отказ одного из компонентов не влияет на работу остальных.
- Помогает добавлять дополнительные компоненты с новыми функциями, не влияя на другие компоненты.
Топологии DevOps
Способы применения DevOps сильно зависят от конкретной организации. По словам Мэттью Скелтона (Matthew Skelton) и Мануэля Пайса (Manuel Pais), чтобы внедрение DevOps проходило успешно, компании применяют разные типы топологий или командных структур. Скелтон и Пайс выделяют девять типов топологий.
Инфографика: BMC / Skillbox Media
Сотрудничество Dev- и Ops-команд
Это идеальная командная структура для DevOps. В ней Dev- и Ops-группы тесно взаимодействуют друг с другом:
- Разработчики серьёзно относятся к задачам поддержки и прислушиваются к Ops-коллегам, если это необходимо.
- А коллеги из поддержки отлично понимают, чем занимаются разработчики.
Распределённые операционные обязанности
Такая топология применяется в Netflix. Её суть в том, чтобы в команде разработки были не только программисты, но и специалисты технической поддержки.
Лучше всего подходит для компаний с отдельными веб-приложениями.
Ops в качестве «инфраструктуры как услуги»
Эта топология подходит для организаций с несколькими службами, расположенными на облачных платформах, но с традиционным IT-отделом, реструктурировать который не планируется. При таком подходе Ops-группа — это, по сути, «инфраструктура как услуга» (infrastructure as a service, IaaS).
DevOps как внешний сервис
Некоторые организации не обладают достаточным опытом или не могут себе позволить организацию отдельного Ops-подразделения. В таком случае они могут поручить управление операционными аспектами ПО внешнему провайдеру.
DevOps «по требованию»
Dev- и Ops-команды временно объединяются, чтобы достичь конкретной цели. Как только код написан и задача выполнена, сотрудников распускают.
DevOps advocacy
Такая топология подходит слабо сплочённым командам. 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) — это среднее время от обнаружения неполадок до восстановления работы системы после их исправления.