Leçons d’observabilité de Tchernobyl – appliquées aux logiciels
Appliqué au logiciel
Cette histoire n’essaie nullement de faire la lumière sur l’incident de Tchernobyl. Il essaie de montrer que l’observabilité et la résilience sont un problème qui existe depuis longtemps et que nous pouvons apprendre les uns des autres pour améliorer nos systèmes. J’ai écrit cela après avoir regardé la série HBO TV si vous ne l’avez pas regardée, ajoutez-la à votre liste de surveillance car c’est une émission vraiment intéressante et révélatrice.
Voici quelques points clés avec lesquels je me suis connecté en regardant la série en relation avec certains des problèmes que nous avons vus avec notre observabilité. Espérons que vous n’aurez pas à faire face à ces problèmes après avoir lu ceci et amélioré vos applications.
Pas génial, pas terrible
Les compteurs Geiger de la salle de contrôle de la centrale n’ont augmenté que de 3,6. Vous vous demandez peut-être en quoi cela est pertinent dans le monde du génie logiciel?
Si vous souhaitez mesurer des temps de réponse longs de votre service, vous utiliserez probablement des centiles. Souvent, vous souhaiterez voir les temps de réponse du 95e ou 99e centile. Il s’agit du délai maximum de 95% ou 99% des demandes. Si vous utilisez simplement une moyenne et que vous avez quelques demandes qui prennent beaucoup de temps, vous ne vous en rendrez peut-être pas compte car elles seront masquées par la moyenne.
Le calcul des moyennes et des centiles dans un système distribué est un peu plus compliqué. Un système distribué dans ce sens est chaque fois que vous exécutez plusieurs instances d’un service, cela peut être en utilisant Kubernetes, AWS, etc. Nous voulons connaître le temps de réponse moyen sur toutes les instances. Si chaque instance calculait sa propre moyenne et que nous faisions la moyenne, nous introduirions un biais car nous ne pouvons garantir que toutes les instances reçoivent le même nombre de demandes. Pour contourner ce problème, chaque instance expose le nombre de demandes et la somme des demandes de traitement. Cela nous permet de calculer la moyenne en tenant compte du nombre de demandes. L’équation serait sum(total_time) / sum(number_requests).
Pour calculer les centiles dans un système distribué, nous utilisons des compartiments. Chaque compartiment compte le nombre de demandes qui ont pris moins que l’étiquette de temps des compartiments. Plusieurs compartiments sont utilisés pour couvrir une gamme de temps de réponse. Lors de la visualisation des centiles, une équation est utilisée pour le calculer à partir des compartiments. Prométhée a une fonction intégrée pour calculer cela pour vous. Voir ici pour la documentation Prometheus sur cette fonction.
Alors, que se passe-t-il si les temps de réponse dépassent l’étiquette de temps de réponse maximum du compartiment? Le seul compartiment qui capturera les demandes est le compartiment infini qui ne nous aide pas beaucoup car toutes les demandes sont inférieures à l’infini. Les équations qui calculent les centiles continueront de fonctionner, mais seront essentiellement plates et maximales à la taille maximale du compartiment. Donc, si votre compartiment maximal est d’une seconde mais que le temps de réponse est d’une minute, les graphiques montreront que le 99e centile prend une seconde. Cela vous fera penser que les choses ont augmenté, mais elles ne sont pas si mauvaises.
Pour lutter contre cela, je suggère d’avoir un temps de réponse moyen disponible sur le même graphique ou des graphiques adjacents aux centiles. De cette façon, si le temps de réponse moyen se rapproche des centiles ou même plus, vous savez que quelque chose se passe.
Mesurer de loin
L’une des raisons pour lesquelles les gens savaient que Tchernobyl était un problème grave était due au fait que les capteurs lointains mesuraient l’augmentation du rayonnement. Vous ne devez pas vous fier aux mesures locales sur les systèmes, car dans les scénarios de défaillance, ils peuvent devenir erronés. Nous devons viser à rendre notre surveillance aussi précise que possible, mais nous ne voulons pas non plus avoir un seul point de défaillance.
Il y a beaucoup de choses entre deux services qui se parlent. Que ce soit le DNS, les équilibrages de charge ou simplement la création de connexions, cela crée un espace où beaucoup de choses peuvent mal se passer. Selon la technologie de surveillance que vous utilisez, vous pouvez être limité au nombre de mesures qu’une application peut exposer. À mon avis, il est important de mesurer les services en aval, mais vous n’aurez peut-être pas besoin qu’il soit aussi granulaire que les mesures de demande de services. Pour les demandes entrantes, vous souhaiterez peut-être mesurer les centiles et les SLO pour tous les codes d’état. Pour l’aval, vous ne pouvez vous soucier que du temps de réponse moyen et des codes d’état groupés, par exemple les 200 par rapport à une métrique individuelle pour 200 et 201. Si vous souhaitez des métriques plus approfondies sur le service, vous pouvez consulter les métriques provenant du service lui-même. Cela vous donne suffisamment d’informations pour déboguer un problème entre les services plutôt qu’un problème dans le service lui-même. Il vous permet également de voir les métriques de base même si le service est en panne.
Faire confiance mais vérifier
Ceci est un vieux proverbe russe utilisé dans la série, je trouve cela drôle car vous ne faites pas vraiment confiance à quelque chose si vous devez le vérifier. Lorsqu’un problème en direct se produit généralement, quelqu’un trouve une anomalie dans un graphique et démarre l’analyse des causes profondes de b̶l̶a̶m̶e. Il est important de vérifier que cette métrique est correcte car il pourrait s’agir d’un bogue avec le rapport ou même causé par quelque chose d’autre sous-jacent à la métrique.
Le but est de comprendre la cause du problème en direct et de le résoudre. Il est important de vérifier votre hypothèse avant de commencer à changer les choses, à perdre du temps et éventuellement à aggraver les choses. Il est important que les personnes utilisant les métriques comprennent comment elles fonctionnent et d’où elles dérivent pour arrêter les devinettes et les décisions incorrectes. Idéalement, les personnes qui possèdent l’application et maintiennent les métriques et le service sont celles qui répondent aux problèmes réels afin de pouvoir prendre des décisions éclairées.
Pourquoi vous inquiéter de quelque chose qui ne va pas se produire?
Il y a certainement un équilibre entre la création d’un incroyable système à 100% de disponibilité et celui qui fonctionne techniquement mais qui est super buggy et qui tombe tout le temps. Malheureusement, je pense que la plupart des équipes ont une résilience et une observabilité. Pour moi, la différence entre l’observabilité et la surveillance réside dans le fait que vous êtes préventif et que vous ajoutez la surveillance aux problèmes et situations potentiels qui peuvent mal tourner.
J’ai dû plaider pour la mise en œuvre de quelque chose pour se protéger contre un échec qui ne s’était pas encore produit (avec des mesures pour le montrer en effet ne l’ont pas encore fait). J’ai décidé de formuler des choses légèrement différentes maintenant plutôt que de dire «si x se produit», je dis «quand x se produit» car nous devons entrer dans l’état d’esprit des choses changent constamment, provoquant inévitablement la rupture des choses et c’est Ordinaire et un signe de progrès. Cela est particulièrement courant dans l’architecture de microservices lorsque les équipes publient régulièrement de la valeur pour les clients.
