Полтора года назад наш счёт за облако выглядел как безобидные три сотни долларов в месяц. Нас было четверо, продукт — небольшой SaaS с парой тысяч активных пользователей, и мы искренне считали, что инфраструктура у нас «копеечная». А потом пришёл счёт на две с половиной тысячи, и я впервые за всё время всерьёз сел разбираться, куда утекают деньги. Спойлер: никакого взлома не было. Мы просто годами делали всё «как удобно сейчас» и ни разу не оглядывались.
Первое, что меня поразило, — мы вообще не понимали структуру расходов. В панели облака была одна цифра за месяц, и всё. Кто из сервисов её съедает, почему вчера было дешевле, чем сегодня, и сколько стоит конкретная фича — ответить никто не мог. Поэтому первым делом я не начал ничего выключать, а занялся скучной вещью: разметкой ресурсов. Мы ввели обязательные теги — продукт, окружение, владелец, и настроили разбивку счетов по ним. Уже через неделю картина сложилась, и она была неприятной: почти треть денег уходила на то, о чём мы давно забыли.
Дальше началась археология. Мы нашли пять дисков от удалённых инстансов, которые продолжали жить своей жизнью. Два кластера баз данных в staging, работавших круглосуточно, хотя разработчики заходили туда раз в неделю. Логи, которые хранились бессрочно и весили больше, чем все наши данные вместе взятые. И, конечно, классику — несколько инстансов, которые мы «на всякий случай» подняли до больших размеров ещё на старте и так и не вернули назад. Утилизация процессора на самом дорогом из них болталась в районе семи процентов. Стыдно вспоминать.
Самое обидное, что эти находки не требовали ни рефакторинга, ни переезда, ни героических усилий. Мы включили политики жизненного цикла для логов и бэкапов — старые версии начали уходить в холодное хранилище и удаляться по расписанию. Настроили автоматическое выключение dev- и staging-окружений по ночам и выходным. Уменьшили размеры инстансов там, где метрики это позволяли. Только эти три вещи срезали счёт примерно на сорок процентов, и продукт этого даже не заметил. Ни одной жалобы от пользователей, ни одного инцидента.
Со второй волной экономии пришлось думать чуть больше. Мы честно посмотрели на графики нагрузки и поняли, что у нас есть предсказуемый базовый уровень, который стоит закрывать долгосрочными обязательствами со скидкой, и пики, которые выгоднее отдавать автомасштабированию и спотовым инстансам. Плюс перенесли часть фоновых задач — всякие отчёты, выгрузки, пересчёты — в часы, когда ресурсы стоят дешевле. Это уже не экономия на спичках, а нормальная инженерная работа, которая окупается каждый месяц заново.
Но главный урок оказался не про технологии, а про процесс. Любая разовая оптимизация деградирует: люди уходят, привычки возвращаются, новые сервисы появляются без разметки. Поэтому мы сделали три простых ритуала. Бюджетные алерты с порогами, которые приходят в общий чат, а не в почту, которую никто не читает. Еженедельный пятнадцатиминутный разбор счёта, где мы смотрим аномалии и решаем, что с ними делать. И правило, что у каждого сервиса есть конкретный человек-владелец, который отвечает за его стоимость так же, как за его доступность. FinOps — это ведь не про экономию ради экономии, а про то, чтобы осознанно понимать, за что ты платишь.
Если у вас небольшой продукт и вы чувствуете, что счёт растёт быстрее пользователей, я бы советовал не паниковать и не бросаться переписывать архитектуру. Начните с наблюдаемости: включите разметку и посмотрите, куда реально уходят деньги. Потом выключите всё, что не нужно круглосуточно. Потом подумайте про скидки и автомасштабирование. И обязательно закрепите это регулярным процессом, иначе через полгода всё вернётся. У нас в итоге счёт снизился почти втрое при выросшей нагрузке, и это оказалось куда менее болезненно, чем я боялся.
А теперь вопрос к вам, коллеги: какой самый неожиданный источник расходов вы находили в своём облаке и что помогло его прикрыть? Делитесь историями — мне кажется, у каждого есть свой любимый «диск-призрак» или вечно бодрствующий staging, о котором стоит рассказать.
Первое, что меня поразило, — мы вообще не понимали структуру расходов. В панели облака была одна цифра за месяц, и всё. Кто из сервисов её съедает, почему вчера было дешевле, чем сегодня, и сколько стоит конкретная фича — ответить никто не мог. Поэтому первым делом я не начал ничего выключать, а занялся скучной вещью: разметкой ресурсов. Мы ввели обязательные теги — продукт, окружение, владелец, и настроили разбивку счетов по ним. Уже через неделю картина сложилась, и она была неприятной: почти треть денег уходила на то, о чём мы давно забыли.
Дальше началась археология. Мы нашли пять дисков от удалённых инстансов, которые продолжали жить своей жизнью. Два кластера баз данных в staging, работавших круглосуточно, хотя разработчики заходили туда раз в неделю. Логи, которые хранились бессрочно и весили больше, чем все наши данные вместе взятые. И, конечно, классику — несколько инстансов, которые мы «на всякий случай» подняли до больших размеров ещё на старте и так и не вернули назад. Утилизация процессора на самом дорогом из них болталась в районе семи процентов. Стыдно вспоминать.
Самое обидное, что эти находки не требовали ни рефакторинга, ни переезда, ни героических усилий. Мы включили политики жизненного цикла для логов и бэкапов — старые версии начали уходить в холодное хранилище и удаляться по расписанию. Настроили автоматическое выключение dev- и staging-окружений по ночам и выходным. Уменьшили размеры инстансов там, где метрики это позволяли. Только эти три вещи срезали счёт примерно на сорок процентов, и продукт этого даже не заметил. Ни одной жалобы от пользователей, ни одного инцидента.
Со второй волной экономии пришлось думать чуть больше. Мы честно посмотрели на графики нагрузки и поняли, что у нас есть предсказуемый базовый уровень, который стоит закрывать долгосрочными обязательствами со скидкой, и пики, которые выгоднее отдавать автомасштабированию и спотовым инстансам. Плюс перенесли часть фоновых задач — всякие отчёты, выгрузки, пересчёты — в часы, когда ресурсы стоят дешевле. Это уже не экономия на спичках, а нормальная инженерная работа, которая окупается каждый месяц заново.
Но главный урок оказался не про технологии, а про процесс. Любая разовая оптимизация деградирует: люди уходят, привычки возвращаются, новые сервисы появляются без разметки. Поэтому мы сделали три простых ритуала. Бюджетные алерты с порогами, которые приходят в общий чат, а не в почту, которую никто не читает. Еженедельный пятнадцатиминутный разбор счёта, где мы смотрим аномалии и решаем, что с ними делать. И правило, что у каждого сервиса есть конкретный человек-владелец, который отвечает за его стоимость так же, как за его доступность. FinOps — это ведь не про экономию ради экономии, а про то, чтобы осознанно понимать, за что ты платишь.
Если у вас небольшой продукт и вы чувствуете, что счёт растёт быстрее пользователей, я бы советовал не паниковать и не бросаться переписывать архитектуру. Начните с наблюдаемости: включите разметку и посмотрите, куда реально уходят деньги. Потом выключите всё, что не нужно круглосуточно. Потом подумайте про скидки и автомасштабирование. И обязательно закрепите это регулярным процессом, иначе через полгода всё вернётся. У нас в итоге счёт снизился почти втрое при выросшей нагрузке, и это оказалось куда менее болезненно, чем я боялся.
А теперь вопрос к вам, коллеги: какой самый неожиданный источник расходов вы находили в своём облаке и что помогло его прикрыть? Делитесь историями — мне кажется, у каждого есть свой любимый «диск-призрак» или вечно бодрствующий staging, о котором стоит рассказать.