There is no root cause

Estaba leyendo el tremendo artículo de abajo y decidí aportar un poco de background para leerlo mejor.


"Each necessary, but only jointly sufficient"
http://www.kitchensoap.com/2012/02/10/each-necessary-but-only-jointly-sufficient/


Es el mejor artículo que leí hasta ahora acerca de "there is no root cause", incluye muchos links a artículos de soporte para las explicaciones.


Lo recomiendo mucho a los que estén acostumbrados a trabajar con sistemas deterministas manejados por la causalidad.


http://es.wikipedia.org/wiki/Sistema_determinista
http://es.wikipedia.org/wiki/Causalidad_(f%C3%ADsica)


-------------
Todo lo que sigue es un poco de background para leer el artículo en el link arriba.




En IT tenemos sistemas que pueden fallar, una manera de ver cómo fallaron y evitar que vuelva a ocurrir es hacer el RCA, Root Cause Analysis, de la falla.


http://en.wikipedia.org/wiki/Root_cause_analysis


El RCA tiene muchas metodologías, una muy en boga es la usada por ITIL:
http://en.wikipedia.org/wiki/RPR_Problem_Diagnosis


[Es importante recordar que alrededor de RPR se articula la organización de personas recomendada por ITIL para asesorar el evento y ubica la root causa, la causa raíz de una falla, para implementar cambios que prevengan que la falla vuelva a ocurrir.]


El RCA suele funcionar para sistemas simples, de pocos componentes y con características preeminentemente deterministas [el determinismo en acción es básicamente lo que ocurre cuando vemos fichas de domino alineadas y la caída de una hacer caer la otra, hasta la última > la root cause del evento es la caída de la primer ficha]


(repitiendo el link)
http://es.wikipedia.org/wiki/Sistema_determinista
Y la verdad se entiende mejor leyendo esta otra definición: http://es.wikipedia.org/wiki/Determinismo_cient%C3%ADfico




En sistemas complejos en cambio, el determinismo está siempre limitado a pocos componentes y a rangos de tiempo específicos.


http://es.wikipedia.org/wiki/Sistema_complejo
http://en.wikipedia.org/wiki/Complex_system
http://en.wikipedia.org/wiki/Complex_system#Topics_on_complex_systems


Ejemplos "de moda" de sistemas complejos IT modernos son la infraestructura de la de Amazon, la de Skype, la de Twitter, etc.


Entonces llegamos a la siguiente hipótesis: "para muchas fallas en sistemas complejos no hay causa raíz"




Es una noción contraintuitiva para el analista, típico IT guy, persona "de sistemas", o como prefieran que los denominen; ello es porque normalmente no se trata un sistema informático como algo que puede fallar y de lo que no se puede resolver la causa raíz exacta y definitiva.


Es decir, es probable encontrar una causa raíz, pero ella estará ajustada a circunstancias muy particulares y específicas, es probable que puedan prevenirse, sin embargo una mínima variación en esas circunstancias podría crear una nueva falla del sistema dando por tierra con las medidas "preventivas" antes tomadas.


¿Damos un ejemplo de la vida real? Sí, Skype falló en 2011 porque: 
- se sobrecargó un cluster de servers ("supernodos") encargados de manejar mensajes fuera de línea 
- en consecuencia muchos clientes Skype recibieron respuestas lentas (debido a la sobrecarga)
- en una versión de Skype para Windows, el evento anterior no fue bien procesado
- esos clientes empezaron a fallar
- la gente de Skype empezó a apagar los supernodos (se apagó un 25-30% de todos los supernodos de Skype)
- la sobrecarga a los demás supernodos provocó el outage masivo (pocos o ningun cliente Skype lograba comunicaciones en algun momento del outage)


Acá nos damos cuenta rápido de qué tan difícil es encontrar la causa raíz si empezamos a ver variaciones del problema preguntado 
¿Que pasaría si hubiera / no hubiera ocurrido X evento?
¿Por qué no pasó antes?
etc.


Si estamos en presencia de un sistema complejo, puede que observemos comportamientos indeterministas en relación con las fallas que pueda ocurrir. Es decir, no se puede usar SOLAMENTE análisis causal para establecer precisamente la causa de la falla. 


¿Qué es Análisis causal?
http://mx.answers.yahoo.com/question/index?qid=20090624084335AANP2GR




¿Hay metodología para analizar problemas en sistemas complejos? Sí
¿Son técnicas de aplicación mecánica? No
¿Puede ser enseñado metódicamente? Sí
¿La experiencia práctica del analista juega un papel decisivo? Sí




En IT la mejor manera de aprender a resolver problemas de sistemas complejos es:


- dominando técnicas de troubleshooting de sistemas simples (para atacar los problemas simples componentes del problema global)
- leyendo "war stories", ejemplos reales de problemas que ocurrieron y fueron resueltos
- ganando "contexto" real (entender el sistema total donde está mixeado el sistema complejo), y técnico para poder encarar el problema (entender lo más posible sobre un sistema complejo vuelve más factible encontrar la causa del problema). 


[El estar en el más alto nivel de proficiencia (el 5to. en el modelo del link) en el campo técnico involucrado en la resolución puede ayudar, ver características en
http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition#The_original_five-stage_model ]


La necesidad de información/conocimiento y experiencia en la práctica es lo que vuelve la resolución de problemas de sistemas complejos un área donde se desenvuelve mejor el IT guy con camino recorrido vs. el potencialmente inexacto y/o superficial análisis de un IT guy con menos experiencia real (dice "potencialmente", o sea, es posible que un novato llegue a hacer buenos análisis).



Links de war stories:
http://mashable.com/2011/04/22/amazon-cloud-collapse/
http://blogs.skype.com/en/2010/12/cio_update.html




Links de material sobre resolución de problemas en sistemas complejos


http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.213
http://ezinearticles.com/?Troubleshooting-Complex-Systems---Planning---Gathering-Problem-Information&id=1295206
http://www.sqlwebpedia.com/content/how-troubleshoot-complex-systems