«DevOps — ключ к успеху на всех этапах жизненного цикла продукта»: интервью со Станиславом Тибекиным, CVO компании Nixys

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

Станислав Тибекин, CVO компании Nixys рассказал обо всех формах DevOps-подряда. А формат интервью помог ответить на самые частые вопросы.

Приятного чтения!

Привет, Станислав! Спасибо, что нашел время для беседы. Расскажи немного о себе и своем опыте, где работаешь, чем занимаешься.

Хм, с чего бы начать. Давайте познакомимся :) Меня зовут Станислав Тибекин, я стратегический директор и управляющий партнер компании Nixys. Работаю в компании более семи лет. Начинал как Junior DevOps Engineer и прошел весь путь до Team Lead. Прозвучит нескромно, но я хорошо знаю DevOps изнутри. За время работы DevOps-инженером я участвовал во многих проектах, видел разные продукты и хорошо представляю себе как потребности бизнеса, так и потребности IT-блока.

Думаю, будет уместно сказать пару слов и о компании: Nixys — это системный IT-интегратор, мы предоставляем услуги по трем направлениям – DevOps & CI/CD, DevSecOps, MLOps. Проще говоря, мы делаем так, чтобы наши клиенты могли спокойно развивать свои продукты, не переживая за безопасность, устойчивость инфраструктуры и автоматизацию.

Звучит впечатляюще, но что такое DevOps? Как ты это определяешь?

DevOps на слуху уже довольно давно, но чаще всего он встречается в словосочетании «DevOps-инженер», поэтому многие думают, что это а-ля должность. Но на самом деле, DevOps — это не вакансия на hh.ru, а методология, практика, которая призвана наладить коммуникацию в команде, привнести в разработку Agile, добавить в нее больше гибкости и по итогу — повысить конкурентоспособность продукта, сократив Time-to-Market.

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

Окей, с терминами разобрались. Предположим, я — продуктовая компания и хочу внедрить DevOps. Иначе говоря, DevOps-инженера у меня в штате нет, а потребность в нем есть. Что мне делать?

Хороший вопрос. Я бы рекомендовал остановиться на каком-то формате DevOps-подряда. Существует несколько основных вариантов:

И с таким подрядчиком можно работать очень долго, много лет. В нашей практике есть клиенты, для которых мы делаем аутсорс с 2012-2013 года. Их бизнес — уже немножко наш бизнес и невозможно представить, чтобы мы формально подходили к нашим обязательствам.

А найм в штат — это вариант, который доступен компаниям, достигшим определенной экономики продукта, финансовой устойчивости.

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

Есть разные подходы. Некоторые критерии (например, экономику продукта) я уже называл, но если опираться на какую-то глобальную концепцию, я бы рекомендовал сначала определить — на каком этапе жизненного цикла находится ваш продукт. С этого ракурса можно увидеть ключевые потребности и риски: как для бизнеса в целом, так и для IT-блока.

Уже ближе к нашей гипотетической ситуации. А какие существуют этапы жизненного цикла продукта? И при чем тут всё-таки DevOps?

Начну немного издалека. В 1966 году Раймонд Вернон, известный экономист, разработал концепцию жизненного цикла продукта.

Он выделял следующие этапы:

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

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

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

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

Если вы дочитали до этого момента, ответьте себе — к какому этапу жизненного цикла вы бы отнесли свой продукт?

Эта концепция применима для всех продуктов, но если твой продукт — не digital, то DevOps тут действительно ни при чём. А вот для digital-продуктов DevOps — это ключ к успеху на всех этапах жизненного цикла.

Предположим, что мой продукт совсем молодой, ближе к MVP. На каком я этапе?

Судя по всему, на этапе внедрения :)

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

Но давайте я расскажу про каждый этап подробнее. Этап внедрения можно охарактеризовать очень просто: «Фиг знает, что будет дальше». Никто не представляет, как будет выглядеть продукт через 3-5 месяцев, как будет выглядеть точка Б, в которую хочется прийти — будущее туманно. Главная задача на этом этапе — проинформировать людей о новом продукте, чтобы получить прибыль и обеспечить продажи, которых сейчас, по сути, нет.

Скорее всего, команда разработки маленькая, 5-7 человек, и распыление DevOps-задач на всех приведет к снижению эффективности сотрудников на основных направлениях. В таком случае лучше делегировать DevOps отдельному специалисту, даже на part-time. На этом этапе DevOps-инженер может напрямую влиять на скорость решения задач и их количество. Кроме этого, на этапе внедрения критически важен Time-to-Market, его можно сократить, если DevOps-инженер добавит гибкости инфраструктуре, например, используя облачные технологии.

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

Записываю, подожди минуту! Ну всё, иду развивать свой продукт. А что там на других этапах?

На этапе роста появляются продажи, активно растет количество пользователей, но растет и ответственность перед ними — больше нельзя «упасть и прилечь», продукт должен работать стабильно, создавать себе репутацию.

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

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

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

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

Да, конечно, технические компетенции и опыт всегда на первом месте. Но еще я бы рекомендовал отдать предпочтение компании, которая не привязана к какому-то вендору, использует open source инструменты — это добавит гибкости их решениям и защитит заказчика от проблем связанных, например, с санкциями.

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

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

#devops #devops_услуги #devops_иженер #it #аутсорс #аутстаф #жизненныйциклпродукта #timetomarket