Облака — это не только модно, это еще и удобно. Если даже вы не работаете в парадигме Cloud First, аренда облачных ресурсов позволяет успешно справляться с пиками нагрузок, решать срочные задачи и так далее. Ну а если вас затянуло в «облачные дали», то сам подход к разработке сервисов становится не таким, как раньше. В нашей практике 2020 год оказался очень показательным. В период пандемии мы, как и многие другие бизнесы, столкнулись с кратным ростом онлайн-трафика и сервисы гиперскейлера позволили нам проходить периоды интенсивной нагрузки на наши системы безболезненно. Но когда все понимают, что стратегия Cloud First оправдывает себя, инфраструктура начинает постепенно (или быстро) перемещаться в облако. Все хотят использовать простые и доступные облачные сервисы, а платить за огромный счет потом никто не хочет. FinOps полезен тем, что помогает навести порядок в облачных финансах.
Что тратим, куда тратим?
Разработчики, конечно, довольны, когда могут получить по требованию любой ресурс, запустить сервис, провести тестирование. Но когда в финансовый отдел приходит счет за облака с набором непонятных технологий внутри и просьбой оплатить в течение 14 дней, у него неизбежно возникают вопросы: «Кто все это заказал? Зачем это нужно бизнесу? Почему так много?» Да, обычно финансисту непросто разобраться с облачным счетом, но даже когда людей, работающих с затратами на облако, выделяют в специальную функцию или отдел, без специальных инструментов навести порядок в затратах по-прежнему оказывается непросто. Более того, вопросы, которые я написал выше, часто оказываются очень даже уместными.
Когда мы подошли к необходимости развития FinOps, наша компания столкнулась с рядом проблем, совершенно типичных для любых организаций, кто уже работает в облаке, но еще не управляет затратами.
Все затраты на облако висели на одной команде, т. е. потребляли одни, а платили другие.
Было невозможно распределять затраты по продуктам, чтобы считать P&L.
Не получалось анализировать, правильно ли используются облачные сервисы.
Не было инструмента, который давал бы в близком к реальному разрезу времени информацию об операционных затратах команды на облачную инфраструктуру.
Инженеры не понимали, как конечная solution architecture влияет на затратную часть продукта.
Поэтому осенью того же года мы приняли решение проработать концепцию развития направления FinOps в компании и внедрить подход.
Если вы еще не изучили саму концепцию FinOps, под спойлером я подготовил небольшой обзор этого направления.
C начала эры гиперскейлеров все больше и больше бизнесов стали размещать свои продукты в облаках. Вместе с открытием больших возможностей облаков компаниям стали приходить счета за использование ресурсов. Подход к управлению облачными затратами родился децентрализованно в нескольких компаниях в разных частях мира, но задача перед всеми была одна: как дать возможность командам оценивать свою эффективность на основании данных о затратах на услуги облачных провайдеров?
Через некоторое время появилось само название FinOps — подробнее об истории возникновения и самом фреймворке можно прочесть в этой книге.
Выделяют 3 основные стадии жизненного цикла FinOps: Inform, Optimize, Operate.
Каждая фаза нацелена на определенный итог в конце и является пререквизитом для следующего этапа.
В случае с FinOps лучше раньше
Итак, на момент начала проекта у нас в облаке работало 2 команды с полноценными продуктами, и уже тогда мы нашли ряд проблем, которые нужно было срочно решать. Оглядываясь назад, я очень радуюсь, что мы так рано начали использовать практики FinOps. Это позволило нам существенно сократить затраты на облака и направить средства в другие важные для ИТ направления. Но начнем по порядку.
Почему эти ребята так много тратят?
Больше всего наших стейкхолдеров расстраивало то, что за все облачные сервисы платит один отдел. В такой ситуации просто невозможно разобраться с расходами, а также хоть как-то мотивировать остальных обдумывать свои запросы к облаку. Поэтому мы решили начать с этого.
В то время у нас не было как такового внутреннего каталога цифровых продуктов, на который можно было бы аллоцировать затраты облака. Но зато наши замечательные коллеги из информационной безопасности уже давно собирали уязвимости по продуктам и сводили их в один реестр. Мы обсудили с ними идею добавить в их каталог уникальный идентификатор продукта, который впоследствии стал сквозным. Так удалось создать первую версию продуктового каталога, который впоследствии стал важным компонентом экосистемы FinOps. Мы используем его как источник мастер-данных для привязки продукта к…
Организационной структуре.
Центрам затрат.
Выделенным ролям ответственных за развитие и обеспечение надежности продукта.
Дальше нам было необходимо соотнести текущую облачную инфраструктуру с центрами затрат и научиться правильно разбивать приходящий раз в месяц счет за услуги. Можно сказать, что это был уровень зрелости crawl по критериям FinOps Fondation.
Кратко про уровни зрелости тут.
Есть три уровня, по которым определяют зрелость FinOps-процессов внутри организации:
Crawl. Обеспечиваем минимальный гигиенический уровень. Этот этап больше ориентирован на достижение быстрых результатов и показ выгод от внедрения FinOps. Тут определяют первые KPI успешности, по которым можно отслеживать сам процесс внедрения. Аллоцировано 50% затрат.
Walk. Плюсы от внедрения понятны командам. Определены пограничные кейсы, приняты решения об их устранении или принятии. Затраты аллоцированы на 80%.
RUN. Практически полная автоматизация. Решаются сложные пограничные кейсы. Затраты аллоцированы на 90%.
Автоматизацию в последнем пункте стоит читать как автоматизацию рутинных процессов, связанных с FinOps, это может быть как выключение непродуктивных сред разработки на выходные, так и нотификация ответственных за ресурсы лиц о возможной экономии.
Когда пользователей много — вам точно НУЖНА автоматизация
После этих подготовительных мер нам уже удалось успешно разбить облачный счет на 2 команды. Параллельно мы начали «продавать» облако внутри компании, и наличие уже хотя бы базового FinOps было очень важно, потому что количество наших внутренних клиентов стало стремительно расти.
На тот момент мы продолжали тегировать облачные ресурсы в ручном режиме, что уже не казалось очень хорошей идеей. И тут мы пришли к первой автоматизации, точнее к self-services. Для этого моя команда разработала удобный пользовательский интерфейс, в котором каждый сотрудник компании может получить кусочек облака под свои нужды, а мы его для них переподготовим, накинем нужные права, обеспечим нужными сетями и, конечно же, будем записывать биллинг.
Вот смотрю я на этот абзац, в котором так просто написал о том, что мы сделали… и понимаю, что на самом деле было сломано изрядно копий до того момента, как получилось то, что должно быть. Если вы тоже решите разрабатывать свой UI для provisioning (подготовки) облаков, готовьтесь, что это будет не так просто, потому что на этом этапе потребуется:
продумать все с точки зрения архитектуры;
не забыть о требованиях современных пользователей к UX/UI.
Но, так или иначе, на этом этапе зародился фронтенд нашей внутренней платформы. Сейчас это называют platform engineering, а недавно CNCF опубликовали интересную статью и рассказали, какими атрибутами должна обладать платформа с их точки зрения. Если будете вести свою разработку или оценивать доступные решения, советую почитать — очень информативно.
Но вернемся к нашей разработке. За счет автоматизации self-service-процессов мы уже знали, к какому продукту и центру затрат привязаны сервисы сразу после того, как пользователь забирал кусочек облака. В итоге проблемы с перевыставлением затрат исчезали.
Чтобы дать командам возможность близко к реальному времени понимать затраты на облачные сервисы в разрезе их продуктов, мы стали раз в час опрашивать облачного провайдера на предмет обновления наших счетов. Сделали для этого красивый интерфейс и как результат:
У каждой команды и менеджеров появилось понимание, сколько стоят все инфраструктурные компоненты их продукта.
Ребята теперь могут посмотреть динамику изменения затрат на конкретные сервисы в разрезе времени.
Разработчики видят цену изменения в архитектуре продукта в близком к реальному времени режиме.
Само собой, это все красиво отображается на графиках и форкастится в режиме реального времени.
Дополнительные сервисы делают жизнь лучше
Спустя какое-то время после запуска MVP нашей FinOps-системы я пошел проводить CustDev с пользователями. Нужно было проверить несколько гипотез. Например, мне было интересно, насколько важно для пользователей видеть реальные бюджеты и наблюдать вживую, как он сгорает (звучит захватывающе, но на самом деле это простой план-факт исполнения бюджета на облако).
Как оказалось, все очень сильно зависит от команд и их зрелости.
Но, к счастью, более зрелых групп оказалось больше, и мы сделали интеграцию с финансовой системой, которая дала возможность показывать расходование бюджета на облачный OPEX.
Второе, что я проверял, — это отношение коллег к сервису рекомендации. Нужно было узнать, хочет ли продуктовая команда получать раз в неделю рекомендации по оптимизации инфраструктуры или нет. Собрав достаточно информации, мы решили сделать и такой сервис.
Сокращение затрат на облако
Проверять возможность оптимизации мы решили с самого простого. Для начала научили систему смотреть, есть ли в облаке брошенные диски. И как оказалось, они всегда есть! И их может быть очень даже приличное количество.
В итоге уже с помощью первой ручной итерации нам удалось сэкономить почти 10% от годового облачного счета только на одной проверке. То, что мы удивились, это будет слабо сказано. Начали раскапывать этот кейс и нашли ответ. Он оказался удивительно простым: один из workflow в нашей инфраструктуре работал с ошибкой и не удалял за собой мусор в виде брошенных дисков. Мы быстро исправили этот баг, но самое главное — инженеры увидели, как ошибка может влиять на затратную часть продукта. И теперь следят за тем, как работает инфраструктура в облаке.
Следующим этапом мы создали сервис рекомендаций, который раз в день рассылает продуктовым командам письмо с предложениями по оптимизации инфраструктуры. Сейчас таких рекомендаций 3.
Проверьте не присоединенные к VM диски.
Оцените, насколько вам нужные эти снепшоты.
У вас неправильный сайзинг для виртуальной машины — сделайте что-то с этим!
Письмо выглядит следующим образом:
Потом мы сделали отдельный интерфейс c сервисом рекомендаций в нашем UI для внутренней платформы, потому что пользователям было удобнее отслеживать рекомендации именно в таком формате.
Как итог, за прошлый год на таких вот оптимизациях мы смогли получить около 30% экономии от нашего облачного счета.
Планы на будущее
В ближайшее время мы планируем разобрать все наши ресурсы общего пользования (shared) и доразбить затраты на кластеры K8s по продуктовым командам. Вообще, с подходом с K8s лично мне импонирует подход, который отображен на схеме ниже. Оно не только «про куб», но и вообще про разбиение затрат на уровне компании.
Чтобы ничего не потерять, уже сейчас мы пошли чуть по другому пути и добавили лейблы на уровне namespace. В нашем случае лейбл — это сквозной ID продукта, про который я писал в первой части статьи.
Учитывая, что платформа уже вовсю работает, мы хотим также начать показывать командам:
Углеродный след от их цифровых продуктов (Carbon footprint).
Структуру Cost efficiency — полной стоимости инфраструктуры гибридного облака, стоимость поддержки, стоимость миграции и имплементации того или иного решения на разной инфраструктуре (on-prem, cloud, multi-cloud).
Добавить алертинг в реальном времени и сообщать об аномалиях потребления облака прямо «в деньгах».
Вовлекать разработчиков в принятие решения о стоимости внедрения изменения. То есть обсуждать новые релизы, которые могут кардинально изменить экономику потребления облака конкретным продуктом. Как уже показала практика, обычно это бывает сюрпризом для владельца бюджета команды и может привести к пересмотру планов разработки.
Итоги
Насколько я вижу, FinOps в России пока еще остается достаточно нишевой историей. Подобные фреймворки не внедряют массово, а нативные инструменты облаков по анализу затрат и возможной оптимизации у российских облачных провайдеров развиты не на достаточном уровне, чтобы действительно работать с затратами профессионально.
При этом нам удалось сократить достаточно большую часть затрат на облако именно благодаря ранней адаптации фреймворка и поддержке со стороны руководства. Если вы только собираетесь внедрять FinOps или смотрите в сторону того, как продать эту историю менеджменту и получить буст в карьере (ведь бизнес любит быть экономным и эффективным), просто начните выстраивать практику FinOps в компании. Для этого достаточно просто взять один продукт в облаке, договориться с его техлидом или продуктовым менеджером, чтобы проанализировать затраты и найти точки оптимизации.
Если вам будет интересен наш опыт глубже или вы захотите попробовать адаптировать наши наработки в сфере FinOps, обращайтесь!
Всем FinOps’а — и побольше!
