Gestion des capacités : Anticiper la croissance de vos serveurs

Votre disque sera plein dans combien de temps ? Si vous ne savez pas répondre à cette question, vous risquez une panne à 3h du matin. Le capacity planning vous permet d'anticiper les besoins en ressources avant d'atteindre la saturation, et d'éviter le gaspillage en ne surdimensionnant pas inutilement.

Ce guide vous apprend à :

Mesurer votre consommation actuelle de CPU, RAM, disque et réseau
Calculer le runway (temps avant saturation) pour chaque ressource
Prévoir la croissance sur 3, 6 et 12 mois
Définir des seuils d'alerte pour agir au bon moment

Qu'est-ce que la planification des capacités ?

La planification des capacités (capacity planning) est une méthode de mesure : on relève périodiquement la consommation d'une ressource, on calcule la pente de cette consommation dans le temps, puis on projette cette pente jusqu'à la limite physique de la ressource. Le résultat est une date, pas un pourcentage.

Trois grandeurs suffisent pour n'importe quelle ressource, qu'il s'agisse d'un système de fichiers, d'un pool mémoire ou d'un nombre maximum de connexions :

La capacité totale : la limite dure, celle au-delà de laquelle le service casse
L'utilisation actuelle : la mesure du jour, relevée par df, free ou une requête Prometheus
Le taux de croissance : l'écart entre deux mesures espacées, ramené à une unité de temps

Ces trois valeurs se combinent en une seule information exploitable, le runway, détaillé juste après. Toute la démarche consiste à les tenir à jour et à recalculer la projection à intervalle régulier.

Pourquoi c'est crucial ?

L'absence de planification ne se traduit pas seulement par des pannes : elle coûte aussi cher dans l'autre sens, en matériel acheté pour rien. Les deux tableaux ci-dessous se lisent en vis-à-vis, le premier décrivant ce qu'on subit, le second ce qu'on obtient en échange de quelques minutes de mesure par mois.

Sans capacity planning, vous subissez les événements :

Situation	Ce qui se passe	Conséquence
Pas de mesures	On découvre que le disque est plein	Panne à 3h du matin
Réaction en urgence	On provisionne dans la panique	Mauvais choix, surcoût
Surdimensionnement "au cas où"	On paie 10 serveurs pour en utiliser 3	Budget gaspillé
Sous-dimensionnement	Le site rame pendant les soldes	Clients mécontents, perte de CA

Avec le capacity planning, vous anticipez :

Action	Résultat
Mesurer régulièrement	On sait où on en est
Calculer le runway	On sait quand agir
Définir des seuils	On est alerté à temps
Prévoir la croissance	On budgète correctement

Le concept clé : le runway

Le runway est le temps qu'il vous reste avant qu'une ressource soit saturée, au rythme actuel de croissance. C'est une durée, exprimée en jours ou en mois, et non un pourcentage d'occupation.

Comment calculer le runway ?

Le calcul se réduit à une division : l'espace qui reste, divisé par la vitesse à laquelle il se consomme. Toute la difficulté porte sur le taux de croissance, qui n'est jamais fourni directement par un outil et doit être dérivé de deux mesures espacées dans le temps.

Runway = (Capacité totale - Utilisation actuelle) / Taux de croissance

Une seule règle à respecter : les trois valeurs doivent partager la même unité. Mélanger des Go et des Gio, ou un taux quotidien avec une capacité mensuelle, produit un runway faux d'un facteur qui passe inaperçu jusqu'à la panne.

Pourquoi le runway est-il si important ?

Le runway transforme une métrique technique ("700 Go utilisés") en une information actionnable ("il nous reste 6 mois"). C'est ce qui permet de :

Planifier : budgéter l'achat de disques ou l'upgrade cloud
Prioriser : un runway de 2 semaines est plus urgent qu'un runway de 2 ans
Communiquer : "il faut commander avant mars" plutôt que "le disque est à 70%"

Les 4 ressources à planifier

Le capacity planning s'applique à toutes les ressources de votre infrastructure. Voici les principales et leurs spécificités.

1. CPU (processeur)

Le CPU est la ressource la plus "élastique" : si vous manquez de puissance de calcul, les traitements ralentissent mais continuent généralement de fonctionner.

Métrique	Ce qu'elle mesure	Comment l'obtenir
Utilisation moyenne	% du temps où le CPU travaille	`mpstat`, Prometheus
Utilisation P95	Pic d'utilisation (95ème percentile)	Grafana, CloudWatch
Load average	Processus en attente du CPU	`uptime`

Runway CPU : Moins critique car l'auto-scaling peut souvent résoudre le problème. Surveillez surtout les pics (P95 > 80%).

2. Mémoire (RAM)

La RAM est plus critique que le CPU : quand elle est pleine, Linux utilise le swap (très lent) ou tue des processus (OOM-Killer).

Métrique	Ce qu'elle mesure	Comment l'obtenir
Mémoire disponible	RAM réellement utilisable	`free -h` (colonne "available")
Swap utilisé	Mémoire débordant sur le disque	`free -h` (ligne "Swap")
Croissance mémoire	Tendance d'utilisation	Prometheus/Grafana

Runway RAM : Critique si le swap est actif. Un runway < 1 mois nécessite une action immédiate.

3. Stockage (disque)

Le disque est souvent la ressource la plus prévisible (croissance linéaire des logs, données, etc.) mais aussi la plus dangereuse : un disque plein = panne totale.

Métrique	Ce qu'elle mesure	Comment l'obtenir
Espace utilisé	% du disque occupé	`df -h`
Croissance quotidienne	Go ajoutés par jour	Prometheus, scripts
Inodes utilisés	Nombre de fichiers	`df -i`

Runway disque : Calculable précisément. C'est souvent la ressource la plus facile à prévoir.

4. Réseau (bande passante)

Le réseau est rarement le goulot d'étranglement, mais quand il l'est, c'est brutal : connexions refusées, timeouts en cascade.

Métrique	Ce qu'elle mesure	Comment l'obtenir
Bande passante utilisée	Mbit/s entrant et sortant	`iftop`, CloudWatch
Connexions actives	Nombre de connexions TCP	`ss -s`
Erreurs/dropped	Paquets perdus	`ip -s link`

Runway réseau : Difficile à prévoir car très variable. Surveillez surtout les pics et les erreurs.

Définir les bons seuils d'alerte

Les seuils d'alerte vous permettent d'être prévenu avant la saturation. Mais comment les choisir ?

Le principe des deux seuils

Un seuil unique force un choix impossible : trop bas, il déclenche des alertes sans objet et l'équipe finit par les ignorer ; trop haut, il prévient quand il est déjà trop tard pour commander du matériel. Deux seuils séparent les deux besoins, parce qu'ils déclenchent deux actions différentes.

Le premier ouvre une fenêtre de planification, le second exige une intervention immédiate. Cette distinction doit se retrouver dans le routage : un warning va dans un canal consulté aux heures ouvrées, un critical réveille quelqu'un.

Seuil	Signification	Action
Seuil d'alerte (warning)	On approche de la limite	Planifier l'ajout de ressources
Seuil critique (action)	On est proche de la saturation	Agir immédiatement

Seuils recommandés par ressource

Les valeurs ci-dessous ne sortent pas d'une norme : elles viennent du temps de réaction que chaque ressource vous laisse une fois le seuil franchi. Le CPU tolère des dépassements courts sans casser, la mémoire beaucoup moins, et un système de fichiers plein arrête net les écritures.

Lisez donc la dernière colonne avant les chiffres : c'est elle qui vous dira s'il faut les remonter ou les descendre chez vous. Un serveur qu'on redimensionne en trois clics chez un fournisseur cloud supporte des seuils plus hauts qu'une machine physique dont le disque se commande trois semaines à l'avance.

Ressource	Seuil d'alerte	Seuil critique	Pourquoi ces valeurs ?
CPU	> 70% (P95)	> 85%	Le CPU peut absorber des pics courts
RAM	> 75%	> 85%	Laisser de la marge avant le swap
Disque	> 75%	> 85%	Les écritures ralentissent quand c'est plein
Connexions	> 60% max	> 80% max	Les nouvelles connexions seront refusées

Visualisation des seuils

Le schéma ci-dessous découpe la plage d'occupation d'une ressource en quatre zones. Ce qu'il faut y lire n'est pas la position des traits, mais la largeur de la bande comprise entre le seuil d'alerte et le seuil critique : c'est votre marge de manœuvre réelle, celle dont vous disposez pour agir sans être en urgence.

Sur une ressource à croissance rapide, cette bande de 10 points peut se franchir en une nuit. C'est le signe qu'il faut abaisser le seuil d'alerte plutôt que d'accélérer la procédure d'intervention.

Visualisation des seuils d'alerte : zone de confort, seuil d'alerte à 75%, seuil critique à 85%, saturation à 100%

Méthode pas à pas

Voici comment mettre en place le capacity planning pour votre infrastructure. Les six étapes suivent l'ordre logique des données : on mesure d'abord un point, puis une tendance, avant de pouvoir projeter quoi que ce soit. Sauter la deuxième étape est l'erreur la plus commune, elle donne un runway calculé sur une croissance devinée.

Comptez au minimum un mois entre l'étape 1 et l'étape 3 sur une infrastructure sans historique de métriques. C'est le temps d'accumulation nécessaire, et il ne se rattrape pas.

Établir une baseline (état actuel)

Avant de prévoir l'avenir, mesurez le présent. Pour chaque ressource :
Fenêtre de terminal
```
# CPU : utilisation moyenne
mpstat 1 10 | tail -1

# RAM : mémoire disponible
free -h

# Disque : espace utilisé
df -h

# Réseau : connexions actives
ss -s
```
Notez ces valeurs et leur date. C'est votre point de référence.
Collecter l'historique

Pour calculer le runway, vous avez besoin de la tendance. Idéalement, 30 jours de données minimum.

Avec Prometheus, mesurez la pente de l'espace disponible, pas de la taille du système de fichiers : node_filesystem_size_bytes est une constante, sa dérivée vaut zéro. La fonction deriv renvoie la variation par seconde, ici multipliée par 86 400 pour obtenir des octets par jour (une valeur négative signifie que l'espace se consomme) :
```
deriv(node_filesystem_avail_bytes{mountpoint="/",fstype!~"tmpfs|overlay"}[7d]) * 86400
```
Prometheus sait aussi projeter directement. predict_linear extrapole la même pente sur une durée donnée, ici 30 jours ; la requête ci-dessous liste les points de montage qui seront pleins d'ici là :
```
predict_linear(node_filesystem_avail_bytes{mountpoint="/",fstype!~"tmpfs|overlay"}[7d], 30 * 24 * 3600) < 0
```
Sans outil, notez manuellement les valeurs chaque semaine pendant un mois.
Calculer le runway pour chaque ressource

Appliquez la formule pour chaque ressource critique :

Ressource Capacité totale Utilisé Croissance/mois Runway
Disque / 500 Go 350 Go 30 Go 5 mois
Disque /data 2 To 1.8 To 100 Go 2 mois ⚠️
RAM 16 Go 12 Go 0.5 Go 8 mois

Priorisez : le disque /data avec 2 mois de runway nécessite une action urgente.

Ressource	Capacité totale	Utilisé	Croissance/mois	Runway
Disque /	500 Go	350 Go	30 Go	5 mois
Disque /data	2 To	1.8 To	100 Go	2 mois ⚠️
RAM	16 Go	12 Go	0.5 Go	8 mois

Configurer les alertes

Dans Prometheus/Alertmanager, créez des alertes sur les seuils. Le filtre fstype n'est pas décoratif : sans lui, l'alerte se déclenche sur les tmpfs et les couches overlay des conteneurs, qui sont pleins par construction et noieraient les vraies alertes.

groups:
  - name: capacity
    rules:
      - alert: DiskSpaceWarning
        expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"} / node_filesystem_size_bytes) * 100 < 25
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Disque {{ $labels.mountpoint }} à plus de 75%"

      - alert: DiskSpaceCritical
        expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"} / node_filesystem_size_bytes) * 100 < 15
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "URGENT: Disque {{ $labels.mountpoint }} à plus de 85%"

Le for: 5m évite une alerte sur un pic de quelques secondes : la condition doit rester vraie pendant cinq minutes avant que l'alerte passe en firing.

Planifier les actions

Pour chaque ressource avec un runway court :
- Cloud : planifier l'upgrade ou l'auto-scaling
- On-premise : commander le matériel (délai de livraison !)
- Budget : demander la validation financière
Réviser mensuellement

Chaque mois, vérifiez :
- Les prévisions étaient-elles justes ?
- Y a-t-il eu des événements imprévus ?
- Faut-il ajuster les modèles ?
Documentez les écarts pour améliorer vos prévisions.

Prévoir la croissance future

Le runway vous dit où vous en êtes. La prévision (forecasting) vous dit où vous allez.

Les 3 méthodes de prévision

Les trois méthodes ci-dessous ne s'opposent pas, elles se choisissent selon la quantité d'historique dont vous disposez. La tendance linéaire demande un mois de données, la saisonnalité une année complète, les scénarios aucune donnée du tout puisqu'ils reposent sur des hypothèses.

Dans la pratique, on commence par la tendance linéaire parce qu'elle est immédiatement calculable, et on bascule vers les deux autres quand elle se trompe : trop optimiste avant les pics récurrents, trop rigide au lancement d'un nouveau service.

Principe : La croissance future sera comme la croissance passée.

Quand l'utiliser : Croissance régulière, pas de changements majeurs prévus.

Calcul :

Utilisation dans N mois = Utilisation actuelle + (Croissance mensuelle × N)

Exemple : 700 Go aujourd'hui, +50 Go/mois → 1000 Go dans 6 mois.

Limite : Ne capture pas les accélérations ou ralentissements.

Principe : Certaines périodes sont plus chargées que d'autres (Noël, soldes, fin de mois).

Quand l'utiliser : Patterns répétitifs dans vos données.

Calcul : Comparer les mêmes périodes d'une année sur l'autre.

Croissance attendue = Croissance même période l'an dernier × (1 + Taux de croissance annuel)

Exemple : Si Black Friday 2024 a généré +200 Go de logs, prévoir +240 Go en 2025 (croissance 20%).

Limite : Nécessite un historique d'au moins 1 an.

Principe : Prévoir plusieurs futurs possibles.

Quand l'utiliser : Incertitude élevée, nouveaux projets.

Calcul : Définir 3 scénarios :

Scénario	Hypothèse	Croissance
Optimiste	Tout se passe bien	+10%/mois
Réaliste	Croissance normale	+20%/mois
Pessimiste	Forte adoption	+40%/mois

Exemple : Lancement d'une nouvelle fonctionnalité → scénario pessimiste pour le dimensionnement initial.

Avantage : Vous êtes préparé quel que soit l'avenir.

Le graphique de prévision

Représenter les trois scénarios sur le même graphique rend visible ce qu'un tableau de chiffres cache : l'écart entre les courbes s'élargit avec le temps. À trois mois, les trois hypothèses donnent des valeurs voisines et le choix importe peu ; à douze mois, elles peuvent différer d'un facteur trois.

C'est la lecture utile de ce schéma : plus votre horizon de prévision est lointain, plus le scénario retenu pèse sur la décision d'achat. Au-delà de six mois, dimensionnez sur la courbe haute et révisez plutôt que de miser sur la courbe médiane.

Graphique de prévision avec 3 scénarios : optimiste, réaliste et pessimiste divergeant à partir de l'état actuel

Le cycle du capacity planning

Le capacity planning n'est pas un exercice ponctuel, c'est un cycle continu. La raison tient à la nature des données : une prévision se fonde sur un taux de croissance mesuré dans le passé, et ce taux change dès qu'un nouveau service arrive, qu'un lot de logs devient plus verbeux ou qu'un client double son usage.

L'étape de révision est celle qu'on saute en premier, et c'est celle qui rend les trois autres utiles. Comparer la prévision du mois dernier à la mesure d'aujourd'hui vous donne l'erreur de votre modèle, donc la marge à appliquer au suivant.

Le cycle du capacity planning : Mesurer, Prévoir, Planifier, Réviser en boucle continue

Fréquence des révisions

Chaque étape du cycle n'a pas la même périodicité ni le même public. Le rythme ci-dessous est calé sur les délais d'action : inutile de recalculer un runway toutes les semaines si la commande de matériel prend un mois, et inutile de convoquer le management sur une donnée qui bouge tous les jours.

La colonne de droite compte autant que les deux autres. Une revue de capacité qui reste entre gens de l'infrastructure rate systématiquement les pics annoncés par le métier, campagne commerciale ou migration d'un gros client.

Activité	Fréquence	Qui
Vérifier les alertes	Quotidien	Ops/SRE
Mettre à jour les dashboards	Hebdomadaire	Ops/SRE
Calculer les runways	Mensuel	Ops/SRE + Tech Lead
Réviser les prévisions	Trimestriel	Équipe + Management
Planifier le budget	Annuel	Management + Finance

Anti-patterns à éviter

Voici les erreurs les plus courantes en capacity planning. Elles se répartissent en deux familles : des erreurs de méthode (dimensionner sur la moyenne, ne jamais réviser) et des erreurs d'organisation (silos, métier non informé). Les secondes coûtent généralement plus cher que les premières, parce qu'aucun outil ne les corrige.

Anti-pattern	Pourquoi c'est un problème	Solution
Pas de mesures	On ne sait pas où on en est	Installer un monitoring de base
Prévisions fixes	On ne corrige jamais les erreurs	Réviser mensuellement
Marge zéro	Le moindre pic cause une panne	Toujours 20-30% de marge
Oublier les pics	On dimensionne sur la moyenne	Utiliser P95, pas la moyenne
Cloud = infini	On oublie les quotas et coûts	Surveiller les limites cloud
Silos d'équipes	Chacun planifie de son côté	Réunion capacity mensuelle
Le métier non informé	L'IT découvre la campagne le jour J	Communication proactive
Provisionnement tardif	On commande quand c'est déjà plein	Agir au seuil d'alerte, pas critique

Tester la capacité réelle : le load testing

Calculer le runway c'est bien, mais tester la capacité réelle c'est mieux. Le load testing vérifie que vos prévisions sont justes.

Les 3 types de tests

Les trois tests ci-dessous se distinguent par la charge appliquée, pas par l'outil utilisé : un même hey ou un même k6 les exécute tous les trois, seuls les paramètres changent. Ce qui change surtout, c'est ce que vous cherchez à observer.

Le load test valide une hypothèse (« la plateforme tient 500 requêtes par seconde »). Le stress test cherche au contraire l'échec, en montant jusqu'à ce que quelque chose casse, pour savoir quoi casse en premier : le CPU, la base de données ou le pool de connexions. Le spike test vérifie la vitesse de retour à la normale après un pic, seul moyen de mesurer réellement le temps de réaction d'un auto-scaling.

Type de test	Objectif	Quand l'utiliser
Load test	Vérifier le comportement sous charge normale	Régulièrement (mensuel)
Stress test	Trouver le point de rupture	Avant les événements majeurs
Spike test	Tester la réaction aux pics soudains	Après des changements d'architecture

Pas besoin d'outils sophistiqués pour commencer. Un simple script avec ab (Apache Bench) ou hey suffit :

# Envoyer 1000 requêtes avec 50 connexions simultanées
hey -n 1000 -c 50 https://votre-site.com/

Checklist de mise en place

Les trois niveaux ci-dessous se franchissent dans l'ordre, chacun n'ayant de sens qu'une fois le précédent en place. Ne cherchez pas à démarrer au niveau 2 : un modèle de prévision construit sur trois semaines d'historique produit des chiffres précis et faux.

Niveau 1 : Minimum viable (1-2 jours de travail)

Ce niveau ne prévoit rien : il vous rend simplement capable de répondre à une question sur l'état actuel sans vous connecter aux serveurs. C'est déjà l'essentiel du bénéfice, parce qu'il supprime les pannes par disque plein, de loin les plus fréquentes.

Un seul runway suffit ici, celui du système de fichiers principal. Le calculer une fois à la main vous apprendra plus que n'importe quel tableau de bord automatique.

Métriques CPU, RAM, disque collectées
Dashboard de capacity visible
Alertes sur les seuils critiques (disque > 85%, RAM > 85%)
Runway calculé pour le disque principal
Revue mensuelle planifiée dans l'agenda

Niveau 2 : Mature (1-2 semaines)

Le passage au niveau 2 se joue sur la rétention des métriques, et c'est un point de configuration à vérifier avant tout le reste : Prometheus purge par défaut ses données au bout de quinze jours, ce qui rend toute prévision trimestrielle impossible. Sans stockage longue durée, les cases suivantes ne peuvent pas être cochées.

L'autre marqueur du niveau 2 est budgétaire. Relier une consommation technique à un coût mensuel transforme le capacity planning en argument recevable hors de l'équipe infrastructure.

Historique des métriques conservé (3+ mois)
Runway calculé pour toutes les ressources critiques
Modèle de prévision formalisé (même simple)
Budget infra connu et suivi
Communication régulière avec le métier
Load testing annuel

Niveau 3 : Avancé (effort continu)

Le niveau 3 change de granularité : on ne prévoit plus par serveur mais par service, ce qui suppose d'attribuer chaque consommation à une application identifiée. Sur une infrastructure mutualisée, c'est le travail le plus long, et il repose entièrement sur la qualité de vos labels ou de vos étiquettes cloud.

Le post-mortem après pic est la case la plus rentable de cette liste. Confronter la prévision faite avant l'événement à la consommation réellement observée est la seule mesure objective de la justesse de votre modèle.

Prévisions par service/application
Scénarios documentés (optimiste/réaliste/pessimiste)
Automatisation des rapports
Intégration avec le processus budgétaire
Simulation de pics avant événements majeurs
Post-mortem après chaque pic (Black Friday, etc.)

Dépannage

Les difficultés du capacity planning ne sont presque jamais techniques : elles viennent d'un modèle mal calibré ou d'une organisation qui n'exploite pas les alertes produites. Les cinq lignes ci-dessous couvrent les situations rencontrées les plus souvent dans les premiers mois de mise en place.

Une remarque sur la troisième : un disque qui se remplit malgré des alertes correctement configurées indique une croissance non linéaire, typiquement un service qui part en boucle de logs. Aucun seuil d'occupation ne l'attrape à temps, seule une alerte sur le taux de croissance le fait.

Symptôme	Cause probable	Solution
Alertes constantes	Seuils trop bas	Ajuster les seuils à votre contexte
Prévisions toujours fausses	Pas assez d'historique	Attendre 3 mois, noter les événements
Disque plein malgré les alertes	Croissance soudaine (logs, attaque)	Alerter aussi sur le taux de croissance
Budget dépassé	Prévisions sous-estimées	Utiliser le scénario pessimiste
Équipe non réactive aux alertes	Alert fatigue	Réduire le nombre d'alertes, prioriser

À retenir

Le runway transforme une métrique technique en information actionnable : "il reste X mois".
Deux seuils d'alerte : warning (planifier) et critical (agir).
20-30% de marge de sécurité sur toutes vos prévisions.
Le disque est souvent le plus prévisible mais aussi le plus dangereux (disque plein = panne).
Révisez mensuellement vos prévisions pour les améliorer.
Communiquez avec le métier : ils savent quand arrivent les pics.

Prochaines étapes

Diagnostic des performances Linux Identifiez rapidement les goulots d'étranglement CPU, mémoire, disque et réseau

Mettre en place Prometheus Collectez les métriques nécessaires au capacity planning

Haute disponibilité Assurez la continuité de service même en cas de panne

SLO et Error Budget Définissez des objectifs de fiabilité mesurables