Счета за облако редко взрываются из-за того, что кто-то нажал не ту кнопку. Они растут постепенно. Забытый постоянный диск здесь, пул узлов GKE, который так и не уменьшился, там, бакет Cloud Storage, хранящий годы отладочных логов. К тому моменту, когда финансы спрашивают, почему счёт удвоился, архитектура уже впитала десятки мелких неэффективностей. Именно поэтому оптимизация затрат GCP — это не финансовая рутина, а архитектурная дисциплина, и она лежит в основе того, чем на самом деле занимается архитектор Google Cloud.
Инструменты все на месте: экспорт биллинга GCP, Recommender API, скидки за обязательства (committed use discounts), скидки за длительное использование. Сложность в том, чтобы знать, какой рычаг дёрнуть, в каком порядке и когда это навредит надёжности. Эта статья проходит через реальный сценарий аудита затрат, показывает, где стандартный плейбук ломается, и сопоставляет каждый шаг с решениями, проверяемыми на экзаменах ACE и PCA — потому что экзамен не просит перечислять типы скидок, он просит выбирать.
Почему FinOps — это архитектурный навык, а не задача биллинга
Каждый ресурс GCP несёт две стоимости: цену в прайс-листе SKU и стоимость решения, которое его создало. Виртуальная машина n2-standard-8, работающая на 4% CPU, — это не проблема инфраструктуры, а решение о размере, принятое однажды и никогда не пересматриваемое. Скидка за обязательства, которая привязывает вас к семейству машин, от которого вы собираетесь мигрировать, — это не экономия, а обязательство.
Механизм прост: цены GCP вознаграждают предсказуемость и наказывают дрейф. Скидки за длительное использование автоматически применяются к долго работающим экземплярам Compute Engine; скидки за обязательства обменивают скидку на обязательство на один или три года. Оба предполагают, что ваша рабочая нагрузка стабильна. Как только нагрузка меняет форму, скидка становится ограничением. Задача архитектора — знать, какие части системы действительно стабильны, а какие только выглядят стабильными в этом квартале.
Разбор: аудит счёта GCP на $40 тыс./месяц
Представьте SaaS-компанию среднего размера, тратящую примерно $40 000 в месяц на GCP. Разбивка выглядит так:
| Сервис | Месячные расходы | Доля |
|---|---|---|
| Compute Engine (ВМ + диски) | $18 000 | 45% |
| GKE (узлы + control plane) | $9 000 | 22,5% |
| Cloud Storage | $5 000 | 12,5% |
| BigQuery | $4 000 | 10% |
| Сеть (egress, LB) | $4 000 | 10% |
Наивный подход — открыть консоль биллинга, отсортировать по стоимости и начать удалять. Так случаются простои. Дисциплинированный порядок: экспорт, атрибуция, рекомендации, действие, обязательство.
Шаг 1 — Экспортируйте данные биллинга, прежде чем что-либо трогать
Включите экспорт Cloud Billing в BigQuery (детализированная стоимость использования). Это даёт гранулярность по строкам: проект, сервис, SKU, метки, местоположение. Без этого вы гадаете. С этим вы можете запрашивать:
SELECT
project.id AS project,
service.description AS service,
SUM(cost) AS total_cost
FROM `billing_dataset.gcp_billing_export_v1_XXXXXX`
WHERE invoice.month = '202609'
GROUP BY project, service
ORDER BY total_cost DESC
LIMIT 20;
Этот единственный запрос обычно показывает, что один-два проекта составляют большую часть расходов, и что метки, которые вы считали согласованными, таковыми не являются. Исправление меток — не блестящая задача, но это разница между аудитом затрат и догадками о затратах.
Шаг 2 — Правайзинг Compute Engine с помощью Recommender
Recommender API выявляет простаивающие и избыточные ресурсы. Для Compute Engine соответствующие типы инсайтов включают google.compute.instance.IdleResourceRecommender и google.compute.instance.MachineTypeRecommender. Вы можете перечислить их:
gcloud recommender recommendations list \
--recommender=google.compute.instance.MachineTypeRecommender \
--location=us-central1-a \
--project=my-project
Каждая рекомендация содержит costProjection — оценку месячной экономии в случае применения. Частая находка: несколько экземпляров n2-standard-8, работающих с загрузкой CPU ниже 10% в течение 30 дней. Уменьшение до n2-standard-4 может сэкономить, скажем, $150 на экземпляр в месяц. На десяти экземплярах это $1 500 — реально, но не революционно.
Неочевидный вывод: правайзинг экономит меньше, чем вы ожидаете; очистка простаивающих ресурсов экономит больше. Постоянные диски, прикреплённые к удалённым ВМ, статические IP на остановленных экземплярах и осиротевшие снимки часто стоят дороже, чем запас CPU, за которым вы гоняетесь. Recommender отмечает и их, но они находятся в других типах инсайтов, и их легко пропустить, если смотреть только на типы машин.
Шаг 3 — GKE: ловушка пула узлов
Стоимость GKE определяется пулами узлов. Ошибка — относиться к пулам узлов как к статической инфраструктуре. Если автомасштабирование включено, но минимальное количество узлов установлено на уровне, который имел смысл во время всплеска трафика полгода назад, вы платите за мощность, которую больше никогда не используете.
Проверьте фактическую утилизацию:
kubectl top nodes
kubectl describe nodes | grep -A5 "Allocated resources"
Если узлы стабильно показывают 20–30% распределения, минимальное количество слишком велико. Снизить его безопасно; автомасштабировщик добавит узлы, когда нагрузка вернётся. Компромисс: задержка масштабирования вверх. Узел, которому требуется 90 секунд на подготовку, — это 90 секунд ухудшенной мощности во время всплеска. Для пакетных нагрузок это нормально. Для API, чувствительного к задержкам, возможно, понадобится небольшой буферный пул.
Шаг 4 — Жизненный цикл Cloud Storage, а не удаление
Хранение — это то, из-за чего команды нервничают. Безопасный ход — не удаление, а правила жизненного цикла. Перемещайте объекты старше 90 дней в Nearline, старше 365 — в Coldline. Экономия зависит от шаблонов доступа, но для бакетов логов и резервных копий сдвиг обычно существенный. Ловушка: затраты на извлечение. Если кто-то действительно читает объект Coldline, вы за это платите. Политики жизненного цикла — это ставка на шаблоны доступа, и эту ставку следует проверять по фактическим логам доступа, а не предполагать.
Шаг 5 — Скидки за обязательства, применяемые последними
Только после правайзинга и очистки следует рассматривать скидки за обязательства (CUD). CUD — это обязательство тратить определённую сумму в час на конкретное семейство машин в регионе в течение одного или трёх лет в обмен на скидку. Размер скидки зависит от срока и типа ресурса, но структурный момент фиксирован: вы фиксируете базовый уровень.
Правильная последовательность: сначала правайзинг, затем наблюдение за новым базовым уровнем как минимум несколько недель, затем обязательство на часть этого уровня — не на весь. Обязательство на 100% текущего использования не оставляет места для сокращения нагрузки. Распространённая практика — обязательство на 60–70% стабильного базового уровня, а остальное пусть плавает на скидках за длительное использование.
Где сам плейбук оптимизации ломается
Каждая стратегия затрат предполагает условия, которые могут измениться. Вот четыре режима отказа, которые стоит распознать, прежде чем они вам дорого обойдутся.
1. Рабочая нагрузка меняет форму после обязательства
Вы обязуетесь по экземплярам n2 на три года, затем команда мигрирует на n2d (AMD) или на GKE Autopilot для лучшей плотности. Обязательство не переносится. Ранний признак: обсуждения дорожной карты архитектуры, упоминающие семейства машин, не покрытые вашим CUD. Если уже слишком поздно: вы не можете отменить обязательство, но иногда можете его использовать, сохраняя небольшой устаревший пул на семействе с обязательством, пока новые нагрузки переезжают в другое место. Это расточительно, но менее расточительно, чем неиспользуемое обязательство.
2. Recommender прав насчёт ресурса, но ошибается насчёт нагрузки
Recommender видит CPU и память. Он не видит, что экземпляр — это сервер лицензий с фиксированным числом ядер, или база данных с моделью лицензирования, привязанной к vCPU. Уменьшение размера нарушает лицензию. Ранний признак: любой экземпляр, тип машины которого был выбран по причине, отличной от производительности. Если уже слишком поздно: вы уже уменьшили размер, и аудит лицензий идёт. Решение не техническое — это разговор с отделом закупок.
3. Скидки за длительное использование уменьшаются при масштабировании вниз
Скидки за длительное использование применяются автоматически к долго работающим экземплярам. Если вы агрессивно проводите правайзинг, оставшиеся экземпляры по-прежнему имеют право на скидку, но общая скидка уменьшается, потому что экземпляро-часов меньше. Это не причина избегать правайзинга; это причина не учитывать экономию дважды в вашем прогнозе. Ранний признак: прогноз экономии, который складывает экономию от правайзинга и экономию от длительного использования, не учитывая их взаимодействие.
4. Экспорт биллинга неполон
Экспорт в BigQuery может запаздывать, а некоторые начисления (плата за скидки за обязательства, определённые сетевые начисления) появляются в других таблицах или с другим временем. Если вы проводите аудит по частичному экспорту, вы занизите цифры. Ранний признак: итоги вашего запроса не совпадают с итогом в консоли биллинга за тот же месяц. Если уже слишком поздно: сверьте данные, прежде чем представлять экономию руководству, иначе цифра будет оспорена, и вся программа потеряет доверие.
Как это соотносится с экзаменами ACE и PCA
Экзамены не проверяют, умеете ли вы запускать gcloud recommender. Они проверяют, умеете ли вы правильно выбирать при ограничениях. Типичный сценарий в стиле PCA: компания хочет снизить затраты Compute Engine, но не может допустить простоя; какой подход вы рекомендуете? Ответ — не «скидки за обязательства», а правайзинг с живой миграцией, затем обязательство на уменьшенный базовый уровень. Порядок и есть ответ.
Аналогично, вопросы уровня ACE проверяют, знаете ли вы, что скидки за длительное использование автоматические, а скидки за обязательства — это покупка, и что их путаница ведёт к неверным моделям затрат. Экзамен вознаграждает архитекторов, которые мыслят последовательностями, а не изолированными фактами.
Пути обучения и их компромиссы
Есть три реалистичных маршрута к этому материалу, и они различаются по стоимости, времени и тому, что вы действительно усваиваете.
| Путь | Время | Стоимость | Что вы получаете | Что вы упускаете |
|---|---|---|---|---|
| Самостоятельное изучение с документацией и песочницей | 3–6 месяцев | Низкая (стоимость песочницы) | Глубокое знакомство с консолью и CLI | Нет обратной связи по решениям; дорогие ошибки в реальном проекте |
| Курсы с фокусом на экзамен | 6–10 недель | Средняя | Структурированное покрытие доменов экзамена | Часто мало практических сценариев затрат |
| Управляемый курс с лабораториями и кейсами | 8–12 недель | Средняя | Практика архитектурных решений и обратная связь | Требует дисциплины для завершения |
Маршрут самообучения самый дешёвый, но имеет специфический режим отказа: вы никогда не узнаете, что ваша модель затрат была неверной, пока не придёт счёт. Проект-песочница с бюджетом $50 учит вас консоли, а не последствиям. Если вы хотите безопасно изучить решения FinOps, вам нужен либо наставник, либо структурированная среда, где проверяется ваше мышление. Курс Архитектор Google Cloud — Professional (ACE + PCA) проходит именно через эти расчёты затрат и архитектуры с практическими лабораториями и кейсами, так что цикл обратной связи существует до появления счёта.
Для смежных навыков материал платформы по SQL и базы данных полезен для понимания экспорта биллинга BigQuery, а разбор автоскейлинга Kubernetes дополняет раздел о затратах GKE.
Кому подходит этот путь — и кому нет
Этот материал подходит инженерам, которые уже работают с GCP и хотят перейти от эксплуатации ресурсов к владению архитектурными решениями. Если вы развернули ВМ, понимаете роли IAM и видели консоль биллинга, вы готовы. Он также подходит архитекторам, готовящимся к ACE или PCA, которые хотят, чтобы измерение затрат было сильной стороной, а не пробелом.
Он не подходит полным новичкам без облачного опыта — концепции затрат предполагают, что вы знаете, что такое VPC. Он также не подходит людям, ищущим чисто финансовый курс; здесь архитектура на первом месте, а финансы следуют. И если ваша организация не собирается связывать себя с GCP на годы, разделы о скидках за обязательства будут академическими — полезными для экзамена, менее полезными для повседневной работы.
Оптимизация затрат в GCP — это последовательность ставок на стабильность, и ценность архитектора в том, чтобы знать, какие ставки делать и когда оставлять место для изменения решения. Если вы хотите практиковать эти решения с обратной связью, а не учиться на неожиданном счёте, курс Архитектор Google Cloud — Professional (ACE + PCA) охватывает архитектурные и стоимостные компромиссы с практическими лабораториями и пробными экзаменами — начните с экспорта биллинга и разбора Recommender, и стройте оттуда.
Начать можно здесь: Google Cloud Architect — Professional (ACE + PCA).