DevOps: как крупному бизнесу повысить эффективность разработки ИТ-продуктов

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

Что такое DevOps

DevOps (Development and Operations) – это методология разработки софта. Её задача – сделать взаимодействие системных администраторов и программистов в команде слаженным.

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

Традиционный цикл выглядит следующим образом:

1. Сначала программисты поэтапно пишут код.

2. После этого его проверяет отдел тестирования.

3. Тестировщики ищут ошибки в коде, и если они их находят, передают его обратно программистам, и всё начинается заново.

4. Если ошибок нет, код отправляется на сборку – там его включают в последнюю версию программы.

5. После добавления в новую версию код снова тестируют. Команда проверяет, всё ли в порядке, нет ли конфликтов. Если есть, код возвращается к программистам на доработку. Если всё хорошо, команда выкатывает релиз ИТ-продукта.

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

Зачем нужен DevOps

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

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

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

• agile-команды разработчиков, которые быстро реагируют на бизнес-требования и внедряют изменения в приложения,

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

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

1. Если что-то можно автоматизировать, это нужно сделать. Исключена необходимость ручной настройки любых элементов системы.

2. Итоговый код должен как можно быстрее доходить до пользователей софта.

3. Программисты не просто «пишут» код – они осознают, как это влияет на проект в целом.

4. Разработка ПО, тестирование и выпуск релизов происходят в единой среде. Это совсем другое восприятие инфраструктуры. Сервера и настройки работают как единый код – достаточно одной правки, чтобы весь проект изменился.

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

Больше, чем просто методология

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

Чем ещё занимаются DevOps-инженеры:

• настраивают серверы и автоматически управляют их конфигурациями;

• создают, настраивают и автоматизируют работу виртуальных контейнеров для быстрого запуска ПО;

• автоматизируют процедуру сборки ПО и его развёртывания на серверах;

• настраивают автоматическое тестирование кода;

• собирают информацию для мониторинга работы всего ИТ-решения и реагируют в случаях, когда какой-то сервис сломался.

В чём трудности внедрения DevOps

Microsoft и консалтинговая компания Sogeti провели исследование Enterprise DevOps Report 2020-21 об актуальной ситуации с внедрением DevOps. Аналитики проинтервьюировали специалистов, внедривших более 250 облачных и DevOps-инструментов, и определили шесть ключевых проблем, с которыми сталкиваются компании в рамках трансформации.

1. Управление продуктами

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

2. Качество

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

3. Управление ИТ

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

4. Удалённая работа и географически распределенные команды

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

5. Соответствие требованиям

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

6. Безопасность

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

Как решать проблемы

• Применение концепции InnerSource. Компания формирует профессиональное сообщество, чьи участники практикуют Open Source, обмениваются инфраструктурой и компонентами для оптимизации работы сотрудников. При этом права на код остаются за бизнесом.

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

• Применение подхода Everything-as-Code. Специалисты обращаются со всеми частями системы как с кодом, а конфигурации сохраняются вместе с исходными данными в репозитории. Это позволяет совершенствовать продукт за счет обновления исходного кода.

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

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

Инструменты на DevOps можно разбить на следующие категории:

• разработка и сборка,

• автоматизация тестирования,

• непрерывная интеграция и развертывание приложений,

• непрерывная обратная связь,

• решения для совместной работы.

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

Инструменты для разработки и сборки

Инструменты данной категории легко интегрируются с другими решениями и позволяют управлять сразу несколькими потоками событий. Выделяют три группы средств:

• управление данными (Data Management) с возможностью вносить правки в схему БД и поддерживать их в соответствии с версией приложения,

• непрерывная интеграция (CI): обязательна способность запускать сборки в изолированной контейнерной среде,

• система управления версиями (SCM), которая должна иметь идеальную поддержку для Git-решений, позволяющих сразу нескольким разработчикам отслеживать изменения в файлах.

Одни из популярных инструментов – GitLab и GitLab-CI. Основная функция – гарантировать комфортное управление Git-репозиторием. GitLab использует непрерывную интеграцию (CI) непосредственно в репозитории в отличие от большинства аналогов. Более того, решения обладают удобным и интуитивно понятным веб-интерфейсом, хорошо поддерживаются.

Есть и другие известные DevOps-инструменты в этой категории. Один из них – GitHub. Это SaaS-решения управления версиями для небольших команд. Для крупных, которые держат IP-адреса в собственной сети, хорошим инструментом может стать виртуальная машина .OVA. В ней нет поддержки систем высокой доступности, что затрудняет обслуживание on-premises.

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

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

FlyWayDB помогает создавать версии БД, мониторить их миграции, без дополнительных средств возвращать или переносить изменения схемы. Программа проверяет и совместимость версий и поддерживает синхронизацию приложений и баз данных.

Для контейнерных приложений также подходит Flocker. Эксперты рекомендуют использовать Relational Database Service, которые позволяют настраивать и масштабировать реляционные базы данных в облаке, и советуют не хранить в контейнере важную информацию.

Инструменты для автоматизации тестирования

Автотесты делятся на три типа: 

• модульные, позволяют убедиться в исправности конкретных функций в рамках одного модуля ПО;

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

• системные, нужны для проверки приложения в целом.

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

Средства для интеграции и развёртывания приложений

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

Для хранения всех используемых артефактов чаще всего используют Nexus. Он надёжный и хорошо поддерживает все ключевые технологии: от Java до Docker и NPM. Nexus помогает получить полное представление о используемых в программных проектах пакетах. При этом она блокирует небезопасные open source экземпляры, которые могут стать вектором атаки.

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

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

Проверка кода с помощью запросов pull – это метод, требующий использования веток. Он помогает сократить их количество и размер, гарантирует тщательное тестирование без потери в скорости разработки.

Часто вместе с термином «непрерывная интеграция» (CI) используют ещё один – «непрерывная доставка» (CD). Это методика быстрой автоматизированной доставки собранного и протестированного кода на сервера. Совместное использование этих подходов позволяет минимизировать показатель Time to Market. 

Один из лидеров среди облачных сервисов для этих целей – Amazon. Если перенести любую технологию и шаблон в Amazon Web Services, система их соберёт и запустит. Бизнес – особенно стартапы – любит этот инструмент за функциональность и низкую стоимость. У AWS есть бесплатная версия, которую можно попробовать, прежде чем принимать решение о покупке.

Еще один инструмент – Azure. Недостаток решения, который часто усложняет работу, – не всегда понятные названия сервисов.

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

Инструменты получения непрерывной обратной связи

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

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

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

Решения для совместной работы

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

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

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

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

***

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

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

Если у вас остались вопросы о DevOps, пишите нам на адрес omni@korusconsulting.ru или заполните форму ниже.