Разбор облачного счета за 30 минут: как CTO замечают лишние расходы

Почему финансы не замечают архитектурные лишние расходы

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

Разбор облачного счета со стороны CTO начинается с другого угла. Вопрос не в том: «почему расходы на вычисления выросли на 18%?». Вопрос в том: «что в архитектуре заставило нас дважды платить за один и тот же результат?». Это совсем разные вопросы, и ответы на них тоже будут разными.

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

Та же проблема всплывает с неиспользуемыми облачными мощностями. Финансы могут заметить, что сервер каждый день стоит одинаково. Но это все равно не покажет, работает ли он десять часов в месяц, а остальное время в основном ждет. Ровный трафик часто мешает увидеть это, а не помогает. Если запросы идут стабильно, кажется, что размер системы нормальный. На деле спокойный график трафика может скрывать слишком большие базы данных, избыточно выделенные узлы Kubernetes или обработчики, которые остаются включенными круглосуточно ради коротких всплесков работы.

Счета тоже скрывают причину и следствие. Расходы растут после релиза, но в счете не написано: «этот новый сервис поиска дублирует то, что уже делала база данных», или «этот аналитический конвейер создал лишние расходы на хранение, передачу данных и инструменты поддержки». Там просто стоит более крупная сумма.

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

Что проверить в первые пять минут

Начните с того, чтобы разбить счет на несколько крупных групп: вычисления, базы данных, хранилище, сеть и мониторинг. Пока не обращайте внимания на мелкие строки. Большая часть лишних трат сидит в одной-двух крупных группах, а не в сервисе за $12, который никто не помнит зачем купил.

Затем сравните рост этих групп с трафиком, заказами, активными пользователями или API-вызовами. Если расходы на вычисления выросли на 35%, а использование продукта — только на 7%, счет явно о чем-то говорит. Команды часто добавляют более крупные инстансы, дополнительные реплики или новый путь данных задолго до того, как финансы заметят закономерность.

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

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

Зарезервированные мощности тоже нужно быстро проверить на реальность. Savings Plans и Reserved Instances помогают только тогда, когда фактическое использование остается близким к обязательству. Если вы зарезервировали намного больше времени работы базы данных или вычислений, чем реально используете, скидка перестает быть скидкой.

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

Этот проход занимает минуты. Он еще не решает проблему, но сразу показывает, какие части стека стоит открыть следующими.

Дублирование сервисов, которое выдает лишнюю работу

Во время разбора облачного счета дублирование часто важнее, чем сама сумма. Финансы видят пять счетов. CTO видит два или три системы, которые делают одну и ту же работу.

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

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

С очередями такая же путаница. Команды добавляют SQS, RabbitMQ или Kafka, но приложение все равно держит собственные таблицы повторных попыток, cron-обработчики или логику фоновых задач, которая по сути работает как вторая очередь. Это значит больше кода, больше точек отказа и два счета за один поток.

Пограничные сервисы тоже стоит сравнить рядом. Очень легко оказаться в ситуации, когда есть CDN, WAF от другого поставщика и дополнительные edge-правила еще от одного инструмента, и все они фильтруют и кэшируют один и тот же трафик. Если каждый слой нужен по понятной причине, оставьте его. Если никто не может объяснить разделение одной фразой, стек стал слишком сложным.

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

Старые сервисы, оставшиеся после миграции, — это самый простой вид лишних трат, который легко пропустить. Хранилище снапшотов, небольшой кластер базы данных, брокер сообщений почти без трафика или старый пул узлов Kubernetes могут стоять там месяцами, потому что «на всякий случай» кажется безопаснее, чем уборка.

Несколько прямых вопросов быстро вскрывают большую часть этого:

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

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

Простаивающие мощности, которые все равно списывают деньги весь месяц

Неиспользуемые мощности прячутся на виду, потому что счет выглядит ровным. Финансы видят обычную месячную сумму. CTO видит серверы, которые сидят на 5% CPU, память, которая никогда не заполняется, и целые окружения, которые остаются онлайн задолго после того, как команда перестала ими пользоваться.

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

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

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

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

Быстрый проход обычно показывает одни и те же паттерны:

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

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

Как форма трафика показывает неверный размер системы

Разбор облачного счета становится куда полезнее, когда вы сопоставляете почасовой трафик и почасовые расходы на вычисления. Общая цифра в счете скрывает время, а именно время показывает, где прячутся лишние траты.

Начните с простой проверки: расходы растут и падают вместе с трафиком или остаются ровными весь день? Если приложение получает резкий всплеск с 9 до 11 утра, а счет за вычисления выглядит одинаково в 3 ночи, значит, вы платите пиковые ставки за тихие часы.

Чаще всего это происходит, когда команда подбирает серверы под самый загруженный час и оставляет их такими на весь месяц. Это кажется безопасным, но стоит дорого. Системе, которой на два часа нужны 20 больших инстансов, в остальные 22 часа может хватать 6.

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

Несколько паттернов проявляются быстро:

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

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

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

Растущая SaaS-команда может видеть основную часть клиентского трафика в одном утреннем окне, запускать отчеты в то же время и держать слишком большие реплики базы данных всю ночь. В счете написано «рост использования». Форма трафика говорит, что система рассчитана не на те часы.

Как разобрать облачный счет за 30 минут

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

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

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

1. Сравните прошлый месяц с текущим и отметьте, что изменилось первым.
2. Пересортируйте расходы по категориям: вычисления, хранилище, сеть и инструменты.
3. Отметьте три строки, которые растут быстрее всего — по сумме или по проценту.
4. Спросите, какое изменение в продукте или у пользователей объясняет каждый скачок.
5. Превратите каждую подозрительную строку в одну проверку и отправьте этот список в engineering и ops до конца дня.

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

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

CTO может получить много пользы от этого получасового прохода, потому что счет рассказывает историю, которую финансы не видят. Финансы видят расходы. Engineering и ops могут сказать, появились ли они из-за роста числа пользователей, неудачного дефолта, забытого сервиса или решения по дизайну, которое имело смысл шесть месяцев назад, а теперь слишком дорого обходится.

Если повторять это каждый месяц, проверка становится быстрее. Первый проход находит лишние расходы. Второй уже начинает показывать привычки.

Простой пример из команды, которая растет как SaaS

SaaS-команда из 25 человек выпускает большой релиз под давлением сроков. Чтобы фоновые задачи не блокировали друг друга, инженеры добавляют вторую очередь для срочного проекта. Это решает текущую проблему, релиз выходит вовремя, и все двигаются дальше.

Дополнительная очередь остается в продакшене после запуска.

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

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

Та же команда отправляет логи в два платных инструмента. Один добавила platform team, второй пришел вместе с feature team, которой нужна была более быстрая настройка во время релиза. Спустя месяцы оба инструмента все еще хранят одни и те же логи и запускают почти одинаковые оповещения о сбоях задач и всплесках ошибок.

Финансы видят, что общие расходы выросли, но счет не объясняет историю. В нем просто показаны более высокие затраты на вычисления, очереди и observability. Он не показывает, что две очереди теперь делают пересекающуюся работу, или что два продукта для логов смотрят на одни и те же события.

Именно поэтому разбор облачного счета полезен даже тогда, когда приложение выглядит здоровым. Примерно за 30 минут CTO может сопоставить три сигнала: вторая очередь, которая так и не исчезла, группы обработчиков с ровным минимальным расходом и дублирующиеся расходы на логи, которые растут одновременно.

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

Ошибки, которые ведут к неправильному решению

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

Команды часто уменьшают размер инстансов раньше, чем изучат форму трафика. Средний CPU за месяц скрывает резкие пики, пакетные задачи, всплески cron и скачки в будни. Если трафик на оформление заказа удваивается на два часа каждое утро, более мелкие инстансы могут выглядеть дешевле на бумаге и все равно обойтись дороже, когда начнутся повторные попытки, тайм-ауты и дерганый автоскейлинг.

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

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

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

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

Быстрая проверка здравого смысла помогает:

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

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

Короткий чеклист перед следующим счетом

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

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

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

Короткая проверка перед счетом обычно включает такое:

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

Форма трафика важнее, чем многие команды ожидают. Если у вашего приложения короткие всплески во время кампании или запуска продукта, вы должны планировать именно их. Но нельзя подгонять под них весь месяц ради нескольких резких пиков. Oleg Sotnikov часто говорит об управлении затратами на уровне архитектуры именно в таком ключе: сначала уберите постоянные лишние траты, а затем закройте всплески самым простым рабочим правилом масштабирования.

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

Что делать после того, как вы нашли лишние траты

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

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

Хороший разбор облачного счета не заканчивается словами «мы сэкономили». Запишите, зачем каждая строка расходов вообще существовала. Возможно, вторая очередь осталась потому, что одна команда спешила с запуском. Возможно, слишком большие базы данных остались потому, что никто не доверял старой миграции. Возможно, трафик выглядел случайным, но всплески создавали маркетинговые кампании. Если зафиксировать причину, тот же самый лишний расход с меньшей вероятностью вернется через три месяца.

Держите заметки простыми:

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

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

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

Второй взгляд часто замечает то, к чему все уже привыкли. Oleg Sotnikov делает такую работу как Fractional CTO, связывая паттерны расходов с решениями по продукту, дизайном инфраструктуры и привычками команды. Если ваш счет продолжает расти по причинам, которые никто не может объяснить, такой внешний разбор может сэкономить много бесполезных споров.