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 » revient invariablement. Les lecteurs fidèles savent probablement que j'ai sur . Dans de nombreuses organisations, l’analyse des incidents repose entièrement sur ce concept. Ils utilisent différentes techniques pour identifier les relations de cause à effet, telles que . Ces méthodes considèrent la « linéarité des événements » comme un dogme indiscutable.
Lorsque vous contestez cette idée et soulignez que la linéarité est trompeuse dans les systèmes complexes, une discussion fascinante naît. Les contestataires 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 sont plus susceptibles de soutenir que la cause profonde est importante et que des relations de cause à effet peuvent toujours être établies dans les événements. En revanche, les DevOps conviennent plus souvent qu’un monde complexe n’obéit pas toujours à la linéarité.
Je me suis toujours demandé pourquoi c'était ça ? Quoi fait aux programmeurs de critiquer l'idée « la cause profonde est un mythe » comme ça ? Comme un système immunitaire qui reconnaît un agent étranger. Pourquoi réagissent-ils de cette façon, alors que les développeurs plutôt enclin envisager cette idée ?
Je ne suis pas entièrement sûr, mais j'ai quelques réflexions à ce sujet. Elle concerne les différents contextes dans lesquels ces professionnels exercent leur travail 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 au fait qu'ils donnent un résultat déterministe, et nous les imaginons comme déterministes : si nous fournissons les mêmes données d'entrée, alors nous attendons généralement le même résultat. de ces systèmes. Et s'il y a un problème avec la sortie (« 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 pendant le processus de développement). Ils recherchent une « erreur » puis modifient les données d’entrée. Cela corrige le "bug".
Hypothèse de base du développement logiciel : les mêmes données d'entrée produisent de manière fiable et déterministe le même résultat.
En fait, un résultat non déterministe est lui-même considéré comme un bug : si le résultat inattendu ou erroné n'est pas reproduit, alors les développeurs ont tendance à étendre l'investigation à d'autres parties de la pile (système d'exploitation, réseau, etc.) qui se comportent également davantage. ou de manière moins déterministe, produisant le même résultat avec les mêmes données d'entrée... et si ce n'est pas le cas, alors cela est toujours considéré comme un bug. Il s'agit tout simplement d'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 allant de soi, pour une grande partie du travail effectué par les programmeurs.
Mais pour tout développeur qui a passé la journée à accumuler du matériel ou à trouver une API cloud, l'idée d'un monde complètement déterministe (tant qu'il est même possible de cartographier toutes les entrées !) est au mieux un concept éphémère. Même si tu le mets de côté , des ingénieurs expérimentés ont vu les choses les plus étranges de ce monde. Ils savent que , sans parler des millions d’autres facteurs environnementaux.
Il est donc plus facile pour les ingénieurs expérimentés de douter que tous les incidents aient une cause fondamentale unique, et des techniques telles que les « Cinq Pourquoi » mèneront correctement (et de manière répétée !) à cette cause fondamentale. En fait, cela contredit leur propre expérience, selon laquelle les pièces du puzzle ne s’intègrent pas aussi parfaitement dans la pratique. Ils acceptent donc plus facilement cette idée.
Bien sûr, je ne dis pas que les développeurs sont naïfs, stupides ou incapables de comprendre à quel point la linéarité peut être trompeuse.
Mais il me semble qu'une réaction commune des développeurs dans ces débats est souvent liée au fait que le concept de déterminisme les sert bien dans l'ensemble dans le travail quotidien. Ils ne sont pas confrontés au non-déterminisme aussi souvent que les ingénieurs doivent attraper les chats de Schrödinger sur leur infrastructure.
Cela n’explique peut-être pas entièrement les réactions observées des développeurs, mais cela nous rappelle avec force que nos réactions sont un mélange complexe de nombreux facteurs.
Il est important de garder à l'esprit cette complexité, qu'il s'agisse de faire face à un incident unique, de collaborer sur un pipeline de livraison de logiciels ou d'essayer de donner un sens au monde dans son ensemble.
Source: habr.com