La realidad de un ingeniero de redes (con fideos y ... ¿sal?)Recientemente, discutiendo varios incidentes con ingenieros, noté un patrón interesante.
En estas discusiones, siempre surge la cuestión de la "causa raíz". Los lectores fieles probablemente sabrán que tengo
algunas ideas sobre
esto . En muchas organizaciones, el análisis de incidentes se basa completamente en este concepto. Utilizan diferentes técnicas para identificar relaciones de causa y efecto, como
Five Why . Estos métodos sugieren la llamada "linealidad de los eventos" como un dogma innegable.
Cuando cuestiona esta idea y señala que la linealidad en sistemas complejos es tranquilizadoramente engañosa, nace una discusión fascinante. Los debatedores insisten apasionadamente en que solo el conocimiento de la "causa raíz" nos permite comprender lo que está sucediendo.
Noté un patrón interesante: los desarrolladores y desarrolladores reaccionan de manera diferente a esta idea. En mi experiencia, los desarrolladores argumentan más a menudo que la causa raíz es importante y que la causalidad siempre se puede establecer en los eventos. Por otro lado, los devops con mayor frecuencia están de acuerdo en que un mundo complejo no siempre está sujeto a la linealidad.
Siempre me pregunté por qué. ¿Qué
hace que los programadores critiquen la idea de "causa raíz - mito"? Como un sistema inmune que reconoce un agente extraño. ¿Por qué reaccionan de esta manera mientras los devops tienen
más probabilidades de considerar esta idea?
No estoy muy seguro, pero hay una consideración al respecto. Se asocia con diversos contextos en los que estos profesionales realizan el trabajo diario.
Los desarrolladores a menudo trabajan con herramientas deterministas. Por supuesto, los compiladores, enlazadores, sistemas operativos son sistemas complejos, pero estamos acostumbrados a dar un resultado determinista, y los presentamos como deterministas: si proporcionamos los mismos datos de entrada, generalmente esperamos la misma salida de estos sistemas . Y si hay un problema ("error"), los desarrolladores lo resuelven analizando los datos de entrada (ya sea del usuario o de un conjunto de herramientas en el proceso de desarrollo). Buscan un "error" y luego modifican la entrada. Esto corrige el error.
La suposición principal del desarrollo de software: los mismos datos de entrada proporcionan de manera confiable y determinista la misma salidaDe hecho, un resultado no determinista se considera en sí mismo un error: si no se reproduce una conclusión inesperada o errónea, los desarrolladores buscan expandir el estudio a otras partes de la pila (sistema operativo, red, etc.) que también se comportan de manera más o menos determinista, dando el mismo resultado con la misma entrada ... y
si no lo es , entonces todavía se considera un error. Es solo que 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 para la mayoría del trabajo que realizan los programadores.
Pero para cualquier devopa que se haya pasado el día recogiendo hierro en bastidores o clasificando la API en la nube, la idea de un mundo completamente determinista (¡siempre y cuando exista la oportunidad de mostrar todos los datos de entrada!) Es, en el mejor de los casos, un concepto fugaz. Incluso descartando las
bromas de BOHF sobre manchas solares , los ingenieros experimentados vieron las cosas más extrañas en este mundo. Saben que
incluso un grito humano puede ralentizar un servidor , sin mencionar millones de otros factores ambientales.
Por lo tanto, es más fácil para los ingenieros experimentados dudar de que todos los incidentes tengan una sola causa raíz, y técnicas como "Five Why" correctamente (¡y repetible!) Conducen a esa causa raíz. De hecho, esto contradice su propia experiencia, cuando las piezas del rompecabezas en la práctica no se suman tan claramente. Por lo tanto, perciben más fácilmente esta idea.
Por supuesto, no estoy diciendo que los desarrolladores sean ingenuos, estúpidos o incapaces de entender cómo la linealidad puede ser engañosa.
Los programadores experimentados probablemente también vieron mucho no determinismo en su vida.Pero me parece que la reacción habitual de los desarrolladores en estas disputas a menudo se relaciona con el hecho de que el concepto de determinismo
en su conjunto les sirve bien en el trabajo diario. No encuentran el no determinismo tan a menudo como los ingenieros tienen que atrapar gatos Schrodinger en su infraestructura.
Tal vez esto no explique completamente las reacciones observadas de los desarrolladores, pero este es un poderoso recordatorio de que nuestras reacciones son una mezcla compleja de muchos factores.
Es importante tener en cuenta esta complejidad, ya sea que estemos investigando un solo incidente o trabajando juntos en una tubería de entrega de software, o tratando de darle sentido a un mundo más amplio.