La première fois que je suis tombé sur le terme système pathologique, j’ai dû chercher ce que cela signifiait. La définition que j'ai trouvée ressemblait à ceci :
système pathologique : présente des comportements extrêmes, anormaux ou autodestructeurs
La deuxième fois que je l’ai découvert, c’était dans le discours de Bryan Cantrill sur les systèmes pathologiquement performants et je l’ai défini comme « des systèmes qui ne fonctionnent pas ».
Cela m'est resté. (L’idée, pas le mot bien sûr. Que j’ai dû chercher à nouveau tout à l’heure.) Il y a quelque chose de vraiment fascinant dans les systèmes qui ne fonctionnent pas comme ils le devraient. Je veux dire : un comportement que personne n’a conçu, que personne ne s’attendrait et peut-être que personne ne comprend – quoi de plus fascinant que ça ?
Dans ma vie de développeur, j’ai eu de nombreuses occasions d’observer des systèmes pathologiques. La plupart d'entre eux au début, lorsque je travaillais sur des applications SaaS, la distinction animal de compagnie/bétail n'était pas encore si courante et votre système de production était un gentil animal de compagnie que vous surveilliez tous les jours, pour vous assurer qu'il ne tombe pas malade (tamagotchi c’est de toi que je parle!).
Mais les deux dernières semaines m'ont apporté une autre chance et j'ai passé avec un collègue à faire principalement une chose : observer un système pathologique et essayer de le réparer, patch par patch.
Observer un système pathologique est un acte contemplatif : vous regardez des graphiques, vous fouillez dans la base de données et exécutez des requêtes, vous regardez tel tableau de bord et tel tableau de bord et essayez de corréler les comportements, vous lisez des logs (journeaux) pour tenter de combler des lacunes dans les connaissances. Vous créez des hypothèses et des théories, certaines très éphémères, d’autres pouvant conduire à une solution.
Le système – fonctionnant dans des centres de données éloignés de vous – commence à paraître beaucoup plus réel et, oserais-je le dire à l'époque de l'IA, vivant lorsque vous passez deux jours à regarder trois graphiques qui montent et descendent en fonction du bouton sur lequel vous appuyez. .
Vous dites des choses comme celles-ci à voix haute :
« Oh, maintenant, pourquoi cela a-t-il augmenté ? Cela ne devrait pas, n’est-ce pas ? »
" 90% de ces graphiques sont inutiles. "
" D'accord, nous avons besoin de X. "
« Ouais, non, c’est ce que fait le code. On dirait que je l’ai même examiné et approuvé. »
"Ahhh, tu sais quoi, peu importe."
"Est-ce que quelqu'un a déjà vu ça?"
« Pourquoi un redémarrage résoudrait-il ce problème ? »
"Cela n'a pas de sens."
"Et puis merde, essayons."
Chaque ligne ici est une leçon. En observant un système pathologique, vous trouvez des bugs et des hypothèses incorrectes dans le code. Vous apprenez comment le système se comporte réellement et à quel point vos hypothèses sur ce à quoi ressemblerait un système se comportant correctement étaient erronées.
Comme Bryan Cantrill le dit dans ses diapositives pour une autre conférence:
Mais un comportement étrange mérite d’être compris : au pire, il améliore notre propre compréhension (c’est-à-dire que le comportement est en fait attendu), mais un comportement étrange peut être un indicateur de quelque chose de bien plus profond – et représente en fait une présentation par ailleurs inoffensive de quelque chose de bien plus grave. un défaut important !
Alors, la prochaine fois que vous rencontrez quelque chose d’étrange : considérez-le comme une opportunité d’apprendre quelque chose.
Merci d'avoir lu.