Привет, Хабр! Меня зовут Эд, я менеджер биллинга в Selectel. Сегодня хотел бы рассказать про подход FinOps, который объединяет продуктовое мышление, мониторинг и управление облачными ресурсами. А еще показать графики и разобрать, кому и зачем это вообще нужно. Спойлер: не только кросс-командным проектам. Приглашаю за подробностями под кат.

Да кто такой этот ваш FinOps


FinOps (Financial Operations или Cloud Financial Operations) — это практика управления затратами, которая помогает компаниям получить наиболее эффективное и экономически выгодное использование облачных ресурсов.

Например, у нас есть IT-инфраструктура с сотней виртуальных машин с блекджеком. Мы понимаем общую стоимость владения и поддержки, но не в разрезе сколько ресурсов из общего пула относится к конкретному проекту.

FinOps помогает привязать вычислительные мощности к деньгам и учитывать стоимость IT-инфраструктуры в бюджете проекта. Мониторинг позволяет получить детальную аналитику потребления, чтобы проводить бюджетирование, основываясь на реальных цифрах.

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

Основные цели FinOps


Мотивация внедрения FinOps во многом зависит от состава команды и зрелости процессов. Среди основных причин можно выделить:

  • Прогнозирование и подсчет расхода текущих ресурсов. Это помогает компаниям детально понимать свои затраты на облачные услуги и контролировать их.
  • Создание культуры принятия экономически обоснованных решений. Подход включает в себя понимание реальных затрат на облако и их влияние на общую бизнес-модель.
  • Увеличение бизнес-ценности облачных инвестиций в on-premise. Каждый потраченный на облако рубль должен способствовать достижению целей.

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

Особенности подхода


Кроме основной цели, о которой говорилось выше, FinOps может быть использован с более глобальными фреймворками по управлению IT-ресурсами. Например, IT Service Management (ITSM) и IT Asset Management (ITAM), но они не сосредоточены исключительно на облачных затратах. Подробнее о совместном использовании фреймворков можно прочитать на официальном сайте FinOps Foundation.

Преимущества

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

Немного практики


Проснувшись однажды утром после беспокойного сна, Грегор Замза обнаружил, что он использует FinOps.

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

Ситуация

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

Решение

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



Основные метрики FinOps и способы отслеживания в Selectel


Теперь разберем, как это выглядит из панели управления.

Затраты на проекты


Первый вопрос, который возникает на подступах к управлению затратами, — это сколько мы сейчас тратим на облачные услуги. Хорошо, если мы сможем получить сумму. Лучше — если можем получить ее с агрегацией, например, по проектам.

На примере Selectel на этот вопрос помогает ответить раздел в панели управления Потребление платформы. Здесь есть информация о текущей стоимости за час, день или месяц.

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

Потребление





С одной стороны, получается, что подход больше полезен крупным компаниям и распределенным командам. Им нужно регулярно нужно актуализировать мощности и ресурсы, чтобы они не простаивали и находились в достаточном запасе при увеличении нагрузки. Отдельной строкой отметим полезность FinOps для продактов при планировании новых фичей. Так они могут рассчитать ресурсы и спланировать реалистичные сроки запуска.

С другой стороны, элементы FinOps актуальны для всех, кто стремится получать точные данные по своим проектам.

Оплата




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

Для отслеживания потребления в своей системе мониторинга можно использовать публичное API, описанное в документации, в блоке Get statistics.

Как альтернатива системе мониторинга, можно использовать Python-скрипты для анализа данных.

Вот пример скрипта, который считает отклонение в потреблении между днями и выводит дельту в процентах в разрезе проекта.

#разница в процентах потребления
import json
import requests
from datetime import datetime, timedelta


# параметры запроса
url = "https://api.selectel.ru/v1/cloud_billing/statistic/consumption"
params = {
   "provider_keys": ["vpc", "mks", "dbaas", "craas", "serverless"],
   "start": "2023-05-26T00:00:00",
   "end": "2023-05-29T23:59:59",
   "locale": "ru",
   "group_type": "metric",
   "period_group_type": "day"
}
headers = {
   "X-Token": "ваш ключ"
}


# отправка GET-запроса
response = requests.get(url, params=params, headers=headers)


# проверка статуса ответа
if response.status_code != 200:
   print(f"Ошибка: {response.status_code}")
   exit()


# загрузка JSON-ответа
json_data = response.json()['data']


# создание словаря для хранения ключей и значений
value_dict = {}


# обход элементов в списке данных
for item in json_data:
   # создание ключа из id и provider_key
   key = f"{item['metric']['id']}:{item['provider_key']}:{item['metric']['name']}"
   # преобразование даты в объект datetime
   date = datetime.strptime(item['period'], '%Y-%m-%dT%H:%M:%S')
   # добавление значения в словарь
   if key in value_dict:
       value_dict[key][date] = item['value']
   else:
       value_dict[key] = {date: item['value']}


# вычисление разницы в процентах для каждого ключа и вывод результата
for key, values in value_dict.items():
   # сортировка по дате
   dates = sorted(values.keys())
   # вычисление разницы в процентах для каждого дня
   for i in range(1, len(dates)):
       prev_value = values[dates[i - 1]]
       current_value = values[dates[i]]
       if prev_value == 0:
           delta_percent = 0
       else:
           delta_percent = (current_value - prev_value) / prev_value * 100
       date_str = dates[i].strftime('%Y-%m-%d')
       print(f"Ключ: {key}, дата: {date_str}, разница в процентах: {delta_percent:.2f}%")


Пример вывода


Ключ: 79c969b1-ec35-43aa-a27f-3a932816c31b:vpc:test_56, дата: 2023-05-23, разница в процентах: 36.75%
Ключ: 79c969b1-ec35-43aa-a27f-3a932816c31b:vpc:test_56, дата: 2023-05-24, разница в процентах: 426.01%
Ключ: 79c969b1-ec35-43aa-a27f-3a932816c31b:vpc:test_56, дата: 2023-05-25, разница в процентах: 188.50%
Ключ: 79c969b1-ec35-43aa-a27f-3a932816c31b:vpc:test_56, дата: 2023-05-26, разница в процентах: 1.07%
Ключ: 79c969b1-ec35-43aa-a27f-3a932816c31b:vpc:test_56, дата: 2023-05-27, разница в процентах: -0.08%
Ключ: 79c969b1-ec35-43aa-a27f-3a932816c31b:vpc:test_56, дата: 2023-05-28, разница в процентах: 0.00%
Ключ: 79c969b1-ec35-43aa-a27f-3a932816c31b:vpc:test_56, дата: 2023-05-29, разница в процентах: -0.09%
Ключ: 9ce7f9b2-b506-4a4c-8154-c9fba8e1758e:vpc:test12.n, дата: 2023-05-23, разница в процентах: 0.12%
Ключ: 9ce7f9b2-b506-4a4c-8154-c9fba8e1758e:vpc:test12.n, дата: 2023-05-24, разница в процентах: -0.35%
Ключ: 9ce7f9b2-b506-4a4c-8154-c9fba8e1758e:vpc:test12.n, дата: 2023-05-25, разница в процентах: 0.38%
Ключ: 9ce7f9b2-b506-4a4c-8154-c9fba8e1758e:vpc:test12.n, дата: 2023-05-26, разница в процентах: -0.04%
Ключ: 9ce7f9b2-b506-4a4c-8154-c9fba8e1758e:vpc:test12.n, дата: 2023-05-27, разница в процентах: 0.00%
Ключ: 9ce7f9b2-b506-4a4c-8154-c9fba8e1758e:vpc:test12.n, дата: 2023-05-28, разница в процентах: 0.00%
Ключ: 9ce7f9b2-b506-4a4c-8154-c9fba8e1758e:vpc:test12.n, дата: 2023-05-29, разница в процентах: 0.14%


Таким образом, FinOps позволяет мониторить и реагировать на следующие ситуации:

  • возникновение «неотслеживаемых» расходов,
  • простой ресурсов,
  • полная загрузка,
  • превышение заранее определенных порогов бюджетов по проекту,
  • изменение тенденций потребления.

Как насчет ЭДО


ЭДО как и FInOps позволяет упростить жизнь и сократить затраты, хотя бы временные на работу с документами.

  • Отправление бухгалтерских документов по умолчанию на почту и в ЭДО. Читайте подробнее о том, как это работает в статье.
  • При регистрации отправляем приглашение для обмена документами в ЭДО юридическим лицам, если они зарегистрированы в системе ЭДО.
  • Автовыставление счетов.
  • Можно подключить дополнительных пользователей для получения документов, уведомлений и счетов.

Заключение


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

Комментарии (8)


  1. ivankudryavtsev
    01.11.2023 14:59
    +2

    Дайте мне контракт с фиксированной суммой, сказала Марья Ивановна из бухгалтерии! Вот и закончился весь финопс :)


    1. edlost Автор
      01.11.2023 14:59

      Такое тоже можно, госы любят) Но это не отменяет финопс, тут с помощью финопса можно управлять сроком или объемом ресурсов, например потратить все в один день или растянуть на несколько месяцев)


      1. ivankudryavtsev
        01.11.2023 14:59

        Так в этом и суть контракта с фиксированной ценой - чтобы на срок контракта все хватило, 1000 в месяц, 12 месяцев. В общем, я понимаю, что есть разное.

        Но я предположу, что в 80-90% случаев никакого FinOps не бывает (что, конечно, может быть и жаль) - просто взяли инфраструктуру и добирают или отказываются по мере необходимости с периодичностью в 1-2-6 месяцев.


  1. ozzyBLR
    01.11.2023 14:59
    +2

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


  1. AlexandreFrolov
    01.11.2023 14:59
    +2

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

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

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

    Еще нужно посчитать, во что обойдется трафик бекапов, если ежедневно делать его на серверы другой компании. У меня получается очень дорого. А из соображений безопасности едва ли стоит хранить бекапы у той же компании, где находится облако.

    Пожалуйста, поправьте, если я в чем ошибаюсь.


  1. Dolios
    01.11.2023 14:59
    +1

    "Press F" в современной инетернет-культуре является выражением соболезнований покойному. Вы точно это имели в виду?


  1. HuckF1nn
    01.11.2023 14:59

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


  1. alexdora
    01.11.2023 14:59
    +1

    Я правильно прочитал статью: Вместо того чтобы потратить деньги на железо для расширения емкости, надо заставить менеджеров по финансам и разработки (если таких нет, нанять) заниматься FinOps чтобы распределять деньги на ресурсы которые стоят в 10-ки раз больше.

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

    Берем пример счета в статье. 3 месяца и можно купить сервер в 4 раза превышающий емкость по RAM/CPU и памяти.
    Итого: Мы не смотрим на графики нагрузки, не считаем дельту, потому что ресурсов в 4 раза больше и их за глаза. Бухгалтерия пищит от счастья. Или я все равно не то что-то говорю?