fbpx

DevOps y la cultura del caos

 In DevOps

Cuando nos referimos a DevOps, la preciosa unión de Developers + Operations que marca la diferencia en el desarrollo de tus proyectos, siempre apostamos por pensar out of the box.

Uno de los mayores miedos a los que desarrolladores y responsables de IT nos enfrentamos es, como el resto de los humanos, el miedo al fallo. Miedo a que se bloquee el desarrollo, miedo a que se comprometa la puesta en marcha, miedo a tener la culpa, miedo al despido…

Por ello, en DevOps hay un sistema que denominamos la cultura del caos: pegarle una patada al corazón de nuestra aplicación, crear el caos dentro de nuestros sistemas, entender cómo se producen los fallos y, una vez detectado y controlado el error, entender cómo crear una suave transición en los próximos imprevistos.

En este aspecto, uno de los adalides de esta teoría, el grupo de desarrolladores tras el proyecto PrinciplesOfChaos.org, establece cuatro principios sobre los que ha de girar nuestra teoría del caos.

Establecer una hipótesis sobre un estado estable

Consiste en observar cuáles son los datos que la aplicación está mostrando al exterior, si son coherentes o no, es decir, establecer una serie de métricas que sirvan como ancla para entender el resto de situaciones que se nos van a presentar en los siguientes pasos.

Basarse en eventos del mundo real (y en producción)

El mundo real y los problemas a los que nos enfrentamos (fallos de red, de balanceadores, caídas de sistema, ascenso o descenso dramático del tráfico) requieren que la simulación de los fallos no se realice solamente en escenarios teóricos, sino que lo hagamos en producción, con tráfico real. Esto puede generar vértigo antes de acometerlo, pero créenos si te decimos que es la única manera factible de realizarlo.

Automatizar para no parar la cultura del caos

Los experimentos vinculados a la teoría del caos son, a la larga, un dolor de cabeza, dado que requieren de un elevado tiempo de ejecución, de análisis y de atención, por lo que la solución tiene un nombre: automatización.

Al estar activos de manera automatizada, siguen atacando de manera controlada pero constante nuestro sistema. Cuantos más datos obtengamos, mejor será nuestra solución a prueba de bombas. Los fallos no preguntan si son teóricos: atacan donde más duele.

Limitar el radio de acción

Si bien es cierto que la teoría del caos requiere de acciones que van a causar leves molestias al cliente, no lo es menos que nuestra responsabilidad es minimizarlas en la medida de lo posible. Cuanto más contenido y localizado esté el fallo, más sencillo será identificar la reacción y posible molestia en el usuario, y más asequible la gestión de incidencias para el equipo.

Toda esta gestión del caos se base en un axioma, y es que el miedo al fallo ha de ser eliminado de nuestro proyecto: los errores, cuando se gestionan de manera adecuada, y con un protocolo de gestión adaptado, son aprendizajes valiosísimos no solo para el proyecto, sino para cada uno de nosotros.

Si disponemos de una estrategia definida para atacar los problemas que surjan, nos será mucho más sencillo poner en marcha todo este protocolo, al habernos tropezado ya con esa (caótica) piedra: reducir tiempos de solución, minimizar los recursos asignados, aumentar la satisfacción del usuario y, muy especialmente, evitar que se repitan.

Si tu proyecto requiere de la mejor implementación de la teoría del caos, no dudes en contactar con Ibaru: atacaremos juntos tu proyecto para que salga reforzado y más duro (y maduro) que nunca.

Recent Posts
¿Qué es DevOps?