Le diagramme que tout le monde dessine est celui du cas idéal : l'utilisateur atteint l'application, l'application atteint la base de données, terminé. C'est bien pour un tableau blanc et inutile pour exploiter un système. La production a une autre forme, car elle doit survivre aux pics de trafic, aux pannes de nœuds, aux déploiements et à l'occasionnel mauvais après-midi. Visualiser cette réalité, et non le croquis bien rangé, est ce qui transforme un diagramme en outil opérationnel.
L'astuce consiste à arrêter de dessiner « qui parle à qui » et à dessiner trois vues qui se superposent : le chemin du trafic, les domaines de défaillance et les limites de mise à l'échelle. La plupart des diagrammes de production sont confus parce qu'ils essaient de montrer les trois à la fois sans intention. Dessinez-les délibérément et l'image devient quelque chose avec quoi vous pouvez réellement raisonner à 3 heures du matin.
Vue un : le chemin du trafic
Suivez une seule requête depuis le monde extérieur jusqu'aux données et retour, et dessinez chaque saut qu'elle effectue réellement. En production, ce chemin est plus long que ne l'admet le croquis :
- Un CDN ou un edge en façade, qui sert les hits de cache avant même que votre origine ne les voie.
- Un répartiteur de charge qui distribue le trafic entre les instances.
- Une couche de serveurs d'application sans état, pas une seule boîte.
- Un cache que la plupart des lectures atteignent avant la base de données.
- Une base de données primaire pour les écritures et des réplicas en lecture pour le reste.
- Un chemin asynchrone : une file d'attente et des workers pour le travail qui ne doit pas se faire en ligne.
Vue deux : les domaines de défaillance
Dessinez maintenant les lignes qui regroupent les éléments selon « ce qui tombe en panne ensemble ». Les zones de disponibilité sont l'exemple évident : deux ou trois colonnes, avec votre couche applicative et votre couche de données réparties entre elles, pour qu'une panne de zone ne vous mette pas à terre. Mais les domaines de défaillance vont au-delà des zones. Un cache partagé est un domaine. Une base de données primaire unique est un domaine. La file d'attente est un domaine. Dessiner ces frontières rend vos points de défaillance uniques impossibles à manquer, car ils apparaissent comme la boîte dont tout dépend et qui n'a aucun partenaire à côté d'elle.
Un diagramme de production prouve sa valeur dès l'instant où il vous montre la boîte que vous ne pouvez pas vous permettre de perdre.
Vue trois : les limites de mise à l'échelle
Indiquez ce qui passe à l'échelle et comment. La couche applicative évolue horizontalement : dessinez-la comme un groupe qui grandit, pas comme une paire fixe. La base de données évolue différemment, verticalement pour les écritures, horizontalement avec des réplicas pour les lectures, et cette asymétrie mérite d'être montrée car c'est là que les systèmes de production se heurtent à un mur. Les groupes d'autoscaling, les pools de workers qui s'étendent selon la profondeur de la file d'attente et tout composant à capacité fixe méritent une note visible. L'histoire de la mise à l'échelle représente la moitié de la planification de capacité, et elle vit dans cette vue.
N'oubliez pas les éléments qui n'existent qu'en production
Le document de conception les omet ; la production ne le peut pas. L'observabilité (métriques, logs, traces) se branche sur presque chaque composant. Les secrets et la configuration viennent de quelque part. Il y a un bastion ou un chemin d'accès privé pour les humains. Les sauvegardes s'exécutent sur la couche de données. Vous n'avez pas besoin de tout dessiner dans un seul diagramme, et vous ne devriez pas, mais une image de production qui les omet tous est une fiction. Donnez une boîte aux plus importants.
Gardez-le à jour, sinon il ment
Un diagramme de production n'est utile que s'il correspond à la production, et la production change constamment. C'est l'argument pour le dériver de votre Terraform ou de vos manifestes et le régénérer à intervalles réguliers, plutôt que d'entretenir amoureusement à la main un dessin qui dérive. Associez le squelette généré à vos annotations, intégrez-le dans le runbook et rafraîchissez-le quand l'infrastructure bouge. Un diagramme de production à jour est l'un des documents à plus fort effet de levier qu'une équipe puisse posséder.
Dessinez le chemin du trafic, marquez les domaines de défaillance, montrez les limites de mise à l'échelle et générez la base à partir de l'infrastructure réelle pour qu'elle reste fidèle. C'est le diagramme que vous voulez vraiment avoir ouvert pendant un incident.