9.7 Planification de capacité et prévision de demande

Vue d’ensemble et motivation

Chaque système a un plafond. Les cœurs de calcul s’épuisent, les disques se remplissent, les bassins de connexion s’épuisent, et une file d’attente qui était vide au petit-déjeuner déborde au déjeuner. La planification de capacité est la discipline d’assortir l’approvisionnement de calcul, stockage, et réseau à la demande que vous attendez, avec assez de marge pour qu’un jour normal ne s’approche jamais du plafond et qu’un mauvais jour échoue gracieusement plutôt que catastrophiquement. La prévision de demande est l’autre moitié : prédire combien de charge arrive, quand, et pourquoi, pour que l’approvisionnement arrive avant la demande plutôt qu’après la panne.

Ce chapitre se trouve entre deux voisins et reste complémentaire aux deux. Le chapitre 3.5 couvre l’évolutivité comme propriété architecturale : comment un système est construit pour pouvoir grandir du tout, à travers l’absence d’état, le partitionnement, et la mise à l’échelle horizontale. Le chapitre 9.1 couvre l’ingénierie de fiabilité de site (SRE), qui fixe les cibles de fiabilité que la capacité doit défendre. Ici, vous prenez l’architecture comme donnée et les cibles comme fixées, puis répondez à une question quantitative : combien de tout devez-vous acheter, réserver, et garder en réserve pour que le système respecte ses objectifs de niveau de service (SLO, les cibles de fiabilité du chapitre 9.1) à travers la demande prévue et les pics que vous n’avez pas prévus. La mise à l’échelle automatique et l’ingénierie de performance (chapitre 2.16) sont des outils que vous utilisez ici, mais ce ne sont pas des substituts à la planification, et les confondre avec la planification est une erreur commune et coûteuse.

Pour les grandes équipes, la capacité cesse d’être une feuille de calcul qu’un ingénieur garde et devient un modèle partagé dont de nombreux services dépendent. Une plateforme de centaines de services partage des bassins finis : connexions de base de données, débit de courtier de messages, quotas de compte cloud, sortie réseau. La croissance d’une équipe peut affamer celle d’une autre si personne ne tient l’image entière. Dans les contextes d’entreprise, les erreurs de capacité se manifestent soit comme des millions gaspillés en infrastructure inactive soit comme des pannes embarrassantes pendant les moments exacts qui comptent le plus. Dans le gouvernement, les enjeux s’aiguisent davantage. Une échéance fiscale, une fenêtre d’inscription aux prestations, ou une campagne d’inscription de santé publique concentre la demande d’une nation en quelques heures, la charge est légalement mandatée plutôt qu’optionnelle, et le public se souvient d’un site qui a plié sous une échéance qu’il s’est fixée lui-même. La planification de capacité est comment vous tenez ces promesses.

Principes clés

Planifiez la capacité pour la demande prévue plus une marge délibérée ; ne fonctionnez pas près de la saturation.
Séparez la planification de capacité, la mise à l’échelle automatique, et l’ingénierie de performance ; chacune résout un problème différent.
Prévoyez depuis la tendance, la saisonnalité, les événements connus, et la croissance d’affaires, pas seulement depuis la semaine dernière.
Trouvez vos vraies limites par le test de charge et le référencement, pas en devinant ou en attendant que la production les trouve.
Traitez la latence près de la saturation comme une falaise, pas une pente ; les cibles d’utilisation existent à cause de la théorie des files d’attente.
Connaissez vos goulots d’étranglement durs : les bassins de connexion, les quotas, et les points uniques ne se mettent pas à l’échelle automatique.
Équilibrez le coût contre la fiabilité délibérément, et révisez la capacité selon une cadence régulière plutôt qu’après un incident.

Recommandations

Séparer la planification de capacité, la mise à l’échelle automatique, et l’ingénierie de performance

Ces trois disciplines sont souvent confondues, et les confondre mène à acheter le mauvais correctif. La planification de capacité est la question à moyen et long terme de combien de ressource totale vous devez approvisionner, réserver, et budgéter sur des semaines, trimestres, et années. La mise à l’échelle automatique est l’ajustement à court terme et automatisé des ressources pour suivre la charge minute par minute : elle vous déplace à l’intérieur de l’enveloppe que la planification a approvisionnée, mais elle ne peut pas conjurer un quota que vous n’avez jamais réservé, réchauffer une base de données froide, ou mettre à l’échelle un composant qui ne fonctionne qu’en instance unique. L’ingénierie de performance (chapitre 2.16) change la forme du problème en rendant chaque unité de travail moins chère, pour que le même matériel serve plus de demande.

La distinction est pratique. Quand un système est lent sous charge, la mise à l’échelle automatique ajoute des instances, l’ingénierie de performance rend chaque instance plus rapide, et la planification de capacité décide si vous pouvez vous permettre les instances et si la base de données en aval peut accepter les connexions qu’elles ouvriront. Une équipe qui atteint seulement pour la mise à l’échelle automatique frappera une limite dure qu’elle n’a jamais planifiée ; une équipe qui atteint seulement pour l’ingénierie de performance optimisera le code pendant que le quota de compte la plafonne quand même. Vous avez besoin des trois, et vous avez besoin de savoir laquelle un problème donné appelle.

Prévoir la demande depuis la tendance, la saisonnalité, les événements, et la croissance d’affaires

Une prévision construite sur la moyenne de la semaine dernière manquera chaque moment intéressant. Construisez la vôtre depuis quatre composantes distinctes. La tendance est la direction sous-jacente : la demande grandit-elle, est-elle plate, ou rétrécit-elle, et à quelle vitesse ? La saisonnalité est le motif répétitif : le pic quotidien à 9 heures, l’accalmie hebdomadaire les week-ends, la poussée annuelle avant les fêtes. Les pics pilotés par événement sont les concentrations ponctuelles : un lancement de produit, une campagne marketing, une mention télévisée, une échéance de dépôt gouvernemental. La croissance pilotée par les affaires est la demande que votre propre feuille de route crée : un nouveau marché, l’intégration d’un grand client, une fonctionnalité qui triple les requêtes par session.

Utilisez la bonne technique pour chacune. Une série temporelle de charge historique, décomposée en tendance et saisonnalité, vous donne un référentiel défendable pour la demande stable. Les événements ne peuvent pas être extrapolés depuis l’historique parce qu’ils n’ont pas d’historique ; ils viennent de parler à l’affaire, lire la feuille de route, et demander au marketing et au produit ce qu’ils sont sur le point de lancer. Les échecs de capacité les plus dommageables sont presque toujours des événements dont l’ingénierie n’a jamais entendu parler. Le remède est organisationnel, pas statistique : un canal permanent où le produit, le marketing, et les opérations déclarent les pics à venir assez à l’avance pour approvisionner contre eux.

Fixer des cibles d’utilisation et respecter la falaise de la théorie des files d’attente

L’instinct de faire fonctionner l’infrastructure « chaude » à 90 % d’utilisation pour économiser de l’argent est un piège, et la raison est la théorie des files d’attente, couverte en profondeur au chapitre 11.3. À mesure qu’une ressource approche de la pleine utilisation, le temps d’attente ne monte pas doucement et linéairement ; il explose. Un serveur à 50 % d’utilisation a une marge confortable ; le même serveur à 90 % peut voir une latence plusieurs fois pire, et à 95 % la file peut s’emballer entièrement. La latence près de la saturation est une falaise, pas une pente, et vos utilisateurs ressentent la falaise comme des délais d’expiration, des nouvelles tentatives, et des erreurs bien avant que la ressource ne soit techniquement « pleine ».

C’est pourquoi les planificateurs de capacité fixent des cibles d’utilisation bien en dessous de 100 %, communément dans la plage de 50 % à 70 % pour les services sensibles à la latence, plus élevées pour le travail par lots orienté débit qui tolère la mise en file d’attente. La cible n’est pas du gaspillage ; c’est le prix d’une latence prévisible. Choisissez la cible depuis le SLO : si votre objectif de latence est strict, votre plafond d’utilisation est plus bas, parce que la latence de queue que la mise en file d’attente produit est exactement ce qui fait exploser un SLO. La marge et la marge de sécurité sont la même idée depuis deux directions. La marge est l’écart entre la charge normale et la capacité ; la marge de sécurité est cet écart exprimé comme une assurance contre une prévision qui tourne haut, un basculement qui concentre la charge, ou un pic que vous n’avez pas vu venir.

Trouver les vraies limites à travers le test de charge et le référencement

Vous ne pouvez pas planifier autour d’une limite que vous n’avez pas mesurée. Le test de charge dirige du trafic synthétique ou rejoué vers un système pour observer comment la latence, le débit, et le taux d’erreur se comportent à mesure que la charge monte, et où ils cassent. Le référencement mesure un composant isolément pour établir son plafond : requêtes par seconde par instance, écritures par seconde par nœud de base de données, messages par seconde par partition de courtier. Ensemble, ils vous disent les deux chiffres dont la planification a besoin : combien une unité de capacité livre, et où tout le système tombe.

Exécutez plusieurs tests distincts. Un test de charge monte jusqu’au pic attendu et confirme que le SLO tient avec de la marge. Un test de stress pousse au-delà du point de rupture pour voir comment le système échoue, parce qu’un système qui se dégrade gracieusement est très différent d’un qui s’effondre. Un test d’endurance maintient une charge modérée pendant des heures ou des jours pour exposer les fuites de mémoire, l’épuisement de connexion, et les problèmes de remplissage de disque qui n’apparaissent qu’avec le temps. Un test de pic frappe soudainement la charge pour vérifier si la mise à l’échelle automatique et les tampons l’absorbent avant que les utilisateurs ne le remarquent. Testez contre des données et une topologie semblables à la production, parce qu’une limite mesurée sur un jeu de données jouet ment. Refaites ces tests quand le système change, pour que vos chiffres décrivent le système que vous avez plutôt que celui que vous aviez il y a un an.

Choisir des stratégies d’approvisionnement délibérément

Les fournisseurs cloud vous laissent acheter la même capacité de façons qui échangent le prix contre la flexibilité, et bien les mélanger est où de l’argent réel est économisé. La capacité à la demande est flexible et coûteuse : vous payez le tarif plein pour la capacité de démarrer et arrêter n’importe quand, ce qui convient à la charge imprévisible et de courte durée. La capacité réservée (engagements d’un ou trois ans, ou plans d’économies) est moins chère par unité en échange d’une promesse de continuer à l’utiliser, ce qui convient à votre charge de base stable. Les instances spot vendent la capacité de surplus à un rabais profond mais peuvent être reprises avec peu d’avertissement, ce qui convient au travail tolérant aux pannes et interruptible comme le traitement par lots et les travailleurs sans état.

Le motif qui fonctionne est en couches. Couvrez votre charge de base stable avec de la capacité réservée pour le coût unitaire le plus bas, absorbez la variation quotidienne et hebdomadaire avec la mise à l’échelle automatique à la demande, et poussez le travail par lots interruptible vers le spot pour récolter le rabais. Gardez un bassin de tampon chaud de capacité pré-approvisionnée pour les services qui ne peuvent pas tolérer le délai de démarrage à froid de la mise à l’échelle depuis zéro, pour qu’un pic soudain rencontre une capacité prête plutôt qu’une file d’attente pendant que de nouvelles instances démarrent. Le bon mélange est une décision de portefeuille, et il change à mesure que la forme de votre demande et la tarification du fournisseur changent, donc revisitez-le.

Cartographier les goulots d’étranglement durs qui ne se mettront pas à l’échelle automatique

La mise à l’échelle automatique engendre une confiance dangereuse, parce que de nombreuses limites se trouvent en aval de la chose qui se met à l’échelle et ne bougent pas quand elle le fait. Les bassins de connexion de base de données sont l’exemple classique : mettez votre niveau sans état à l’échelle de 10 à 100 instances et chacune ouvre des connexions vers la même base de données, qui a un plafond dur sur les connexions concurrentes et commencera à en refuser de nouvelles. Les comptes cloud portent des quotas sur presque tout : instances par région, adresses IP, appels d’API par seconde, concurrence de fonction. Tout point unique de l’architecture, une base de données primaire, un nœud leader, un cache partagé, un appareil sous licence, est un plafond que la mise à l’échelle horizontale ailleurs ne peut pas élever.

Rendez ceux-ci explicites. Gardez un inventaire écrit de chaque limite dure entre une requête et sa réponse : tailles de bassin, valeurs de quota, composants à instance unique, limites de débit tierces, comptes de sièges de licence. Pour chacune, enregistrez la valeur actuelle, l’usage actuel, et la charge à laquelle elle se lie. Cet inventaire est la différence entre un plan de capacité qui décrit tout le système et un qui décrit seulement les parties faciles et élastiques tandis qu’un bassin de connexion attend silencieusement de mettre fin à votre lancement. Élevez les quotas avant le besoin, parce que les augmentations de quota de fournisseur peuvent prendre des jours à approuver.

Approvisionner pour les événements de pic, pas seulement la moyenne

Les moyennes cachent les moments qui comptent. Un système dimensionné pour la charge moyenne échouera au pic, et pour de nombreuses organisations le pic est tout l’objectif : la ruée de détail au plus gros jour de shopping, le pic de diffusion à une finale en direct, le portail fiscal à l’échéance de dépôt, le site de prestations quand l’inscription ouvre. Planifiez ces événements nommés individuellement. Estimez le pic depuis l’affaire (utilisateurs concurrents attendus, requêtes par session, le multiple par rapport à un jour normal), approvisionnez à ce pic avec de la marge, testez en charge à ce niveau, et mettez en scène la capacité avant l’événement plutôt que de vous démener pendant celui-ci.

Traitez un lancement ou une échéance comme un événement opérationnel avec un livre d’exécution. Préchauffez les caches et bassins de tampon, élevez les quotas à l’avance, gelez les déploiements risqués pendant la fenêtre, et mettez des humains d’astreinte qui peuvent agir si la prévision s’avère basse. Après l’événement, capturez le vrai pic et à quel point vous étiez proche de vos limites, parce que ce chiffre est la meilleure entrée pour le plan de l’année prochaine. Les échéances gouvernementales méritent une attention spéciale : elles sont auto-imposées, publiquement connues, et immuables, donc il n’y a aucune excuse d’être surpris et aucun moyen de se cacher quand vous l’êtes.

Instrumenter la capacité et la réviser selon une cadence

La planification de capacité fonctionne sur des données, et les données viennent de l’observabilité du chapitre 9.2. Suivez l’utilisation de chaque ressource contrainte (CPU, mémoire, disque, réseau, bassins de connexion, profondeur de file d’attente) contre sa limite, pour que vous puissiez voir la marge rétrécir avant qu’elle ne disparaisse. Surveillez directement les signaux de saturation : longueurs de file d’attente, temps d’attente, et taux de rejet révèlent la falaise de mise en file d’attente approchant. Tracez ces tendances sur des semaines pour projeter quand une ressource frappera son plafond au taux de croissance actuel, et alertez sur la projection plutôt que sur la valeur actuelle seule, pour que vous approvisionniez avant le mur plutôt qu’à celui-ci.

Tenez des révisions de capacité selon une cadence régulière, mensuelle ou trimestrielle, plutôt que seulement après un incident. Dans chaque révision, comparez la prévision à la demande réelle et corrigez le modèle, parcourez l’inventaire de limite dure et vérifiez la marge contre chacune, regardez les événements à venir et les plans d’affaires, et décidez quoi réserver, élever, ou retirer. Gardez un modèle de capacité vivant : un document simple ou une feuille de calcul qui fait correspondre les moteurs de demande aux besoins de ressource, pour que n’importe qui puisse demander « qu’arrive-t-il à la base de données si le trafic double » et obtenir une réponse du modèle au lieu d’une panne. Le modèle n’est jamais parfait, mais un modèle écrit et régulièrement corrigé bat l’intuition à chaque fois.

Compromis : avantages et inconvénients

Approche	Avantages	Inconvénients
Cible d’utilisation élevée	Coût par unité plus bas ; moins de capacité inactive	La latence explose près de la saturation ; pas de place pour les pics ou le basculement
Marge généreuse	Latence prévisible ; absorbe les pics et le basculement	Coût stable plus élevé ; peut cacher l’inefficacité
Capacité réservée	Prix unitaire le plus bas pour la charge de base stable	Risque d’engagement si la demande chute ou change
Capacité à la demande	Flexible ; correspond à la charge variable minute par minute	Prix unitaire le plus élevé ; peut surprendre le budget
Instances spot	Rabais profond pour le travail interruptible	Reprises sans avertissement ; inadaptées au travail avec état ou critique en latence
Mise à l’échelle automatique	Suit la charge automatiquement à l’intérieur de l’enveloppe	Ne peut pas dépasser le quota réservé ; démarrages à froid ; masque les limites en aval
Bassin de tampon (capacité chaude)	Absorbe les pics soudains instantanément	Paie pour la capacité inactive entre les pics

La tension centrale est le coût contre la fiabilité, et il n’y a aucun paramètre qui optimise les deux. Fonctionnez maigre et vous économisez de l’argent jusqu’au jour où un pic rencontre une ressource saturée et la latence tombe de la falaise de mise en file d’attente. Fonctionnez généreusement et vous dormez bien tout en payant pour une marge qui reste inactive la plupart du temps. Résolvez la tension avec le SLO plutôt qu’avec la peur ou l’économie. Approvisionnez assez de marge pour respecter la cible de fiabilité à travers les pics prévus plus une marge, et pas plus, puis laissez FinOps (opérations financières pour la dépense cloud, chapitre 9.4) chasser le gaspillage qui ne défend aucun SLO. Le but est un équilibre délibéré : chaque dollar de marge acheté délibérément pour acheter une quantité connue de fiabilité, et chaque dollar de gaspillage retiré délibérément parce qu’il n’en achète aucune.

Questions à discuter avec votre équipe

Savons-nous réellement la charge à laquelle chacun de nos goulots d’étranglement durs se lie, ou supposons-nous que la mise à l’échelle automatique nous sauvera ? La plupart des équipes peuvent vous dire que leurs instances se mettent à l’échelle automatique, et la plupart ne peuvent pas vous dire la limite de connexion concurrente sur leur base de données primaire, la limite de débit d’API de leur tiers le plus important, ou le quota de compte qui plafonne leur concurrence de fonction. Ce sont les limites qui mettent fin aux lancements, et elles ne bougent pas quand le niveau sans état se met à l’échelle. Apportez l’inventaire écrit des limites dures si vous en avez un, et si vous n’en avez pas, cette absence est le résultat. Pour chaque limite, vous voulez trois chiffres : le plafond, l’usage d’aujourd’hui, et le niveau de demande auquel ils se rencontrent. Partout où vous ne pouvez pas produire les trois, vous avez un goulot d’étranglement que vous gérez par l’espoir.
Quand avons-nous testé en charge pour la dernière fois au niveau de notre pire pic à venir, sur des données semblables à la production, et le SLO a-t-il tenu avec de la marge ? Un plan de capacité est un ensemble d’affirmations sur comment le système se comporte sous charge, et une affirmation non testée est une supposition qui porte un costume. Le pic qui compte n’est pas la moyenne du mois dernier mais le prochain lancement, la prochaine fête, ou échéance, et le test ne signifie quelque chose que si les données et la topologie ressemblent à la production, parce qu’une limite mesurée sur un jeu de données jouet ment. Apportez les résultats de vos tests de stress et d’endurance les plus récents, y compris où le système s’est cassé et comment il a échoué quand il l’a fait. Si la réponse honnête est que vous n’avez jamais poussé le système jusqu’à son point de rupture délibérément, alors vous découvrirez ce point en production, au pire moment possible, avec des utilisateurs qui regardent.
Comment le produit, le marketing, et les opérations disent-ils à l’ingénierie qu’un pic arrive avant qu’il ne se produise, et à quelle distance à l’avance ? Les échecs de capacité les plus coûteux ne sont pas des erreurs de modélisation ; ce sont des événements dont l’ingénierie n’a jamais entendu parler avant que le trafic n’arrive. Une prévision peut extrapoler la tendance et la saisonnalité depuis l’historique, mais un événement n’a pas d’historique, donc il ne peut venir que des gens qui le planifient. Apportez les trois derniers pics de demande et demandez, pour chacun, combien de jours d’avertissement l’ingénierie a reçus et si c’était assez pour réserver de la capacité et tester en charge. La preuve que vous voulez est un canal permanent avec un délai assez long pour approvisionner contre lui, parce que les augmentations de quota cloud seules peuvent prendre des jours. Si le canal n’existe pas, votre plan de capacité est aveugle exactement aux moments qu’il existe pour protéger.
Quelle cible d’utilisation chaque service sensible à la latence fait-il réellement fonctionner, et pouvons-nous retracer ce chiffre à son SLO plutôt qu’à une cible de coût ? Cela compte parce que la pression de faire fonctionner l’infrastructure chaude est constante et vient de la partie de l’organisation qui voit la facture mais pas la falaise de mise en file d’attente, donc à moins que la cible ne soit écrite et justifiée depuis l’objectif de latence, elle dérive vers le haut jusqu’à ce qu’un pic trouve le bord. Les considérations concurrentes sont de l’argent réel d’un côté et la latence de queue de l’autre, et la position honnête est que la marge sous 100 % est le prix d’une latence prévisible, pas du gaspillage à tailler. Apportez l’utilisation actuelle de vos quelques principaux services, le SLO que chacun défend, et la latence que vous avez mesurée à cette utilisation sous charge, pour que la discussion argumente depuis des preuves plutôt que depuis l’instinct. Dans une plateforme d’entreprise ou gouvernementale où un bassin partagé soutient de nombreux services, convenez la cible centralement et enregistrez qui peut la changer, parce qu’une seule équipe élevant silencieusement son plafond peut pousser une ressource dont d’autres dépendent par-dessus la falaise pour tout le monde.
Quel est notre mélange de capacité réservée, à la demande, et spot, quand l’avons-nous revisité pour la dernière fois, et correspond-il toujours à la forme de notre demande ? Le mélange est où les plus grandes économies soutenues et le plus grand gaspillage soutenu se cachent tous deux, parce qu’une charge de base stable payée à des tarifs à la demande brûle de l’argent chaque heure tandis qu’une position réservée sur-engagée paie pour une capacité que la demande a depuis dépassée ou est tombée en dessous. La tension est le coût contre la flexibilité et le risque d’engagement : la capacité réservée est la moins chère par unité mais vous enferme, le spot est encore moins cher mais peut être repris sans avertissement, et la demande achète la liberté à prime. Apportez la répartition actuelle par coût, la courbe de demande qu’elle est censée couvrir, et le taux de reprise et le rayon d’explosion de toute charge de travail spot, pour que la salle puisse voir si le travail interruptible est vraiment interruptible. Dans les contextes d’entreprise et gouvernementaux, liez les engagements réservés au cycle de marchés publics et de budget, parce que les engagements pluriannuels et plans d’économies sont des obligations financières que la finance et l’audit voudront justifiées contre la demande prévue, pas contre la commodité du dernier trimestre.
Quand un événement de pic nommé arrive, qui possède le préchauffage, les élévations de quota, les gels de déploiement, et l’appel de lancement ou non, et est-ce écrit comme un livre d’exécution que nous avons répété ? Les événements de pic sont les moments que la planification de capacité existe pour protéger, et ils échouent le plus souvent non pas parce que le plan était faux mais parce que personne n’était responsable de l’exécuter sous pression le jour même. Les considérations qui entrent en compétition ici sont la vitesse et l’autonomie contre la coordination : les équipes veulent continuer à livrer, pourtant un déploiement risqué pendant la fenêtre de ruée peut défaire des mois d’approvisionnement, donc quelqu’un doit détenir l’autorité de geler et d’arrêter le lancement. Apportez le livre d’exécution pour votre prochain grand événement, les délais pour les augmentations de quota et le réchauffement de bassin de tampon, et le registre de qui a tenu chaque rôle la dernière fois et si les transferts ont tenu. Pour une échéance gouvernementale qui est auto-imposée, publiquement connue, et immuable, nommez le propriétaire responsable et le chemin d’escalade explicitement, parce qu’il n’y a aucune option de délester la charge ou de demander aux citoyens de revenir plus tard, et un pic que personne ne possède est un pic que personne ne défendra quand il arrivera.

Regard sectoriel

Jeune pousse. Votre ressource la plus rare est l’attention d’ingénierie, donc gardez la planification de capacité bon marché et appuyez-vous sur l’élasticité du fournisseur cloud pour la variation quotidienne. La seule chose que vous ne pouvez pas sauter est une liste écrite des limites dures qui ne se mettent pas à l’échelle automatique : votre plafond de connexion de base de données primaire, votre limite de débit tierce la plus importante, et les quotas de compte que vous frapperiez sous un pic soudain de fonctionnalité ou de presse. Testez en charge à plusieurs fois votre pic normal sur des données de taille production avant votre première vraie ruée, parce que la confiance fragile que la mise à l’échelle automatique vous donne est exactement ce qui casse quand une base de données refuse des connexions.

Petite entreprise. Vous n’avez pas de spécialiste de capacité et un budget serré, donc traitez cela comme un problème d’achat et configuration plutôt qu’un projet de modélisation. Favorisez les services gérés qui absorbent la mise à l’échelle pour vous, fixez des alertes de dépense et des tableaux de bord d’utilisation simples pour qu’une facture incontrôlée ou une ressource saturante soit visible tôt, et connaissez les quelques événements nommés (une ruée saisonnière, un grand client qui se lance) qui définiront votre année. Réservez de la capacité pour votre charge de base stable pour couper la facture, et résistez à construire une machinerie de prévision que vous ne pouvez pas maintenir quand la forme de la demande bouge à peine.

Grande entreprise. Le problème est un ensemble partagé et fini de bassins derrière des centaines de services, donc la capacité devient de la gouvernance de portefeuille : un inventaire de limite dure maintenu, des cibles d’utilisation dérivées centralement des SLO, et un mélange délibéré de capacité réservée, à la demande, et spot revisité contre la tarification en direct. Standardisez les tests de charge, stress, endurance, et pic pour que chaque équipe mesure de la même façon sur des données semblables à la production, et exécutez des révisions de capacité selon une cadence qui attrape une marge en rétrécissement avant qu’un incident ne le fasse. Budgétez la coordination explicitement, parce que la croissance d’une équipe peut affamer celle d’une autre quand personne ne tient tout le modèle.

Gouvernement. La demande est souvent légalement concentrée en une échéance immuable et publiquement connue, donc planifiez pour ce pic nommé spécifiquement et approvisionnez une large marge de sécurité, puisque vous ne pouvez pas délester la charge ou demander aux citoyens de revenir plus tard. Les règles de marchés publics façonnent l’approvisionnement : les engagements réservés pluriannuels et les accords de quota de fournisseur doivent être justifiés contre la demande prévue et survivre à l’audit, donc gardez la prévision, la preuve de test de charge, et l’inventaire de limite dure documentés et défendables. Publiez des attentes réalistes où vous le pouvez, élevez les limites de fournisseur bien avant la fenêtre, et enregistrez le vrai pic à chaque cycle, parce que la responsabilité publique signifie qu’un portail qui plie sous une échéance qu’il s’est fixée lui-même est un échec que tout le pays voit.

Exemples

Jeune pousse. Une jeune pousse de dix personnes fait tourner une application grand public sur une infrastructure cloud à mise à l’échelle automatique et se sent en sécurité parce que le nombre d’instances grandit avec la charge. Leur première présentation télévisée triple le trafic en une heure, le niveau sans état se met à l’échelle magnifiquement, et l’application tombe quand même : chaque nouvelle instance ouvrait des connexions de base de données jusqu’à ce que la base de données atteigne son plafond de connexion et commence à les refuser. La leçon refaçonne leur pratique. Ils ajoutent un regroupeur de connexions devant la base de données, écrivent chaque limite dure entre une requête et une réponse, et testent en charge à plusieurs fois leur pic normal sur un jeu de données de taille production. Ils couvrent leur charge de base stable avec un engagement de capacité réservée pour le rabais et gardent un petit bassin de tampon chaud pour que le prochain pic rencontre une capacité prête. Les changements coûtent une semaine et convertissent leur confiance fragile en un plan qu’ils peuvent défendre.

Grande entreprise. Un détaillant mondial traite son plus gros jour de vente comme l’événement de capacité de l’année. Des mois à l’avance, une équipe transversale construit une prévision de demande depuis la tendance et saisonnalité des années précédentes plus le plan de marchandisage, traduit la prévision en besoins de ressource à travers un modèle de capacité, et approvisionne au pic projeté avec une marge généreuse. Ils testent en charge, stress, endurance, et pic le chemin complet sur des données semblables à la production, élèvent chaque quota cloud pertinent des semaines à l’avance, préchauffent les caches et bassins de tampon, et gèlent les déploiements risqués pour la fenêtre environnante. La capacité réservée couvre la charge de base stable pour le coût, la mise à l’échelle automatique à la demande absorbe la courbe quotidienne, et le travail par lots interruptible fonctionne sur spot. L’observabilité suit chaque ressource contrainte contre sa limite en temps réel pendant l’événement, avec des alertes sur la saturation projetée plutôt que la valeur actuelle. Le jour passe sans drame, ce qui est exactement le résultat que la planification a acheté.

Gouvernement. Une agence fiscale nationale fait tourner un portail de dépôt dont la demande est légalement concentrée dans les jours avant une échéance immuable, quand tout un pays dépose en même temps. L’agence planifie pour ce pic spécifiquement plutôt que pour une moyenne annuelle qui serait dénuée de sens. Elle estime les déposants concurrents depuis les années précédentes et les données de population, approvisionne à ce pic avec une large marge de sécurité parce qu’il n’y a aucune option de délester la charge ou de demander aux citoyens de revenir plus tard, et teste en charge à la concurrence projetée sur des données réalistes. L’équipe garde un inventaire écrit de chaque quota et point unique de défaillance, élève les limites avec les fournisseurs bien avant la fenêtre, et fixe des cibles d’utilisation assez basses pour que la falaise de mise en file d’attente reste loin de la ruée d’échéance. Après chaque saison de dépôt, ils enregistrent le vrai pic et combien de marge restait, alimentant le modèle de l’année prochaine. Le public voit un portail qui reste debout le jour pour lequel il est conçu, ce qui est tout le but de la promesse de l’institution.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

Le retour sur la planification de capacité apparaît comme deux coûts évités qui tirent dans des directions opposées, ce qui est ce qui rend la discipline précieuse. Le sous-approvisionnement coûte des pannes, et les pannes pendant les événements de pic coûtent le plus : revenu perdu, transactions perdues, et dommage réputationnel précisément quand l’audience est la plus grande. Un site de détail en panne son plus gros jour ou un portail gouvernemental s’effondrant à son échéance de dépôt paie pour des années de planification en une seule mauvaise heure. Le sur-approvisionnement coûte dans le sens opposé, en factures cloud pour une capacité qui reste inactive, et à l’échelle d’entreprise, quelques points de sur-approvisionnement chronique à travers une flotte s’élèvent à des millions de dollars par an. La planification de capacité est la pratique qui trouve le milieu délibéré : assez pour défendre le SLO à travers les pics, pas plus que cela.

Le coût pour adopter est surtout de la discipline plutôt que de l’outillage. Vous construisez une prévision de demande, écrivez vos limites dures, exécutez des tests de charge selon une cadence, mélangez vos stratégies d’approvisionnement, et tenez des révisions de capacité régulières. Le coût total de possession (TCO) s’améliore des deux côtés à la fois : moins d’incidents pilotés par la capacité abaissent le coût de l’indisponibilité et de la réponse d’urgence, et le redimensionnement continu plus un mélange réservé-et-spot sensé abaissent la facture d’infrastructure stable. Pour faire valoir le dossier auprès de la direction, connectez la capacité aux chiffres qu’elle surveille déjà. Liez le sous-approvisionnement au revenu perdu par heure d’indisponibilité de pic et aux violations de SLO avec des pénalités contractuelles, et liez le sur-approvisionnement au rapport de gaspillage FinOps du chapitre 9.4. L’argument n’est pas une prudence abstraite ; c’est de l’argent des deux côtés d’un cadran que vous pouvez fixer délibérément.

Anti-patterns et pièges

La mise à l’échelle automatique comme plan : faire confiance aux instances élastiques pendant qu’un bassin de connexion de base de données, un quota de compte, ou un point unique plafonne silencieusement tout le système.
Fonctionner chaud pour économiser de l’argent : cibler une utilisation de 90 % ou plus et rencontrer la falaise de mise en file d’attente, où la latence explose et le SLO casse.
Les moyennes au lieu des pics : dimensionner pour la charge moyenne pour que le système échoue exactement à l’événement de pic qui justifiait sa construction.
Prévoir depuis l’historique seul : extrapoler la tendance et la saisonnalité tout en manquant le lancement ou la campagne dont l’ingénierie n’a jamais été informée.
Les limites non testées : planifier autour d’un point de rupture que personne n’a mesuré, puis le découvrir en production au pire moment.
Les tests de charge sur données jouet : mesurer la capacité sur des données et une topologie irréalistes, produisant des chiffres qui mentent sur le vrai système.
Aucun inventaire de limite dure : gérer les quotas, bassins, et points uniques par mémoire et espoir plutôt que par une liste écrite et maintenue.
Tout réserver ou ne rien réserver : sur-engager envers une capacité réservée que la demande dépasse ou tombe en dessous, ou payer des tarifs à la demande complets pour une charge de base stable.
La révision de capacité seulement après les incidents : traiter la planification comme une lutte contre les incendies réactive au lieu d’une cadence régulière qui approvisionne avant le besoin.

Modèle de maturité

Niveau 1, Initier. La capacité est réactive et ad hoc. Les équipes ajoutent des ressources après qu’elles s’épuisent, font confiance à la mise à l’échelle automatique pour tout gérer, et n’ont pas de prévision, pas d’inventaire de limite dure, et pas de test de charge. Les événements de pic sont rencontrés avec espoir, et les pannes pendant les lancements et échéances sont traitées comme de la malchance.

Niveau 2, Développer. Des pratiques de base apparaissent mais varient par équipe. Une certaine surveillance montre l’utilisation, un peu de test de charge se produit avant les grands événements, les quotas majeurs sont connus, et une prévision approximative existe par endroits, mais le modèle n’est pas maintenu, les goulots d’étranglement en aval sont souvent manqués, et la marge est fixée par règle empirique plutôt que depuis le SLO.

Niveau 3, Standardiser. La planification de capacité est une discipline documentée appliquée à l’échelle de l’organisation. Une prévision de demande combine tendance, saisonnalité, événements, et croissance d’affaires ; un inventaire de limite dure écrit est maintenu ; les cibles d’utilisation dérivent des SLO ; les tests de charge, stress, endurance, et pic tournent selon une cadence contre des données semblables à la production ; et l’approvisionnement mélange réservé, à la demande, et spot délibérément. Un canal permanent porte les avertissements d’événement du produit et du marketing vers l’ingénierie.

Niveau 4, Gérer. La capacité est mesurée et contrôlée contre des référentiels. La prévision est comparée à la demande réelle à chaque cycle et l’erreur est suivie et réduite ; l’utilisation, les signaux de saturation, et la marge contre chaque limite dure sont tracés en tendance et alertés comme projections plutôt que valeurs actuelles ; les événements de pic sont révisés après coup contre le vrai pic observé ; et le mélange d’approvisionnement, la couverture d’engagement réservé, et le coût par SLO sont rapportés comme métriques qui conditionnent les décisions de lancement ou d’arrêt. Les données, pas l’intuition, décident quoi réserver, élever, ou retirer.

Niveau 5, Orchestrer. La planification de capacité est continuellement améliorée et intégrée à travers l’organisation. Les prévisions sont validées et affinées automatiquement, la saturation est projetée et approvisionnée contre avant qu’elle n’arrive, les mélanges d’approvisionnement sont optimisés contre la tarification en direct, les événements de pic fonctionnent depuis des livres d’exécution répétés, et le coût et la fiabilité sont équilibrés délibérément contre le SLO à travers toute la plateforme. Le modèle de capacité est un actif partagé et adaptatif qui rééquilibre la flotte à mesure que la forme de la demande et la tarification du fournisseur changent.

Pistes de réflexion

Quelle est votre cible d’utilisation actuelle pour les services sensibles à la latence, et pouvez-vous la justifier depuis votre SLO et le comportement de mise en file d’attente plutôt que depuis un désir d’économiser de l’argent ?
Lesquels de vos composants ne peuvent pas du tout se mettre à l’échelle automatique, et qu’arrive-t-il au reste du système quand l’un d’eux sature ?
Si votre trafic doublait le trimestre prochain, quelle ressource frappe son plafond en premier, et combien de jours de délai auriez-vous besoin pour l’élever ?
Comment décidez-vous le mélange de capacité réservée, à la demande, et spot, et quand l’avez-vous revisité pour la dernière fois contre la forme réelle de votre demande ?
Quand un événement de pic arrive, qui possède le préchauffage, les élévations de quota, et la décision de lancement ou non, et est-ce écrit comme un livre d’exécution ?
Vos alertes de capacité se déclenchent-elles sur la saturation projetée des semaines à l’avance, ou seulement sur l’utilisation actuelle une fois que le mur est déjà proche ?

Points clés à retenir

La planification de capacité assortit l’approvisionnement à la demande prévue avec une marge délibérée ; elle est distincte de la mise à l’échelle automatique (court terme, à l’intérieur de l’enveloppe) et de l’ingénierie de performance (unités de travail moins chères).
Prévoyez depuis la tendance, la saisonnalité, les événements connus, et la croissance d’affaires, et obtenez des avertissements d’événement du produit et du marketing, parce que les événements n’ont pas d’historique à extrapoler.
Respectez la falaise de la théorie des files d’attente (chapitre 11.3) : la latence explose près de la saturation, donc fixez des cibles d’utilisation depuis votre SLO et gardez une vraie marge.
Trouvez les limites par des tests de charge, stress, endurance, et pic sur des données semblables à la production, et gardez un inventaire écrit des goulots d’étranglement durs qui ne se mettront pas à l’échelle automatique.
Mélangez capacité réservée, à la demande, et spot avec des bassins de tampon chauds, planifiez les événements de pic nommés individuellement, et révisez la capacité selon une cadence plutôt qu’après les pannes.

Références et lectures complémentaires

Betsy Beyer, Chris Jones, Jennifer Petoff, et Niall Richard Murphy (éd.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, et Stephen Thorne (éd.), The Site Reliability Workbook: Practical Ways to Implement SRE
John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
Martin L. Abbott et Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise
Brendan Gregg, Systems Performance: Enterprise and the Cloud
Leonard Kleinrock, Queueing Systems, Volume 1: Theory
J. R. Storment et Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management