Programmeurs, devops et chats Schrodinger

La réalité d'un ingénieur réseau (avec des nouilles et ... du sel?)

Récemment, en discutant de divers incidents avec des ingénieurs, j'ai remarqué une tendance intéressante.

Dans ces discussions, la question de la «cause profonde» se pose invariablement. Les lecteurs fidèles sauront probablement que j'ai quelques réflexions à ce sujet. Dans de nombreuses organisations, l'analyse des incidents est entièrement basée sur ce concept. Ils utilisent différentes techniques pour identifier les relations de cause à effet, comme Five Why . Ces méthodes suggèrent la soi-disant "linéarité des événements" comme un dogme indéniable.

Lorsque vous remettez en question cette idée et faites remarquer que dans les systèmes complexes, la linéarité est trompeuse et rassurante, une discussion fascinante est née. Les débatteurs insistent avec passion sur le fait que seule la connaissance de la «cause profonde» nous permet de comprendre ce qui se passe.

J'ai remarqué un schéma intéressant: les développeurs et les développeurs réagissent différemment à cette idée. D'après mon expérience, les développeurs soutiennent plus souvent que la cause première est importante et que les relations de cause à effet peuvent toujours être établies dans les événements. D'un autre côté, les devops conviennent plus souvent qu'un monde complexe n'est pas toujours soumis à la linéarité.

Je me suis toujours demandé pourquoi? Qu'est-ce qui pousse les programmeurs à critiquer l'idée de «cause profonde - mythe»? Comme un système immunitaire qui reconnaît un agent étranger. Pourquoi réagissent-ils de cette façon alors que les devops sont plus susceptibles de considérer cette idée?

Je ne suis pas sûr, mais il y a une considération à cet égard. Elle est associée à différents contextes dans lesquels ces professionnels effectuent leur travail au quotidien.

Les développeurs travaillent souvent avec des outils déterministes. Bien sûr, les compilateurs, les éditeurs de liens, les systèmes d'exploitation sont tous des systèmes complexes, mais nous sommes habitués à donner un résultat déterministe, et nous les présentons comme déterministes: si nous fournissons les mêmes données d'entrée, alors nous nous attendons généralement à la même sortie de ces systèmes . Et s'il y a un problème («bug»), les développeurs le résolvent en analysant les données d'entrée (soit de l'utilisateur soit d'un ensemble d'outils dans le processus de développement). Ils recherchent une «erreur» puis modifient l'entrée. Cela corrige le bogue.


L'hypothèse principale du développement logiciel: les mêmes données d'entrée donnent de manière fiable et déterministe la même sortie

En fait, un résultat non déterministe est en soi considéré comme une erreur: si une conclusion inattendue ou erronée n'est pas reproduite, les développeurs cherchent à étendre l'étude à d'autres parties de la pile (système d'exploitation, réseau, etc.) qui se comportent également de façon plus ou moins déterministe, donnant la même chose résultat avec la même entrée ... et si ce n'est pas le cas , il est toujours considéré comme un bug. C'est juste que c'est maintenant un bug du système d'exploitation ou du réseau.

Dans tous les cas, le déterminisme est une hypothèse de base, presque considérée comme acquise pour la plupart du travail effectué par les programmeurs.

Mais pour tout devopa qui a passé la journée à collecter du fer dans des racks ou à trier l'API cloud, l'idée d'un monde complètement déterministe (tant qu'il est possible d'afficher toutes les données d'entrée!) Est, au mieux, un concept éphémère. Même en mettant de côté les blagues BOHF sur les taches solaires , des ingénieurs expérimentés ont vu les choses les plus étranges de ce monde. Ils savent que même un cri humain peut ralentir un serveur , sans parler de millions d'autres facteurs environnementaux.

Il est donc plus facile pour les ingénieurs expérimentés de douter que tous les incidents ont une seule cause racine, et des techniques comme «Five Why» correctement (et répétables!) Conduisent à cette cause racine. En fait, cela contredit leur propre expérience, lorsque les pièces du puzzle dans la pratique ne s'additionnent pas si clairement. Par conséquent, ils perçoivent plus facilement cette idée.

Bien sûr, je ne dis pas que les développeurs sont naïfs, stupides ou incapables de comprendre comment la linéarité peut être trompeuse. Les programmeurs expérimentés ont probablement également vu beaucoup de non-déterminisme au cours de leur vie.

Mais il me semble que la réaction habituelle des développeurs dans ces différends est souvent liée au fait que le concept de déterminisme dans son ensemble les sert bien dans le travail quotidien. Ils ne rencontrent pas le non-déterminisme aussi souvent que les ingénieurs doivent attraper les chats Schrodinger sur leur infrastructure.

Peut-être que cela n'explique pas complètement les réactions observées des développeurs, mais c'est un puissant rappel que nos réactions sont un mélange complexe de nombreux facteurs.

Il est important de garder cette complexité à l’esprit, que nous enquêtions sur un seul incident ou que nous travaillions ensemble sur un pipeline de livraison de logiciels ou que nous essayions de comprendre un monde plus large.