FinOps, или практика управления расходами компании на облачную инфраструктуру, и DevOps, процесс эффективного создания приложений в облаке, в идеале должны идти рука об руку.
При наличии оптимизированного процесса разработки и инженеров, ориентированных на снижение затрат, компании могут создавать функциональные продукты с высокой рентабельностью и высоким потенциалом масштабируемости. Однако внедрить FinOps в жизненный цикл DevOps и наоборот не всегда просто. Вы не можете просто попросить своих инженеров в один прекрасный день начать следовать принципам FinOps и ожидать, что они сразу же перестроят свое мышление на приоритет облачных затрат.
По мере того как мы будем обсуждать приведенные ниже способы сохранить финансовую составляющую в качестве главного приоритета на протяжении всей разработки, помните, что изменения будут постепенными и итеративными, а не масштабными и мгновенными. Отмечая постепенный прогресс, а не требуя немедленного успеха, вы поможете своей команде освоить новые обязанности с меньшим сопротивлением.
Ниже приводим несколько способов как побудить инженеров сосредоточиться на FinOps как части жизненного цикла DevOps:
1. Объясните разработчикам, почему затраты на облако так важны
С каждым годом кажется, что в среднестатистической SaaS-компании на разработчиков возлагается все больше и больше обязанностей. В "старые добрые времена" разработчики могли прийти на работу и провести день, занимаясь тем, что они любят больше всего: написанием кода.
Теперь разработчики отвечают за наставничество, мониторинг операций, участие в совещаниях, обеспечение безопасности программного обеспечения и написание кода. Несмотря на все большее количество обязанностей, разработчики в целом по-прежнему любят создавать полезные продукты. Если продукт успешен и хорошо используется, разработчики, работавшие над ним, будут счастливы.
Однако Saas-компании должны быть осторожны и не сваливать все эти обязанности на разработчиков, не объясняя причин. Балансировать между этими обязанностями непросто, и в каждой области есть масса возможностей для ошибок. Например, заглянуть на шесть месяцев вперед, чтобы предсказать стоимость еще не созданного продукта, - задача не из легких.
Если вся команда разработчиков понимает, почему такая задача важна для компании - в данном случае для того, чтобы маржа продукта оставалась на высоком уровне и компания зарабатывала, а не теряла деньги, - ее выполнение кажется гораздо более целесообразным.
По возможности указывайте конкретные цифры и ограничения вместе с целями. Допустим, ваша компания хочет разработать новую функцию для существующего продукта. Хорошая дорожная карта, которую вы можете предоставить своим разработчикам, должна включать в себя:
возможности новой функции
желаемый бюджет
желаемый результат с точки зрения маржи или прибыли
влияние этого результата на компанию
реалистичные прогнозы о том, сколько клиент готов будет заплатить за конечный продукт и сколько пользователей он может поддерживать
Ваша команда может сразу приступить к работе, а может развернуться и сказать: "Эта функция не будет рентабельной, если вы планируете продавать ее за X рублей, потому что вот эта часть будет стоить миллионы рублей, а ваша заявленная клиентская база не сможет принести достаточный доход, чтобы перевесить затраты".
В любом случае, предоставление разработчикам как можно большего объема информации способствует продуктивным дискуссиям и помогает им с самого начала ориентироваться на цели компании.
2. Обеспечьте разработчиков данными и инструментами, необходимыми для достижения целей FinOps
Если спросить среднестатистического человека, каким будет его семейный бюджет через десять лет, он не сможет ответить. Так много переменных отделяет настоящее от далекого будущего, что практически невозможно предсказать, как будут выглядеть вещи через десятилетие. Количество людей в семье может увеличиться или уменьшиться, члены семьи могут сменить работу, инфляция может резко подскочить, и еще множество других вещей может произойти в период между этим и тем временем. Нет никакой прочной системы отсчета, на основе которой можно было бы сделать обоснованное предположение.
Однако если вы спросите владельца собаки, сколько будет стоить содержание второй собаки точно такого же размера и типа, то, скорее всего, получите очень точный ответ. Этот человек привык определять стоимость корма, визитов к ветеринару и препаратов от блох. Они могут проанализировать предыдущие покупки и точно сказать, сколько они потратили и на какие услуги. Другими словами, у них есть данные за прошлые периоды и инструменты (их выписки с указанием предыдущих расходов на содержание собак), чтобы ответить на ваш вопрос.
Предоставление вашим разработчикам возможности использовать относительную оценку - это мощный инструмент эффективной практики FinOps. Разработчики, которые понимают факторы стоимости облачных вычислений на детальном уровне для функций, которые они создают и поддерживают, лучше подготовлены к принятию экономически обоснованных решений при проектировании и создании новых предложений.
Используя решения, подобные тем, что предлагает платформа Клаудмастер, разработчики могут просматривать все соответствующие данные о затратах, связанных с существующими облачными сервисами, и использовать эту информацию в качестве основы для будущих оценок.
3. Прививайте привычку следить за расходами на облака
Скорее всего, вам не нужно напоминать о том, что утром нужно причесаться и почистить зубы. Вы делаете это каждый день с самого детства, и эти привычки настолько укоренились, что было бы странно внезапно перестать их выполнять.
Точно так же вы хотите, чтобы каждый разработчик в команде выбирал экономически эффективную инфраструктуру и помнил о расходах по умолчанию, как если бы это была давно отработанная привычка. Лучший способ добиться этого - сформировать культуру достижения целей, связанных с затратами, чтобы каждый разработчик понимал, где находятся приоритеты компании. Если вы часто обсуждаете вопросы стоимости и предоставляете информацию о целях, связанных с затратами, это отличная отправная точка.
Когда команда начнет достигать этих целей, хорошей идеей будет публичное признание этих достижений. Если один сотрудник получит признание за свое превосходное мышление и усилия в области FinOps, другие члены команды, скорее всего, будут подражать его поведению.
4. Предвидеть возможные проблемы на ранней стадии
Как вы планируете действовать, если что-то пойдет не так?
Слишком много компаний устанавливают бюджеты на проекты для своих разработчиков, а затем оставляют их без дополнительной информации, инструментов или руководства. Спустя полгода они смотрят на проект и понимают, что он вышел за рамки бюджета. Это не только расстраивает всех участников проекта, но и не позволяет естественным образом решить проблему, поскольку деньги уже потрачены.
Частью успешной работы, как в финансовом плане, так и в плане разработки, является разработка способов итеративного улучшения прошлых неудач и смягчения последствий будущих ошибок. Один из способов сделать это заранее обдумать какими способами или с помощью каких инструментов можно быстро обнаружить проблемы и ошибки до того, как они выйдут из-под контроля.
Например, если вы ежедневно отслеживаете расходы на проект, вы уже на ранней стадии узнаете, что затраты на проект растут слишком быстро. Здесь на помощь вам придет прогнозирование бюджета на самых ранних этапах исходя из текущих показателей расходов на инфраструктуру.Таким образом, у вас будет достаточно времени, чтобы скорректировать ситуацию и попробовать другой подход, прежде чем проект станет слишком дорогостоящим.
Для подготовки статьи использовалась информация из источника: https://www.cloudzero.com/blog/finops-lifecycle/