AndrewKozlov
New member
Полгода назад я открыл счёт за облако и тихо выругался: 4 200 долларов за месяц за проект, который приносил не так уж много выручки. Продукт жил, пользователи не жаловались, но каждый месяц мы платили как за небольшой завод. Я не стал переписывать архитектуру с нуля и не нанимал консультантов за большие деньги — просто сел разбираться, куда именно уходят деньги. Через восемь недель счёт был 1 350 долларов при том же трафике и той же функциональности. Рассказываю, как это вышло.
Первое и самое важное — видимость. Я включил детализацию расходов по тегам и честно разметил всё, что можно: сервис, окружение, команда, владелец. Результат был неприятным: почти треть трат не имела ни одного владельца. Когда появилась картина по тегам, сразу всплыли мёртвые ресурсы — диски, отключённые от машин, старые снапшоты, пара балансировщиков, которые уже никуда не вели, и три базы данных, к которым за месяц не было ни одного подключения. Только на этом этапе, ничего не оптимизируя по сути, мы сняли около 500 долларов.
Дальше — окружения разработки. У нас было четыре стенда, которые, как выяснилось, жили круглосуточно и в выходные. Никто не работал в субботу, но машины исправно крутились и потребляли. Я повесил расписание: стенды поднимаются в восемь утра по будням и гасятся в девять вечера, а по выходным не поднимаются вовсе. Плюс отдельно настроил автоостановку по простою — если к стенду нет обращений полтора часа, он уходит спать. Экономия около 600 долларов в месяц, а команда почти не заметила разницы.
Потом я занялся размерами машин. У нас был классический страх нехватки ресурсов: мы брали инстансы с запасом на пик и держали их постоянно. Метрики показали, что средняя загрузка процессора — около пятнадцати процентов, а память упирается в потолок раз в месяц на десять минут. Я перевёл сервисы на более мелкие машины и часть нагрузки перенёс на ARM-процессоры, где цена за ту же производительность заметно ниже. Вместо постоянного запаса настроил автомасштабирование с расширением на пиковые часы. Это дало ещё около 700 долларов.
Отдельная история — данные и логи. Я был уверен, что самое дорогое у нас — серверы приложений. Оказалось, что логи и метрики съедали почти столько же. Мы хранили сырые логи за год, никто их не открывал, но оплата приходила исправно. Я ввёл политику хранения: горячие логи живут две недели, дальше уезжают в холодное хранилище, а всё старше полугодия просто удаляется. Кроме того, я вырезал из приложений отладочную болтовню, которую включали для одной задачи и забыли выключить. Это вернуло нам примерно 400 долларов.
И только после всей этой уборки я пошёл договариваться о скидках. Смысл в том, что скидки за долгосрочные обязательства бессмысленны, пока внутри бардак: ты фиксируешь на год неоптимизированные расходы. Когда два месяца подряд счёт был стабильным, я взял обязательства на базовую часть нагрузки, а всё пиковое и разовые задачи перевёл на спотовые машины с корректной обработкой прерывания. Это добавило около 800 долларов экономии. Но подчеркну: это был последний шаг, а не первый.
Чего я делать не советую. Не режьте слепую наблюдаемость, бэкапы и алерты — одна авария без них обойдётся дороже годовой экономии. Не удаляйте снапшоты, не убедившись, что из них никто не разворачивается. И не превращайте это в разовую кампанию: я теперь смотрю отчёт по расходам раз в неделю, а вопрос цены обсуждается на ревью вместе с качеством кода. У каждого инженера есть доступ к расходам своего сервиса, и это меняет решения удивительно быстро. Когда человек видит, что ещё один лишний кэш стоит как половина его зарплаты, он начинает думать иначе.
Если коротко, рецепт такой: сначала измерить и разметить, потом выключить лишнее, потом уменьшить размеры, потом заняться данными, и только в конце зафиксировать скидки. Никакой магии, только дисциплина и любопытство. А теперь вопрос к вам, коллеги: какая неожиданная статья расходов в облаке стала для вас самым большим сюрпризом — логи, трафик между зонами или что-то совсем неочевидное?
Первое и самое важное — видимость. Я включил детализацию расходов по тегам и честно разметил всё, что можно: сервис, окружение, команда, владелец. Результат был неприятным: почти треть трат не имела ни одного владельца. Когда появилась картина по тегам, сразу всплыли мёртвые ресурсы — диски, отключённые от машин, старые снапшоты, пара балансировщиков, которые уже никуда не вели, и три базы данных, к которым за месяц не было ни одного подключения. Только на этом этапе, ничего не оптимизируя по сути, мы сняли около 500 долларов.
Дальше — окружения разработки. У нас было четыре стенда, которые, как выяснилось, жили круглосуточно и в выходные. Никто не работал в субботу, но машины исправно крутились и потребляли. Я повесил расписание: стенды поднимаются в восемь утра по будням и гасятся в девять вечера, а по выходным не поднимаются вовсе. Плюс отдельно настроил автоостановку по простою — если к стенду нет обращений полтора часа, он уходит спать. Экономия около 600 долларов в месяц, а команда почти не заметила разницы.
Потом я занялся размерами машин. У нас был классический страх нехватки ресурсов: мы брали инстансы с запасом на пик и держали их постоянно. Метрики показали, что средняя загрузка процессора — около пятнадцати процентов, а память упирается в потолок раз в месяц на десять минут. Я перевёл сервисы на более мелкие машины и часть нагрузки перенёс на ARM-процессоры, где цена за ту же производительность заметно ниже. Вместо постоянного запаса настроил автомасштабирование с расширением на пиковые часы. Это дало ещё около 700 долларов.
Отдельная история — данные и логи. Я был уверен, что самое дорогое у нас — серверы приложений. Оказалось, что логи и метрики съедали почти столько же. Мы хранили сырые логи за год, никто их не открывал, но оплата приходила исправно. Я ввёл политику хранения: горячие логи живут две недели, дальше уезжают в холодное хранилище, а всё старше полугодия просто удаляется. Кроме того, я вырезал из приложений отладочную болтовню, которую включали для одной задачи и забыли выключить. Это вернуло нам примерно 400 долларов.
И только после всей этой уборки я пошёл договариваться о скидках. Смысл в том, что скидки за долгосрочные обязательства бессмысленны, пока внутри бардак: ты фиксируешь на год неоптимизированные расходы. Когда два месяца подряд счёт был стабильным, я взял обязательства на базовую часть нагрузки, а всё пиковое и разовые задачи перевёл на спотовые машины с корректной обработкой прерывания. Это добавило около 800 долларов экономии. Но подчеркну: это был последний шаг, а не первый.
Чего я делать не советую. Не режьте слепую наблюдаемость, бэкапы и алерты — одна авария без них обойдётся дороже годовой экономии. Не удаляйте снапшоты, не убедившись, что из них никто не разворачивается. И не превращайте это в разовую кампанию: я теперь смотрю отчёт по расходам раз в неделю, а вопрос цены обсуждается на ревью вместе с качеством кода. У каждого инженера есть доступ к расходам своего сервиса, и это меняет решения удивительно быстро. Когда человек видит, что ещё один лишний кэш стоит как половина его зарплаты, он начинает думать иначе.
Если коротко, рецепт такой: сначала измерить и разметить, потом выключить лишнее, потом уменьшить размеры, потом заняться данными, и только в конце зафиксировать скидки. Никакой магии, только дисциплина и любопытство. А теперь вопрос к вам, коллеги: какая неожиданная статья расходов в облаке стала для вас самым большим сюрпризом — логи, трафик между зонами или что-то совсем неочевидное?