Table of Contents
Uno de los mayores incentivos para asistir a la Software Crafters de Barcelona de este año fueron los open spaces que tuvieron lugar el primer día por la tarde. En estos open spaces se trataron temas tan interesantes como «ramas vs integración continua», «monolitos vs microservicios«, «como gestionar la diversidad en nuestro lugar de trabajo» o compartir las experiencias desastrosas que hemos tenido en salidas a producción.
Es en este último punto en el que queremos hacer hincapié en este artículo, ya que una de las estrategias comentadas en este open space y que más nos sorprendieron fue la de «Ingeniería del caos».
Pasos de Ingeniería del caos
Esta técnica se basa en poner a prueba nuestro entorno de producción provocando fallos intencionados en el mismo, de forma que podamos saber cómo reacciona nuestro sistema ante estos fallos en un entorno controlado. Estos fallos podrían ser, por ejemplo, desconectar uno de los microservicios de nuestro sistema, tumbar una base de datos, o simular una caída en la red.
Si llevamos a cabo esta técnica, aunque a primera vista pueda parecer peligrosa, hemos de asumir que los beneficios obtenidos de la misma serán mayores que los riesgos; ya que el hecho de provocar un fallo en nuestro sistema nos permitirá observar qué partes del mismo se comportan correctamente y cuales no, y podremos estar preparados cuando dicho fallo ocurra en un entorno no controlado.
Llevar a cabo estos experimentos no es una tarea trivial, por lo se definen unos pasos para que su ejecución sea lo más segura posible y sus resultados sean válidos. De esta forma podremos tomar las acciones adecuadas a la hora de solucionar los errores que hayamos encontrado. Estos pasos están definidos en la web Principles of chaos y son los siguientes:
- Definir un estado de ejecución correcto (steady state) de nuestro sistema. Necesitamos definir unos parámetros de ejecución de nuestro sistema (por ejemplo ciertos valores de ciertas métricas) que definan que está funcionando de la forma esperada para poder medir las diferencias cuando provoquemos el fallo. Además, como en todo experimento que se precie, necesitaremos un grupo de control y un grupo experimental; siendo el primero el grupo en el que mantendremos una ejecución normal y el segundo el grupo en el que aplicaremos el experimento.
- Definimos la hipótesis de que este estado de ejecución «correcto» continuará en ambos grupos.
- Realizamos el experimento. Introducimos las variables en nuestro sistema que reflejen los eventos que queremos simular, como la caída de un servidor o una base de datos.
- Buscamos diferencias de funcionamiento en las métricas comparándolas con las definidas en el primer paso, y comparándolas también con el grupo de control. De esta forma tratamos de rebatir la hipótesis definida en el paso dos.
Como programadores, siempre intentamos hacer nuestro código libre de fallos y lo más estable posible, intentando anticiparnos a todos los errores que puedan ocurrir. Ingeniería del caos va un paso más allá y nos habla de observar cómo se comporta nuestro sistema en presencia de estos fallos, de forma que, si los hemos controlado correctamente estaremos a salvo, pero si no lo hemos hecho, nos daremos cuenta de dónde están estos fallos y podremos solucionarlos.
Si queréis tener más información sobre ingeniería del caos, no olvidéis de subscribiros a nuestro newsletter mensual aquí.
Si te gustó este artículo “Ingeniería del caos”, te puede gustar:
Barcelona como ciudad inteligente
Mapa de los “main players”: ecosistema startup y tech en Barcelona
Proyectos IoT que cambiarán el mundo
Ecosistema de salud digital en Barcelona
Inovación disruptiva: ejemplos
Búsqueda visual en el comercio electrónico
