La realidad de un ingeniero de redes (con fideos y… ¿sal?)
Recientemente, mientras hablaba de varios incidentes con ingenieros, noté un patrón interesante.
En estas discusiones, invariablemente surge la cuestión de la “causa raíz”. Los lectores fieles probablemente sepan que tengo en . En muchas organizaciones, el análisis de incidentes se basa enteramente en este concepto. Utilizan diferentes técnicas para identificar relaciones de causa y efecto, como . Estos métodos asumen la llamada “linealidad de los acontecimientos” como dogma indiscutible.
Cuando se cuestiona esta idea y se señala que la linealidad es tranquilizadoramente engañosa en sistemas complejos, nace una discusión fascinante. Los contendientes insisten apasionadamente en que sólo el conocimiento de la “causa raíz” nos permite comprender lo que está sucediendo.
Noté un patrón interesante: los desarrolladores y los devops reaccionan de manera diferente a esta idea. En mi experiencia, es más probable que los desarrolladores argumenten que la causa raíz importa y que siempre se pueden establecer relaciones de causa y efecto en los eventos. Por otro lado, los DevOps suelen estar de acuerdo en que un mundo complejo no siempre obedece a la linealidad.
Siempre me pregunté por qué es esto. Qué hace ¿Los programadores critican así la idea de que “la causa raíz es un mito”? Como un sistema inmunológico que reconoce un agente extraño. ¿Por qué reaccionan de esta manera, mientras que los devops bastante inclinado considerar esta idea?
No estoy del todo seguro, pero tengo algunas ideas al respecto. Se relaciona con los diferentes contextos en los que estos profesionales desarrollan su trabajo diario.
Los desarrolladores suelen trabajar con herramientas deterministas. Por supuesto, los compiladores, los enlazadores, los sistemas operativos son sistemas complejos, pero estamos acostumbrados a que den un resultado determinista y los imaginamos como deterministas: si proporcionamos los mismos datos de entrada, normalmente esperamos que el mismo resultado de estos sistemas. Y si hay un problema con la salida (“error”), entonces los desarrolladores lo resuelven analizando los datos de entrada (ya sea del usuario o de un conjunto de herramientas durante el proceso de desarrollo). Buscan un "error" y luego cambian los datos de entrada. Esto soluciona el "error".
Supuesto básico del desarrollo de software: los mismos datos de entrada producen de manera confiable y determinista el mismo resultado.
De hecho, un resultado no determinista se considera en sí mismo un error: si el resultado inesperado o erróneo no se reproduce, entonces los desarrolladores tienden a extender la investigación a otras partes de la pila (sistema operativo, red, etc.), que también se comportan más o menos determinista, produciendo el mismo resultado con los mismos datos de entrada... y si no es, entonces esto todavía se considera un error. Ahora es un error del sistema operativo o de la red.
En cualquier caso, el determinismo es un supuesto básico, casi dado por sentado, en la mayoría del trabajo que realizan los programadores.
Pero para cualquier desarrollador de desarrollo que haya pasado el día acumulando hardware o descubriendo una API en la nube, la idea de un mundo completamente determinista (¡siempre que sea posible mapear todas las entradas!) es, en el mejor de los casos, un concepto fugaz. Incluso si lo dejas a un lado , ingenieros experimentados han visto las cosas más extrañas de este mundo. ellos saben que , sin mencionar los millones de otros factores en el medio ambiente.
Por lo tanto, es más fácil para los ingenieros experimentados dudar de que todos los incidentes tengan una única causa raíz, y técnicas como los "Cinco porqués" conducirán correctamente (¡y repetitivamente!) a esa causa raíz. De hecho, esto contradice su propia experiencia, donde las piezas del rompecabezas no encajan tan perfectamente en la práctica. Por tanto, aceptan esta idea más fácilmente.
Por supuesto, no estoy diciendo que los desarrolladores sean ingenuos, estúpidos o incapaces de entender cómo la linealidad puede ser engañosa.
Pero me parece que una reacción común de los desarrolladores en estos debates a menudo tiene que ver con el hecho de que el concepto de determinismo les sirve bien en general en el trabajo cotidiano. No se topan con el no determinismo con tanta frecuencia como los ingenieros tienen que atrapar a los gatos de Schrödinger en su infraestructura.
Puede que esto no explique completamente las reacciones observadas de los desarrolladores, pero es un poderoso recordatorio de que nuestras reacciones son una mezcla compleja de muchos factores.
Es importante recordar esta complejidad, ya sea que estemos lidiando con un solo incidente, colaborando en un proceso de entrega de software o tratando de darle sentido al mundo en general.
Fuente: habr.com