Эра DevOps: принять как данность, адаптироваться и применять

DevOps коренным образом меняет способ и сроки разработки ИТ-продуктов. Именно такой подход позволяет удовлетворить постоянно меняющиеся потребности бизнеса.  DevOps будет расширять свое влияние на отрасль в следующие несколько лет, охватывая новые отрасли и сегменты бизнеса. Почему так происходит? Объясняет Алексей Бородулин, менеджер направления «Интеллектуальные облачные и инфраструктурные сервисы» компании Accenture в России.

Конвейер бесконечной бизнес-эволюции

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

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

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

Сначала появился Agile как принцип эффективной и оперативной разработки программного обеспечения. Бизнес получил прозрачность работы продуктовой команды, а также возможность оперативно вносить изменения в требования к продукту. Однако скорость вывода функционала на клиента оставалась на прежнем уровне. Возник конфликт на стыке работы продуктовой команды и подразделений эксплуатации.

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

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

На практике это позволяет получать следующие результаты: международному софтверному гиганту требовалось развернуть собственную платформу eCommerce на территории России для обеспечения соблюдения закона о защите ПДн. Платформа имеет традиционную архитектуру и технологический стек, основанный как на open-source, так и на проприетарных решениях.

Внедрение DevOps практик для автоматизации релизного цикла платформы eCommerce и комплексного решения для мониторинга инфраструктуры платформы позволило сократить время развертывания релизов с 2 дней до 30 минут.

Порвать с традициями

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

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

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

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

Проектирование, разработка и поддержка платформы с применением микросервисной архитектуры приложений, гибких методологий Agile и практик DevOps позволили сократить время доставки изменений с недели до 1 дня. Количество развертываний в продуктивную среду увеличилось до 5 раз в день вместо 1 раза в неделю до внедрения DevOps. Сокращение трудозатрат – в 4 раза: развёртывание 50+ микросервисов в продуктивную среду сейчас занимает 2 часа, вместо одного рабочего дня ранее.

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

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

Концепция и переход

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

Идеальная «пятёрка» соответствует микрорелизному и даже безрелизному подходу, когда каждая строчка нового кода автоматически проходит все ступени проверки, почти мгновенно попадая в продуктив.

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

Классическая дорожная карта перехода на DevOps состоит из двух направлений:

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

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

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

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

 Всерьез, надолго и повсюду

Сегодня любой проект по созданию или изменению продукта, особенно предназначенного для работы с конечным потребителем, будь то B2B или B2C модель, так или иначе требует использования DevOps практик. Это реалии сегодняшнего дня, соответствовать которым – must have для любой организации, претендующей на технологическую релевантность и конкурентоспособность.

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

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

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

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

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

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

Как это работает в крупной компании

Нужно сразу разделить две базовые сферы применения DevOps. Разные типы клиентов (внутренние заказчики ИТ-департамента и внешние пользователи) требуют разных целевых показателей желаемого time to market. Основной сценарий применений DevOps – для разработки и развития внешних ИТ-инструментов и решений. Это классическая история с завязанными на конечных клиентах и потребителях цифровых решениях, с полным задействованием всех возможностей конвейера непрерывной доставки. Здесь TTM требуется обеспечивать на максимальном уровне.

Например, глобальная нефтегазовая компания. Охват – более 70 стран, выпускает около 3,7 миллиона баррелей нефтяного эквивалента в день и имеет 44 000 станций обслуживания по всему миру. Компании требовалось сократить показатель T2M (time-to-market), чтобы иметь возможность быстрее отвечать на отзывы клиентов, сократить трудозатраты на применение изменений для работающих приложений, быстрее доставлять новый функционал и бизнес-ценность для клиентов.

По итогам проекта внедрения DevOps для мобильной и веб-версии приложения для клиентов компании скорость внедрения новых форматов бизнес-ценности для клиентов компании выросла в 23 раза, а число активных пользователей увеличилось с 800 тыс. до 1,5 млн. за 1 год.

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

Выводы

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