Когда появляется потребность в DevOps-команде, перед бизнесом всегда встают конкретные вопросы: “А всё-таки, как решить мою проблему — нанять DevOps-специалиста в штат, использовать аутстафф или отдать проект на аутсорс? Есть ли четкие критерии для выбора? Что будет эффективнее?”
На конференции DevOps Conf 2023 я, Станислав Тибекин, CVO компании Nixys, рассказываю именно об этом, а в качестве основного критерия для выбора модели взаимодействия предлагаю использовать этап жизненного цикла вашего продукта.
Доклад полностью (с шутками, кейсами и глубоким анализом) доступен на канале Youtube, а ниже — только основное.
Как работает 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 вообще :( В будущем вы можете оказаться в ситуации, когда у вас уже 30-40 микросервисов, но нет созависимых деплоев, процессов, гибкости, нет возможности отката…
Этап роста
Ура! У вас появляются продажи, активно растет количество пользователей, но растет и ответственность перед ними — вы больше не можете позволить себе “упасть и прилечь”.
Растет команда возникают трудности во взаимодействии. Появляется потребность во внедрении релиз-менеджмента. Растет и количество микросервисов — появляется потребность в карте взаимодействия всех сервисов. Если бы она была в каждой продуктовой команде, это бы помогло избежать проблемы “кто-то что-то сломал, потому что не знал структуру взаимодействия микросервисов”.
Кроме этого, повышается частота релизов, что, в свою очередь, приводит к рискам падения продукта — здесь DevOps-инженер должен заранее предлагать конкретные решения, чтобы этих простоев избежать — превентивные мониторинги, автоскейлинг и так далее. Становится очевидной потребность в быстром rollback’е — очень важно иметь возможность быстро откатить “неликвидный” продакшн, чтобы сократить негативный опыт пользователя.
На этом этапе главный вопрос бизнеса: “Почему инфраструктура, за которую я плачу, неэффективна?”. От DevOps-инженера ожидается, что он будет помнить о специфике бизнеса — сезонности, распродажах и т.д. Плюс держать в уме, что на этом этапе бизнес вкладывает большие деньги в маркетинг, а значит — стоит ожидать постоянного притока новых клиентов.
Когда нужен подрядчик?
Когда вы вышли из MVP без процессов;
Инфраструктура масштабируется медленно, а растете вы быстро;
Вы уже теряете деньги из-за ошибок разработчиков, отсутствия тестов, rollback’ов и т.д.;
Продажи вышли за пределы одного часового пояса и вам нужна поддержка 24/7;
Вы не хотите терять клиентов — особенно сейчас, когда стоимость их привлечения так высока;
А когда нужно уходить?
Вам хватает прибыли для содержания своей команды;
Нет возможности обеспечить полное погружение в цели бизнеса и важность текущих работ. О чем речь? Чтобы грамотно вводить в курс дел подрядчика, нужен человек, полностью погруженный во все детали проекта и способный корректировать работы. Если такого человека нет, то стоит рассмотреть модель аутстаффа, а не аутсорса;
"Бомбы замедленного действия"
Вы можете:
Самое опасное — не продумать обеспечение безопасности. Здесь уже появляются и репутационные риски. Никто не считает, сколько денег будет потрачено на устранение последствий DDoS-атаки в апреле в сравнении с оплатой провайдеру по DDoS-у с января по март, даже с учетом адаптации работы проекта через proxy. Посчитайте, вы очень удивитесь;
Проигнорировать Disaster Recovery — не делать регулярных проверок отказоустойчивости;
Этап зрелости
На этом этапе уже есть легаси, скорее всего, требующее рефакторинга. Также повышенного внимания требует вопрос обратной совместимости. Говоря о безопасности, мы уже имеем в виду не только файервол и DDoS, но и потребность в средствах мониторинга полного состояния серверов и отслеживание любого незадекларированного поведения в вашей инфраструктуре.
Главная цель бизнеса на этапе зрелости — возврат прибыли на прежние значения, в том числе через тестирование новых гипотез. DevOps может помочь в A / B тестировании новых микросервисов, blue / green deployment, если мы говорим про тестирование всей инфраструктуры, а также с IaC — это тоже позволит разработчикам быстро и дешево тестировать какие-либо гипотезы.
Возможно, продукт выходит на международные рынки — значит Devops-инженеру нужно делать инструменты максимально унифицированными, чтобы безболезненно использовать их на облаках других регионов.
Когда нужен подрядчик?
Когда нужны проектные работы или не хватает компетенций внутри компании, а ждать пока HR закроет эту позицию нет времени;
Собственная команда максимально нагружена, а бэклог расписан на год вперед;
А когда нужно уходить?
Все просто — уходите, когда проект закончился :)
Бонус: синхронизируем бизнес и DevOps-подрядчика
В качестве шпаргалки, хотел бы предложить вопросы, которые бизнесу стоит задать DevOps-подрядчику, чтобы сделать работу с ним максимально эффективной:
А также вопросы, которые DevOps’у стоит задать перед началом работ, чтобы синхронизироваться с бизнесом:
Если у вас остались вопросы — буду рад ответить на них в комментариях!
Видео:
Презентация:
И приглашаю вас подписаться на наш TG-канал и YouTube — мы всегда рады новым друзьям!