FinOps et gestion budgétaire

Résumé succinct

1. on mesure la valeur et le coût unitaire (unit-economics),

2. nous mettons les budgets et les guardrails,

3. prédire la demande et planifier la capacité,

4. nous gérons les achats/rabais,

5. Nous changeons l'architecture et les processus pour SLO avec un minimum de TCO.

Rôles et responsabilités

Product/Business : objectifs de chiffre d'affaires/MAU/LTV, limites budgétaires.
FinOps : méthodologie, rapports, achats, signaux budgétaires.
Ingénierie/SRE : rightsizing, skate, cache/architecture, leviers opérationnels.
Data/Analytics : prévisions de charge et de coûts, anomalies.
Sécurité/Conformité : exigences de stockage/logs/DR qui affectent le TCO.

RACI : FinOps gère les processus et les rapports → les ingénieurs mettent en œuvre des changements économiques → l'entreprise approuve les budgets/priorités.

Métriques et économie unitaire

$/1000 RPS (ou $/1k événements/transactions) est la mesure de base du coût du service.
$/ms p95 - combien coûte le décalage de la queue de latence (important pour la conversion).
$/MAU, $/dépôt, $/joueur/mois - unités d'affaires.
TCO = compute + storage + network egress + managed-services + licences + main-d'œuvre.
Cost Coverage Ratio : part de la consommation « fermée » sur demande par les plans de commit.

Exemple : le service donne 60k RPS à 120 $/h → 2 $/1000 RPS· h. Toute optimisation est comparée à cette référence.

Tagging et transparence

Tags obligatoires : « bou », « product », « service », « owner », « region », « tier », « cost-center ».
Sans tags, nous ne créons ni ne prolongeons les ressources.

Showback/Chargeback : rapports hebdomadaires par équipe/produit liés à des mesures unitaires.
Anomalies : delta quotidien> X % et ressources « muettes » (0 RPS, il y a un coût).

Budgets, guardrails et alertes

Budget mensuel par service/produit + soft/hard guardrails.

• burn-rate diurne> plan de × (jours par mois/jours restants),
• egress/log-ingest> seuil,
• spot-déplacement> N % du temps,
• croissance des ressources « no man's ».
• Politiques : interdiction des ressources sans tags, auto-TTL, limites de classe de stockage.

Prévision des coûts

1. Pilotes : MAU, DAU, RPS par itinéraire, part de cache, saisonnalité/ivens.
2. Modèle : tendance de base + saisonnalité + scénarios (base/agressif).
3. Transfert en argent : profils de consommation par couches (edge/proxy/app/DB/loging).
4. Poser les étapes : tête haute 30 % pour les pics, réserve pour les DR/plans communs.

Cost_month ≈ Σ (RPS_route × $/1kRPS_route × часы) + egress + storage + managed

Achats et modes de consommation

Reserved/Savings/Committed Use (1-3 ans) - ferme une base stable (économie de 30-70 %).
Spot/Préemptible - CI/analytique/asynchrone, convoyeurs de données.
Mix : base - commit, pics - on-demand, fond/background - spot.
La règle est de 70/20/10: 70 % - commit, 20 % - élastique à la demande, 10 % - spot.

Leviers d'économie d'ingénierie (pas de perte de SLO)

Rightsizing : CPU 50-70 % point de travail, recommandations VPA, petites instances mieux rangées.
Auto-scaling sous SLO : HPA/KEDA par latency/lag/RPS et pas seulement par CPU.
Cache et CDN : clé de cache sans « bruit », échelle TTL, tiered-cache/origin-shield → egress↓, DB↓.
Réseau : Brotli/gzip, webp/avif, diff-API, keepalive, limitation des retraits (retry-budget).
Stockage : classes (chaud/chaud/froid), politiques de lifecycle, TTL sur les données temporaires.
Logs/métriques/tracés : sample, tail-based, stockage high-res 7-14 jours.
Architecture : gRPC/protobaf entre les services, batch/stream au lieu de chats, sélection OBD par profil (KV pour les lectures fréquentes).

Coût de fiabilité et DR

RTO/RPO → valeur : actif-actif vs actif-passif, backup à froid.
Calcul : combien coûte une minute d'inactivité vs combien coûte une réplique supplémentaire/région.
Politique : « nous payons pour la fiabilité si le risque est remboursé ».

Dashboards FinOps (ensemble minimum)

1. Présentation : par produit/service/région, tendances, prévisions jusqu'à la fin du mois.
2. Unité économique : $/1k RPS, $/ms p95, $/MAU (par semaine).
3. Egress/Storage : egress Go/$, répartition des classes de stockage.
4. Logging/Observability : ingest par source, % de logs utiles, coût des « queues » p99.
5. Commit Coverage : part de la consommation fermée, risque de sous-utilisation.
6. Anomalies : top spike et ressources « muettes ».

Processus et rituels

Week-end FinOps : top 10 des fuites, owner → action → ETA.
Monthly Cost Review : fait vs budget, efficacité des achats, révision des commits.
Pre-event Review : plan des pics (min-répliques, pools warm, cache, limites PSP).
Blameless post-mer sur les incidents de prix (fuite des loges, runaway autoscale).

Chèque d'implémentation

• Tagging rigoureux, showback/chargeback par équipe.
• Les mesures unitaires sont définies ($/1k RPS, $/ms p95, $/MAU).
• Les budgets/guardrails/alerties sont personnalisés.
• Les prévisions de coûts sont liées aux prévisions de trafic et de SLO.
• Les plans de commit et le portefeuille spot/on-demand sont équilibrés.
• Rightsizing et SLO-Skaling inclus (HPA/KEDA/VPA/CA).
• Cache/CDN/egress optimisé, lifecycle dans le stockage.
• Logs/métriques/tracés - sample et TTL.
• La politique de RTO/RPO et son coût sont fixés.
• Les examens hebdomadaires et mensuels fonctionnent.

Erreurs typiques

Pas d'économie unitaire → je discute « sur les sensations ».
Les ressources sans tags, les "no man'de l'environnement vivent depuis des mois.
Stockez tout en classe chaude sans lifecycle.
Logs comme « trou noir » - 100 % ingest, 5 % lecture.
Commit pour « tout » de suite → sous-utilisation et des amendes.
Auto-skale par CPU sans tenir compte de latency/lag → trop-payé ou la rupture de SLO.
DR excédentaire sans justification commerciale.

Mini-playbooks

1) Audit FinOps rapide « trois jours »

1. Coupe du top 10 des services et egress. 2) Activer lifecycle sur les objets « anciens ».
2. Coupez les logs bruyants/activez tail-based. 4) Entrez TTL stajings/preview.
3. Fixer $/1k RPS et objectifs à − de 15 %/mois.

2) − 25 % egress par semaine

1. Tiered-cache + origin-shield. 2) Traduction des images en webp/avif.
2. Diff-API et Brotli. 4) Réduire le taux de retri et activer la request-collapsing.

3) L'attaque « runaway autoscale »

1. Augmenter la stabilisation/cooldown, minReplicas au sommet.
2. Transfère une partie des fonds vers spot et batch de la fenêtre.
3. Chauffer les images (image pre-pull) et TLS/connexions.

4) Sous-utilisation des commits

1. Réassembler le portefeuille, transférer une partie de l'on-demand dans le commit.
2. Migrer les workloades appropriées sur le type ARM/autre.
3. Activer l'auto-parking dans les heures non travaillées.

Exemples d'artefacts

sql
SELECT product, service, date_trunc('week', usage_date) AS wk,
SUM(cost_usd) AS cost, SUM(rps) AS rps,
ROUND(SUM(cost_usd) / NULLIF(SUM(rps)/1000,0), 3) AS usd_per_1k_rps
FROM finops_daily
GROUP BY 1,2,3
ORDER BY 3 DESC;

rego package finops deny[msg] {
input. resource. tags. owner == ""
msg:= "resource without owner tag"
}
deny[msg] {
input. resource. env == "dev"
input. resource. ttl == ""
msg:= "dev resource without TTL"
}

Spécificité pour iGaming/fintech

Pics (matchs/tournois) : soulever minReplicas/minNodes à l'avance, réchauffer CDN/TLS/caches, itinéraires gris pour les bots ; headroom point sur les endpoints chauds (lobby/catalogues/fides de match).
Paiements/PSP : comptabilisation des quotas/valeur par les fournisseurs, egress pool séparé et idempotence → moins de prises.
Antifrod/AML : contrôle en plusieurs étapes (chèque grise bon marché sur le bord → scoring coûteux seulement si nécessaire).
Fournisseurs de contenu : Cache CDN, limites de fréquence de rafraîchissement, renégociation des contrats aux grands ivens.

Résultat

Un FinOps efficace n'est pas de « réduire les coûts », mais de les gérer en fonction de la vitesse du produit et du SLO.
Gardez un coût unitaire transparent, construisez des budgets et des guardrails, combinez vos achats avec des leviers d'ingénierie, automatisez vos économies et faites régulièrement une revue des coûts. Ainsi, la plate-forme restera rapide, durable et rentable, même au sommet de la croissance.