Счёт за облако растёт незаметно: забытый GPU после эксперимента, overprovisioned Postgres «на вырост», трафик в чужой регион, три неиспользуемых staging. FinOps — не про «сэкономить любой ценой», а про связку архитектуры, закупок и инженерии так, чтобы рубль инфраструктуры покупал надёжность и скорость поставки.
В OtherCode мы размещаем продукты на Yandex Cloud, Selectel, выделенных и облачных VPS RU, а иногда в гибриде с on-prem заказчика. Ниже — как выбираем площадку, считаем TCO и не запираемся в одном зарубежном hyperscaler.
Зачем считать инфраструктуру как продукт
Инженеры видят latency и CPU. Финансы видят строку в P&L. FinOps соединяет оба взгляда:
| Вопрос | Без FinOps | С FinOps | |--------|------------|----------| | Кто владеет стоимостью сервиса | «Облако само» | Команда продукта / tech lead | | GPU для URAP | Включили и забыли | Job-based, auto-stop, бюджет на эксперимент | | Выбор региона | Где привыкли | Данные, закон, RTT до пользователей | | Резерв мощности | +300% «на всякий» | Rightsizing по p95 + запас |
Для студии и клиентов в РФ отдельно важны: доступность сервисов, платежи, поддержка, риски блокировок и требования к локализации данных. Про замену привычных Google-сервисов в российском контексте мы писали отдельно: Google-сервисы в России и альтернативы.
Карта площадок: что используем и когда
Yandex Cloud
Подходит, когда нужны managed-сервисы без своей возни с патчами:
- managed PostgreSQL / object storage / сети;
- пиковые мощности под ML (URAP: обучение, batch OCR);
- быстрый старт окружения без закупки железа.
Платим за удобство и API автоматизации. Контролируем: размер дисков, неиспользуемые IP, старые снимки, простой VM.
Selectel и аналогичные RU-провайдеры
Хороший баланс цены и контроля: выделенные и облачные ресурсы, понятная поддержка, гибкость под промышленные и SaaS-нагрузки. Часто сажаем API и воркеры ближе к пользователям и интеграциям в РФ.
Dedicated / VPS RU
Основной паттерн для многих продуктов студии — предсказуемый VPS:
- сайт othercode.ru (Next.js) и связанные Node-сервисы под PM2;
- Docker Compose для API/workers;
- предсказуемый monthly bill вместо сюрпризов pay-as-you-go на каждый чих.
VPS выигрывает, когда нагрузка стабильна, команда умеет администрировать и не нужен каждую неделю новый managed-сервис из каталога.
On-prem / контур заказчика
Для enterprise и промышленной телеметрии (контуры рядом с Typhoon/Modbus, Galvatec) часть данных не должна уходить во внешнее облако. Тогда облако — только для шлюза, обновлений и агрегированной аналитики, а «сырьё» остаётся у заказчика.
Anti lock-in: почему не «всё в один US cloud»
Один глобальный провайдер удобен в туториалах. На практике для продуктов с аудиторией и юрлицами в РФ риски включают:
- платежи и верификацию аккаунтов;
- сетевую доступность и RTT;
- compliance и хранение ПДн;
- внезапные ограничения сервисов и API.
Стратегия OtherCode — переносимые артефакты:
- Приложения в Docker, CI в GitLab на своих runners.
- Инфраструктура как код / воспроизводимые compose/helm-описания, где уместно.
- БД — PostgreSQL (в т.ч. PostGIS для Synapse Stream), а не проприетарный lock-in без необходимости.
- Объектное хранилище с S3-совместимым API, чтобы сменить endpoint без переписывания домена.
Мы можем держать staging в одном месте, prod — в другом, или быстро переехать с VPS на Yandex Cloud managed DB, не переписывая бизнес-логику Game API.
Стоимость GPU и AI: отдельная статья бюджета
URAP AI и эксперименты с LLM/OCR легко сжигают бюджет.
| Режим | Где крутим | Как контролируем стоимость | |-------|------------|----------------------------| | Online inference | CPU / лёгкий GPU / оптимизированный runtime | Latency SLA vs $/1k docs | | Batch OCR / retrain | GPU VM по расписанию | Автовыключение, spot/preemptible где допустимо | | Eval в CI | Отдельный runner / ночной pipeline | Не на каждый commit | | Embeddings / RAG | CPU или малый GPU + кэш | Кэш чанков, дедуп документов |
Правило: GPU не для «чтобы было». Сначала измеряем CPU-baseline; GPU включаем, когда экономит wall-clock или открывает нужное качество в рамках SLA.
Content Factory (Telegram) и большинство Next.js/API-нагрузок GPU не требуют. Diom (Flutter) бьёт по бюджету скорее сборками CI и backend RPS, чем видеокартами.
Rightsizing на практике
Rightsizing — регулярный ритуал, не разовый аудит после шока от счёта.
Что смотрим раз в месяц
- CPU/RAM p95 vs запрошенные limits (контейнеры и VM);
- размер дисков vs реальные данные + рост;
- простой staging ночью и на выходных;
- старые образы в registry и забытые volume snapshots;
- трафик между зонами/провайдерами (часто дороже compute).
| Симптом | Типичная причина | Действие | |---------|------------------|----------| | CPU < 20% постоянно | Overprovision | Уменьшить тариф / лимиты | | Swap / OOM | Undersize или утечка | Профиль + апсайз точечно | | Диск 90%+ | Логи / бэкапы на том же volume | Ротация, вынос бэкапов | | Счёт GPU вырос ×3 | Забытая VM | Автоstop + алерт на uptime |
Для Synapse Stream с PostGIS отдельно смотрим размер индексов и bloat — «просто добавить CPU» дороже, чем настроить вакуум и запросы. Оптимизация PostgreSQL у нас описана в отдельном материале: PostgreSQL оптимизация.
Модель TCO: не только цена VM
Считаем полную стоимость владения на горизонте 12 месяцев:
- Compute + storage + traffic провайдера.
- Люди: часы на админку k8s vs VPS.
- Простой: стоимость инцидента × вероятность.
- Лицензии и managed-наценки.
- Миграция: сколько стоит сменить площадку через год.
Иногда «дорогой» managed Postgres дешевле младшего инженера, который ночами чинит репликацию. Иногда наоборот — VPS с понятным бэкапом выгоднее красивого SLA в каталоге.
Пример сравнения (упрощённо)
| Вариант | Плюсы | Минусы | Когда берём | |---------|-------|--------|-------------| | VPS RU + Docker + PM2 | Цена, контроль, простота | Сами патчи и мониторинг | Стабильная нагрузка, small team | | Yandex Cloud managed | Меньше ops на БД/сеть | Выше $/unit, риск «расползания» сервисов | Нужен managed + пики | | Hybrid (VPS app + cloud DB/GPU) | Гибкость | Две сети, два биллинга | AI batch + стабильный API | | On-prem заказчика | Данные дома | Долгий доступ, разный зоопарк | Enterprise / промышленность |
Как FinOps встроен в разработку
- В GitLab CI параллельные runners ускоряют поставку, но минуты тоже стоят денег — тяжёлые job по правилам.
- Production-деплои othercode.ru через PM2 не требуют кластера из пяти нод «для солидности».
- Redis-очереди и кэш снижают повторный compute (дешевле докинуть кэш, чем удвоить CPU под URAP).
- Метрики продукта (конверсии, ошибки API) смотрим вместе с рублями инфраструктуры — иначе оптимизируем не то.
Для аналитики в РФ опираемся не только на зарубежные стеки: Яндекс Метрика и собственные события в PostgreSQL часто достаточны на старте продукта.
Сетевые и скрытые статьи расходов
В счёте за облако часто «выстреливают» не VM, а побочные сервисы:
- Исходящий трафик — отдачи файлов, бэкапы «в другой регион», CDN без нужды.
- Публичные IP и балансировщики — забытый IP после теста стоит каждый месяц.
- Снимки дисков и старые образы в registry — тихий рост storage.
- Managed DB storage autoscaling — удобно, пока не осознаёте потолок.
- NAT / egress между VPC и on-prem — для гибрида Typhoon/Galvatec считаем заранее.
Практика: раз в месяц экспорт billing CSV (или аналог у провайдера) и 30 минут разбора с tech lead продукта. Без этого FinOps остаётся лозунгом.
Резервирование vs on-demand
| Стратегия | Плюс | Минус | |-----------|------|-------| | On-demand | Гибкость | Дорого на стабильной нагрузке | | Reserved / committed | Ниже цена | Нужен прогноз на 6–12 мес | | Spot / preemptible для batch | Дёшево для URAP retrain | Нужны checkpoint и retry | | Свой VPS 24/7 | Предсказуемый bill | Capex/операционка на патчи |
Для othercode.ru и большинства клиентских API мы чаще берём предсказуемую посадку. Для GPU-batch — максимально эфемерные машины.
Безопасность как часть стоимости
Дешёвый хостинг с дырявым SSH и без бэкапов — не экономия. В TCO закладываем:
- время на hardening и обновления;
- стоимость инцидента утечки (особенно документы URAP и геоданные Synapse);
- изоляцию контуров: staging не ходит в prod БД «для удобства»;
- отдельный бюджет на тестирование restore.
On-prem заказчика иногда дороже облака по людям, но дешевле по риску регуляторики — решение продуктовое, не «религиозное».
Как считаем инфраструктуру на этапе оценки проекта
На пресейле OtherCode закладывает черновой bill of materials:
- Ожидаемый RPS / документы в сутки / число устройств Modbus.
- Нужен ли GPU и сколько часов в месяц.
- Объём хранения (файлы, таймсерии, гео).
- Требования к локализации и резервированию.
- Кто администрирует: студия, заказчик, гибрид.
Клиент видит не только оценку разработки Next.js/Flutter/API, но и порядок цифр за 12 месяцев хостинга. Это снижает конфликт через полгода, когда «внезапно» приходит счёт за Yandex Cloud.
Связка с продуктами: Diom бьёт по push и API; Content Factory — по числу ботов и медиа; Synapse — по PostGIS и realtime; URAP — по CPU/GPU и object storage. Разные профили — разные рекомендации площадки.
Прагматичный roadmap оптимизации
Если счёт уже вырос, порядок действий обычно такой:
- Выключить забытое (GPU, staging, IP).
- Rightsizing CPU/RAM по p95.
- Кэш и очереди (меньше повторного compute).
- Вынести тяжёлую аналитику с primary DB.
- Только потом — смена провайдера или k8s «чтобы утилизация была».
Смена облака ради 10% экономии при месяце миграции команды — часто ложный FinOps.
Чеклист перед масштабированием счёта
- [ ] У сервиса есть владелец стоимости
- [ ] Есть алерт на аномальный spend / uptime GPU
- [ ] Staging не равен prod по размеру «на всякий»
- [ ] Бэкапы восстановлены хотя бы один раз
- [ ] План миграции на второго провайдера существует на бумаге
- [ ] AI/GPU отделены бюджетом от online API
Итог
OtherCode выбирает хостинг прагматично: VPS RU и PM2/Docker для предсказуемых продуктов, Yandex Cloud и Selectel — когда нужны managed и пики, GPU — по делу, архитектура — переносимая, без культа одного US-облака. FinOps — часть инженерной культуры, а не табличка в конце квартала.
Если нужно спроектировать инфраструктуру и бюджет под ваш продукт в РФ — напишите нам.
