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

Prérequis

Ce guide suppose que vous avez :

• Un accès à vos métriques serveur (Prometheus, Grafana, CloudWatch, ou équivalent)
• Une connaissance basique des ressources système (CPU, RAM, disque)
• Idéalement, lu notre guide sur le diagnostic des performances Linux

Si vous n’avez pas encore de monitoring, consultez d’abord notre guide sur Prometheus.

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

Imaginez que vous gérez un parking. Chaque jour, vous comptez les places occupées. Si le parking se remplit de 10 places supplémentaires chaque semaine, vous savez exactement quand il sera complet — et quand il faudra construire un étage supplémentaire.

La planification des capacités (capacity planning), c’est exactement ça pour vos serveurs : mesurer ce qui est utilisé, observer la tendance, et prévoir quand ajouter des ressources.

La métaphore du réservoir

Pensez à chaque ressource (CPU, RAM, disque) comme un réservoir d’eau :

• Niveau actuel : combien est utilisé maintenant ?
• Débit d’entrée : à quelle vitesse ça se remplit ?
• Capacité totale : quand sera-t-il plein ?

Le capacity planning répond à cette question simple : dans combien de temps le réservoir débordera-t-il ?

Pourquoi c’est crucial ?

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 (littéralement “piste d’atterrissage”) est le temps qu’il vous reste avant qu’une ressource soit saturée, au rythme actuel de croissance.

Comment calculer le runway ?

La formule est simple :

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

Exemple concret

Situation : Un disque de 1 To, actuellement utilisé à 700 Go, qui grossit de 50 Go par mois.

Calcul :

• Capacité restante : 1000 Go - 700 Go = 300 Go
• Taux de croissance : 50 Go/mois
• Runway : 300 / 50 = 6 mois

Interprétation : Si rien ne change, le disque sera plein dans 6 mois. Il faut planifier son extension maintenant, pas dans 5 mois.

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%”

Attention aux pics

Le runway est calculé sur la croissance moyenne. Mais si vous avez des pics (Black Friday, campagne marketing), le runway réel peut être beaucoup plus court. Ajoutez toujours une marge de sécurité de 20-30%.

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

Le piège des inodes

Un disque peut avoir de l’espace libre mais être saturé en inodes (trop de fichiers). Pensez à surveiller les deux métriques. Commande : 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

Utilisez deux niveaux d’alerte pour chaque ressource :

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

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

Adaptez à votre contexte

Ces seuils sont des points de départ. Ajustez-les selon :

• La criticité : un serveur de production mérite des seuils plus bas
• La réactivité : si vous pouvez ajouter des ressources en 5 minutes (cloud), les seuils peuvent être plus hauts
• L’historique : observez vos pics réels et ajustez

Visualisation des seuils

Méthode pas à pas

Voici comment mettre en place le capacity planning pour votre infrastructure.

1. Établir une baseline (état actuel)

   Avant de prévoir l’avenir, mesurez le présent. Pour chaque ressource :

   # 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.

2. Collecter l’historique

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

   Si vous utilisez Prometheus, une requête comme celle-ci donne la croissance :

   rate(node_filesystem_size_bytes{mountpoint="/"}[30d])

   Sans outil, notez manuellement les valeurs chaque semaine pendant un mois.

3. 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.

4. Configurer les alertes

   Dans Prometheus/Alertmanager, créez des alertes sur les seuils :

   groups:
     - name: capacity
       rules:
         - alert: DiskSpaceWarning
           expr: (node_filesystem_avail_bytes / 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 / node_filesystem_size_bytes) * 100 < 15
           for: 5m
           labels:
             severity: critical
           annotations:
             summary: "URGENT: Disque {{ $labels.mountpoint }} à plus de 85%"

5. 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

6. 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

Tendance linéaire

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.

Saisonnalité

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.

Scénarios

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

Règle des 20-30%

Ajoutez toujours une marge de sécurité de 20-30% à vos prévisions. Les pics imprévus arrivent toujours au pire moment.

• Prévision : 800 Go dans 6 mois
• Avec marge 25% : 1000 Go → dimensionnez pour 1 To

Le cycle du capacity planning

Le capacity planning n’est pas un exercice ponctuel, c’est un cycle continu.

Fréquence des révisions

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 :

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

Le piège du 'Cloud auto-scale'

L’auto-scaling ne résout pas tout :

• Il a des limites (quotas, coûts)
• Il met du temps à réagir (5-10 minutes)
• Certaines ressources ne scalent pas (disque, base de données)

Le capacity planning reste nécessaire même avec l’auto-scaling.

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

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

Commencez simple

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

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

• 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)

• 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)

• 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

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

×

📖 Voir la documentation →