Tech and Solve

How to apply chaos engineering in a devteam?

Durante el pasado ScaleConf Colombia realizado en Medellín, me topé con una charla sobre ingeniería del caos que por su título me causó mucha curiosidad Chaos Engineering: Injecting failure for building resilience in systems
Chaos Engineering: Injecting failure for building resilience in systems
Tras participar en ella, comprendí por definición qué es la ingeniería del caos y sus componentes clave: Resiliencia y Confiabilidad. Con ellos sobre la mesa, la aplicabilidad de este concepto dentro de un equipo de desarrollo es alta dadas las limitantes del día a día en infraestructura, software, aplicaciones, entre otras. 
En este contexto, el CAOS estaría representado por las indisponibilidades, fallos, insatisfacción de usuarios finales y por último largas noches de café y mucho estrés. 
Lo que sugiere la Ingeniería del Caos es entonces preparación y entrenamiento, pero de forma organizada: con un método, con unos principios y como una forma divertida de aprender aún más de lo que haces, garantizando de esta forma su calidad.
Conozcamos un poco mas a fondo el método para realizarlo:
Según la ponente @yurynino del ScaleConf Colombia 2019 y la documentación de referencia sobre el tema, encontramos los siguientes pasos para su aplicación en un devteam:
  • Definir el estado correcto de funcionamiento del sistema, dados los parámetros que lo garanticen para medir posteriormente variables como rendimiento, tasas de error, latencia, entre otros.
  • Hacer una hipótesis de que este estado correcto de funcionamiento continuará tanto en el grupo de control como en el grupo experimental.
  • Introducir variables que reflejan eventos del mundo real, como servidores que se bloquean, discos duros que funcionan mal, conexiones de red caídas, etc.
  • Intentar refutar la hipótesis buscando una diferencia en el estado estable entre el grupo de control y el grupo experimental.
Cuanto más difícil es interrumpir el estado correcto de funcionamiento, más confianza tenemos en el comportamiento del sistema. Si se descubre una debilidad, ahora tenemos un objetivo de mejora antes de que ese comportamiento se manifieste en el sistema en general.
Como conclusión puedo decir que la utilidad de esta disciplina va más allá del mero hecho de prever fallos y establecer estrategias antes de que sucedan, es más un cambio cultural del cómo garantizamos la calidad de un producto orientado a un usuario para que esté satisfecho y tenga un producto idóneo.
Por último una frase que me gusto mucho… “Chaos verifies that the system does work, rather than trying to validate how it works.”
Artículo escrito por Andrés Rincón para #BlogTechAndSolve