Fondamentaux du capacity planning¶

Pourquoi planifier la capacité, quelles ressources surveiller et quel vocabulaire utiliser.

Pourquoi planifier¶

Le capacity planning répond a une question simple : est-ce que mon infrastructure tiendra face à la demande future ? Sans réponse rigoureuse, deux scenarios extremes guettent l'équipe ops.

Conséquences business du sous-dimensionnement¶

Indisponibilite : saturation CPU, OOM killer, base de données qui refuse des connexions
Dégradation progressive : latences qui s'envolent avant la panne franche
Perte de revenus : chaque minute de downtime a un coût mesurable (e-commerce, SaaS)
Erosion de confiance : les SLA rates fragilisent les contrats et la relation client

Conséquences business du sur-dimensionnement¶

Factures cloud excessives : instances surdimensionnees actives 24h/24
Complexité inutile : clusters trop grands, maintenance alourdie
Capital immobilise : on-premise avec matériel sous-utilisé pendant des années
Fausse sécurité : marges énormes qui masquent des problèmes d'architecture

Sur-dimensionnement silencieux, sous-dimensionnement bruyant

Le sous-dimensionnement se voit immédiatement (alarmes, incidents, appels de nuit). Le sur-dimensionnement reste silencieux des mois — jusqu'à l'audit FinOps ou la coupure budgetaire. Les deux sont des échecs de planification.

Sous vs sur-dimensionnement¶

Dimension	Sous-dimensionnement	Sur-dimensionnement
Impact immédiat	Pannes, latences, SLA rates	Aucun visible
Impact financier	Perte de revenus, pénalités	Gaspillage budgetaire
Détection	Alertes, incidents	Audit, review trimestrielle
Correction	Urgente (scaling en crise)	Planifiee (rightsizing)
Risque residuel	Perte de données possible	Inertie organisationnelle

Ressources clés a surveiller¶

Quatre catégories de ressources constituent les goulots d'étranglement classiques.

graph TD
    A["Requete utilisateur"] --> B["CPU"]
    A --> C["RAM"]
    A --> D["Reseau"]
    B --> E["Saturation → latence"]
    C --> F["OOM → crash"]
    D --> G["Bandwidth → timeout"]
    E --> H["Stockage / IOPS"]
    F --> H
    G --> H
    H --> I["Incident"]

CPU¶

Indicateur principal : utilisation moyenne + percentile 95
Seuil de vigilance : 70 % en moyenne soutenue sur 5 minutes
Pieges : steal time (virtualisation), throttling (containers), single-thread bottleneck

RAM¶

Indicateur principal : mémoire disponible, swap utilisé
Seuil de vigilance : moins de 15 % de mémoire libre
Pieges : fragmentation, cache page agressif de Linux (pas un problème), fuites mémoire applicatives

Stockage et IOPS¶

Indicateur principal : utilisation disque (%), IOPS consommees, latence I/O (ms)
Seuil de vigilance : 80 % utilisation disque, latence > 10 ms sur SSD
Pieges : inodes epuises avant espace disque, RAID degradé qui plafonne les IOPS

Réseau¶

Indicateur principal : débit entrant/sortant, paquets perdus, latence RTT
Seuil de vigilance : 70 % de la bande passante nominale
Pieges : burst courts non captures par moyennes, egress cloud facturable

Vocabulaire essentiel¶

Terme	Définition
Capacity	Volume maximum qu'un système peut traiter sans dégradation
Demand	Charge réelle ou prévue que le système doit absorber
Headroom	Marge entre la demande actuelle et la capacité maximale
Saturation	État ou la ressource est a 100 % — les requêtes attendent ou échouent
Throughput	Nombre d'opérations traitees par unite de temps (req/s, MB/s)
Latency	Temps de réponse pour une opération individuelle
Utilization	Ratio demand / capacity exprime en pourcentage
Baseline	Mesure de référence établie sur une periode representative
Headroom cible	Marge réservée délibérément pour absorber les pics (ex : 30 %)

Loi de Little

Dans un système stable : L = λ × W — le nombre moyen de requêtes en cours (L) est egal au débit d'arrivee (λ) multiplié par le temps moyen de traitement (W). Doubler le temps de traitement double la file d'attente.

Points clés¶

Planifier la capacité est un processus continu, pas un événement annuel
Les quatre ressources (CPU, RAM, stockage, réseau) peuvent chacune devenir le goulot d'étranglement
Le vocabulaire précis (headroom, saturation, throughput) facilite la communication entre équipes
Chaque décision de dimensionnement a des conséquences business mesurables