Когда счёт за облако вырастает, первый рефлекс — найти виноватого. «Кто заказал эту m5.4xlarge?», «почему у этого сервиса 8 Гб памяти на 200 Мб нагрузки?». Это удобная, но ложная модель. Перерасход в облаке почти никогда не следствие халатности. Он — закономерный итог множества локально-рациональных решений, которые в сумме дают коллективно-иррациональный результат. И пока FinOps пытается лечить это нравоучениями, ничего не меняется.
Defensive overprovisioning: каждый прав по отдельности
Разберём типичный сценарий. Сервис однажды упал по OOM в три часа ночи. Дежурный инженер удвоил memory request — и был прав: никто не хочет быть тем, чьим именем подписан инцидент. В другой раз latency подскочила во время рекламной кампании — подняли CPU «с запасом по всему стейтменту». Тоже разумно: спайк дороже железа.
Каждое из этих решений по отдельности — осторожное и оправданное. Но если просуммировать N таких решений по сотням сервисов за пару лет, получается картина, которую показывает любой аудит: 70–80% выделенной ёмкости простаивает. Никто не действовал глупо. Глупой оказалась система, которая поощряла перестраховку и никак не показывала её цену.
Отсюда вывод, который меняет всю практику: бесполезно винить инженера за overprovisioning. Это не индивидуальная проблема, а системная — и решать её надо системно:
- Видимость на месте принятия решения. Cost-аннотация прямо в PR: «эта правка добавит $40/мес». Не отчёт через два месяца, когда контекст забыт, а цифра в момент, когда инженер всё ещё держит изменение в голове.
- Разумные дефолты на paved path. HPA target 70%, requests по P95/P99, а не по пиковому всплеску. Большинство людей принимают дефолт — так сделайте дефолт правильным.
- VPA в advisory-режиме. «Запрошено 1 Гб, наблюдаемый P99 — 200 Мб». Не автоматическое урезание, а информация: решение остаётся за инженером, но теперь оно осознанное.
- Коллективная ответственность вместо персональной. Механика в духе error budget: команда вышла за квартальный cost-таргет — значит, в следующий спринт закладывается rightsizing. Ответственность на команде, а не на стрелочнике.
Showback раньше chargeback
Из той же логики растёт правило очередности. Chargeback — реальное списание расходов с бюджета команды — выглядит как «честный» механизм. Но запущенный без подготовки, он создаёт billing-friction: люди начинают спорить с цифрами, прятать ресурсы под чужие теги, воспринимать FinOps как налоговую.
Showback — «вот сколько потратила ваша команда», без списания — почти всегда даёт значимое снижение затрат сам по себе. Видимость работает без принуждения: достаточно показать инженеру стоимость его сервиса, и он сам начнёт её оптимизировать, потому что профессиональная гордость сильнее, чем страх перед бюджетом. Сначала показать, потом — если зрелость дойдёт — считать. Chargeback без предшествующего showback — это боль, на которую никто не подписывался.
LLM как новая статья переменных затрат
В 2026 у этой логики появилось свежее измерение. AI-агенты в DevOps — триаж, Slack-боты, агентные workflow — превратили вызовы LLM API в видимую строку облачного счёта. И здесь — та же ловушка локальной рациональности, только наоборот: дорого не потому, что перестраховались, а потому, что выбрали инструмент не по задаче.
Reasoning-модель за $75 за миллион выходных токенов, запущенная на рутинном kubectl get pods, — это «принципал-инженер, которого вызвали поменять лампочку». По отдельности — «ну она же умнее». В сумме — счёт, который никто не закладывал. Дисциплина та же, что и с инфраструктурой:
- Маршрутизация модели по задаче. Частые, повторяющиеся операции — на дешёвые/бесплатные модели; reasoning — только на редкие глубокие разборы.
- Детект несоответствия дорогой модели дешёвой задаче — хороший индикатор скрытых трат.
- Cost-теги на API-ключи. Обращайтесь с ключом как с EC2-инстансом: team / service / cost-center обязательны. Иначе через полгода никто не вспомнит, чей агент сжёг бюджет.
Реальный кейс: четыре мониторинговых крона, гонявшие сотни вызовов в день на дорогой reasoning-модели, после перевода рутины на бесплатный tier дали −80–85% LLM-затрат. Архитектура не менялась — поменялось соответствие инструмента задаче.
Что из этого следует
FinOps — это не «команда по урезанию косты», которой инженеры начинают сопротивляться. Это инженерная дисциплина, которая признаёт: люди в облаке ведут себя рационально в рамках той информации, что у них есть. Хотите другой результат — меняйте не людей, а их информационную среду. Видимость в нужный момент, правильные дефолты, обратная связь на уровне команды. Цена становится частью инженерного решения — а не сюрпризом в конце месяца.