На встрече по бюджету показывают рост облачного счёта. Финансы просят сократить расходы, разработчики объясняют их увеличением нагрузки. Обе стороны могут быть правы. Пока компания не связывает деньги с конкретной работой продукта, разговор заканчивается либо произвольным процентом сокращения, либо обещанием «посмотреть оптимизацию».
FinOps организует эту связь: расходы, использование ресурсов и результат становятся общей темой инженерной, продуктовой и финансовой команд. Здесь разберём облачную инфраструктуру. Практика шире самого облака, но начать полезнее с понятного участка расходов, чем сразу пытаться описать всю экономику технологий.
Счёт вырос. А работа подорожала?
Условный пример: сервис проверки документов потратил за месяц 120 тысяч рублей и завершил 20 тысяч проверок. В следующем месяце расходы составили 150 тысяч, завершённых проверок — 30 тысяч. При одинаковом составе затрат средняя стоимость результата снизилась с шести до пяти рублей, хотя общий счёт вырос. Это арифметика примера, не отраслевой ориентир.
Теперь нужно проверить знаменатель. Не считаем ли мы каждую повторную попытку отдельной проверкой? Сохранилось ли качество? Не стала ли работа проще? Если система трижды обрабатывает один документ, цена вызова может выглядеть приятно, а цена готового результата — совсем иначе.
Также важно отделять среднюю стоимость от цены следующей операции. В среднем уже распределены резерв мощности и общие расходы. Дополнительная проверка может использовать свободный ресурс почти без прироста счёта либо потребовать перехода на другой размер базы. По одной средней величине нельзя обещать себестоимость любого будущего объёма.
Выбор технической и бизнес-единицы измерения описан в материале FinOps Foundation об удельной экономике. Для нашего сервиса полезно видеть обе: затраты на обработку и стоимость завершённой проверки с согласованным качеством.
Чей расход, если база общая
Теги и разделение счетов помогают найти владельца выделенного ресурса. С общей базой, сетью или диагностикой сложнее: счёт приходит один, пользуются несколько продуктов. Делить поровну просто, но продукт с тяжёлыми отчётами может создавать несопоставимо больше работы.
Нужна понятная договорённость: какие расходы относятся напрямую, какие распределяются по наблюдаемому использованию, а какие остаются общими. Неизвестную часть лучше показать отдельно, чем незаметно приписать ближайшей команде. Варианты распределения рассматривает FinOps Foundation.
Распределённый расход не всегда управляем получателем. Команда не сможет уменьшить стоимость общей базы, если не имеет права менять ни запросы соседей, ни размер сервера. У общей части тоже должен быть владелец решения. Иначе внутренний счёт только создаст новые взаимные претензии.
У сравнения должна быть одна основа
До выводов согласуйте период, валюту и состав стоимости: хранение, передача данных, поддержка, тестовые среды, резервирование. Отдельно покажите разовые кредиты и изменения цен. Если в прошлом месяце действовал рекламный кредит, его окончание не доказывает ухудшение архитектуры.
Предоплату и долгосрочные обязательства тоже нужно отражать последовательно. Сумма платежа в этом месяце и стоимость потреблённой услуги за месяц отвечают на разные вопросы. Финансам нужны данные для сверки счёта; инженерам — сопоставимая оценка изменения. Один график не обязан заменять оба отчёта.
После оптимизации сравнивайте похожую работу. Уменьшение расходов из-за падения числа клиентов не является инженерной экономией. Отказ от резервирования тоже следует назвать изменением уровня защиты, а не просто победой над лишними серверами.
Низкая средняя загрузка также не доказывает бесполезность ресурса. Он может держать резерв на отказ соседа, обслуживать короткий пик или обеспечивать необходимый объём памяти. Перед уменьшением мощности полезно проверить именно эти условия, время ответа и ошибки. Если после сокращения команда вынуждена вручную ограничивать клиентов, часть расходов просто переехала из облачного счёта в работу поддержки и потерянные возможности продукта.
Скидка может пережить ресурс, ради которого её купили
Провайдер может предложить меньшую ставку в обмен на обязательство оплачивать определённое использование. Это другой рычаг, чем сокращение самого использования. Если сначала купить долгосрочное обязательство, а затем убрать соответствующую нагрузку, часть платежей может остаться.
Поэтому закупки и архитектурные изменения нужно обсуждать вместе. Проверяют, к какой работе применима скидка, сколько обязательства используется и какую долю подходящей нагрузки оно покрывает. Эти показатели различаются. Связь скидок с изменением ресурсов и риск двойного подсчёта выгоды разобраны в руководстве по оптимизации ставок.
Предлагаемую экономию стоит разделить на снижение будущего счёта, высвобождение уже оплаченной мощности и предотвращение будущего роста. Все три результата полезны, но это не одни и те же деньги. Складывать их без проверки нельзя.
Сигнал о расходах должен приводить к безопасному действию
Цикл повторной обработки способен увеличить счёт задолго до окончания месяца. Команде нужен сигнал, который можно сопоставить с выпуском, объёмом работы и состоянием очереди. Уведомление о бюджете само по себе не означает, что ресурсы остановятся или расход прекратится.
Автоматическое выключение тоже не универсальное решение. Остановить забытый тестовый стенд и прервать обработку принятых документов — разные действия. Нужно заранее определить владельца, предел воздействия и судьбу незавершённой работы. Данные биллинга могут поступать с задержкой; для быстрой реакции пригодятся и технические показатели. Такой процесс описывает Anomaly Management.
Что должно измениться на следующей встрече
Вместо общей задачи «снизить cloud bill» выберите конкретную: убрать повторное чтение большого файла, изменить хранение старых документов или скорректировать резерв мощности. Запишите владельца, ожидаемый эффект, стоимость работы и ограничения по качеству. После изменения сравните фактический результат с той же исходной моделью.
Для небольшого продукта достаточно такого разбора нескольких крупных статей. Отдельная платформа распределения затрат понадобится не автоматически, а когда ручной процесс перестанет отвечать на нужные вопросы. Полезный итог встречи — принятое решение с проверяемым эффектом, включая решение сохранить дорогую защиту, если компания понимает, зачем она нужна.