A realidade dun enxeñeiro de rede (con fideos e... sal?)
Recentemente, mentres discutía varios incidentes cos enxeñeiros, notei un patrón interesante.
Nestas discusións, invariablemente xorde a cuestión da "causa raíz". Os lectores fieis probablemente saben que o teño en . En moitas organizacións, a análise de incidentes baséase totalmente neste concepto. Utilizan diferentes técnicas para identificar relacións causa-efecto, como . Estes métodos asumen a chamada "linealidade dos acontecementos" como un dogma indiscutible.
Cando desafías esta idea e sinalas que a linealidade é un engano tranquilizador nos sistemas complexos, nace unha discusión fascinante. Os disputantes insisten apaixonadamente en que só o coñecemento da "causa raíz" nos permite comprender o que está a suceder.
Notei un patrón interesante: os desenvolvedores e os devops reaccionan de forma diferente a esta idea. Segundo a miña experiencia, os desenvolvedores son máis propensos a argumentar que a causa raíz importa e que as relacións causa-efecto sempre poden establecerse nos eventos. Por outra banda, os DevOps coinciden con máis frecuencia en que un mundo complexo non sempre obedece á linealidade.
Sempre me preguntei por que é isto? Que fai programadores para criticar a idea de "a causa raíz é un mito" así? Como un sistema inmunitario que recoñece un axente estraño. Por que reaccionan deste xeito, mentres que os devops máis ben inclinado considera esta idea?
Non estou totalmente seguro, pero teño algunhas reflexións sobre isto. Relaciona os distintos contextos nos que estes profesionais desenvolven o seu traballo diario.
Os desenvolvedores adoitan traballar con ferramentas deterministas. Por suposto, os compiladores, os enlazadores e os sistemas operativos son todos sistemas complexos, pero estamos afeitos a que dan un resultado determinista e imaxinamos que son deterministas: se proporcionamos os mesmos datos de entrada, normalmente esperamos a mesma saída. a partir destes sistemas. E se hai un problema coa saída ("erro"), os desenvolvedores solucionan-lo analizando os datos de entrada (xa sexa do usuario ou dun conxunto de ferramentas durante o proceso de desenvolvemento). Buscan un "erro" e despois cambian os datos de entrada. Isto soluciona o "error".
Suposición básica do desenvolvemento de software: os mesmos datos de entrada producen de forma fiable e determinista a mesma saída.
De feito, un resultado non determinista é en si mesmo considerado un erro: se non se reproduce a saída inesperada ou errónea, entón os desenvolvedores tenden a estender a investigación a outras partes da pila (sistema operativo, rede, etc.) que tamén se comportan máis. ou de forma menos determinista, producindo o mesmo resultado cos mesmos datos de entrada... e se non é o caso, entón isto aínda se considera un erro. Agora é un erro do sistema operativo ou da rede.
En calquera caso, o determinismo é un suposto básico, case dado por feito, para gran parte do traballo que fan os programadores.
Pero para calquera tipo de devops que pase o día acumulando hardware ou descubrindo unha API na nube, a idea dun mundo completamente determinista (sempre que sexa posible mapear todas as entradas!) É un concepto fugaz no mellor dos casos. Aínda que o deixes de lado , enxeñeiros experimentados viron as cousas máis estrañas deste mundo. Eles sábeno , sen esquecer os millóns de outros factores do medio ambiente.
Polo tanto, é máis fácil para os enxeñeiros experimentados dubidar de que todos os incidentes teñan unha única causa raíz, e técnicas como os "Cinco por que" levarán correctamente (e repetidamente!) a esa causa raíz. De feito, isto contradí a súa propia experiencia, onde as pezas do puzzle non encaixan tan ben na práctica. Polo tanto, aceptan esta idea máis facilmente.
Por suposto, non digo que os desenvolvedores sexan inxenuos, estúpidos ou incapaces de entender como a linealidade pode ser enganosa.
Pero paréceme que unha reacción común dos desenvolvedores nestes debates ten que ver moitas veces co feito de que o concepto de determinismo sérvenlles ben en xeral no traballo cotián. Non atopan o non determinismo tantas veces como os enxeñeiros teñen que atrapar os gatos de Schrödinger na súa infraestrutura.
É posible que isto non explique completamente as reaccións observadas dos desenvolvedores, pero é un poderoso recordatorio de que as nosas reaccións son unha complexa mestura de moitos factores.
É importante lembrar esta complexidade, tanto se estamos lidando cun único incidente, colaborando nunha canalización de entrega de software ou tratando de dar sentido ao mundo máis amplo.
Fonte: www.habr.com