В мире облачных технологий часто возникает конфликт между целями DevOps и FinOps. DevOps стремится к скорости, надежности и масштабируемости, в то время как FinOps сосредоточен на эффективности затрат и часто на том, чтобы некоторые затраты сократить. Кажется, что эти задачи находятся в противофазе: одни строят, другие — урезают. На самом деле, современные DevOps-практики, направленные на повышение производительности и эффективности, являются самым мощным инструментом FinOps. А оптимизация затрат — это не самоцель, а естественное и неизбежное следствие правильно выстроенных инженерных процессов.
Мне давно хотелось услышать мнение DevOps про практики FinOps, и вот в подкасте FinOpsWeekly вышло интервью с участием Виктора Фарчича, в котором он в присущей ему провокационной манере говорит о том, как одно дополняет другое и как девопсы видят оптимизацию со своей стороны. Предлагаемые решения в основном рассчитаны на Kubernetes, но основной посыл и обсуждаемые тренды так или иначе актуальны для многих компаний: эфемерные среды разработки, right-sizing и масштабирование.
Виктор — участник групп Google Developer Experts и Docker Captains, а также автор книг и статей о DevOps и TDD. Его главные увлечения — это DevOps, контейнеры, Kubernetes, микросервисы, непрерывная интеграция, доставка и развертывание (CI/CD), а также разработка через тестирование (TDD). LinkedIn страница Виктора.
Давайте посмотрим на идеальный сценарий для DevOps и бизнеса. Когда приложение исправно работает, пользователи без проблем приходят в приложение, транзакции проходят быстро, пользователь доволен, конверсия и удержание клиентов повышаются, клиентов и транзакций становится больше, а само приложение становится дешевле в эксплуатации.
Достичь идеальных показателей быстродействия и доступности возможно, но цена таких ресурсов будет очень высокой. Поэтому ключевая проблема DevOps специалистов — это найти оптимальное соотношение цены и бизнес-результата при динамически меняющейся нагрузке.
DevOps в своей работе стремится к тому, чтобы мощности соответствовали реальной нагрузке, не сильно больше и не меньше. Возможность динамически масштабировать ресурсы как раз дает такие важные преимущества, как релизы без даунтайма и высокую производительность. С точки зрения DevOps, деньги, которые удовлетворенные скоростью и доступностью клиенты несут в компанию, должны быть частью уравнения, которое определяет эффективность использования ресурсов.
Если мы посмотрим на FinOps как на стратегию максимизации ценности каждого вложенного рубля, то придем к выводу что финопс-специалисты и девопсы работают на общую цель. Как это часто бывает, экономия становится приятным побочным эффектом, а не главной движущей силой.
Снижение затрат — это следствие, а не цель.
Однако давайте пойдем дальше, ведь как удовлетворить растущий трафик — это только первая часть истории. Кроме умения быстро вырасти, также важно уметь быстро сжаться.
Классический пример — подготовка к Черной пятнице или Новому году. Компания может успешно справиться с пиковой нагрузкой, масштабировав инфраструктуру вверх. Но если после окончания пикового спроса она не сможет так же эффективно масштабироваться вниз, то результат, по словам Виктора, будет таким: «Мы отлично справились с нагрузкой в пятницу, однако через две недели после мы обанкротились».
Необходимость управлять ресурсами в динамике вскрывает фундаментальный недостаток традиционного планирования — статический прогноз загрузки.
Как же современные команды решают проблему подбора ресурсов в мире, который не стоит на месте?
Смерть оценкам на глазок: эра автоматической оптимизации
По мнению Виктора Фарчича, традиционный подход к планированию ресурса в динамичной облачной среде безнадежно устарел. Пытаться без практического тестирования угадать, сколько CPU и памяти понадобится новому приложению, — задача невозможная.
Подход к управлению ресурсами прошел три ключевые фазы эволюции:
Фаза 1: Слепые догадки. Устаревший метод, основанный на предположениях. Команды выделяли ресурсы «с запасом», что неизбежно приводило к перерасходу.
Фаза 2: Наблюдение. С появлением инструментов мониторинга, таких как Prometheus, инженеры перешли к анализу реальных данных. Они могли вручную изучать графики потребления CPU и памяти и корректировать настройки. Это был шаг вперед, но он все еще требовал ручного вмешательства.
Фаза 3: Автоматизация. Современный подход заключается в том, что системы сами анализируют данные и автоматически масштабируются. Вместо человека решения принимают машины. Например, инструмент Vertical Pod Autoscaler (VPA) в Kubernetes может работать в режиме наблюдения, чтобы точно определить, сколько ресурсов потребляет приложение, и автоматически корректировать его запросы.
Итак, совет от Виктора: вместо того, чтобы угадывать, нужно опираться на данные и делегировать принятие решений автоматизированным системам. Этот подход особенно важен не только в продуктиве, но и в средах разработки, где скрыты огромные, но часто незаметные издержки.
Сила эфемерности: революция в Dev-окружениях
Огромные скрытые затраты часто связаны с постоянно работающими средами для разработки и тестирования, которые работают 24/7 и обычно выделены один раз и на всю команду. Такие среды обычно большие и дорогие, создавать что-то дополнительно — еще дороже. И здесь видны две основные проблемы:
Лишняя трата денег. Системы продолжают работать и потреблять ресурсы, пока инженеры спят. Это как не выключать свет в офисе на выходных.
Создание «бутылочных горлышек». Из-за высокой стоимости компании могут позволить себе лишь несколько общих сред. Это заставляет разработчиков ждать в очереди. Каждая минута, которую разработчик тратит в ожидании свободной среды, — это прямые финансовые потери и упущенная выгода для бизнеса.
На базе Kubernetes можно создавать среды, которые будут жить ровно столько сколько с ними работает разработчик или тестировщик, то есть эфемерные среды. Такой подход позволяет одновременно снизить затраты и повысить продуктивность, предоставляя каждому разработчику собственное изолированное окружение по требованию.
Механизм работы эфемерных сред прост и эффективен:
окружение создается автоматически по требованию (например, при создании pull request),
после периода неактивности (например, через 5 минут ? ) оно так же автоматически уничтожается.
Для реализации этого подхода можно посмотреть в сторону таких инструментов, как Knative и vСluster.
Архитектура продукта — ключ к оптимизации
Часто оказывается, что главным препятствием на пути к оптимизации затрат является сам программный продукт. Если он не спроектирован для работы в облачной среде, например, не может масштабироваться горизонтально, то никакие инструменты не помогут эффективно управлять его ресурсами.
Самый простой способ обосновать выделение бюджета — это сказать: если мы вложим вот столько, то вернем вот такую сумму. Здесь FinOps может помочь аргументировать необходимость инвестиций в рефакторинг или даже полное переписывание приложения.
Цель таких изменений — не просто сделать программный продукт дешевле, а максимизировать ценность, получаемую с каждого потраченного рубля. Например, для крупного маркетплейса ускорение процесса покупки на несколько секунд может представлять огромную бизнес-ценность, которая принесет миллионы. Инвестиции в производительность приложения напрямую транслируются в рост доходов, что является лучшим аргументом для бизнеса.
Когда базовые принципы оптимизации на уровне приложений и инфраструктуры внедрены, можно переходить к более сложным стратегиям для достижения нового уровня эффективности.
Продвинутые тактики и взгляд в будущее
Помимо базовой оптимизации, существуют более сложные, но высокоэффективные стратегии, выходящие за рамки одного приложения или кластера.
Тестирование в проде и сила Observability
Никакие тесты в изолированной среде не способны полностью имитировать реальное поведение пользователей. Поэтому по-настоящему значимым является тестирование в проде. Поймите правильно, это не означает запуск юнит-тестов на боевой системе. Это означает наличие продвинутых систем observability и автоматизации, которые позволяют системе в реальном времени видеть, что происходит, прогнозировать изменения и автоматически на них реагировать.
Мультиклауд-стратегия для Non-Production
Виктор Фарчич указывает на ставшими доступными новые возможности: использование более дешевых и быстрых облачных провайдеров для сред разработки и тестирования. Раньше такой подход был слишком сложен, но сегодня, когда Kubernetes стал отраслевым стандартом, инфраструктура у разных провайдеров на 99% одинакова, — это делает перенос непроизводственных нагрузок простым и выгодным. Есть альтернативы крупным провайдерам, которые иногда быстрее и чаще дешевле.
Новый вызов: FinOps для AI
Затраты на обучение AI/ML моделей, особенно на дорогостоящих GPU, в ближайшем будущем сделают текущие расходы на инфраструктуру незначительными. Когда один запуск обучения модели или неожиданная популярность AI-сервиса могут вылиться в затраты на сотни тысяч, практики FinOps становятся не просто полезными, но и критически важными. Оптимизация на этом уровне станет следующим большим вызовом для индустрии.
Технологический ландшафт постоянно усложняется, требуя от компаний комплексного и стратегического подхода к управлению облачными ресурсами, где инженерные практики и финансовая дисциплина идут рука об руку.
И в заключении: победила дружба
DevOps и FinOps являются союзниками, а не противниками. Главный вывод прост: инвестиции в автоматизацию, правильную архитектуру, масштабируемость и производительность разработчиков не только создают более качественный продукт, но и являются самым надежным путем к финансовой эффективности в облаке.
Задачу оптимизации затрат нужно рассматривать комплексно, не упуская из внимания ценность, которую имеет масштабируемость архитектуры, быстродействие и доступность сервисов для клиентов.