Применение DevOps-аутсорса на разных этапах жизненного цикла продукта

Kate · 13 Апр 2023

Как работает DevOps на заказ?

Существует несколько основных форматов взаимодействия с DevOps-командой.

Аутсорсинг. Но не тот аутсорсинг, про который вы, возможно, думаете. 10-20 лет назад заказчик просто брал задачу, выполнял ее и вообще не думал о боли бизнеса клиента. Сегодня мы говорим про современный аутсорс, когда команда подрядчика максимально заинтересована в том, что она делает и эта заинтересованность, по сути, равна заинтересованности in-house команды.
Аутстаффинг — это про делегирование найма. Быстрый и легкий способ проскочить ресурсоемкий этап подбора и адаптации сотрудника и сразу приступить к решению задач.
Проектные работы. Отличный вариант, если у вас есть логически обособленный проект, задачи по которому можно оформить в какой-то конкретный список и делегировать его подрядчику.
Найм в штат — если позволяет экономика продукта.

Какие существуют этапы жизненного цикла продукта?

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

Внедрение — продукт находится в поиске собственного рынка, возможно, слабо представляет его, прибыли почти нет;
Рост — продукт находит свой рынок, начинает отвоевывать его у конкурентов, отстраивается от них через формирование своего уникального торгового предложения (УТП);
Зрелость — продукт занимает стабильную лидирующую позицию на рынке, его прибыль стабильна, начинается масштабирование продукта на другие рынки (страны и т.д.);

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

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

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

Этап внедрения

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

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

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

На этом этапе DevOps-инженер может напрямую влиять на скорость решения задач и их количество. Например, у вас 7-10 разработчиков и два окружения с определенным flow, скорее всего это неэффективно. Почему бы сразу не посчитать стоимость окружений, поднять их, сделать адекватный flow и не перейти на следующий этап с качественной инфраструктурой?

Кроме этого, на этапе внедрения критически важен time-to-market, его можно сократить, если DevOps-инженер добавит гибкости инфраструктуре, например, используя облачные технологии.

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

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

Когда нужен подрядчик?

Для создания инфраструктуры вам нужен senior — он стоит дорого, найти его сложно, а хотелось бы "еще вчера”. Подрядчик может выделить вам сеньора в считанные дни.
Вы не готовы брать единицу, которую не можете загрузить фулл-тайм, в свой штат. Выгоднее взять еще одного разработчика.
Хотите разгрузить разработчиков от непрофильных задач.
Хотите улучшить SLA или получаете много пользовательских жалоб, связанных с недостатками инфраструктуры.

Когда нужен DevOps-подрядчик на этапе внедрения

А когда нужно уходить?

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

"Бомбы замедленного действия"

Какие трудности могут помешать продукту при переходе на следующий этап?

Вы можете:

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

Этап роста

Ура! У вас появляются продажи, активно растет количество пользователей, но растет и ответственность перед ними — вы больше не можете позволить себе “упасть и прилечь”.

Характеристики этапа роста
Растет команда возникают трудности во взаимодействии. Появляется потребность во внедрении релиз-менеджмента. Растет и количество микросервисов — появляется потребность в карте взаимодействия всех сервисов. Если бы она была в каждой продуктовой команде, это бы помогло избежать проблемы “кто-то что-то сломал, потому что не знал структуру взаимодействия микросервисов”.

Кроме этого, повышается частота релизов, что, в свою очередь, приводит к рискам падения продукта — здесь DevOps-инженер должен заранее предлагать конкретные решения, чтобы этих простоев избежать — превентивные мониторинги, автоскейлинг и так далее. Становится очевидной потребность в быстром rollback’е — очень важно иметь возможность быстро откатить “неликвидный” продакшн, чтобы сократить негативный опыт пользователя.

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

Когда нужен подрядчик?

Когда вы вышли из MVP без процессов;
Инфраструктура масштабируется медленно, а растете вы быстро;
Вы уже теряете деньги из-за ошибок разработчиков, отсутствия тестов, rollback’ов и т.д.;
Продажи вышли за пределы одного часового пояса и вам нужна поддержка 24/7;
Вы не хотите терять клиентов — особенно сейчас, когда стоимость их привлечения так высока;

Когда нужен DevOps-подрядчик на этапе роста

А когда нужно уходить?

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

"Бомбы замедленного действия"

Вы можете:

Самое опасное — не продумать обеспечение безопасности. Здесь уже появляются и репутационные риски. Никто не считает, сколько денег будет потрачено на устранение последствий DDoS-атаки в апреле в сравнении с оплатой провайдеру по DDoS-у с января по март, даже с учетом адаптации работы проекта через proxy. Посчитайте, вы очень удивитесь;
Проигнорировать Disaster Recovery — не делать регулярных проверок отказоустойчивости;

Этап зрелости

Характеристики этапа зрелости
На этом этапе уже есть легаси, скорее всего, требующее рефакторинга. Также повышенного внимания требует вопрос обратной совместимости. Говоря о безопасности, мы уже имеем в виду не только файервол и DDoS, но и потребность в средствах мониторинга полного состояния серверов и отслеживание любого незадекларированного поведения в вашей инфраструктуре.

Главная цель бизнеса на этапе зрелости — возврат прибыли на прежние значения, в том числе через тестирование новых гипотез. DevOps может помочь в A / B тестировании новых микросервисов, blue / green deployment, если мы говорим про тестирование всей инфраструктуры, а также с IaC — это тоже позволит разработчикам быстро и дешево тестировать какие-либо гипотезы.

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

Когда нужен подрядчик?

Когда нужны проектные работы или не хватает компетенций внутри компании, а ждать пока HR закроет эту позицию нет времени;
Собственная команда максимально нагружена, а бэклог расписан на год вперед;

А когда нужно уходить?

Все просто — уходите, когда проект закончился