Контроль расходов на облако для небольших команд начинается с простых сокращений

Почему счета растут раньше, чем ваш продукт

Большинство счетов за облако растут не потому, что внезапно пришло слишком много пользователей. Они увеличиваются потому, что небольшие команды под давлением запускают новые инструменты и продолжают платить за них уже после того, как спешка прошла.

Это особенно часто бывает, когда один основатель, один инженер или fractional CTO быстро принимает решения по инфраструктуре без ops-команды. Тестовое приложение запускают для демо. Staging-база живет намного дольше, чем сам запуск. Кто-то подключает второй инструмент для мониторинга, потому что первый неделю раздражал. По отдельности это не выглядит дорогим.

Проблема в базовых расходах. Многие сервисы начинают брать плату еще до того, как трафик заметно вырастет. Управляемая база данных, хранение логов, CI-раннер, бэкапы и несколько небольших серверов могут в сумме стоить сотни или тысячи в месяц, даже если число пользователей почти не меняется.

Обычно картина скучная. Один сервис поддерживает production. Еще два — тестирование, демо или старые эксперименты. Еще один инструмент дублирует то, за что вы уже платите. Счета приходят на разные аккаунты, и никто не видит общую сумму.

Последняя проблема важнее, чем кажется. Расходы часто прячутся по корпоративным картам, возмещениям основателя, командным бюджетам и годовым продлениям. Одна команда платит за отслеживание ошибок. Другая — за хостинг, в котором уже есть базовый мониторинг. Финансы видят отдельные списания, а не дублирование.

Так трафик стоит на месте, а расходы растут. Продукт обслуживает столько же пользователей в марте и в июне, но компания платит больше в июне, потому что появились дополнительные окружения, дополнительные снимки и три инструмента вместо одного.

Чаще всего лишние траты — это не рост, а хвосты. Прежде чем говорить о переписывании или смене провайдера, посмотрите, что команда включила, продлила дважды или просто забыла выключить после запуска. Обычно именно там лежат первые настоящие savings.

Сначала смотрите на архитектуру, а не на код

Когда lean-команда видит большой счет, первая мысль — настроить запросы или переписать медленный код. Но обычно это не самый дешевый путь. Лишние расходы часто начинаются раньше — когда простая функция зависит от слишком большого числа сервисов.

Возьмите одно типичное действие, например загрузку файла или оформление заказа, и проследите все сервисы, которых оно касается. У многих стартапов цепочка длиннее, чем ожидалось: web-приложение, API, auth, очередь, worker, база данных, object storage, CDN, логи, алерты и несколько платных дополнений. Каждый элемент по отдельности кажется небольшим. Вместе они создают постоянные ежемесячные расходы, больше точек отказа и дополнительные платежи за передачу данных.

На раннем этапе обычно выигрывает простота. Маленькому приложению редко нужны microservices, отдельные базы под каждую область или тяжелая message bus-система. Один app service, одна база данных, object storage и базовый мониторинг справляются с куда большим трафиком, чем ожидают большинство основателей. Чистая структура все равно важна, но каждый лишний компонент добавляет работу по обновлениям, наблюдению и объяснению.

Расходы на хранение и сеть стоит быстро проверить еще до начала крупной разработки. Трафик между регионами, NAT gateways, долгое хранение логов, бэкапы и дублирующее хранение файлов могут незаметно обогнать расходы на compute. Держите связанные сервисы ближе друг к другу. Задавайте короткий срок хранения для логов и снимков. Решите, какие данные должны оставаться быстрыми, а какие можно через неделю или месяц перевести в более дешевое хранилище.

Требования к uptime должны соответствовать бизнес-риску, а не тревожности. Если внутренний инструмент нужен только в рабочее время, вам, скорее всего, не нужен multi-region failover и круглосуточные алерты в первый же день. Часто достаточно быстрого восстановления, проверенных бэкапов и понятных правил дежурства. Дорогую схему стоит оставлять на тот момент, когда час простоя будет стоить больше, чем инфраструктура.

Именно здесь помогает fractional CTO. Самая большая экономия часто приходит не от настройки слоев, а от их удаления. Если сегодня одна функция проходит через девять сервисов, сокращение этого числа до четырех может снизить счет быстрее, чем месяцы работы над кодом.

Сначала найдите неиспользуемые сервисы

Неиспользуемые сервисы обычно легко заметить, если кто-то специально их ищет. Сервер может неделями держаться на 2 процентах CPU. База данных может хранить старые тестовые данные, к которым никто не прикасается. Очередь может пустовать весь месяц, но счет при этом продолжает приходить.

Так происходит, когда за уборку никто не отвечает. Команды поднимают staging-копию для релиза, запускают демо-окружение для звонка с продажами или тестируют новый кэш в течение одного спринта. Потом работа идет дальше, а инфраструктура остается.

Быстрый аудит обычно находит одно и то же: серверы с ровным низким использованием весь месяц, staging и demo-окружения, которые давно никто не открывает, забытые базы данных и очереди от прошлых тестов, логи и метрики, которые все еще идут от заброшенных проектов, а также снимки, диски или IP-адреса, оставшиеся после выключения.

Названия могут вводить в заблуждение. «temp», «new» и «copy» часто означают «никто уже не помнит, зачем это существует». Если у сервиса нет владельца, нет недавнего трафика и нет понятной цели, отправляйте его в список на отключение.

Не останавливайтесь на compute. Команды часто выключают машину, но продолжают платить за подключенное хранилище, бэкапы, load balancer и данные мониторинга. Сервер исчезает. Расход остается.

Логам нужно уделить особое внимание. Старые проекты могут продолжать отправлять логи, traces и метрики еще долго после завершения работы. На тихих системах длинный срок хранения имеет еще меньше смысла. Сильно сократите retention для ненужных проектов, оставьте в архиве только то, что может пригодиться, а остальное удалите.

Расписание помогает больше, чем кажется. Development-, testing- и demo-системам редко нужно работать ночью или по выходным. Автоматизируйте время запуска и остановки — и можно быстро сократить инфраструктурные расходы без трогания production.

Прежде чем кто-то заговорит о миграции или переписывании, проверьте, что все еще работает, кто за это отвечает и выполняло ли это реальную работу за последние 30 дней. Часто это самый простой выигрыш.

Проверьте пересечение лицензий до продлений

Лишние лицензии заметить сложнее, чем слишком большой сервер, но они быстро складываются в заметную сумму. Наступает месяц продления, и lean-команда понимает, что платит за три продукта, которые все отправляют алерты, хранят логи или запускают одни и те же build jobs.

Начните с обычной таблицы. Запишите каждый платный инструмент, ежемесячную стоимость, дату годового продления, количество мест и кто еще им пользуется. Включите trial-планы, которые незаметно стали платными, аккаунты подрядчиков и подписки, оформленные на корпоративные карты. Команды почти всегда находят несколько мест, привязанных к людям, которые ушли несколько месяцев назад.

Затем ищите дублирование. Небольшие команды добавляют инструменты по одному в периоды завалов, поэтому одинаковые продукты просачиваются внутрь почти без обсуждения. Это могут быть два чат-приложения, hosted CI-сервис, хотя команда уже использует GitLab runners, или отдельные продукты мониторинга для инфраструктуры и ошибок приложения.

Когда дублирование стало видно, выберите по одному инструменту для каждой задачи и сознательно откажитесь от остальных. С мониторингом все быстро становится запутанным. Многие стартапы платят за логи, метрики, uptime checks и отслеживание ошибок в нескольких местах, хотя более простая схема вполне справляется с повседневной работой.

Места тоже нужно проверять. Удалите доступ у бывших сотрудников, краткосрочных подрядчиков и всех, кто сменил роль, но сохранил старые лицензии. Десять забытых мест в нескольких продуктах могут стоить дороже небольшого сервера.

Не ждите, пока это заметит финансовый отдел. Спросите, кто отвечает за каждое продление, до того как оно придет. Если у инструмента нет владельца, проверьте, нужен ли он команде вообще.

Один аккуратный день может убрать реальные расходы без трогания кода продукта. Именно поэтому пересечение лицензий стоит проверить до любой глубокой переписки.

Проверьте расходы за один день

Чтобы найти первые сокращения, не нужен месяц аналитики. Один основатель, один инженер и fractional CTO обычно могут заметить лишние траты за один день, если смотреть на счет простым способом.

Начните с последних трех счетов, а не только с текущего месяца. Один счет может скрывать всплеск или разовый платеж. Три месяца показывают тенденцию.

Используйте простую таблицу с пятью колонками: сервис или инструмент, ежемесячная стоимость, команда или владелец, назначение и действие. В колонке действия лучше писать прямо: оставить, сократить или убрать.

Так хаотичный счет превращается в то, что можно быстро обсудить. Больше всего работает колонка с назначением. База данных, привязанная к production, легко оправдать. Staging-сервер, к которому не прикасались шесть недель, — уже нет. Второй инструмент мониторинга, который дублирует первый, должен сразу вызывать вопросы.

Сгруппируйте расходы двумя способами. Сначала по типу сервиса: compute, storage, monitoring, CI/CD и software tools. Потом — по команде или владельцу. Расходы без владельца обычно живут вечно.

После этого пока не трогайте мелочи. Сначала исправьте три крупнейших статьи. В большинстве стартапов основную часть счета формируют несколько позиций: слишком большие базы данных, тестовые машины, которые работают весь день, или дублирующие лицензии. Уменьшение одного большого инстанса обычно дает больше, чем отмена десяти мелких инструментов.

Используйте простой принцип: если статья дорогая, непонятная и не связана с выручкой или uptime, отправляйте ее в список на сокращение, пока кто-то не объяснит, почему ее стоит оставить.

До конца встречи решите, кто может утверждать новый регулярный расход. Правило должно быть коротким. Пусть владелец продукта утверждает продуктовые инструменты, engineering lead — изменения инфраструктуры, а основатель или CTO — любое новое ежемесячное обязательство. У многих команд бюджет утекает не из-за одного дорогого сервера. Он утекает из-за кучи маленьких согласований, которые никто не отслеживает.

Простой пример из небольшого стартапа

В стартапе из пяти человек часто оказывается три копии одной и той же системы: production для клиентов, staging для внутреннего тестирования и demo-стек для звонков с продажами. Это звучит разумно. Проблемы начинаются, когда все три работают как production, круглосуточно.

Представим, что у команды в каждом окружении есть по одной managed базе данных. Production это действительно нужно. Staging — часто нет. Demo-стеку — почти никогда. Но первоначальная схема остается, и три базы продолжают списывать деньги каждый час.

Мониторинг растет таким же образом. Один инженер подключает инструмент для логов. Потом кто-то добавляет еще один продукт для алертов и отслеживания ошибок. Оба собирают много одинаковых событий, и оба берут за это плату. В итоге у команды появляется дублирование, больше шума и более высокий счет.

Хранилище ведет себя тише, поэтому его игнорируют дольше. Старые test buckets хранят файлы бэкапов после пробных запусков, неудачных импортов и разовых QA-проверок. Никто их не открывает. Никто их не восстанавливает. Они просто лежат там месяц за месяцем.

Хороший первый проход — это уборка:

• поставить на паузу или уменьшить demo-базу данных
• перевести staging на расписание, а не держать его включенным постоянно
• выбрать один путь мониторинга для каждой задачи и остановить дублирующий сбор событий
• удалить старое тестовое хранилище и задать короткий срок хранения для одноразовых бэкапов

Ничто из этого не меняет продукт. Клиенты ничего не замечают. Команде не нужен план миграции. Они просто перестают платить за копии, дублирование и остатки.

Вот почему первая проверка расходов часто кажется немного скучной. И это хорошо. Экономия обычно лежит в обычной уборке, а не в героической инженерной работе. Когда очевидные лишние траты убраны, оставшийся счет начинает рассказывать более честную историю.

Ошибки, из-за которых расходы остаются высокими

Команды часто неделями обсуждают переписывание, прежде чем посмотреть, куда вообще уходят деньги. Это наоборот. Сначала измерьте использование: CPU, рост памяти, рост хранилища, нагрузку на базу данных, трафик по часам и то, как часто используется каждый сервис.

Если приложение почти весь день тихое, а серверы постоянно работают на максимальном размере, проблема, скорее всего, пока не в коде. Счет подсказывает, что емкость и трафик не совпадают.

Еще одна частая ошибка — гнаться за маленькими скидками на сервисах, которые почти не влияют на итог. Сэкономить 10 процентов на инструменте за 20 долларов приятно, но на общей сумме это почти не скажется. Более крупные сокращения обычно находятся в больших серверах, слишком крупных базах данных, дублирующих продуктах мониторинга или платных местах, которые никто не открывал в прошлом месяце.

Свободная мощность тоже слишком долго остается без дела. Команды держат дополнительные инстансы, большие тарифы и backup-окружения на случай, если они когда-нибудь понадобятся. Иногда такая осторожность оправдана. Но чаще временная подушка превращается в постоянный расход.

Ранние стартапы еще и копируют схемы, рассчитанные на компании в десять раз больше. Они добавляют Kubernetes, отдельные staging-кластеры, несколько инструментов observability, премиум-поддержку и слои security tooling еще до того, как у продукта появляется стабильное использование. Позже это может иметь смысл. Слишком рано — и инфраструктура превращается в ежемесячный налог на обучение.

Небольшой пример показывает это лучше всего. Стартап из пяти человек видит, что его cloud bill удвоился, и решает, что приложению нужен новый backend. Один анализ использования показывает два слишком больших сервера, неиспользуемую staging-базу и CI-план с гораздо большим числом минут, чем нужно команде. Сокращение этих расходов быстрее и безопаснее, чем переписывание приложения.

У платных инструментов должен быть названный владелец, который сможет ответить на два простых вопроса: зачем он нам все еще нужен и чем мы его заменим, если отменим. Без этого продления происходят по инерции.

Быстрые проверки перед следующим счетом

Короткая проверка до закрытия биллингового цикла может быстро сократить реальные расходы. Самые простые выигрыши обычно очевидны: неиспользуемые сервисы, слишком большие базы данных, лишние места в ПО, быстрый рост хранилища и отсутствие алертов по расходам.

Для этого не нужна полноценная ops-команда. Основатель, финансовый руководитель или fractional CTO может открыть billing dashboard и отчеты по использованию и за один раз увидеть явные лишние траты.

Пройдитесь по короткому чек-листу:

• проверьте все сервисы без трафика за последние 30 дней
• посмотрите базы данных, которые большую часть времени работают ниже 10 процентов нагрузки
• удалите платные места, которыми никто не пользовался в этом месяце
• сравните рост хранилища с ростом числа пользователей
• включите алерты по расходам на 50, 75 и 90 процентах месячного лимита

Небольшие команды пропускают это, потому что каждая отдельная позиция кажется безобидной. Одна простаивающая база, три неиспользуемых места и log bucket, который растет каждый день, могут незаметно добавлять несколько сотен долларов в месяц.

Простой пример: если число пользователей не выросло, а object storage увеличился на 40 процентов, вероятная причина — шумные логи или дублирующиеся файлы, а не здоровый рост. Если production-база неделями держится на 6 процентах нагрузки, уменьшить ее часто безопаснее, чем людям кажется.

Одна привычка делает все это проще. Записывайте, кто отвечает за каждую статью расходов. Сервисы без владельца обычно живут вечно, и никто не выключает их, пока счет не начнет реально болеть.

Решите, что делать дальше

Большинству команд не нужно переписывание, чтобы снизить следующий счет. Им нужен один ответственный, один короткий аудит и понятная очередность работ. Лучшие savings обычно начинаются с простых исправлений, а не с героизма.

Хорошо работает простой порядок:

1. Сократите лишние расходы уже на этой неделе. Выключите неиспользуемые сервисы, уберите тестовые окружения, к которым никто не прикасается, и уменьшите все, что явно слишком велико.
2. После уборки зафиксируйте архитектурные улучшения. Когда шум исчезнет, будет проще увидеть, какие расходы связаны с реальными потребностями продукта, а какие — со старыми решениями.
3. Поставьте ежемесячный обзор расходов в календарь. Тридцати минут часто достаточно, если счет понятный, а за чек-лист отвечает один человек.
4. Если никто не может взять это на себя, привлеките внешнюю помощь. Обычно это дешевле, чем позволять лишним тратам тянуться еще один квартал.

Небольшой стартап может сделать это за один день. Один основатель открывает cloud bill, один инженер проверяет, что еще работает, и вместе они сравнивают продления ПО с реальным использованием. Уже это может заметно сократить расходы еще до начала любого технического проекта.

Если нужен внешний аудит, сделайте запрос узким. Попросите три вещи: где деньги утекают сегодня, какие архитектурные решения создают повторяющиеся расходы и какие лицензии можно убрать до следующего продления. Oleg Sotnikov at oleg.is работает со стартапами и небольшими компаниями как fractional CTO и advisor, проверяя архитектуру, инфраструктуру и регулярные расходы на инструменты до того, как они решат идти в большое переписывание.

Поставьте ежемесячный обзор в календарь прямо сейчас. А потом на этой неделе уберите один неиспользуемый сервис. Часто этого достаточно, чтобы запустить всю уборку.