AndrewLucky
New member
Привет, форумчане. Хочу поделиться историей, которая за полтора года срезала облачный бюджет моей команды почти вдвое, и при этом никто не выгорел, не уволился и не начал тихо саботировать любого, кто произносит слово «экономия». Начиналось всё классически: в конце квартала прилетел счёт, от которого дёрнулся глаз. Продукт мы гнали быстро, стендов развелось больше, чем разработчиков, а тестовые окружения бодро крутились круглосуточно, хотя трогали их часов шесть в сутки. Дальше расскажу, что реально сработало, а что оказалось красивой теорией из чужих презентаций.
Способ первый и самый недооценённый: сначала измерять, потом резать. Пока я не понимал, какое подразделение и какой сервис съедают деньги, любые сокращения превращались в гадание на кофейной гуще. Мы ввели единые метки для команд, проектов и окружений, завели еженедельный отчёт с разбивкой по сервисам и выяснили, что примерно четверть счёта — это забытые экспериментальные кластеры, оставшиеся после трёх давно закрытых инициатив. Их никто не удалял, потому что никто не считал их своими. Как только у каждого сервиса появился владелец и понятная цена, разговоры из плоскости «облако дорогое» перешли в «вот мой сервис, вот его стоимость, что делаем».
Способ второй и третий идут в паре: расписания для нетестовой среды и честный подбор размера инстансов. Мы просто выключили разработческие и стейджинговые окружения на ночь и на выходные, оставив на связи только тех, кто дежурит, и это дало мгновенный эффект без единой строки правок в коде. Параллельно прошлись по продакшену и обнаружили, что добрый десяток машин загружен на десять процентов, а ещё несколько — на девяносто пять с постоянными алертами. Апскейл перегруженных и даунскейл простаивающих убрал и тормоза, и лишние траты. Команда вздохнула с облегчением: никто не любит работать на железе, которое задыхается.
Способ четвёртый — навести порядок в хранилищах. Объектное хранилище и диски умеют незаметно превращаться в свалку: старые снапшоты, логи годичной давности, артефакты сборок, бэкапы, которые никто никогда не восстанавливал. Мы настроили политики жизненного цикла, чтобы холодные данные автоматически уезжали в более дешёвые классы хранения, а откровенный мусор удалялся по сроку. Отдельным открытием стали осиротевшие диски, оставшиеся после удалённых инстансов, — они спокойно жили и копили счёт месяцами.
Способ пятый — скидки за предсказуемость, но с умом. Когда профиль нагрузки стал понятен, мы оформили обязательства по самым стабильным сервисам и перевели часть CI-задач и пакетной обработки на прерываемые инстансы, где потеря машины не критична. Главное правило, которое я вынес: не покупай обязательства на год вперёд ради красивой цифры, если не уверен в архитектуре хотя бы на пару месяцев. Мы один раз обожглись, закоммитившись под сервис, который потом переписали, и с тех пор берём обязательства маленькими долями и пересматриваем их каждый квартал.
Способ шестой, и он самый важный, — культура и прозрачность. Экономия не должна быть чьей-то личной инициативой, иначе она умрёт через месяц. Мы поставили алерты на аномальный рост расходов, завели короткий еженедельный пятнадцатиминутный обзор бюджета и добавили стоимость в дашборд, на который команда и так смотрит. Инженеры начали сами предлагать правки, потому что увидели цифры и поняли, что за ними стоит. Никаких приказов сверху, никаких тайных урезаний — только видимые данные и общая ответственность.
Мой главный вывод звучит скучно, но он честный: FinOps — это не разовая кампания по сокращению, а привычка, которая приносит плоды именно на длинной дистанции. Лучший способ не тормозить команду — не забирать у неё ресурсы молча, а показать цену и дать инструменты влиять на неё. У нас получилось сохранить скорость разработки, убрать лишние траты и даже улучшить стабильность продакшена, потому что мы наконец узнали, где у нас узкие места. Если коротко: измеряйте, договаривайтесь, автоматизируйте и не превращайте экономию в наказание.
А теперь вопрос к вам, друзья: какой самый неожиданный источник лишних облачных трат вы находили в своём проекте и что помогло его закрыть? Уверен, у каждого есть своя история про забытый кластер или золотую базу данных, которой давно никто не пользуется, — делитесь, вместе мы насобираем отличный чек-лист!
Способ первый и самый недооценённый: сначала измерять, потом резать. Пока я не понимал, какое подразделение и какой сервис съедают деньги, любые сокращения превращались в гадание на кофейной гуще. Мы ввели единые метки для команд, проектов и окружений, завели еженедельный отчёт с разбивкой по сервисам и выяснили, что примерно четверть счёта — это забытые экспериментальные кластеры, оставшиеся после трёх давно закрытых инициатив. Их никто не удалял, потому что никто не считал их своими. Как только у каждого сервиса появился владелец и понятная цена, разговоры из плоскости «облако дорогое» перешли в «вот мой сервис, вот его стоимость, что делаем».
Способ второй и третий идут в паре: расписания для нетестовой среды и честный подбор размера инстансов. Мы просто выключили разработческие и стейджинговые окружения на ночь и на выходные, оставив на связи только тех, кто дежурит, и это дало мгновенный эффект без единой строки правок в коде. Параллельно прошлись по продакшену и обнаружили, что добрый десяток машин загружен на десять процентов, а ещё несколько — на девяносто пять с постоянными алертами. Апскейл перегруженных и даунскейл простаивающих убрал и тормоза, и лишние траты. Команда вздохнула с облегчением: никто не любит работать на железе, которое задыхается.
Способ четвёртый — навести порядок в хранилищах. Объектное хранилище и диски умеют незаметно превращаться в свалку: старые снапшоты, логи годичной давности, артефакты сборок, бэкапы, которые никто никогда не восстанавливал. Мы настроили политики жизненного цикла, чтобы холодные данные автоматически уезжали в более дешёвые классы хранения, а откровенный мусор удалялся по сроку. Отдельным открытием стали осиротевшие диски, оставшиеся после удалённых инстансов, — они спокойно жили и копили счёт месяцами.
Способ пятый — скидки за предсказуемость, но с умом. Когда профиль нагрузки стал понятен, мы оформили обязательства по самым стабильным сервисам и перевели часть CI-задач и пакетной обработки на прерываемые инстансы, где потеря машины не критична. Главное правило, которое я вынес: не покупай обязательства на год вперёд ради красивой цифры, если не уверен в архитектуре хотя бы на пару месяцев. Мы один раз обожглись, закоммитившись под сервис, который потом переписали, и с тех пор берём обязательства маленькими долями и пересматриваем их каждый квартал.
Способ шестой, и он самый важный, — культура и прозрачность. Экономия не должна быть чьей-то личной инициативой, иначе она умрёт через месяц. Мы поставили алерты на аномальный рост расходов, завели короткий еженедельный пятнадцатиминутный обзор бюджета и добавили стоимость в дашборд, на который команда и так смотрит. Инженеры начали сами предлагать правки, потому что увидели цифры и поняли, что за ними стоит. Никаких приказов сверху, никаких тайных урезаний — только видимые данные и общая ответственность.
Мой главный вывод звучит скучно, но он честный: FinOps — это не разовая кампания по сокращению, а привычка, которая приносит плоды именно на длинной дистанции. Лучший способ не тормозить команду — не забирать у неё ресурсы молча, а показать цену и дать инструменты влиять на неё. У нас получилось сохранить скорость разработки, убрать лишние траты и даже улучшить стабильность продакшена, потому что мы наконец узнали, где у нас узкие места. Если коротко: измеряйте, договаривайтесь, автоматизируйте и не превращайте экономию в наказание.
А теперь вопрос к вам, друзья: какой самый неожиданный источник лишних облачных трат вы находили в своём проекте и что помогло его закрыть? Уверен, у каждого есть своя история про забытый кластер или золотую базу данных, которой давно никто не пользуется, — делитесь, вместе мы насобираем отличный чек-лист!