Compartir a través de

Desplazamiento a la derecha para ejecutar pruebas en producción

  • Artículo

Desplazamiento a la derecha es la práctica de mover algunas pruebas más adelante en el proceso de DevOps para probar en producción. Las pruebas en producción usan implementaciones reales para validar y medir el comportamiento y el rendimiento de una aplicación en el entorno de producción.

Una manera en que los equipos de DevOps pueden mejorar la velocidad es con una estrategia de prueba de desplazamiento a la izquierda. El desplazamiento a la izquierda inserta la mayoría de las pruebas anteriormente en la canalización de DevOps, para reducir la cantidad de tiempo para que el código nuevo llegue a producción y funcione de forma confiable.

Pero aunque muchos tipos de pruebas, como las pruebas unitarias, pueden desplazarse fácilmente a la izquierda, algunas clases de pruebas no se pueden ejecutar sin implementar toda una solución o parte de ella. La implementación en un servicio de control de calidad o almacenamiento provisional puede simular un entorno comparable, pero no hay ningún sustituto completo del entorno de producción. Los equipos encuentran que determinados tipos de pruebas deben producirse en producción.

Las pruebas en producción proporcionan:

  • La amplitud y diversidad del entorno de producción.
  • La carga de trabajo real del tráfico del cliente.
  • Perfiles y comportamientos según evoluciona la demanda de producción con el tiempo.

El entorno de producción sigue cambiando. Aunque una aplicación no cambie, la infraestructura en que se basa cambia constantemente. Las pruebas en producción validan el estado y la calidad de una implementación de producción determinada y del entorno de producción en constante cambio.

El desplazamiento a la derecha a las pruebas en producción es especialmente importante para los escenarios siguientes:

Implementaciones de microservicios

Las soluciones basadas en microservicios pueden tener un gran número de microservicios desarrollados, implementados y administrados de forma independiente. El desplazamiento de pruebas a la derecha es especialmente importante para estos proyectos, ya que las diferentes versiones y configuraciones pueden llegar a producción de muchas maneras. Independientemente de la cobertura de pruebas de preproducción, es necesario probar la compatibilidad en producción.

Garantizar la calidad posterior a la implementación

La liberación a producción es solo la mitad de la entrega de un software. La otra mitad es garantizar la calidad a escala con una carga de trabajo real en producción. Dado que el entorno sigue cambiando, un equipo nunca termina las pruebas en producción.

Los datos de prueba de producción son literalmente los resultados de la prueba de la carga de trabajo del cliente real. Las pruebas en producción incluyen la supervisión, las pruebas de conmutación por error y la inyección de errores. Esta prueba realiza un seguimiento de errores, excepciones, métricas de rendimiento y eventos de seguridad. La telemetría de prueba también ayuda a detectar anomalías.

Anillos de implementación

Para proteger el entorno de producción, los equipos pueden implementar cambios de forma progresiva y controlada mediante implementaciones basadas en anillos y marcas de características. Por ejemplo, es mejor detectar un error que impida que un comprador complete su compra cuando menos del 1 % de los clientes están en ese anillo de implementación que cambiar después a todos los clientes a la vez. El valor de la característica con errores detectados debe superar las pérdidas netas de esos errores, medida de forma significativa para la empresa en cuestión.

El primer anillo debe ser el tamaño más pequeño necesario para ejecutar el conjunto de integración estándar. Las pruebas pueden ser similares a las que ya se ejecutaron anteriormente en la canalización en otros entornos, pero las pruebas validan que el comportamiento es el mismo en el entorno de producción. Este anillo identifica errores obvios, como configuraciones incorrectas, antes de que afecten a los clientes.

Una vez validado el anillo inicial, el siguiente anillo puede ampliarse para incluir un subconjunto de usuarios reales para la ejecución de pruebas. Si todo se ve bien, la implementación puede avanzar a través de más anillos y pruebas hasta que todos los usuarios lo usen. La implementación completa no significa que hayan terminado las pruebas. El seguimiento de la telemetría es fundamental para las pruebas en producción.

Inyección de errores

Los equipos suelen emplear la inserción de errores y la ingeniería de caos para ver cómo se comporta un sistema en condiciones de error. Estas prácticas ayudan a:

  • Validar que los mecanismos de resistencia implementados funcionan realmente.
  • Comprobar que un error de un subsistema está contenido en ese subsistema y no se traslada en cascada para producir una interrupción importante.
  • Demostrar que el trabajo de reparación de un incidente anterior tiene el efecto deseado, sin tener que esperar a que se produzca otro incidente.
  • Crear simulacros de entrenamiento más realistas para los ingenieros de sitio activos, para que puedan prepararse mejor para tratar los incidentes.

Se recomienda automatizar los experimentos de inyección de errores, ya que son pruebas costosas que deben ejecutarse en los sistemas que cambian constantemente.

La ingeniería de caos puede ser una herramienta eficaz, pero debe limitarse a entornos controlados que tienen poco o ningún impacto en el cliente.

Pruebas de conmutación por error

Una forma de inyección de errores es la prueba de conmutación por error para apoyar la continuidad empresarial y la recuperación ante desastres (BCDR). Los equipos deben tener planes de conmutación por error para todos los servicios y subsistemas. Los planes deben incluir:

  • Una explicación clara del impacto empresarial de la interrupción del servicio.
  • Un mapa de todas las dependencias en términos de plataforma, tecnología y personas que elaboran los planes BCDR.
  • Documentación formal de los procedimientos de recuperación ante desastres.
  • Una cadencia para ejecutar periódicamente simulacros de recuperación ante desastres.

Pruebas de errores de disyuntor

Un mecanismo de disyuntor corta un componente determinado de un sistema más grande, normalmente para evitar que los errores de ese componente se extiendan fuera de sus límites. Puede activar intencionadamente los disyuntores para probar los escenarios siguientes:

  • Si un dispositivo de reserva funciona cuando se activa el disyuntor. El dispositivo de reserva podría funcionar con pruebas unitarias, pero la única manera de saber si se comportará según lo previsto en producción es insertar un error para desencadenarlo.

  • Si el disyuntor tiene el umbral de sensibilidad adecuado para abrirse cuando sea necesario. La inserción de errores puede forzar la latencia o desconectar las dependencias para observar la capacidad de respuesta del disyuntor. Es importante comprobar no solo que se produzca el comportamiento correcto, sino que suceda lo suficientemente rápido.

Ejemplo: Prueba de un disyuntor de caché de Redis

Redis Cache mejora el rendimiento del producto al acelerar el acceso a los datos usados habitualmente. Considere un escenario que tome una dependencia no crítica en Redis. Si Redis deja de funcionar, el sistema debe seguir funcionando, ya que puede revertir al uso del origen de datos original para las solicitudes. Para confirmar que un error de Redis desencadena un disyuntor y que la reserva funciona en producción, ejecute periódicamente pruebas con estos comportamientos.

En el diagrama siguiente se muestran las pruebas para el comportamiento de reserva del disyuntor de Redis. El objetivo es asegurarse de que cuando se abra el separador, las llamadas en última instancia irán a SQL.

Diagram showing tests for the Redis circuit breaker and fallback behavior.

En el diagrama anterior se muestran tres AT, con los disyuntores delante de las llamadas a Redis. Una prueba obliga al disyuntor a abrirse a través de un cambio de configuración y, a continuación, observa si las llamadas van a SQL. A continuación, otra prueba comprueba el cambio de configuración opuesto, cerrando el disyuntor para confirmar que las llamadas vuelven a Redis.

Esta prueba valida que el comportamiento de reserva funciona cuando se abre el disyuntor, pero no valida que la configuración del disyuntor abra el disyuntor cuando debería. La prueba de ese comportamiento requiere simular errores reales.

Un agente defectuoso puede introducir errores en las llamadas que van a Redis. En el diagrama siguiente se muestran las pruebas con inyección de errores.

Diagram showing Redis circuit breaker testing with fault injection.

  1. El inyector de errores bloquea las solicitudes de Redis.
  2. Se abre el disyuntor y la prueba puede observar si funciona la reserva.
  3. El error se quita y el disyuntor envía una solicitud de prueba a Redis.
  4. Si la solicitud se realiza correctamente, las llamadas vuelven a Redis.

Otros pasos podrían probar la sensibilidad del separador, si el umbral es demasiado alto o demasiado bajo, y si otros tiempos de espera del sistema interfieren con el comportamiento del disyuntor.

En este ejemplo, si el disyuntor no se abre o se cierra según lo previsto, podría provocar un incidente de sitio activo (LSI). Sin las pruebas de inyección de errores, es posible que el problema no se detecte, ya que es difícil realizar este tipo de pruebas en un entorno de laboratorio.

Pasos siguientes