Архітектура вартості
1) Принципи і ролі
Cost as a Feature. Ціна - частина UX/продукту та архітектурних рішень.
Спільна відповідальність. Інженери, платформа/DevEx, фінанси, продукт - єдина петля зворотного зв'язку.
Єдине джерело істини. Каталог тегів/міток, словник витрат і джерела даних.
Петля «Спостерігай → Оптимізуй → Керуй». Вбудовані дашборди, автоматичні гейти і політики.
Ролі: Архітектор вартості, FinOps аналітик, Власник продукту, Платформна команда.
2) Модель даних вартості
Одиниці обліку (unit economics):- За API: '$/1000 запитів','$/мілісекунду CPU','$/ГБ egress'.
- За дані: «$/ГБ-місяць зберігання», «$/запит до БД», «$/млн повідомлень».
- За користувача: `CAC`, `ARPU/ARPPU`, `Gross Margin`, `LTV:CAC`.
- За потік: '$/транзакцію','$/деплою','$/тестовий прогін'.
cost_record {
ts, provider, account, region, service, usage_qty, usage_unit,
list_price, net_price, discounts,
tags: { env, team, product, feature, tenant, cost_center, pii, tier },
resource_id, allocation_keys: {req_id?, tenant_id?, dataset?}
}Золоті теги (обов'язкові): `env`, `team`, `product`, `feature`, `cost_center`, `owner`, `pii`, `tier (hot/warm/cold)`, `region`.
3) Атрибуція: showback/chargeback
Showback: прозорі звіти по командах/фічах без тарифікації внутрішніх трансферів.
Chargeback: розподіл за правилами: прямі витрати → власнику; shared-ресурси - за ключами: RPS, CPU-секунди, GB-години, обсяг подій.
cluster_cost = sum(provider_cost where resource in "k8s-node:")
weights = { service: cpu_seconds(service)/total_cpu_seconds }
for service in services:
charge[service] = direct_cost(service) + cluster_cost weights[service]4) Політики та гейти вартості (Policy as Code)
Правила бюджету: ліміти по'env/team/feature'; авто-алерт/блок деплоя при прогнозованому перевищенні.
Вимоги до міток: ресурси без обов'язкових тегів - deny в admission-контролері.
Ліміти профілю: заборона великих машин в'dev', TTL на ephemeral-ресурси, мінімальні резервування.
yaml policy: require-tags-and-limits deny_if_missing_tags: [team, product, env, cost_center, owner]
constraints:
env==dev:
max_instance_type: "c6i. large"
ttl_hours: 725) Обчислення: патерни зниження вартості
Правильний розмір (rightsizing): авто-підбір vCPU/RAM на основі p95/p99, сезонності та headroom.
Авто-масштабування: target-based (CPU/RPS/lag), step-функції; захист від thrash через гістерезис.
Вибір прайс-моделі: on-demand vs spot/preemptible, Reserved Instances/Savings Plans; суміш для критичних і фонів.
Batch-конвеєри: вікна «дешевого» навантаження, batch-компресія, пріоритетні черги.
Кешування та коалесинг запитів: зниження читань з дорогих джерел.
Edge/оптимізація мережі: HTTP/2/3, keep-alive, компресія, CDN.
if rps > target1. 2 for 3m: replicas += ceil(rps/target); cool_down 5m if rps < target0. 6 for 10m: replicas = max(min_replicas, replicas-1)6) Зберігання та дані: гаряче/тепле/холодне
Тиринг: гарячі дані (миттєвий доступ), теплі (рідкісні запити), холодні/архів.
Формати: колонкові (Parquet/ORC) для аналітики, компресія і партіонування за датою/ключем.
TTL/ILM: політика життя набору: `hot 7d → warm 90d → cold 365d → delete`.
Кеш-шар: Redis/Memcached з request coalescing, захист від miss-штормів.
Квоти та бюджети запитів: передбачувані ліміти на дорогі джоїни/скани.
yaml dataset: events_main lifecycle:
- phase: hot; duration: 7d; storage: nvme
- phase: warm; duration: 90d; storage: ssd; compress: zstd
- phase: cold; duration: 365d; storage: object; glacier: true
- phase: purge; duration: 0d7) Мережа та egress
Мінімізуйте міжрегіональний трафік: локальні копії та агрегація на краю.
CDN і кеші: origin-shield, розумні TTL, валідація/інвалідація.
Протоколи: бінарні (gRPC) для чатовості, компресія тільки там, де вигідно.
Дедуп подій і фільтрація на продюсері: «не веземо сміття».
8) Обсервабіліті і вартість SRE
Картки вартості телеметрії: '$/лог-ГБ','$/метрика-серія','$/траса'.
Семплювання та агрегація: tail-based sampling, downsampling метрик, ретеншн за важливістю (SLO-метрики - вище пріоритет).
Дедуп логів і «лог-санітарія»: заборона ПД, зниження фантомних полів, ліміти на розмір події.
9) CI/CD і тестові середовища
Ephemeral-стенди з авто-TTL, оточення «по PR».
Perf-smoke в PR: короткі прогони для ранньої оцінки «вартості запиту».
Кеш/артефакти: повторне використання контейнерів, компіляцій.
Гейти: білд/деплою відхиляється, якщо «ціна латентності »/RPS погіршилася відносно базлайну> X%.
10) Прогнозування, бюджети та аномалії
Forecasts: сезонність/тренд, події (кампанії, релізи), кореляція «фічі → вартість».
Бюджети за рівнем: team/product/feature/tenant; ескалації при 80/90/100%.
Аномалії: раптові піки по сервісу/регіону/аккаунту; автоматичний «бісект» і відкат прапора.
if forecast(month_end_cost) > budget0. 9 and variance ↑:
alert(team_owner)
suggest: rightsizing + RI/SP coverage + ILM tighten11) Закупівлі та комерція
RI/Savings Plans/Committed Use: покривайте стабільну базу; моніторьте покриття і «unutilized» відсотки.
Spot/Preemptible: фонові задачі і tolerant-воркфлоу; checkpointing і швидкий перезапуск.
Ліцензії та SaaS: матриця ROI, бенчмаркінг альтернатив, періодичний «vendor fitness review».
12) Багатоарендність і білінг
Partitioning by tenant: логічний/фізичний поділ, ліміти та квоти.
Tenant-aware лімітери/рейткепси: запобігають «галасливому сусіду».
Usage-моделі: білінг по подіям, RPS, обсягами даних; прозорі метрики для клієнтів.
13) Безпека та комплаєнс як фактор вартості
Крипто і зберігання: FPE/ключі - витрати на KMS/HSM; оптимізуйте частоту операцій.
Регуляторні копії: відокремлюйте «юридичні» ретеншени від операційних; архів дешевше «вічного теплого» зберігання.
Data minimization: менше даних - менше рахунків і ризиків.
14) Інженерні анти-патерни (дорого!)
Чатові API без батчів і кешування.
Безлімітні черги і необмежена паралельність - зростання латентності і рахунку.
Нульові TTL і гарячі ключі без коалессинга.
«Всевидячі» дашборди з мільйонами метрик серії.
Ресурси без тегів → «сірі» витрати без власника.
Відсутність ILM/TTL → вічне зростання сховища.
15) Інструменти та артефакти (vendor-neutral)
Каталог тегів (schema + лінтер в CI).
Cost-екстрактор (агрегація usage/billing, нормалізація в єдиний формат).
Дашборди unit economics (API-вартість, dataset-вартість, tenant-вартість).
Автоправки (rightsizer, RI/SP-рекомендатор, ILM-енфорсер).
Політики вартості (admission/OPA/Kyverno) і «червоні лінії» бюджету.
16) Міні-рецепти
Формула «ціни запиту» (HTTP)
request_cost = (cpu_ms $/cpu_ms) +
(mem_mb_s $/mb_s) +
(egress_mb $/mb) +
(db_calls $/call) +
(cache_ops $/op miss_penalty)Швидкий аудит сервісу
Топ-3 дорожчають ендпоінта по $/1000 req.
Hit/miss кешу і «штормові» ключі.
Списки ресурсів без тегів.
ILM і ретеншн датасетів.
Покриття RI/SP (%).
Економний retry-полісі
retry = min(3, floor(budget_ms / (base_timeout_ms 1. 5^attempt)))
jitter = uniform(0. 5..1. 5)17) Чек-лист архітектора вартості
1. Визначені unit-метрики ('$/req','$/GB-month','$/txn') і власники?
2. Тег-політика enforced? Ресурси без тегів блокуються?
3. Showback/chargeback і звіти по продуктах/фічам впроваджені?
4. Автоскейл і rightsizing налаштовані, headroom визначений?
5. Дані товані (hot/warm/cold), ILM/TTL застосовуються?
6. Egress і міжрегіональні потоки мінімізовані? CDN/кеші включені?
7. Обсервабіліті оптимізована (sampling, retention, downsampling)?
8. CI/CD гейти на регрес вартості і policy-checks активні?
9. Прогнози/бюджети/аналіз аномалій автоматизовані?
10. RI/SP/Spot-мікс покриває базові навантаження?
11. Для multi-tenant є квоти, лімітери та прозорі usage-метрики?
12. Документований FinOps runbook і план щомісячного cost-review?
Висновок
Архітектура вартості - це не «економія будь-якою ціною», а управління цінністю: скільки коштує кожна мілісекунда і який дохід вона приносить. Вбудовуючи вартість в архітектуру, процеси та інструменти (теги, політики, гейти, дашборди, ILM, автоскейл), ви отримуєте платформу, де рішення приймаються на основі метрик і економіки, а не інтуїції. Це прискорює продукт, знижує ризики і робить бізнес передбачувано прибутковим.