|
Professor Seleznov
|
«Кто виноват и что делать?» — эти два вопроса, которые классики русской литературы адресовали обществу, сегодня как никогда актуальны для ИТ-директоров и финансовых руководителей. Готовы к ответу? «Виноват» не конкретный человек, а не оптимально работающая инфраструктура. Что же делать? — внедрять FinOps.
FinOps — это не технология, а организационная методика. Важная часть инструментария FinOps — правильно построенная информационная система, которая собирает, хранит и дает анализировать данные о расходах на ИТ-инфраструктуру и нагрузке. В этой статье мы разберем архитектурное ядро такой системы.
Мультитенантность: одна система — много клиентов
Если вы строите FinOps-систему для своего бизнеса, то она должна включать данные о всех департаментах и дочерних компаниях. Если вы продаете FinOps как услугу — у вас десятки разных клиентов. Как сделать систему, которая будет работать для всех, оставаясь единой?
Ответ — мультитенантность, подход из мира облачных технологий, когда одна инсталляция обслуживает множество независимых клиентов (тенантов). И каждый из них ничего не знает о существовании прочих. В нашей модели это выражается в иерархии сущностей:
Реселлер— поставщик FinOps-услуг. Это может быть внутренний ИТ-департамент крупной корпорации или внешняя компания.
Клиент— тот, кто потребляет FinOps-услугу. У каждого клиента в рамках одного реселлера свой «личный кабинет» (клиентская панель управления) и своя инфраструктура, подключенная к этому «кабинету».
Объект— любой элемент инфраструктуры, состоящий из произвольного набора ресурсов, необходимых для создания или существования этого объекта (инфраструктурные ресурсы, вычислительные ресурсы, облачные ресурсы и т.п. - это все понятия-синонимы). Объекты могут быть связаны между собой (например, объект «диск» связан (входит в состав) с объектом «сервер», или несколько объектов «вычислительный узел» связаны (входят в состав) с объектом «вычислительный кластер» и т.п.).
Подключение— инфраструктура клиента, имеющая некоторый технологический тип (Яндекс.Облако, AWS, VMware vSphere, Proxmox…) или не имеющая такого типа. От уточнения типа подключения могут зависеть некоторые алгоритмы сбора и обработки данных, поэтому это важный параметр.
Такая «мультитенантная» архитектура позволяет изолировать данные клиентов (потребителей FinOps-услуг), настраивать разные правила и стилистику пользовательского интерфейса для каждого реселлера (поставщика FinOps-услуг) и строить отчеты в любом разрезе — от всего холдинга до отдельного виртуального дата-центра.
Три кита: событие, объект, ресурс
Данные о структуре, расходах, полученных (установленных) и оплаченных мощностях приходят из биллинговых систем.
Данные о нагрузке (фактическом использовании купленного) приходят из мониторинговых систем. Задача FinOps-системы — все это собрать, обогатить и связать. Для этого рассмотрим еще 3 категории сущностей:
Событие — фиксация того, что произошло с инфраструктурой (объектами) в разрезе финансовых расходов и использования оплаченного. Нас интересуют два типа событий:
- Биллинговое событие: «за период X мы получили N единиц ресурса Y объекта Z и оплатили K единиц по такой-то цене, на такую-то сумму (иногда получение может быть явно не связано с оплатой)».
- Событие нагрузки (метрика): «в момент X ресурс Y объекта Z использовался на A% или на B единиц».
Объект (в терминах ITSM/ITIL - конфигурационная единица/configuration item) — то, из чего состоит наша инфраструктура, за что мы несём расходы и за чем мы наблюдаем: виртуальная машина, сервер, база данных. Напомним, что объекты могут быть связанными друг с другом: кластер →хост → диск.
Ресурс — то, что необходимо для создания или функционирования объекта, использование чего измеряется в каких-то единицах (CPU, RAM, диск) и за что мы обычно платим. Объект — это «черный ящик», а ресурсы — его «внутренности».
Модель биллинговых событий: кто и за что платит?
Просто взять счет от облачного провайдера и занести его в базу недостаточно. Для анализа нужно знать, за что именно платишь и к чему это относится. Рассмотрим необходимые атрибуты биллингового события:
| Атрибут |
Что фиксирует |
| Когда |
Временная метка (период списания или начисления платы) |
| Что |
Какой ресурс получен или оплачен |
| Сколько было поставлено |
Количество единиц ресурса, которые были выданы или установлены в объект (установленная мощность) |
| Сколько к оплате |
Количество единиц ресурса было использовано в периоде из установленного объема, цена за единицу, фактическая стоимость (может отличаться от расчетной из-за скидок) |
| Для чего |
Какой объект использует этот ресурс |
| Где |
Место размещения объекта (возможна древовидная иерархия мест размещения) |
Существует международная модель сбора биллинговой информации — Focus (FinOps Open Cost & Usage Specification). Наши требования в целом соответствуют ей, но есть важные различия: в модели Focus иерархия объектов и мест размещения более плоская, чем требуется для сложных инфраструктур с глубокой вложенностью (например, VMware vSphere с семью уровнями).
Модель данных о нагрузке: проценты или ядра?
Данные о нагрузке — это ответ на вопрос «насколько эффективно мы используем купленное?». Мониторинговые системы могут выдавать данные в натуральных единицах (например, «3 ядра CPU загружены») или же в процентах («30% от установленной на объект мощности используется»). При этом в модели данных необходимо предусмотреть два отдельных поля: value_units и value_percent, чтобы избежать ошибок при анализе.
Контроль качества данных: от хаоса к порядку
Управление качеством данных (Data Quality) — это одна из основ аналитической системы, где качество данных оценивается по четырем критериям:
1. Полнота: Все ли ожидаемые файлы загружены? Все ли обязательные поля заполнены?
3. Достоверность: Соответствуют ли данные форматам (валидность) и справочникам (соответствие)? Например, пришел ли тип объекта из нашего справочника типов?
4. Своевременность: Загружены ли данные к установленному сроку?
5. Непротиворечивость: Не нарушена ли логика? Например, дата списания денег не может быть раньше даты создания объекта (если только это не предусмотрено бизнес-правилами).
При обнаружении нарушении возможны два подхода:
- Жесткий: ошибочная запись аварийно завершает весь ETL-процесс.
- Мягкий: ошибка фиксируется в специальном журнале событий контроля качества данных, ETL-процесс продолжает свою работу, игнорируя ошибочные данные.
Поэтому так важен журнал нарушений, в котором запись должна содержать все ключевые данные: дата и время, код процесса, код правила, что было не так, фактическое значение, признак результата (жесткий/мягкий).
Таблицы фактов и измерения
Основа аналитической системы, построенной на базе пространственного моделирования, — таблица фактов. Каждое событие (биллинговое или нагрузочное) — одна строка в этой таблице. Таблица фактов фиксирует как числа (количество, цена, стоимость, значение нагрузки), так и контекст: ссылки на таблицы-справочники (dim_date_id, dim_resource_id, dim_object_id, dim_location_id).
Типы таблиц фактов:
1. Транзакционные — фиксируют завершенное событие (списание денег). Это основной тип.
2. Периодические моментальные снимки (счетчики) — фиксируют состояние на момент времени (показания нагрузки).
3. Накопительные моментальные снимки — фиксируют прохождение процесса по шагам (жизненный цикл заявки). Это единственный тип, где допускается обновление существующей записи.
Схема «Звезда» (Star Schema): в центре — таблица фактов, вокруг — таблицы измерений, связанные с ней через идентификаторы. Это оптимальный компромисс между скоростью работы (минимум JOIN-ов) и гибкостью. Важное отличие от обработки транзакций в реальном времени, здесь измерения — это не те же самые сущности, что в OLTP. Это просто списки уникальных значений контекста. Их назначение — фильтровать, группировать и давать названия.
Схема «Снежинка» (Snowflake): когда таблицы измерений начинают ссылаться на другие таблицы. Рекомендация: избегать этого, если есть возможность. Это усложняет работу BI-инструментов, хотя на небольших объемах может быть приемлемо.
Виды измерений:
Согласованные измерения — один и тот же справочник используется в разных таблицах фактов и его назначение, смысл и содержание согласован во всех бизнес-подразделениях. Это позволяет строить «галактику» — связывать данные из разных источников (например, расходы и нагрузку) по общим осям.
Измерение «Свалка» (Junk Dimension) — сборник комбинаций низкокардинальных атрибутов (статусы, флаги). Вместо десятка столбцов-флагов в таблице фактов вы создаете один справочник комбинаций. Это уменьшает размер таблицы и ускоряет работу.
Вырожденное измерение — атрибут, который не имеет собственной таблицы справочника (номер счета-фактуры, ИНН, серийный номер). Он хранится прямо в таблице фактов как строка. Такое измерение не нужно нормализовывать, потому что каждое значение уникально.
Измерение «Дата-время» — самый мощный и настоятельно рекомендуемый теорией справочник. В нем хранятся не просто даты, а все возможные атрибуты:
- день недели, номер недели в году;
- признак выходного/праздничного дня;
- квартал, месяц, декада;
- сезон (зима, весна, лето, осень);
- часть дня (утро, день, вечер, ночь);
- час, минута, секунда.
Наличие такого справочника позволяет строить сложную аналитику без дополнительных вычислений на лету — например, сравнить расходы в выходные и будни или найти корреляцию с временем суток.
Заключение: ваша первая «звезда» на пути к FinOps
Построение системы учета расходов начинается не с подключения API облачного провайдера, а с проектирования модели данных. Без правильного фундамента любая надстройка будет шаткой.
1. Мультитенантность — это база. Реселлеры, клиенты, подключения — эта иерархия позволяет масштабировать систему на любое количество потребителей.
2. Разделяйте биллинг и нагрузку. Это два разных типа событий с разными источниками, разными атрибутами и разными методами анализа.
3. Стройте «звезду». Таблица фактов с числами и набор таблиц измерений с контекстом — это архитектурный паттерн, проверенный десятилетиями.
Описанная архитектура легла в основу Клаудмастер. Мы спроектировали платформу так, чтобы она выдерживала иерархию любой сложности: от небольшого стартапа до гигантских холдингов с сотнями дочерних компаний.
Узнайте больше о том, как Клаудмастер выстраивает FinOps-процессы, на примере наших кейсов.-Источник
|
