Как работает 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 закроет эту позицию нет времени;
- Собственная команда максимально нагружена, а бэклог расписан на год вперед;
А когда нужно уходить?
Все просто — уходите, когда проект закончился
Применение DevOps-аутсорса на разных этапах жизненного цикла продукта
Когда появляется потребность в DevOps-команде, перед бизнесом всегда встают конкретные вопросы: “А всё-таки, как решить мою проблему — нанять DevOps-специалиста в штат, использовать аутстафф или...
habr.com