Lire la queue longue
La latence vit sur une courbe, pas sur un nombre
Une latence moyenne cache ce que les utilisateurs vivent. Les vrais services produisent une distribution: une courbe montrant combien de requêtes ont pris combien de temps.
Trois points sur cette courbe portent la majeure partie du sens opérationnel:
- p50 (médiane): le milieu de la distribution. La moitié des requêtes se terminent plus vite, l'autre moitié plus lentement. Décrit l'expérience typique.
- p99: le 99e percentile. Seulement 1% des requêtes ont pris plus longtemps que cela. Décrit la pire expérience pour les utilisateurs typiques.
- p99.9: seulement 0,1% des requêtes ont pris plus longtemps. Décrit la pire expérience pour les utilisateurs avancés qui accèdent au service souvent.
Insight géométrique: les distributions de latence ont presque toujours une queue longue à droite. La courbe monte rapidement jusqu'à un pic autour de la médiane, puis descend lentement vers la droite, souvent avec une petite bosse loin de la moyenne. Cette bosse représente les utilisateurs les plus lents: ceux qui écrivent des tickets en colère.
Pourquoi les moyennes trompent: un service avec médiane de 50 ms & p99 de 5 000 ms a un écart de 100x entre l'expérience typique & celle de la queue. La moyenne arithmétique pourrait se situer à 100 ms, cachant complètement la catastrophe. La moyenne arithmétique est une projection de point unique d'une forme 2D: presque toutes les informations de la forme disparaissent.
Le problème de multiplication des percentiles: une requête qui touche 10 services backend, chacun avec un p99 de 100 ms, a un p99 d'environ 600 ms (pas 100 ms). Les queues lentes se multiplient. C'est pourquoi le livre SRE avertit: «méfiez-vous du plus lent de N». À mesure que N augmente, la latence de votre queue se dégrade rapidement.
Mathématiques de la latence de queue
Le service A a un flux de requête qui se divise en 5 services backend en parallèle & attend toutes les réponses. Chaque backend a une latence p99 de 100 ms.
Dépletion du budget comme pente
Tracer le budget au fil du temps
Un budget d'erreur tracé sur des axes 2D (le temps sur x, le budget restant sur y) révèle la santé du service en un coup d'œil. La forme de la courbe de dépletion porte les mêmes informations que dix tableaux de bord individuels.
Trois formes de référence:
- Dépletion linéaire saine: le budget baisse en ligne droite proportionnelle au temps écoulé. Au jour 14 d'une fenêtre de 28 jours, la moitié du budget devrait rester. C'est l'objectif SLO rendu visible.
- Combustion rapide: une pente raide vers le bas. Indique un problème de fiabilité actif. Si la pente est assez raide, le budget s'épuise avant le reset de la fenêtre, déclenchant la politique de budget d'erreur.
- Courbe guérie: un segment plat ou montant. Le service fonctionne mieux que son SLO. Le budget restant augmente au fil du temps, ouvrant la place à des lancements risqués.
Burn rate est la pente de la ligne de dépletion, normalisée: un burn rate de 1 signifie brûler le budget exactement aussi vite que le temps passe (parfaitement aligné avec SLO). Un burn rate de 10 signifie brûler 10x plus vite que permis: le budget mensuel entier se déplèrerait en 2,8 jours à ce rythme.
Alertes multi-fenêtre multi-burn-rate: le cahier de travail SRE de Google recommande d'alerter sur des conditions combinées comme 'burn rate au-dessus de 14,4 au cours de la dernière heure ET au-dessus de 14,4 au cours des 5 dernières minutes'. La géométrie: une pente raide soutenue, pas juste une brève pointe. Cette forme filtre les perturbations transitoires tout en attrapant les menaces de dépletion réelles.
Lire un burn rate
L'objectif SLO de votre équipe est 99,9% sur 28 jours. Au jour 7, vous avez déjà utilisé 60% de votre budget d'erreur. Le burn rate actuel au cours des 24 dernières heures est de 8.
Les services comme graphique dirigé
La production comme un DAG
Les services modernes fonctionnent comme un graphique de dépendances. Chaque service est un nœud. Chaque appel du service A au service B est une arête dirigée de A à B. L'image complète forme un graphique dirigé (parfois un DAG, parfois avec des cycles via les tentatives asynchrones).
Propriétés géométriques critiques:
- Out-degree: combien de services un nœud dépend. Un out-degree plus élevé signifie plus de modes de défaillance en amont. Un service qui dépend de 12 backends échoue si l'un de ces 12 échoue.
- In-degree (fan-in): combien de services dépendent de ce nœud. Un in-degree plus élevé signifie qu'une seule défaillance ici se cascade largement. Une base de données avec 30 services dépendants a le rayon de blast le plus grand.
- Centralité de betweenness: combien de chemins les plus courts passent par un nœud. Les nœuds à haut betweenness sont les points d'étranglement. Les services d'authentification & les API principales marquent généralement haut.
- Composantes fortement connectées: groupes de services qui forment des cycles. Si A appelle B & B appelle A, vous avez un cycle. Les cycles compliquent la récupération de défaillance: démarrer l'un des services nécessite que l'autre fonctionne déjà.
Blast radius est le concept géométrique qui dirige l'investissement en fiabilité. Le rayon de blast d'une défaillance est le sous-graphique de services dépendants qu'elle affecte. L'ingénierie de la fiabilité investit lourdement dans les nœuds avec le plus grand rayon de blast. Le moyen le moins cher d'améliorer la fiabilité globale du système est souvent d'ajouter de la redondance ou de la dégradation gracieuse aux nœuds avec le plus haut betweenness.
Raisonnement du rayon de blast
Un service consommateur dépend de: AuthService, UserDB, ProductCatalog, PaymentGateway, RecommendationEngine, EmailService, AnalyticsService. AuthService a 47 autres services dépendant de lui. EmailService a 3 autres services dépendant de lui. RecommendationEngine a 2 autres services dépendant de lui.
Géométrie de l'information d'un tableau de bord
Les pixels sont un bien immobilier
Un tableau de bord est une surface 2D avec une zone finie. Chaque pixel alloué à un signal est un pixel non alloué à un autre. La conception du tableau de bord est un problème de géométrie: disposer les informations les plus pertinentes pour la décision dans la plus petite zone visuelle tout en préservant les relations spatiales qui aident à la reconnaissance.
Modèles de lecture: les lecteurs occidentaux scannent en forme de F (haut-gauche d'abord, puis à travers, puis vers le bas). Le signal le plus important appartient au haut-gauche. Le bas-droit reçoit le moins d'attention.
Groupage Gestalt: les signaux du même service appartiennent au même groupe visuel. La latence, le trafic, les erreurs & la saturation d'un service appartiennent à une grille 2x2, pas dispersés sur l'écran. La proximité visuelle encode la relation logique.
Codage couleur: rouge pour les erreurs, jaune pour la saturation, vert pour les plages saines. Les choix de couleur sont des conventions, pas aléatoires. Les inverser coûte de la charge cognitive à chaque coup d'œil pendant les incidents.
Mise à l'échelle de l'axe Y: un graphique mis à l'échelle 0-100% paraît calme même pendant un doublement du trafic. Un graphique mis à l'échelle automatiquement aux valeurs récentes paraît alarmant pendant la variation normale. Les deux choix ont des utilisations appropriées; le choix est géométrique, pas cosmétique.
Densité d'information: trop peu de signaux laissent l'équipe aveugle à ce qui ne va pas. Trop de signaux enterrent le signal dans le bruit. Le ratio data-ink d'Edward Tufte s'applique: maximisez le ratio d'encre qui transmet l'information à l'encre qui décore. Le minimalisme de style sparkline bats les widgets encombrés d'un coup d'œil.
Concevoir pour un premier coup d'œil
Votre équipe conçoit un seul tableau de bord principal pour un service qui a 8 SLI critiques sur 4 dépendances backend. Le tableau de bord doit répondre à la première question de l'ingénieur on-call à 3 du matin en moins de 5 secondes: 'est-ce qu'il y a quelque chose qui brûle, & si oui, où?'
Géométrie de l'ingénierie de la fiabilité de site: conclusion
Les formes qui font fonctionner la production
Vous avez parcouru quatre structures géométriques qui fonctionnent sous la pratique SRE:
- Distributions de latence comme des courbes à queue longue où les points percentiles portent plus de vérité que les moyennes
- Cônes de budget d'erreur où la pente de dépletion révèle la santé du service mieux que le nombre restant
- Graphiques de dépendance de service où le rayon de blast & la centralité dirigent l'investissement en fiabilité
- Mises en page de tableau de bord comme une zone 2D où l'allocation de pixels est un problème de géométrie avec des conséquences opérationnelles
La pensée géométrique est ce qui sépare l'ingénierie de la fiabilité du travail opérationnel générique. Un ingénieur ops lit des nombres. Un ingénieur SRE lit des formes. Les formes codent les informations qu'aucun nombre unique ne peut capturer: la pente d'un burn rate, la fatness d'une queue, la centralité d'un nœud, la gestalt d'un panneau de tableau de bord.
La leçon compagnon sur l'ingénierie de la fiabilité elle-même couvrait les pratiques. Cette leçon couvrait la géométrie sous-jacente. Ensemble, ils forment l'échafaudage visuel & conceptuel de l'ingénierie de la fiabilité moderne.