Инженер говорит: всё оптимизировано.
Счёт продолжает расти.
Никто не врёт. Просто никто не смотрел.
Именно поэтому появляются FinOps-инженеры. Иногда это правильно. Иногда — нет.
Коллега прошёл собеседование на позицию FinOps.
Первый час — перечисление инструментов. Как квалификационный экзамен на знание названий, не разговор о деньгах.
Потом началась вторая часть — уже про мышление. Про cost per request, про прогнозирование, про то как делить shared costs между командами. Вот это уже интереснее.
Но показательно другое. Компания большая. Денег тратится много. И им нужен отдельный человек, который будет следить за тем, куда эти деньги уходят.
Ничего плохого. Просто это диагноз.
За 16 лет в DevOps у меня никогда не было коллеги с должностью “FinOps инженер”. Но кто-то же должен был думать про деньги.
Помню созвон, где обсуждали PoC. По плану — запустить RDS за $600/месяц. Для PoC. С минимальной нагрузкой. Надолго.
Я спросил: “Ребят, нам точно нужен вот такой инстанс? Нагрузка маленькая, но работать будет долго — может возьмём подешевле?”
Команда засмеялась. Я засмеялся тоже — чтобы не выбиваться. Никто не ответил. Даже тимлид.
Запустили. Покрутили несколько месяцев, пока не закрыли PoC. Деньги ушли. Вопрос так и остался без ответа.
Или другой момент: однажды посчитал стоимость одного и того же API на AWS и GCP при одинаковой нагрузке. Разница оказалась в 2 раза. Никто в команде этого не знал — потому что никто не считал.
https://blog.yushkov.org/ru/posts/ran-the-same-api-on-aws-and-gcp
Коллега — senior DevOps, FinOps не его специализация — открыл Cost Explorer, посмотрел на топ расходов. Самая большая строка: CloudTrail. Который стоит почти ничего. Оказалось, в части аккаунтов его настроили “с запасом” — логи писались в два региона. Трафик между регионами и генерировал расходы. Исправили по рекомендации самого AWS: один регион, синк в S3. Сэкономили $720k в год.
AWS об этом прямо говорит на своих экзаменах: “сделать можно по-всякому, но экономнее — вот так”. Просто никто не запоминает советы, которые дают бесплатно.
Возвращаясь к FinOps.
Компания, которая искала FinOps специалиста, уже пробовала иначе: попросила кого-то из инженеров “следить за расходами”. Тот находил задачи, добавлял в бэклог. Через несколько месяцев руководитель спросил: “Какие результаты?” Ответ: “Задачи в бэклоге.”
Это не вина инженера. Это структурная проблема:
FinOps без полномочий = список рекомендаций, которые никто не приоритизирует.
Когда FinOps реально нужен?
Математика простая. FinOps инженер — это минимум ~$100k в год. Чтобы окупился — нужно находить и экономить сопоставимо.
Если ваши расходы на инфраструктуру меньше $300-500k в год — отдельная ставка, скорее всего, не окупится. Правильнее: инженеры с cost mindset плюс периодический аудит.
Но дело не только в деньгах. Важнее вопрос: есть ли у этого человека реальные полномочия что-то менять?
Потому что FinOps который “рекомендует” — это дорогой бэклог-менеджер.
FinOps который может сказать “выключаем” — это уже другая история.
Что делать, если вы не на том уровне трат?
Попросить кого-то из своих инженеров “посмотреть” — они знают инфраструктуру лучше любого внешнего специалиста. Но нужны полномочия и время, иначе снова получите бэклог.
Или нанять кого-то на разовый аудит — не отвлекая команду и не создавая постоянную ставку ради периодической задачи. В среднем первый аудит даёт 30% экономии, иногда больше — один из последних кейсов показал 50%. Без смены провайдера и без даунтайма. Для сравнения: Flexera говорит, что в среднем по рынку 42% облачных расходов тратится впустую.
“Работает” ≠ “работает за разумные деньги” ≠ “будет работать дёшево завтра”.
А если честно — вы знаете, сколько тратите на каждый сервис прямо сейчас?
Делаю аудит IT-инфраструктуры. Нахожу не только что сломано, но и что тихо съедает бюджет.
Если в вашем AWS/GCP счёте есть строчки которые сложно объяснить — пишите, разберём.
https://itaudit.yushkov.org/