Contenido
- Preparándose para el fracaso
- Los siguientes pasos
- Sin errores, sin estrés: su guía paso a paso para crear software que cambie su vida sin destruir su vida
- Aprendizaje y mejora a través de simulacros
Fuente: presiónUA / iStockphoto
Para llevar:
Los sistemas modernos deben ser capaces de manejar el caos para evitar el tiempo de inactividad. Es por eso que es más importante que nunca probar a fondo los sistemas y garantizar su resistencia.
A pesar de nuestros mayores esfuerzos para evitarlos, los incidentes de TI son una parte inevitable del trabajo, y tratar de adelantarse al tiempo de inactividad que afecta el negocio solo se está volviendo más complicado. Los sistemas actuales están estrechamente acoplados y son cada vez más complejos, y con más partes móviles, hay más oportunidades para que las cosas salgan mal.
Esta es una razón por la cual cada vez más organizaciones están recurriendo a microservicios para una mayor disponibilidad de servicio y una mejor capacidad de recuperación ante fallas. Pero si bien estas son excelentes premisas para romper las aplicaciones monolíticas, también pueden potencialmente aumentar el riesgo de falla, a menos que estén diseñadas expresamente teniendo en cuenta la capacidad de recuperación.
Preparándose para el fracaso
Dada la naturaleza inherentemente caótica de los sistemas distribuidos, los servicios deben desarrollarse no solo para anticipar la falla, sino también para recuperarse automáticamente en caso de falla. Esto significa instigar fallas de forma regular para garantizar que sus sistemas puedan manejar el caos sin interrumpir el servicio a los clientes finales. Y para lograr esto, necesita la capacidad de simular tráfico similar a la producción en entornos de prueba.
Por supuesto, es una buena idea probar la resistencia antes de que los cambios lleguen a la producción. Si no hace esto, no podrá verificar que sus servicios pueden soportar cargas medias y pico. De hecho, la apuesta más segura es garantizar que su producto pueda manejar hasta el doble de la cantidad máxima sin tener que escalar.
Cuando se trata de pruebas de resistencia, las herramientas correctas no deberían preocuparse demasiado por cómo se manejan las solicitudes, solo que tienen el impacto correcto al final. Recuerde que bajo ciertas condiciones, el servicio de entrada puede fallar en entregar una solicitud al resto del sistema pero no informar la falla. No se arriesgue a que los problemas pasen desapercibidos al monitorear asegurándose de que la validación de extremo a extremo se esté produciendo. (Para obtener más información, consulte Fallos tecnológicos: ¿podemos vivir con ellos?)
Los siguientes pasos
Después de comprender cómo se comportan los servicios bajo carga, es hora de comenzar a presentar los eventos de falla. Al igual que con todas las pruebas de software, es mejor tener herramientas automatizadas que le permitan reproducir escenarios de manera fácil y rápida, de modo que pueda coordinar eventos complejos que afecten a diferentes tecnologías de infraestructura. Y más allá de la capacidad de verificar arreglos y cambios en los servicios, esto le permite ejecutar escenarios de falla aleatorios en cualquier entorno y en un horario.
Los eventos de falla significativos dependen en gran medida del diseño de sus servicios, y puede formularlos haciendo preguntas específicas que sean relevantes para usted. Por ejemplo, ¿cuál es el impacto para las personas que usan el front-end cuando una base de datos se vuelve inaccesible durante un cierto período de tiempo? ¿Pueden esos usuarios navegar por la interfaz de usuario web? ¿Pueden seguir emitiendo actualizaciones a su información, y esas actualizaciones se procesarán correctamente cuando la base de datos vuelva a ser accesible?
Si ejecuta múltiples microservicios, puede preguntar si habrá una interrupción global si algún servicio individual falla. O si tiene un mecanismo de cola para amortiguar la comunicación entre servicios, ¿qué sucede cuando el servicio (o servicios) de consumo deja de funcionar? ¿Los usuarios podrán seguir trabajando con su aplicación? Y dada una carga promedio, ¿cuánto tiempo tiene antes de que las colas se desborden y comience a perder s?
Sin errores, sin estrés: su guía paso a paso para crear software que cambie su vida sin destruir su vida
No puede mejorar sus habilidades de programación cuando a nadie le importa la calidad del software.
Una vez que haya definido algunas preguntas clave sobre su infraestructura, puede comenzar a enumerar diferentes formas de simular esas fallas. Puede ser suficiente para detener un servicio en particular o un servidor de base de datos. Es posible que desee bloquear el subproceso principal de un servicio para simular un punto muerto, mientras su contenedor aún está en funcionamiento y responde. Puede decidir introducir reglas en su red para bloquear el tráfico entre servicios específicos. En entornos Linux, puede usar herramientas como "tc" para emular situaciones de red como paquetes de alta latencia, descartados, corruptos o duplicados. (Puede ser importante involucrar a los usuarios en las pruebas. Lea más en 4 Razones por las cuales los usuarios finales necesitan participar en las pruebas antes de UAT).
Aprendizaje y mejora a través de simulacros
Uno de los aspectos más valiosos de la creación de escenarios de fallas es que pueden exponer todas las formas potenciales en que el sistema puede fallar, creando así el camino hacia la lógica de autocuración. Su equipo realizará los pasos para recuperar los servicios manualmente, un gran ejercicio, por cierto, para confirmar que pueden hacerlo dentro de los SLA. Se puede trabajar en la automatización de este proceso de recuperación, pero mientras tanto, puede estar tranquilo sabiendo que su equipo ha recorrido el proceso de volver a encarrilar los servicios. Al hacer que los escenarios de falla sean aleatorios y regulares y no revele los detalles completos de la ejecución, también puede incluir el descubrimiento y los diagnósticos en el ejercicio, que es, después de todo, una parte crítica de los SLA.
En esencia, la ingeniería del caos toma la complejidad del sistema como algo dado, lo prueba simulando condiciones nuevas y extravagantes, y observa cómo responde el sistema. Estos son los equipos de ingeniería de datos que necesitan rediseñar y reconfigurar el sistema para lograr una mayor resistencia. Hay tantas oportunidades para aprender cosas nuevas y útiles. Por ejemplo, puede encontrar instancias en las que los servicios no reciben actualizaciones cuando los servicios posteriores han cambiado, o áreas en las que falta la supervisión por completo. ¡No faltan formas emocionantes de hacer que su producto sea más resistente y robusto!