Как контролировать расходы на облачную инфраструктуру: финансовый DevOps (a.k.a. FinOps) и сокращение затрат на 30%

Получив неограниченные ресурсы, компании могут необоснованно увеличивать затраты на облако вне зависимости от реальных потребностей. Вместе c Ильей и Виталием, экспертами «Лаборатории FinOps», разберем, как изменить эту ситуацию, внедрив в компании методологию FinOps (Cloud Financial Operations) — процессы и культуру управления затратами на облачные технологии.

Чтобы плавно перейти к FinOps’у, вспомним основу: какие бизнес-задачи решает облако.

• Сокращение time-to-market. Быстрое развертывание и эффективная поддержка ИТ-инфраструктуры с приходом облака больше не является проблемой — время от постановки задачи до разработки сократилось в разы.
• Увеличение скорости доступа к инновациям. Бизнесу не надо задумываться о поддержании ИТ-инфраструктуры на должном технологическом уровне, за это отвечает провайдер. Обновления существующих сервисов, а также новые инновационные сервисы, резервное копирование, DBAAS и другие решения доступны мгновенно и внедряются легко в отличие от развертки на собственных ресурсах.
  
• Ускорение разработки. Разработчикам не нужно проходить через процессы procurement’а и запрашивать новые мощности у отдела финансов. Все доступно гораздо быстрее. Сам процесс разработки также ускоряется — частью облачного предложения стала инфраструктура как код (IaC). Облако — это не только серверы, но и оболочка сервисов вокруг — environment.
  
• Обеспечение высокой масштабируемости инфраструктуры. В случае необходимости компании могут в дата-центрах за короткий период закупить оборудование или заключить партнерское соглашение с аутсорсинговым провайдером железа. Но избавиться от обеспеченной таким образом инфраструктуры гораздо сложнее — это все долгосрочные контракты. В облаке масштабирование «вверх» и «вниз» идет без транзакционных издержек за счет эластичности — одного из главных преимуществ облачной модели.
  

Как показали многочисленные кейсы успешной цифровой трансформации, правильно сконфигурированное облако экономически эффективнее собственных дата-центров за счет приведенных выше преимуществ.

Блок технических проблем, которые приводят к неэффективному использованию облака, достаточно широкий, но можно выделить два основных направления.

1. Неиспользуемые ресурсы

Мгновенный доступ к ресурсам зачастую приводит к избыточности. Например, компания подключает дополнительные виртуальные машины, чтобы справиться с нагрузкой на «черную пятницу», но забывает отключить их после использования. При системе биллинга ‘Pay as You Go’ неиспользуемые ресурсы продолжают тратить деньги.

Вот лишь некоторые кейсы неиспользуемых мощностей:

• ресурсы под Load Test, которые забыли выключить (виртуальные машины, базы данных, network);
• различные компоненты облачной архитектуры, которые не были удалены после окончания использования (например: IP-адреса без привязки, балансировщики нагрузки, вычислительные ресурсы и т.д.);
  
• неоптимальный tier хранения данных (платим за хранение с быстрым доступом, а файлы в последний раз запрашивались год назад).
  

2. Не адаптированная под облако архитектура

В облаке время и мощность работы сервера должны зависеть от загрузки приложения, поэтому нужна архитектура, позволяющая безболезненно выключаться («даунскейлиться») на время низкого потребления мощностей.

Приложение, построенное для работы в неэластичном формате дата-центра («всегда включено» — always on), например, теряет данные при каждой остановке сервера. Восстановление может быть долгим или вовсе невозможным.

Изменение архитектуры — сложная задача. Не удивительно, что приложения часто переносят «как есть». В результате они настроены не оптимально и не используют эластичность — основное преимущество облака.

Концептуально с переездом в облако сильно поменялась роль финансов в процессах ИТ-прокьюремента компании. Если раньше финансисты утверждали приобретение ИТ-ресурсов для команд разработки, то теперь разработчики (DevOps, QA, AppDev) могут бесконтрольно тратить деньги через код. В больших компаниях, где затраты на облако исчисляются миллионами долларов, такое отсутствие контроля ведет к проблемам экономической неэффективности. Традиционные подходы для анализа и прогнозирования бюджета просто не работают в новых облачных реалиях.

1. Сложность систем тарификации облачных ресурсов (оплата сервисов тарифицируется по разным схемам: за CPU в час, гигабайты, API-запросы и т. д.).

Разные модели биллинга и большое количество данных влияют на стоимость облачных услуг. Тарификация за каждый ресурс в облаке со своей моделью оплаты значительно повышает сложность аудита биллинга. Компаниям необходима экспертиза для базового понимания данных биллинга, предоставляемых провайдером облачных услуг. От этого зависит интерпретация затрат на облако и правильное построение отчетов.

2. Прогнозирование затрат на облачные сервисы требует понимания архитектуры и нового инструментария для мониторинга.

Ситуация, когда затраты растут, а в компании не понимают причину. Происходит в силу разных проблем:

• ресурсы, поднятые на Dev/Test-окружениях, не используются: например, подняли ресурсы под нагрузочное тестирование и не выключили;
• нет механизмов масштабирования (Auto scaling);
  
• ошибки в архитектуре: например, временное хранилище в приложении не имеет политик удаления данных — данные накапливаются и стоимость растет;
  
• различные технические ошибки: например, после удаления виртуальных машин остальные компоненты не удаляются (блочные диски, IP-адреса и т. д.).
  

Резюмируя, технические проблемы связаны с тем, что перемещение рабочих нагрузок в облако происходит без изменений (по модели lift-and-shift); финансовые — c отсутствием процессов контроля.

Практика Cloud FinOps стала ответом на перечисленные проблемы. FinOps — это процессы, система, культура управления затратами. FinOps помогает анализировать затраты на облачные технологии и принимать бизнес-решения — в том числе технические — об изменении архитектуры и очистке неиспользуемых ресурсов.

С помощью фреймворка FinOps можно:

• оптимизировать расходы на облачную инфраструктуру;
• прогнозировать бюджет за счет широкого спектра инструментов для сбора и анализа данных;
  
• проводить аудит и мониторинг использования облачных ресурсов.
  

Фреймворк представляет собой три стадии, по которым нужно идти циклически:

1. Стадия информирования. Включает процессы обеспечения прозрачности: настройку мониторинга, аудит облачных затрат и т. д.
2. Стадия оптимизации. Процесс оптимизации облачной инфраструктуры на основании полученных из первого шага данных.
   
3. Стадия управления. Процесс обеспечения непрерывности и эффективности вышеперечисленных стадий. Подразумевает культурную составляющую, которую сложнее всего достичь. Когда в компании много облачных ресурсов и от них зависит бизнес, недостаточно раз в квартал идти и что-то чистить. Инженеры должны знать, к чему ведут их действия с точки зрения экономической эффективности.
   

Разберем на примере. Компания Lyft (основной конкурент Uber в США) тратит на облако больше $100 млн в год. Стандартный биллинговый файл компании несколько лет назад имел следующие характеристики:

• 1.5+ Гб — размер дневного счета в формате CSV;
• 45+ Гб — объем месячных данных;
  
• 120+ столбцов;
  
• 2M+ строк за один день.
  

А еще есть данные финансового характера из API, внутренние технические данные (типа статистики по контейнерам Kubernetes), а также данные по организационной структуре компании (для бюджетирования и возврата платежей). Кроме того, сами по себе «сырые» данные бесполезны без глубокой аналитики. Прибавьте к этому прогнозирование, бюджетирование и выявление аномалий.

Команда инженеров Lyft построила решение, обеспечивающее прозрачность использования облачных сервисов. Появилась понятная метрика, которая рассчитывала стоимость облачных сервисов для обеспечения одной поездки (Cost per Ride). За 6 месяцев перевозчик на 40% сократил затраты на облако.

Второй кейс — пример технического редизайна. ИТ-компания PandaDoc помогает автоматизировать документооборот и отслеживать торговую документацию. PandaDoc сделала реинжиниринг систем, изменила архитектуру используемых процессоров и сократила затраты на вычислительные ресурсы на 45%, которые обычно составляют 60% от всего чека.

К 2020 году «финансовый DevOps» оформился в полноценную дисциплину. Джонатан Стормен (J.R. Storment), соучредитель ведущей облачной платформы для управления затратами на облачные ресурсы Cloudability, и Майк Фуллер (Mike Fuller), главный системный инженер облачного центра Atlassian, выпустили книгу, которая фактически стала библией для этой индустрии.

Центр знаний методологии — FinOps Foundation (часть The Linux Foundation), в котором более 5 000 активных пользователей. К сообществу подключаются крупные игроки, которые у себя внедрили методологию и активно участвуют в ее развитии: EA, Apple, Adobe, Atlassian, Goldman Sachs.

На сегодняшний день любая организация, которая использует облачные ресурсы или делает первые шаги цифровой трансформации, так или иначе использует FinOps.

В пример можно привести один из крупнейших международных банков. Примерно два года назад они начали активно переводить свои американские офисы в облако. В процессе перехода FinOps уже был заложен в проект.

Наша практика показывает, что для успешного и эффективного внедрения необходимы следующие составляющие:

• Вовлеченность топ-менеджмента компании — позволяет сформировать единое понимание и актуализировать приоритеты у всех участников процесса.
• Централизованная FinOps-команда — является фасилитатором, отвечающим за внедрение и кросс-командную коммуникацию. Размер централизованной команды зависит от объема затрат на облако и сложности инфраструктуры, это может быть даже один человек.
  
• Итеративность — рекомендуемый метод внедрения FinOps-фреймворка. В рамках каждой из трех фаз есть набор задач, которые могут внедряться постепенно. Например, на фазе информирования одна из задач — тегирование ресурсов. С этой задачи чаще всего начинается внедрение фреймворка. Итерационный подход возможен и на уровне организационной структуры. Можно выделить первую группу команд для пилотирования фреймворка, потом масштабировать.
  

Дисциплина FinOps появилась относительно недавно, но уже успела себя хорошо зарекомендовать во множестве компаний. Сам фреймворк продолжает развиваться и эволюционировать, но на первых этапах все компании проходят через идентичный набор шагов.

На множестве примеров мы видим, что проблема управления затратами на облачную инфраструктуру часто возникает у компаний, использующих облака, поэтому мы рекомендуем действовать проактивно. Также стоит отметить, что ключевым отличием методологии от проектов по оптимизации является непрерывность. В связи с перечисленными выше изменениями процессов разработки, которые несет с собой облако, необходимы процессы и инструменты для управления затратами на облачную инфраструктуру в режиме 24/7.