Cloud ou on-prem : ce qu'un SRE vérifie sous le service

Le fournisseur d'infrastructure est la plus grande dépendance qu'un service puisse avoir, et un SRE la traite comme toutes les autres : il lit ce à quoi elle s'engage réellement, cartographie où elle tombe en bloc, et vérifie ce qui se passe quand elle ne répond pas. C'est vrai que le fournisseur soit AWS ou une équipe plateforme qui fait tourner des racks deux étages plus bas. Les questions sont identiques des deux côtés ; ce qui change, c'est qui y répond. Sur un cloud, le fournisseur répond et vous vérifiez. On-prem, vous répondez, et personne ne vous vérifie. Ce billet est la checklist, en six domaines : l'engagement, les domaines de défaillance, les control planes, les limites, la capacité et la maintenance.

Ceci est la Partie 4 de Budget for Failure, la seconde de niveau 201 et la dernière de la série. La Partie 1 a défini le rôle, la Partie 2 lui a donné des chiffres, et la Partie 3 l'a emmené dans le code applicatif. Cette partie passe sous le code.

1. L'engagement : vos dépendances plafonnent votre SLO

La Partie 2 a listé ce à quoi quatre SLA d'AWS s'engagent. Faites maintenant l'arithmétique que la plupart des revues d'architecture sautent. Une requête qui doit traverser un load balancer, une couche compute, une base de données et un stockage objet ne réussit que si les quatre réussissent. Si les défaillances sont indépendantes, les disponibilités se multiplient :

ALB (multi-AZ)      0.9999
EC2 (multi-AZ)      0.9999
RDS (Multi-AZ)      0.9995
S3 Standard         0.9990
------------------------------
product             0.9983   =  99.83%
allowed downtime    about 73 minutes in 30 days

Avant que votre propre code n'ait levé une seule exception, le plancher contractuel sous cette pile est de 99,83 pour cent. AWS tourne normalement bien au-dessus de ses planchers de SLA, donc le chiffre pratique est meilleur, mais la conclusion tient : vous ne pouvez pas promettre 99,99 pour cent par-dessus une dépendance dure qui s'engage à 99,9. Vous abaissez la promesse, ou vous rendez la dépendance souple avec un cache, une file ou un repli, comme dans la Partie 3.

On-prem, il n'y a pas de document de SLA à multiplier, donc vous construisez le même tableau à partir de votre propre historique : disponibilité mesurée de la baie de stockage, du cluster d'hyperviseurs, du cœur de réseau, de l'alimentation. Si personne n'a ces chiffres, c'est le premier constat de la revue.

2. Les domaines de défaillance : ce qui meurt ensemble

La multiplication suppose l'indépendance. Un domaine de défaillance est un ensemble de choses qui partagent une cause de défaillance, et le travail du SRE est de les connaître et de placer les réplicas à travers eux.

Trois vérifications s'appliquent des deux côtés. Les réplicas de chaque système à état sont-ils vraiment dans des domaines différents, ou trois nœuds d'un quorum sont-ils dans une seule zone ou un seul rack ? Quelque chose de single-homed se trouve-t-il sur le chemin de quelque chose de multi-homed, comme une NAT gateway qui sert trois zones, ou deux switches « redondants » sur la même arrivée électrique ? Et une fois disparu le plus grand domaine auquel vous prévoyez de survivre, la capacité restante suffit-elle à porter toute la charge ? Survivre à la perte d'une zone avec trois zones signifie n'en faire tourner aucune à plus des deux tiers.

La série Nothing Fails Alone, ce sont quatre incidents travaillés sur exactement ce sujet, y compris un script read-only qui trouve les concentrations single-zone dans un compte AWS.

3. Control plane et data plane

Chaque plateforme a deux moitiés. Le data plane fait le travail : les instances tournent, les load balancers transmettent, le DNS répond. Le control plane change les choses : lancer une instance, modifier une route, redimensionner un groupe. Les control planes sont plus complexes et tombent plus souvent, et ils ont tendance à tomber pendant les gros incidents, c'est-à-dire exactement quand un plan de reprise veut s'en servir.

La question pour chaque procédure de reprise est donc de savoir si elle a besoin d'un appel au control plane pour réussir. Une conception qui survit à la perte d'une zone parce que la capacité tourne déjà ailleurs est statiquement stable. Une qui survit parce que l'autoscaling lancera des remplaçants dépend du control plane EC2 au moment où tous les autres clients l'appellent. L'article de l'Amazon Builders' Library sur la stabilité statique est la référence.

On-prem, la même séparation existe sous d'autres noms : l'API server Kubernetes, vCenter, l'automatisation IPAM et DNS, le fournisseur d'identité dont dépendent chaque login et chaque token de service. Demandez ce qui fonctionne encore quand chacun est en panne, et si l'outillage utilisé pour réparer une panne (le VPN, le bastion, le pipeline de déploiement, le système de chat) tourne sur l'infrastructure qu'il est censé réparer.

4. Les limites : la panne qui ressemble à un quota

La saturation, parmi les golden signals de la Partie 1, a une forme côté fournisseur que les métriques d'hôte ne montrent jamais. Sur AWS, les limites qui finissent dans les postmortems sont rarement le CPU :

• Service quotas. vCPU On-Demand en cours par famille d'instances, exécutions Lambda concurrentes par compte, Elastic IP, règles par security group. Un scale-out qui heurte un quota échoue au pire moment.
• Limites de débit d'API. Les API du control plane throttlent par compte et par Région. Un outil de déploiement, un autoscaler et un agent de supervision qui appellent tous Describe* peuvent se throttler mutuellement.
• Espace d'adressage. Un sous-réseau à court d'IP libres arrête les nouveaux pods, les nouvelles interfaces réseau Lambda et les nouvelles instances, avec une erreur qui ne mentionne aucun des trois.
• Plafonds par ressource. IOPS et débit d'un volume EBS, connexions d'une classe d'instance RDS, ports d'une NAT gateway.

Traitez chacune comme un SLI de saturation avec une alarme bien avant 100 pour cent. Pour beaucoup de quotas, CloudWatch publie l'utilisation dans le namespace AWS/Usage, et la fonction metric math SERVICE_QUOTA() renvoie la limite courante, donc une seule expression donne le pourcentage de quota utilisé. Pour le reste, un script d'inventaire planifié suffit.

On-prem, les limites sont physiques et plus lentes à relever : unités de rack, alimentation et refroidissement par rack, ports de switch, cœurs sous licence, débit des contrôleurs de stockage, la taille du plan d'adressage fait il y a cinq ans.

5. La capacité : élastique ne veut pas dire infini

La promesse du cloud, c'est que la capacité arrive en minutes. C'est en général le cas, et un SRE prévoit les fois où ce ne l'est pas. Un type d'instance précis dans une zone précise peut renvoyer InsufficientInstanceCapacity, le plus souvent pendant un événement de zone, quand tout le monde bascule vers les mêmes zones survivantes. Les défenses sont la diversité (plusieurs types d'instances et toutes les zones dans l'Auto Scaling group), le pré-provisionnement pour le cas de failover, et les On-Demand Capacity Reservations pour les charges qui ne peuvent pas attendre.

On-prem, le délai se compte en semaines ou en mois, donc la planification de capacité est une discipline de prévision : croissance mesurée, calendrier d'achats, et marge dimensionnée en N+1 ou N+2 par rapport aux domaines de défaillance ci-dessus. La décision qui affecte le plus la fiabilité se prend au moment de l'achat, bien avant l'incident qui la teste.

Dans les deux mondes, faites un test de charge pour trouver la première limite au lieu de l'estimer. Le chiffre qui compte est le niveau de trafic auquel le SLI de la Partie 2 commence à se dégrader, et quelle ressource en est la cause.

6. La maintenance : les incidents avec une date dessus

Une grande part des incidents est planifiée à l'avance par quelqu'un puis oubliée. Sur un cloud : avis de retrait d'instance, fenêtres de maintenance de base de données, versions de moteur et de Kubernetes arrivant en fin de support standard, expiration de certificats, runtimes dépréciés. AWS publie la plupart d'entre eux par compte via AWS Health, qui peut être routé via EventBridge dans la même file que le reste de votre travail opérationnel. Non lus, ils deviennent des redémarrages surprises.

On-prem, la liste est plus longue et entièrement à vous : firmware, patching d'hyperviseur et de système d'exploitation, remplacement de disques et de batteries, cycles de renouvellement matériel, contrats de support fournisseur, pièces de rechange sur site. Chacun a besoin d'un propriétaire et d'un calendrier. Une plateforme en retard de trois versions majeures dépense son budget d'erreur par avance.

La dernière vérification dans ce domaine, c'est la façon dont vous apprenez que le fournisseur passe une mauvaise journée. Une status page est écrite par des gens pendant un incident et prend du retard sur lui. Mesurez le fournisseur vous-même, de l'extérieur : un canary synthétique qui exerce le vrai chemin utilisateur depuis un autre réseau vous parle d'un problème régional avant le dashboard, et il garde le dénominateur du SLI vivant quand le vrai trafic ne peut pas vous atteindre.

Qui possède quoi

Aucune colonne n'est plus courte parce que le travail aurait disparu. Un cloud déplace les lignes du bas vers un fournisseur qui a plus de pratique que presque n'importe quelle entreprise seule, et en échange vous prenez une dépendance que vous ne pouvez pas inspecter. Ce compromis est en général le bon. Cela reste un compromis, et le SRE est la personne capable d'en énoncer les deux côtés.

Modes de défaillance et ce qu'il faut surveiller

Traiter le SLA comme une prévision. C'est une clause tarifaire avec un crédit attaché. Concevez d'après le comportement mesuré et les domaines de défaillance, pas d'après le pourcentage sur la page.

Multi-zone sur le schéma seulement. Trois zones dans la liste de sous-réseaux et une seule en état running, ou un failover qui n'a jamais été exercé. Testez-le volontairement, à l'intérieur du budget d'erreur.

Une reprise qui a besoin de ce qui est cassé. Des runbooks dont la première étape est un login console ou une exécution de pipeline dans la Région affectée.

Des limites découvertes en production. Chaque quota et plafond de la section 4 est bon marché à trouver dans un test de charge et cher à trouver pendant un lancement.

Où cela vous mène

Le parcours de la série, en un seul passage. Vous prenez en charge la fiabilité comme un problème d'ingénierie et vous plafonnez le travail manuel pour avoir le temps de le résoudre (Partie 1). Vous énoncez la fiabilité que le service doit viser sous forme de SLO, et vous dépensez l'écart délibérément comme un budget d'erreur avec une politique signée (Partie 2). Vous allez dans le dépôt corriger les timeouts, les retries et les rollouts qui décident du chiffre, et vous réveillez sur le burn rate plutôt que sur le CPU (Partie 3). Et vous savez ce que la plateforme sous vous promet, où elle tombe en bloc, et ce que vous ferez quand cela arrivera (Partie 4). Les outils pour les quatre, la plupart des ingénieurs les utilisent déjà. Ce qui fait de ce travail du SRE, c'est que chacun d'eux répond maintenant à une seule question : les utilisateurs obtiennent-ils la fiabilité convenue, et quel est le moyen le moins cher de la maintenir ?

À lire ensuite

• Partie 3 de cette série : Le SRE dans le code : timeouts, retries et alertes as code.
• The Fix Shares Fate With the Outage : trois incidents où le chemin de reprise dépendait du control plane qui était en panne.
• Your LLM Bill Is an Observability Problem sur ercan.ai : la même réflexion sur la dépendance au fournisseur appliquée aux API de modèles, où les quotas et le coût sont les signaux de saturation.

Pour du conseil en AWS, architecture cloud, pratique SRE, pipelines CI/CD, Linux et plus encore, commencez par ercanermis.com.

Références

• Amazon Builders' Library: Static stability using Availability Zones
• AWS whitepaper: AWS Fault Isolation Boundaries
• Amazon CloudWatch: Visualizing your service quotas and setting alarms
• Amazon EC2: On-Demand Capacity Reservations
• AWS Health: Monitoring events with Amazon EventBridge
• Amazon Compute Service Level Agreement
• Google SRE Book, Chapter 18: Software Engineering in SRE (capacity planning)