Je passe mes journées à manipuler des objets, des tables et des services. À force, un serveur devient le rectangle propre et toujours disponible du diagramme. En réalité, une requête traverse une chaîne physique dont chaque morceau peut interrompre le service.

Prenons une page de commande :

utilisateur → commutateur → firewall → serveur Web
            → commutateur → serveur applicatif
            → réseau SAN → baie de disques

Le serveur Web dépend de ses alimentations, d’une unité de distribution, d’un UPS et du courant du bâtiment. Les commutateurs et la baie ont leur propre chemin. La climatisation retire la chaleur produite. Le DNS et Active Directory peuvent être sur d’autres machines encore. Aucun de ces éléments n’apparaît dans la méthode EnregistrerCommande, mais ils participent à son exécution.

La redondance doit suivre des domaines de panne. Deux serveurs branchés sur la même PDU partagent la panne de cette PDU. Deux cartes réseau dans le même commutateur partagent le commutateur. Deux machines virtuelles placées sur le même hôte — si l’infrastructure utilise cette approche — partagent l’hôte. Compter deux boîtiers ne suffit pas.

Je dessinerais les chemins A et B :

Dépendance	Chemin A	Chemin B	Test de bascule
alimentation serveur	PDU-A / UPS-A	PDU-B / UPS-B	retirer une alimentation
réseau	NIC-A / SW-A	NIC-B / SW-B	couper un port
stockage	HBA-A / fabric-A	HBA-B / fabric-B	désactiver un chemin
application	WEB01	WEB02	retirer WEB01 du répartiteur

Si les colonnes A et B rejoignent finalement le même disjoncteur ou le même contrôleur, la séparation est incomplète. Le test doit provoquer la perte d’un chemin pendant une charge, pas seulement vérifier que les voyants sont verts.

La température fait partie de la disponibilité. Un serveur de 500 W transforme presque toute cette puissance en chaleur. Vingt machines représentent 10 kW, environ 34 000 BTU/h à extraire. Une climatisation arrêtée n’éteint pas les serveurs instantanément; la température monte, les ventilateurs accélèrent, certains processeurs réduisent leur fréquence, puis les protections coupent. Le premier symptôme applicatif peut être une lenteur avant l’arrêt.

Les compteurs doivent donc relier les couches :

1. temps de réponse et erreurs de l’application;
2. files de requêtes du serveur Web;
3. CPU, mémoire et garbage collection;
4. latence et file des disques;
5. erreurs réseau et bascules de liens;
6. température d’entrée, courant et état UPS;
7. profondeur des files dans les services dépendants.

Avec une heure synchronisée et un identifiant de corrélation, on peut voir qu’une pointe de latence SQL coïncide avec la reconstruction d’un disque ou une bascule SAN. Sans ça, chaque équipe possède un graphique séparé et conclut que sa couche va bien.

Une panne physique crée aussi de l’incertitude métier. Si le serveur tombe après le commit SQL mais avant la réponse HTTP, la personne reclique sur l’autre nœud. Une architecture redondante sans identifiant d’opération fabrique deux commandes plus efficacement. Haute disponibilité et idempotence doivent donc être conçues ensemble.

La capacité mérite une marge. Faire rouler chaque serveur à 90 % fonctionne jusqu’à la perte d’un nœud, quand les survivants doivent absorber sa charge. Je teste le service avec un nœud absent et je garde assez de courant, refroidissement, ports réseau et IOPS pour ce mode dégradé. La sauvegarde reste nécessaire même avec RAID et cluster; une suppression logique se réplique très bien.

Je ne vais pas régler la climatisation moi-même. Ma pratique d’architecte-développeur sera de mettre sur le diagramme les dépendances qui changent la panne, demander leurs chemins communs et participer à un exercice de bascule. Le rectangle Serveur peut rester simple dans une vue, mais l’équipe doit posséder une deuxième vue qui montre ce qui le garde réellement vivant.