3.5 Évolutivité, performance, et résilience

Vue d’ensemble et motivation

L’évolutivité, la performance, et la résilience sont trois qualités distinctes, et les gens les mélangent souvent. La performance est la vitesse à laquelle le système répond et combien de travail il fait par unité de ressource. L’évolutivité est à quel point il maintient la performance à mesure que la charge grandit. La résilience est à quel point il continue de fonctionner, ou se dégrade gracieusement, quand les choses échouent. Un système peut être rapide mais non évolutif (excellent à faible charge, s’effondre à forte charge), évolutif mais fragile (gère le volume mais tombe quand un composant échoue), ou résilient mais lent. Une grande organisation a besoin des trois, conçues dès le départ, parce que rétro-adapter l’une d’elles après le lancement est coûteux et perturbateur.

Pour les systèmes d’entreprise et gouvernementaux, les conséquences de mal faire cela sont publiques et sévères. Pensez à un portail de prestations qui plie le premier jour d’un nouveau programme, un système de dépôt fiscal qui expire à l’échéance, ou une plateforme de paiement qui tombe pendant les achats de pointe. Ce sont les échecs qui font la une, déclenchent des enquêtes, et érodent la confiance publique. Ces systèmes affrontent aussi une charge fortement pointue, souvent légalement chronométrée (échéances de dépôt, fenêtres d’inscription, jours de paie) et des obligations strictes de disponibilité et de récupération. Vous devez planifier la capacité pour des pics prévisibles, dégrader gracieusement sous les imprévisibles, et récupérer dans des limites définies de temps et de perte de données après un sinistre. C’est de l’ingénierie avec une dimension de redevabilité publique.

Ce chapitre couvre la mise à l’échelle horizontale contre verticale, l’absence d’état et le sharding comme facilitateurs de l’échelle, l’équilibrage de charge, la mise à l’échelle automatique et la planification de capacité, l’ingénierie de performance avec des budgets explicites, les motifs de résilience et l’ingénierie du chaos, et la reprise après sinistre multi-région encadrée par le RTO, le RPO, et la continuité d’activité. Le message unificateur est que ces qualités sont le produit d’une conception délibérée et d’un test continu, pas de l’espoir.

Voir aussi : chapitre 3.3 (systèmes distribués), chapitre 9.1 (ingénierie de fiabilité des sites), et chapitre 9.2 (observabilité et surveillance).

Principes clés

Concevez pour la mise à l’échelle horizontale, pas verticale. La mise à l’échelle verticale a un plafond et un point de défaillance unique ; la mise à l’échelle horizontale est comment vous atteignez une échelle grande et résiliente.
L’absence d’état est le facilitateur de l’échelle horizontale. Si toute requête peut aller à toute instance, vous pouvez ajouter et retirer de la capacité librement.
Vous ne pouvez pas améliorer ce que vous ne mesurez pas. Le travail de performance est piloté par le profilage et les tests de charge contre des budgets explicites, jamais par la supposition.
Tout échoue ; concevez pour cela. Supposez que les composants échoueront et construisez pour que le système survive à leur échec.
La dégradation gracieuse bat l’échec brutal. Un système partiellement fonctionnel qui abandonne des fonctionnalités non essentielles vaut mieux qu’une panne totale.
La capacité est planifiée, les pics sont absorbés. Prévoyez la charge prévisible ; utilisez la mise à l’échelle automatique et la marge pour le reste.
Les objectifs de récupération sont des décisions d’affaires. Le RTO et le RPO sont choisis par l’affaire contre le coût, puis conçus techniquement.
Testez la résilience délibérément. Vous ne savez pas qu’un système est résilient jusqu’à ce que vous l’ayez fait échouer exprès.

Recommandations

Préférer la mise à l’échelle horizontale et concevoir des services sans état

La mise à l’échelle verticale (des machines plus grosses) est simple et parfois le bon premier pas, mais elle heurte un plafond dur, devient disproportionnellement coûteuse au sommet, et laisse un point de défaillance unique. La mise à l’échelle horizontale (plus de machines derrière un équilibreur de charge) s’échelonne bien plus loin et améliore la disponibilité, parce que perdre une instance est survivable. Le prérequis est l’absence d’état. Ne gardez aucun état de session client ou de requête sur l’instance ; poussez-le vers un magasin partagé (base de données, cache, jeton). Les services sans état peuvent être ajoutés, retirés, remplacés, et équilibrés en charge librement, ce qui est ce qui rend possible à la fois la mise à l’échelle automatique et le déploiement progressif. Là où l’état doit être partitionné, faites du sharding par une clé qui distribue la charge uniformément et garde les données liées sur le même shard.

Équilibrer la charge, mettre à l’échelle automatiquement, et planifier la capacité

Placez un équilibreur de charge devant chaque palier échelonné pour distribuer le trafic et router autour des instances malsaines via des vérifications de santé. Configurez la mise à l’échelle automatique pour ajouter de la capacité quand un indicateur avancé (CPU, profondeur de file de requête, latence) franchit un seuil et la retirer quand la charge baisse. Réglez la vitesse de mise à l’échelle et les périodes de refroidissement pour ne ni retarder derrière un pic ni osciller. La mise à l’échelle automatique n’est pas un substitut à la planification de capacité. Pour des pics prévisibles et critiques pour l’affaire (échéances fiscales, périodes d’inscription, événements de vente), prévoyez la charge, pré-provisionnez ou préchauffez la capacité, et faites des tests de charge vers cette cible à l’avance. La mise à l’échelle automatique seule ne peut pas réagir instantanément à un changement en marche, et les démarrages à froid ajoutent de la latence exactement quand vous pouvez le moins vous le permettre. Gardez toujours de la marge. Fonctionner à 100 % ne laisse aucune place pour absorber les pics ou les pannes.

Concevoir la performance contre des budgets explicites

Fixez des budgets de performance (des cibles concrètes telles que la latence API p95 sous 200 ms, une page interactive sous 2 secondes, ou un coût par transaction sous un seuil) et imposez-les en test et surveillance pour que les régressions fassent échouer le pipeline plutôt que d’atteindre les utilisateurs. Pilotez l’optimisation par la mesure. Profilez pour trouver le vrai goulot d’étranglement, qui est rarement où vous le supposez, et faites des tests de charge pour trouver où le système se casse et comment il se comporte près de cette limite. Concentrez-vous sur le chemin critique et la queue (p95/p99), parce qu’à l’échelle les latences de queue dominent l’expérience utilisateur. Optimisez le plus grand goulot d’étranglement en premier, remesurez, et arrêtez quand vous atteignez le budget. Sur-optimiser du code déjà adéquat est un effort gaspillé.

Construire des motifs de résilience et valider avec l’ingénierie du chaos

Appliquez les motifs de résilience des systèmes distribués : délais d’expiration, nouvelles tentatives bornées avec recul, disjoncteurs (qui échouent rapidement quand une dépendance est malsaine), et cloisons (qui isolent les bassins de ressources pour qu’une panne ne puisse pas épuiser le reste), plus la dégradation gracieuse (abandonner ou simplifier les fonctionnalités non essentielles sous stress : désactiver les recommandations, servir du contenu en cache, mettre en file le travail non urgent) et le délestage de charge (rejeter ou limiter les requêtes excédentaires pour protéger le cœur plutôt que de s’effondrer entièrement). Éliminez les points de défaillance uniques à travers la redondance à chaque palier. Puis validez la résilience avec l’ingénierie du chaos. Injectez délibérément des pannes (tuer des instances, ajouter de la latence, couper une dépendance, faire échouer une zone) dans des expériences contrôlées, en commençant en test et en mûrissant vers des journées de jeu en production, pour prouver que le système se comporte comme conçu. Une résilience jamais testée n’est qu’une hypothèse.

Planifier le multi-région, la reprise après sinistre, et la continuité d’activité

Décidez explicitement les objectifs de récupération : le RTO (Recovery Time Objective, combien de temps vous pouvez être en panne) et le RPO (Recovery Point Objective, combien de données vous pouvez vous permettre de perdre). Ce sont des décisions d’affaires avec des implications de coût directes, et elles pilotent l’architecture. Les options varient en coût et en vitesse : sauvegarde-et-restauration (le moins cher, le plus lent), pilot light, standby chaud, et multi-région actif-actif (le plus cher, RTO/RPO quasi nul). Choisissez le palier que justifie la criticité de chaque système. Tout n’a pas besoin d’actif-actif. Répliquez les données à travers les régions de façon cohérente avec le RPO choisi, automatisez le basculement, et, par-dessus tout, testez le basculement régulièrement. Une reprise après sinistre non testée échoue de façon fiable quand elle est finalement nécessaire. Enveloppez tout cela dans un plan de continuité d’activité couvrant les personnes, les communications, et les recours manuels, pas seulement la technologie.

Compromis : avantages et inconvénients

Choix	Avantages	Inconvénients
Mise à l’échelle verticale	Simple, pas de changement de code, faible effort initial	Plafond dur, coûteux au sommet, point de défaillance unique
Mise à l’échelle horizontale	Échelle quasi illimitée, améliore la disponibilité	Exige l’absence d’état, l’équilibrage de charge, plus d’opérations
Mise à l’échelle automatique	Assortit le coût à la demande, gère la charge variable	Réagit avec retard ; démarrages à froid ; peut osciller si mal réglée
Multi-région actif-actif	RTO/RPO quasi nul, survit à la perte d’une région	Coût et complexité les plus élevés, cohérence des données difficile
RS sauvegarde-et-restauration	Le moins cher, le plus simple	Long RTO, fenêtre de perte de données plus grande

Le compromis central est le coût contre l’assurance. Chaque incrément de marge d’évolutivité, de performance, et de capacité de récupération coûte de l’argent et de la complexité, et les retours sont non linéaires. Passer de 99,9 % à 99,99 % de disponibilité, ou d’une heure de RTO à des secondes, peut multiplier le coût. La discipline est de dimensionner chaque investissement à la criticité réelle du système et à la tolérance de l’affaire pour le temps d’arrêt et la perte de données, plutôt que d’ingénierer réflexivement tout au niveau le plus élevé. Un système de paiement orienté citoyen mérite une redondance actif-actif ; un outil de reporting interne non.

Questions à discuter avec votre équipe

Quand votre dernier incident sérieux s’est produit, lequel des trois (performance, évolutivité, résilience) a réellement échoué, et avez-vous corrigé le bon ? Le chapitre les sépare délibérément : un système peut être rapide mais s’effondrer sous charge, s’échelonner mais tomber quand un composant meurt, ou survivre aux pannes tout en étant lent. Les équipes diagnostiquent souvent mal, ajoutant de la capacité à un problème de résilience ou renforçant un système qui était simplement sous-provisionné pour un pic. Parcourez les deux derniers incidents sérieux et nommez quelle qualité a échoué et ce que la réponse a réellement amélioré. La distinction change la correction : absence d’état et sharding pour l’échelle, redondance et disjoncteurs pour la résilience, profilage et budgets pour la performance. Bien identifier la catégorie est la différence entre dépenser pour le remède et dépenser pour un symptôme.
Les régressions de performance font-elles échouer votre pipeline, ou atteignent-elles les utilisateurs avant que quiconque ne le remarque ? Un budget de performance (latence p95, temps d’interactivité de page, coût par transaction) ne protège les utilisateurs que s’il est imposé automatiquement, donc un changement qui le dépasse fait échouer la construction plutôt que d’être livré. Dans une grande équipe avec de nombreux contributeurs, la latence s’infiltre par mille petits commits, et sans une porte la queue pourrit lentement jusqu’à ce qu’un lancement l’expose. Apportez vos budgets actuels et vérifiez s’ils sont câblés dans la CI et la surveillance, et s’ils ciblent p95 et p99 plutôt que des moyennes, parce que la queue est ce que les utilisateurs ressentent à l’échelle. Là où aucun budget n’existe, en fixer un est le premier mouvement. L’imposition est ce qui transforme une bonne intention en une propriété qui survit à la croissance de l’équipe.
Sous stress, qu’est-ce qui se délestage en premier, et avez-vous conçu cet ordre ou le découvrirez-vous pendant la panne ? La dégradation gracieuse et le délestage de charge signifient que le système abandonne le travail non essentiel pour protéger le cœur, mais seulement si vous avez décidé à l’avance ce qui est essentiel. Pour un service orienté citoyen, ce classement est souvent une décision de politique : soumettre une déclaration fiscale doit survivre même si les tableaux de bord de statut et les recherches historiques s’éteignent. Si personne n’a choisi, le système délestage tout ce qui échoue en premier, ce qui peut être exactement ce dont les utilisateurs ont le plus besoin. Listez vos fonctionnalités par ordre de priorité et confirmez que l’architecture peut abandonner les basses priorités (réponses en cache, recommandations désactivées, travail non urgent mis en file) sans emporter le chemin critique avec elles. Puis testez-le sous charge réelle, parce qu’une dégradation non testée n’est qu’un espoir.
Pour votre système le plus critique, quels sont le RTO et le RPO, qui a réellement choisi ces chiffres, et quand avez-vous prouvé pour la dernière fois que vous pouvez les respecter ? Le Recovery Time Objective (combien de temps vous pouvez être en panne) et le Recovery Point Objective (combien de données vous pouvez vous permettre de perdre) sont des décisions d’affaires avec des implications de coût directes, pourtant dans une grande équipe ils sont souvent inventés par qui a écrit le manuel d’exploitation plutôt que possédés par les personnes responsables du service. La tension concurrente est le coût contre l’assurance : réduire le RTO d’une heure à des secondes ou le RPO de minutes à zéro peut multiplier la facture d’infrastructure, donc le bon chiffre est celui que l’affaire paiera réellement, pas le plus impressionnant. Apportez les objectifs documentés, la date du dernier vrai test de basculement, et le temps mesuré et la perte de données que ce test a produits, parce qu’un objectif non testé est un souhait. Dans les contextes d’entreprise et gouvernementaux, ces chiffres peuvent être fixés par la loi, le contrat, ou le SLA, donc nommez qui les valide et si la dernière répétition a satisfait l’obligation ou l’a discrètement manquée.
Pour votre plus grand pic prévisible, faites-vous confiance à la mise à l’échelle automatique pour réagir dans l’instant, ou avez-vous prévu la charge, pré-provisionné, et fait des tests de charge vers cette cible ? La mise à l’échelle automatique réagit avec retard et les démarrages à froid ajoutent de la latence exactement quand vous pouvez le moins vous le permettre, donc un changement en marche connu (une échéance de dépôt, une fenêtre d’inscription, un événement de vente) est précisément le cas où la mise à l’échelle réactive échoue et où la planification de capacité délibérée gagne. La tension est le coût : préchauffer la capacité pour un pic signifie payer pour une marge qui reste inactive la majeure partie de l’année, et la tentation est d’espérer que la mise à l’échelle automatique la couvre gratuitement. Apportez les chiffres de pic de l’année dernière, la prévision de cette année avec la croissance, et les résultats d’un test de charge exécuté vers un multiple de cette prévision plutôt que vers le trafic moyen d’aujourd’hui. Pour un service gouvernemental ou d’entreprise faisant face à un pic légalement chronométré, ajoutez la conséquence de se tromper, puisqu’un portail de prestations ou un système fiscal qui plie le premier jour devient une enquête publique, pas seulement un après-midi lent.
Avez-vous déjà délibérément fait échouer un composant en production, et le palier de redondance de chaque système correspond-il réellement à sa criticité et son coût ? Une résilience jamais testée est une hypothèse, et les paliers que vous pouvez acheter vont de la sauvegarde-et-restauration bon marché au standby chaud jusqu’au multi-région actif-actif coûteux, donc la discipline est de dépenser l’assurance là où elle est justifiée plutôt que de tout dorer ou de ne rien protéger. Les considérations concurrentes sont le rayon d’impact et le budget : les expériences de chaos doivent avoir des garde-fous et un interrupteur d’abandon, et l’actif-actif pour un outil de reporting interne est du gaspillage tandis que la sauvegarde seule pour une plateforme de paiement est de la négligence. Apportez un inventaire de vos points de défaillance uniques, le palier de redondance de chaque système critique, et la preuve de la dernière injection de panne contrôlée et de ce qu’elle a révélé. Dans les portefeuilles d’entreprise et gouvernementaux, cartographiez chaque palier à une cote de criticité documentée pour qu’un auditeur puisse voir que l’argent suit le risque, et pour que personne n’ait à défendre la dépense pour la première fois pendant la panne.

Regard sectoriel

Jeune pousse. Vous ne pouvez pas prédire si un lancement apportera cinquante inscriptions ou cinquante mille, donc achetez l’échelle plutôt que de la construire : exécutez des services sans état derrière un équilibreur de charge géré et laissez la plateforme s’échelonner automatiquement sur le taux de requête. Fixez un budget de performance modeste et choisissez des magasins de données gérés pour qu’un pic ne force pas une réarchitecture à 2 heures du matin. Sautez la reprise après sinistre multi-région et les programmes de chaos pour l’instant ; gardez des sauvegardes testées et dépensez votre attention d’ingénierie rare sur le produit, pas sur une redondance que votre trafic ne justifie pas encore.

Petite entreprise. Sans spécialiste de fiabilité et avec un budget serré, le choix acheter-contre-construire penche fortement vers acheter : une plateforme gérée ou une pile sans serveur fait de la mise à l’échelle et du basculement le travail du fournisseur, et une seule région bien exploitée suffit généralement. Cadrez la résilience comme un petit nombre de promesses concrètes que vous pouvez tenir, comme une sauvegarde nocturne dont vous avez réellement restauré une fois et une fenêtre de récupération réaliste que vous avez communiquée aux clients. Évitez de payer pour de l’actif-actif ou des tests de charge continus que ni votre trafic ni votre personnel ne justifient.

Grande entreprise. Le problème est la cohérence à travers de nombreuses équipes : standardisez les budgets de performance imposés en CI, une bibliothèque partagée de motifs de résilience (délais d’expiration, disjoncteurs, cloisons), et un palier de redondance documenté pour chaque système lié à sa criticité. Réservez le multi-région actif-actif aux services de niveau un, exécutez un programme d’ingénierie du chaos avec des garde-fous et des journées de jeu en production, et traitez la planification de capacité pour les pics connus comme une discipline planifiée plutôt qu’une réflexion après coup. Gouvernez le RTO et le RPO centralement pour que chaque système critique ait des objectifs possédés et testés qu’un auditeur peut vérifier.

Gouvernement. La charge est souvent légalement chronométrée et les obligations de disponibilité sont légales, donc la planification de capacité ne peut pas compter sur la mise à l’échelle automatique réagissant dans l’instant : prévoyez le pic d’échéance, pré-provisionnez, et faites des tests de charge bien au-dessus de la prévision. L’approvisionnement devrait spécifier le RTO, le RPO, et un calendrier de basculements répétés comme exigences contractuelles, pas des promesses de fournisseur, et devrait éviter l’enfermement mono-région pour les services critiques. Décidez à l’avance quel chemin est légalement essentiel (soumettre une déclaration, réclamer une prestation) pour que la dégradation délestage d’abord les tableaux de bord de statut et les recherches, et soyez transparent avec le public sur les pannes et la récupération plutôt que d’espérer que personne ne remarque.

Exemples

Jeune pousse. Une petite start-up se lançant sur Product Hunt ne peut pas prédire si elle obtiendra cinquante inscriptions ou cinquante mille, donc elle garde ses services sans état derrière un équilibreur de charge géré et laisse la plateforme s’échelonner automatiquement sur le taux de requête. Elle fixe un budget de performance modeste (les pages répondent en moins de 300 ms au 95e percentile) et choisit une base de données gérée pour qu’un pic de trafic ne force pas une réarchitecture à 2 heures du matin. Quand le pic du jour de lancement arrive réellement, le site ralentit un peu plutôt que de tomber, et l’équipe passe la journée à parler à de nouveaux utilisateurs au lieu de combattre une panne.

Grande entreprise. Une entreprise de streaming média exploite des services sans état à travers plusieurs régions derrière un équilibrage de charge mondial, s’échelonnant automatiquement sur le taux de requête pour suivre la vague quotidienne des heures de pointe. Les budgets de performance conditionnent chaque livraison sur la latence de démarrage p99. Sous une panne régionale, le trafic bascule automatiquement vers des régions saines, et les fonctionnalités non essentielles (illustrations personnalisées, rafraîchissement de recommandation) se dégradent en premier pour protéger la lecture. L’entreprise exécute des expériences de chaos continues en production, terminant régulièrement des instances et injectant de la latence, si bien que les vraies pannes sont indistinguables des exercices et ne causent aucune panne visible par les clients.

Gouvernement. Une agence fiscale sait que son système de dépôt affronte un pic massif et légalement fixe chaque année. Plutôt que de compter sur la mise à l’échelle automatique pour réagir dans l’instant, elle prévoit la charge de pointe des années précédentes, pré-provisionne la capacité des semaines à l’avance, et fait des tests de charge à 150 % de la prévision. L’architecture est sans état derrière des équilibreurs de charge avec une seconde région en standby chaud. Le RTO et le RPO sont fixés par politique (pas plus de 15 minutes de temps d’arrêt et perte de données quasi nulle pour les déclarations soumises), et le basculement est répété trimestriellement. Sous charge extrême, les fonctionnalités non critiques (tableaux de bord de statut, recherches historiques) se délestent en premier pour que la soumission de déclaration, le chemin légalement essentiel, reste disponible.

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

L’évolutivité, la performance, et la résilience sont des cas classiques où le coût de l’échec dépasse largement le coût de la prévention. Mais la prévention est visible sur le budget et l’échec n’est que potentiel, ce qui explique pourquoi elles sont chroniquement sous-financées jusqu’au premier désastre. Le coût d’adoption est réel : infrastructure redondante, capacité multi-région, outillage de test de charge et de chaos, et le temps d’ingénierie pour construire l’absence d’état et les motifs de résilience. Le coût de ne pas investir est une panne très médiatisée pendant la demande de pointe : revenu perdu à la minute pour le commerce, obligations légales manquées et enquête publique pour le gouvernement, pénalités d’accord de niveau de service (SLA), et dommage réputationnel durable.

Cadrez le dossier pour la direction avec des chiffres que l’affaire comprend déjà. Estimez le coût d’une heure de temps d’arrêt pendant le pic (transactions perdues, pénalités, remédiation, réputation), puis comparez-le au coût annuel de la redondance et du test qui le prévient. Pour les systèmes critiques, la prévention est presque toujours une fraction d’un seul incident majeur. Liez le RTO et le RPO à de l’argent explicite : combien de revenu ou combien de transactions par heure de temps d’arrêt, et combien de perte de données est légalement ou commercialement tolérable. Présentez la performance comme un levier de revenu et de satisfaction, puisque des systèmes plus rapides convertissent mieux et coûtent moins par transaction, et présentez la résilience comme une assurance dont la prime est petite par rapport à la perte couverte. L’argument le plus fort est que ces qualités sont bon marché à concevoir dès le départ et ruineuses à rétro-adapter après la panne qui force la question.

Anti-patterns et pièges

Sessions collantes et état dans l’instance. Stocker l’état de session sur le serveur, empêchant la mise à l’échelle horizontale libre et le remplacement sûr d’instance.
Mise à l’échelle automatique comme planification de capacité. Supposer que la mise à l’échelle automatique absorbera un pic de changement en marche connu auquel elle est trop lente pour réagir.
Fonctionner chaud sans marge. Opérer à une utilisation proche de 100 %, ne laissant rien pour absorber les pics ou les pannes.
Optimiser sans profiler. Régler du code qui n’est pas le goulot d’étranglement pendant que le vrai reste intact.
Ignorer la queue. Rapporter la latence moyenne pendant que les utilisateurs p99 souffrent ; les moyennes cachent la douleur à l’échelle.
Reprise après sinistre non testée. Un plan de RS et des sauvegardes jamais exercés et qui échoueront quand nécessaires.
Points de défaillance uniques. Un équilibreur de charge, un primaire de base de données, une région : un composant non redondant qui fait tout tomber.
Ingénierie du chaos sans garde-fous. Injecter des pannes sans contrôle de rayon d’impact ni interrupteur d’abandon, causant la panne même que vous vouliez prévenir.

Modèle de maturité

Niveau 1 (Initier) : Ad hoc et réactif. Instance unique ou échelonnée verticalement, avec l’état gardé sur le serveur. Pas de test de charge, pas de budgets de performance, et pas de reprise après sinistre au-delà de sauvegardes occasionnelles dont personne n’a restauré. Toute panne de composant cause une panne totale, et les problèmes d’échelle sont découverts en production.
Niveau 2 (Développer) : Des pratiques de base apparaissent mais varient d’équipe à équipe. Certains services sont échelonnés horizontalement et sans état derrière un équilibreur de charge, avec une mise à l’échelle automatique de base sur quelques-uns d’entre eux. Le test de charge a lieu avant les grands lancements mais pas routinièrement, et les sauvegardes existent tandis que la reprise après sinistre est documentée mais rarement exercée. Ce qu’une équipe fait bien, une autre ne l’a pas commencé.
Niveau 3 (Standardiser) : Les pratiques sont documentées et imposées à l’échelle de l’organisation. La capacité est planifiée pour les pics connus avec de la marge, les budgets de performance sont imposés en CI pour que les régressions fassent échouer la construction, et les motifs de résilience (délais d’expiration, nouvelles tentatives bornées, disjoncteurs, cloisons) plus la dégradation gracieuse sont la valeur par défaut. Le RTO et le RPO sont définis par système, les paliers de redondance sont assignés par criticité, et le basculement de reprise après sinistre est testé selon un calendrier régulier à travers les équipes.
Niveau 4 (Gérer) : Les qualités sont mesurées et contrôlées par rapport à des références. Les équipes suivent la latence p95 et p99, les budgets d’erreur, et l’utilisation et la marge par rapport à la prévision, et alertent sur les violations plutôt que de les découvrir au lancement. Les temps de basculement testés sont comparés à la cible de RTO et RPO, les seuils de dégradation et de délestage de charge sont validés avec des métriques, et les décisions de feu vert ou non sur les livraisons et la capacité sont pilotées par les données. Là où les chiffres dérivent de la référence, l’écart est visible et possédé plutôt que caché derrière des moyennes.
Niveau 5 (Orchestrer) : L’évolutivité, la performance, et la résilience sont continuellement améliorées et intégrées à travers l’organisation. Le multi-région actif-actif est utilisé partout où la criticité le justifie, l’ingénierie du chaos fonctionne continuellement incluant des journées de jeu en production, et la prévision de capacité alimente directement la planification et l’approvisionnement. La résilience est validée en continu, les objectifs de récupération sont respectés et prouvés de façon cohérente, et l’architecture s’adapte à mesure que les motifs de charge et le tableau de risque changent, liée à la planification de continuité d’activité et de risque.

Pistes de réflexion

Lesquels de vos services gardent encore de l’état sur l’instance, et qu’est-ce qui vous empêche de les rendre sans état ?
Pour votre système le plus critique, quels sont le RTO et le RPO, qui les a fixés, et quand avez-vous prouvé pour la dernière fois que vous pouvez les respecter ?
La mise à l’échelle automatique vous protège-t-elle réellement contre votre plus grand pic connu, ou comptez-vous sur elle pour faire quelque chose qu’elle ne peut pas ?
Où se trouve votre point de défaillance unique restant, et quel est le plan pour le retirer ?
Mesurez-vous et budgétez-vous la latence p99, ou vous cachez-vous derrière des moyennes ?
Avez-vous déjà délibérément fait échouer un composant en production ? Sinon, comment savez-vous que votre résilience fonctionne ?

Points clés à retenir

Distinguez la performance, l’évolutivité, et la résilience ; un grand système a besoin des trois, conçues dès le départ.
La mise à l’échelle horizontale et les services sans état sont le fondement de l’échelle, de la disponibilité, et du déploiement sûr.
Combinez la mise à l’échelle automatique avec une vraie planification de capacité et de la marge pour les pics prévisibles et critiques pour l’affaire.
Pilotez la performance par le profilage et les tests de charge contre des budgets explicites, en vous concentrant sur le chemin critique et la queue.
Construisez la résilience avec des délais d’expiration, des disjoncteurs, des cloisons, une dégradation gracieuse, et de la redondance, puis validez-la avec l’ingénierie du chaos.
Fixez le RTO et le RPO comme des décisions d’affaires, concevez la RS pour correspondre à la criticité de chaque système, et testez le basculement régulièrement.

Références et lectures complémentaires

Martin Kleppmann, Designing Data-Intensive Applications
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Betsy Beyer et al. (Google), Site Reliability Engineering et The Site Reliability Workbook
Casey Rosenthal et Nora Jones, Chaos Engineering
Brendan Gregg, Systems Performance: Enterprise and the Cloud
John Allspaw, The Art of Capacity Planning
Ilya Grigorik, High Performance Browser Networking
Nassim Nicholas Taleb, Antifragile