Вопросы на собеседовании: FinOps-инженер

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

• Инженеры получают данные о затратах, на которые можно повлиять, например рост стоимости сервиса с $800 до $1 100 в день.
• Финансы получают объяснимый прогноз, а не неожиданный счёт после закрытия месяца.
• Продукт может сопоставлять затраты с результатом, например снизить стоимость одного оплаченного заказа с $0,12 до $0,09.

Этот цикл делает затраты прозрачными, улучшает их и закрепляет улучшения в регулярной работе.

• Inform распределяет счёт на $30 000 между командами, сервисами и продуктами, чтобы владельцы видели свою долю.
• Optimize находит действие, например удалить пять простаивающих VM стоимостью $70 в месяц каждая.
• Operate назначает ответственного, измеряет результат и повторяет проверку при изменении потребления или цен.

Потребление показывает объём использованного ресурса, а затраты показывают плату за этот объём с учётом цены и модели скидок.

• Работа VM в течение 100 часов является потреблением; при цене $0,10 в час валовые затраты составят $10.
• После скидки затраты могут снизиться при тех же 100 часах, поэтому нужно проверять обе величины.
• Скачок затрат может быть вызван ростом потребления на 30 процентов, более дорогим регионом или окончанием скидки.

Эти представления затрат отвечают на разные вопросы о начислениях за потребление, распределении обязательств и договорных ценах.

• Unblended cost провайдера сохраняет unblended-ставку каждой строки потребления и даёт близкое к прайс-листу представление без претензии на универсальную основу затрат.
• Amortized или effective cost распределяет авансовые и регулярные платежи и выгоды обязательств по покрытому потреблению и времени.
• Net views зависят от схемы: AWS NetUnblended и NetAmortized применяют скидки платёжной организации, а FOCUS BilledCost и EffectiveCost отражают суммы счёта и стоимость с учётом обязательств; строки кредитов остаются отдельными от скидок.

Надёжное закрытие объединяет признание начисленных расходов финансами, контекст потребления от инженеров и бизнес-объяснение от продукта.

• Финансы признают начисленные расходы до получения финального счёта, например $9 800 по суточным данным, пока ожидаются запоздалые строки.
• Инженеры объясняют изменения, например новый кластер добавил 2 000 вычислительных часов за календарный расчётный период.
• Продукт подтверждает, что дополнительные $600 дали результат, например 15 000 дополнительных клиентских транзакций.

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

• Измерения провайдера включают аккаунт или подписку, сервис, регион и ID ресурса.
• Бизнес-измерения включают продукт, команду, центр затрат, клиента и окружение.
• Счёт на $12 000 можно сначала разделить по аккаунтам, затем по тегу продукта, а оставшиеся $900 пометить как нераспределённые.

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

• Аккаунты AWS, подписки Azure и проекты GCP группируют ресурсы и начисления внутри именованного контейнера.
• Раздельные контейнеры production и development позволяют распределить затраты $7 000 и $2 000 без проверки каждого ресурса.
• Это крупные границы, поэтому в общем аккаунте всё равно нужны теги или данные по ресурсам для разделения команд.

Теги или labels добавляют к ресурсам бизнес-контекст, чтобы начисления можно было группировать и назначать владельцам.

• Ресурс с тегами product=checkout и environment=prod можно показать и в отчёте по продуктам, и в отчёте по окружениям.
• Ключи и значения нужно нормализовать, потому что Team=Payments и team=payments могут образовать разные группы.
• Теги не должны содержать чувствительные данные; лучше использовать стабильные идентификаторы, а не отображаемое имя сотрудника.

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

• Лучше требовать небольшой набор cost_center, owner, product и environment, чем 20 необязательных ключей.
• Допустимые значения проверяют в инфраструктурном коде или policy-инструментах, отклоняя env=production, если стандарт требует env=prod.
• Compliance нужно считать еженедельно, например из $1 000 затрат подходящих ресурсов корректно размечены $920, значит показатель равен 92 процентам.

Затраты без возможности тегирования нужно явно выделять и распределять по документированному резервному правилу.

• Некоторые сборы за поддержку, налоги, начисления marketplace и сервисы уровня провайдера не имеют ресурсного тега.
• Их нужно помещать в именованную категорию вроде Shared Platform, а не молча относить к unknown.
• Сбор за поддержку $1 000 можно распределить по доле подходящих затрат команд или оставить централизованным, если такова согласованная политика.

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

• Общую стоимость control plane Kubernetes в $3 000 можно разделить по запрошенным CPU, если requests отражают зарезервированную ёмкость.
• Платформу логирования можно распределить по принятым GB: если команда A отправила 60 GB, а команда B 40 GB, доли составят 60/40.
• Драйвер нужно опубликовать, а при слабых измерениях сохранить централизованную долю вместо сомнительного распределения.

Showback показывает отнесённые на команду затраты, а chargeback отражает их в её бюджете или бухгалтерском учёте.

• Showback-дашборд может показать Payments потребление на $8 400, не меняя бюджет команды.
• Chargeback проводит эти $8 400 по центру затрат Payments в бухгалтерской книге, поэтому ошибки распределения влияют на финансовый результат.
• Команды часто начинают с showback, чтобы повысить качество данных до внедрения контролей chargeback.

Эти измерения отвечают на вопросы, кто платит, кто действует и где работает нагрузка.

• cost_center=CC120 связывает начисление $4 000 с бюджетной структурой финансов.
• owner=payments-platform назначает инженерную команду ответственной за проверку начисления.
• environment=prod отделяет затраты обслуживающей клиентов системы от dev или test, которые можно выключать по расписанию.

Allocation coverage показывает долю подходящих затрат, назначенную принятому владельцу или бизнес-измерению.

• Если из $100 000 подходящих затрат у $92 000 есть корректный владелец, покрытие равно 92 процентам.
• Явно нераспределяемые позиции исключают только по документированному правилу, а не ради улучшения KPI.
• Нужно отслеживать и покрытие затрат, и compliance ресурсов, потому что одна дорогая база без тега важнее 100 мелких ресурсов.

Иерархия определяет, как начисления, скидки и владение сворачиваются из дочерних аккаунтов в платёжную организацию.

• Управляющий или платёжный аккаунт получает начисления от связанных аккаунтов, подписок или проектов.
• Папки бизнес-юнитов или organizational units позволяют свернуть дочерние аккаунты на $5 000 и $7 000 в итог подразделения $12 000.
• Перенос аккаунта в середине месяца усложняет сравнения, поэтому изменения иерархии требуют дат вступления в силу и истории соответствий.

Для базовой проверки таблицы Athena из legacy AWS CUR нужны поля типа начисления, времени, сервиса, потребления, ресурса и стоимости.

• line_item_line_item_type различает Usage, Tax, Credit, Refund и записи, связанные с обязательствами.
• line_item_usage_start_date, product_product_name и line_item_usage_type показывают, когда и что было потреблено.
• Если для отчёта включены resource IDs, line_item_resource_id связывает начисления поддерживаемых ресурсов с line_item_usage_amount и line_item_unblended_cost.

Я бы агрегировал столбец стоимости по сервису за ограниченный расчётный период и отсортировал результат по убыванию.

• Нужно отфильтровать реальные столбцы партиций таблицы, обычно year и month, а также ограничить line_item_usage_start_date нужными датами потребления.
• В SELECT указать product_product_name и SUM(line_item_unblended_cost), затем выполнить GROUP BY по полю сервиса.
• Результат отсортировать по сумме затрат по убыванию и ограничить десятью строками, проверив, нужны ли в выборке кредиты и налоги.

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

• Фильтр по одному linked account, июню и EC2 позволяет ответить на конкретный вопрос вместо просмотра всего счёта.
• Группировка по типу инстанса, региону или cost allocation tag помогает найти сегмент, вызвавший рост на $2 000.
• При сравнении нужно сохранять одну метрику затрат и детализацию, чтобы не сопоставлять дневной unblended-график с месячным amortized-графиком.

FOCUS 1.4 CostAndUsage нормализует платёжные данные, чтобы затраты и потребление разных провайдеров имели единые названия и значения.

• BillingAccountId, SubAccountId, ServiceName, ChargePeriodStart и ChargePeriodEnd определяют иерархию, сервис и период начисления.
• BilledCost и EffectiveCost дают представления для счёта и стоимости с учётом обязательств, а ConsumedQuantity и ConsumedUnit описывают потребление.
• ChargeCategory классифицирует Usage, Purchase, Credit, Tax и Adjustment; ChargeClass отмечает исправление закрытого периода, а не общий тип начисления.

FinOps-отчёт должен указывать свежесть данных и допускать изменение недавних периодов при поступлении запоздалых записей.

• Если пайплайн загрузил данные по 06:00 UTC, нужно показать эту отметку, а не называть сегодняшний итог $4 200 окончательным.
• Скользящее окно, например последние семь дней, нужно пересчитывать для захвата задержанного потребления и исправленных начислений.
• Итоги месяца фиксируют или версионируют только после согласованной с финансами точки закрытия, а поздние корректировки учитывают отдельно.