Chaotic Testing introduce el caos en su sistema para fortalecerlo. Es una metodología sólida empleada por gigantes empresariales para evitar interrupciones y fallas en todo el sistema.
Estás migrando tu base de datos. El proceso tardó meses en tomar forma, cientos de horas invertidas en construir un canal de compatibilidad, docenas de desarrolladores revisando manualmente los datos y reuniones los fines de semana para cumplir con el plazo. Y luego, durante la migración, una subida de tensión hace que el sistema se caiga...
Nadie podría haber predicho esto, pero este pequeño descuido podría sabotear todo el proyecto o, peor aún, causar un daño irreparable a su base de datos.
Los humanos fuimos diseñados para ser cautelosos ante el futuro, es una herramienta biológica diseñada para mantenernos vivos ante nuevas experiencias. Pero aun así, rara vez, o nunca, tendemos a pensar en el peor de los casos.
Pero, en palabras de Augustus De Morgan, “la primera experiencia ya ilustra una verdad de la teoría, bien confirmada por la práctica: todo lo que puede suceder sucederá si hacemos suficientes intentos”. Si suena vagamente familiar, es porque a De Morgan se le suele atribuir el mérito de ser uno de los primeros en hablar sobre la ley de Murphy: “Todo lo que puede salir mal, saldrá mal”.
Altamente improbable no imposible
Un amigo mío dice en broma “cuando salgas en vivo, la pregunta no es ¿explotará? En cambio, ¿de qué color será la explosión? Bromas aparte, hay más que un poco de verdad en sus palabras.
Los entornos de desarrollo suelen intentar recrear los entornos de producción lo más cerca posible de la realidad o viceversa. Desafortunadamente, los sistemas informáticos son extremadamente volátiles, por lo que incluso la diferencia más pequeña puede tener consecuencias de gran alcance, y eso es sólo la punta del iceberg.
Los sistemas se rompen, las conexiones a Internet tienen latencia, los servidores fallan, los discos duros fallan y los datos se corrompen. Estas cosas suceden y a veces tenemos muy poco control sobre cuándo o cómo. ¿Recuerda aquel año 2011, cuando cientos de usuarios perdieron sus datos debido a una falla de AWS?
¿Es probable que vuelva a suceder? No, pero ¿es posible? Sí, y es por eso que los ingenieros siempre diseñan sistemas a prueba de fallos. Si la NASA no hubiera diseñado un dispositivo a prueba de fallos, el Apolo 11 se habría estrellado en la Luna debido a un error informático .
El código de error 1202 de Apollo significaba que la computadora de a bordo estaba sobrecargada de tareas. Afortunadamente, los programadores de la NASA anticiparon esta posibilidad y crearon un sistema de respaldo que reiniciaría rápidamente la computadora y liberaría memoria para nuevos cálculos.
Minimizar el tiempo de recuperación
La historia del alunizaje es un excelente ejemplo de lo que los ingenieros modernos llaman MTTR, que minimiza el tiempo necesario para recuperarse de un fallo. Si no se pueden evitar los desastres, entonces nuestra solución es minimizar el tiempo necesario para reactivar los sistemas.
Digámoslo de esta manera: imagine que tiene dos empresas competidoras, la empresa A está experimentando varias interrupciones del sistema a lo largo del día, mientras que la empresa B ha experimentado una única interrupción. Sin más información, a todo el mundo le gustaría ser una empresa B.
Pero digamos que el MTTR (tiempo de recuperación promedio) de la empresa A es de alrededor de 20 segundos, mientras que el de la empresa B es de alrededor de 4 a 6 horas. Si la empresa A tuviera 20 cortes a lo largo del día, tendría un tiempo de inactividad total de 6 a 10 minutos. De repente, la frecuencia de las interrupciones del sistema parece mucho menos importante.
¿Cómo se minimiza el tiempo de recuperación? Bueno, una de las primeras cosas que debes hacer es bloquear tu sistema a propósito. A esto se le llama falla controlada. Aunque pueda parecer contradictorio, cuando lo piensas, empieza a tener mucho sentido.
En una falla controlada, usted anuncia la fecha y hora en que el sistema fallará, pero la falla en sí no se revela, por lo que el equipo necesita diagnosticar el problema y poner el sistema en funcionamiento lo más rápido posible.
Mientras esto sucede, monitoreamos los datos del sistema antes, durante y después de la falla. El objetivo es ayudar en el esfuerzo de recuperación, pero también proporciona datos para su posterior análisis y mejora.
Este tipo de ejercicio abre la puerta a nuevos conocimientos a medida que el equipo descubre los efectos de fallos inesperados del sistema. Es un cambio de perspectiva a través de la terapia de choque, cuando de repente el sistema a prueba de fallas revela su frágil yo.
Con los conocimientos adquiridos en estos ejercicios, podrá crear nuevos procedimientos con una comprensión más clara de sus defectos. Aunque el ejercicio puede resultar estresante, los resultados merecen la pena. Y, francamente, puede ser uno de los ejercicios intelectualmente más desafiantes para un equipo de desarrollo.
Entra en la prueba caótica
Los ejercicios de falla controlada son solo la punta del iceberg y una introducción básica a las pruebas caóticas/ingeniería caótica. En esencia, las pruebas caóticas consisten simplemente en crear la capacidad de provocar fallos continuos pero aleatorios en su sistema de producción.
Chaotic Engineering fue una estrategia central para el gigante del streaming Netflix. El equipo de ingeniería tenía una amplia variedad de “monos del caos”, o fallas potenciales que podrían surgir en cualquier momento, desde latencia hasta una interrupción mundial de los servicios web de Amazon.
Estos fallos caóticos, a su vez, obligan a tu equipo a pasar del desarrollo defensivo a un enfoque más agresivo. Para ser más precisos, es un método para desarrollar la resiliencia del sistema y del propio equipo.
Un sistema resiliente tiene la flexibilidad de adaptarse a circunstancias catastróficas, por ejemplo, una plataforma de streaming que redirige su tráfico cuando un cambio repentino en la latencia provoca un retraso en la transmisión de datos.
Un equipo resiliente es flexible y de mente abierta, capaz de adaptarse rápidamente y desarrollar nuevas estrategias cuando enfrentan problemas imprevistos. Los equipos resilientes tienden a ver las emergencias como oportunidades para crecer y adaptarse, en lugar de temerlas o sentirse estresados.
La resiliencia es algo que se puede construir, tanto en términos de sistema como de dinámica de equipo, y las pruebas caóticas impulsan esta mentalidad. Es un poco como esos simulacros de extinción de incendios que hacíamos cuando éramos niños. Al simular una crisis, nos acostumbramos y aprendemos a mantener la calma cuando las cosas se salen de control.
Tenga en cuenta que este método es extremadamente exigente para los desarrolladores y no se recomienda para equipos recién formados o proyectos de pequeña escala. Esto es adecuado para proyectos con muchas partes móviles, donde un solo error puede tener consecuencias de gran alcance.
Las pruebas caóticas se recomiendan activamente como uno de los mejores métodos para avanzar hacia la resiliencia y el MTTR y son utilizadas por gigantes del software y la ingeniería como IBM .
Induzca el caos para proteger su negocio
Construir con caos puede parecer un oxímoron, pero no se puede negar la evidencia. Netflix es, con diferencia, uno de los sistemas más sólidos del planeta, lo que es un testimonio de lo buenas que pueden ser las pruebas caóticas cuando se hacen correctamente.
