DevOps в продуктовой разработке

Рассказываем менеджерам продуктов и аналитикам про DevOps, как он встраивается в продуктовые процессы разработки и на что влияет.

Всем привет! Меня зовут Женя, и нет, я не DevOps-инженер, случайно зашедший на VC. Уже несколько лет вместе с моими командами я создаю отечественные инструменты для разработки и тестирования.

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

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

Как отметил Джин Ким, автор книги "The Phoenix Project", DevOps направлен на оптимизацию потока создания ценности от идеи до конечного пользователя с минимальными потерями. Это достигается за счет автоматизации, постоянной интеграции и доставки, а также улучшения обратной связи.

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

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

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

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

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

На этом этапе используются разные инструменты оркестрации (Docker и Kubernetes), хранения и версионирования кода (GitLab, Bitbucket), CI/CD (GitLab CI, Jenkins), хранения артефактов (Nexus, jFrog).

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

Финальными шагами становятся развертывание, эксплуатация и мониторинг. В процессе развертывания ранее написанный и протестированный код попадает на промышленные стенды: при настроенной автоматизации это становится рутинным действием, а не “каждый релиз как подвиг”. Именно на этом этапе обычно считают показатель Time to Market, на основе которого некоторые компании делают выводы об эффективности разработки.

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

Хоть эти шаги и описаны последовательно, но существуют они параллельно. Пока кто-то пишет код, другой запускает тестирование ранее отправленного кода, где поднимается и падает прод.

В DevOps есть свои метрики с блэк-джеком и бенчмарками. Особую популярность получили DevOps Research and Assessment (DORA), или просто дора-метрики.

Чтобы подробно рассказать про них и про метрики SPACE, которые тесно связаны с разработкой, но мало распространены, потребуется отдельная статья. Поэтому расскажу совсем коротко.

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

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

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

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

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

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