El entorno de staging se conecta al servicio real una sola vez para una comprobación, y se olvida desconectarlo. Un mes después, la ejecución automática crea una decena de cuentas reales en el servicio de producción y la pasarela de pagos cobra dinero de verdad por un pedido de prueba. La avería no está en la ejecución en sí, sino en que el staging y producción no están separados a nivel de configuración. Veamos cómo ocurre y qué revisar para que una ejecución automática no termine convertida en un incidente real.

La avería típica: cómo una ejecución de prueba crea cuentas reales

El escenario casi siempre es el mismo: la configuración del staging se clonó desde producción, se cambiaron algunos valores, pero se olvidó la dirección de la API o la clave de acceso. Las ejecuciones funcionan durante meses sin problemas, hasta que una de ellas toca el endpoint de registro o de pago. Entonces aparecen en la base de datos real cuentas verdaderas con nombres de prueba como test_user_1, y en la pasarela de pagos, cobros reales por pedidos de prueba.

Peor aún si la avería no se detecta enseguida: esas cuentas viven semanas en producción, entran en la analítica, distorsionan las métricas de conversión y se confunden con usuarios reales al analizar incidentes.

Separar las configuraciones del staging y de producción por claves y direcciones

La forma fiable de no depender de la memoria es separar físicamente las configuraciones: el staging tiene su propio conjunto de claves de acceso, su propia dirección de API y su propio dominio para callbacks. Un archivo de configuración común con un interruptor «prueba/producción» es la fuente de la mayoría de las averías, porque el interruptor puede olvidarse o confundirse durante el despliegue.

Conviene contrastar el formato de las claves con la documentación, por ejemplo con la documentación de la API de alquiler de números: a menudo la clave de prueba y la real son casi indistinguibles a simple vista, y la diferencia solo se nota por el prefijo o por la sección del panel personal donde se emitió la clave.

Un pool separado de números y buzones de correo para las ejecuciones

Una ejecución así necesita números y buzones reales; sin ellos no se puede comprobar la recepción de SMS ni de correos de confirmación. El error es tomarlos del pool real compartido: un número ocupado por las ejecuciones sale de la venta y, después de la ejecución, puede quedar vinculado a una cuenta real que nadie planeaba crear.

El esquema correcto es un pool aparte con el estado «prueba», asignado desde el momento de la entrega, y un registro independiente para él: los mismos campos que para los recursos reales, es decir, entorno, fecha y estado. Cómo se organiza un registro así en conjunto se explica en el artículo inventario de números, correos e IP.

Señales de que el staging apunta al lugar equivocado

Algunas señales que conviene revisar antes de cada lanzamiento de configuración: en los logs del staging aparece el dominio real o una dirección real del pool de rotación por API; un contador de la analítica real crece al mismo ritmo que la ejecución automática; al correo real de soporte llegan mensajes automáticos con nombres de prueba; el saldo de la billetera real baja sin acciones manuales justo cuando solo debería estar corriendo una ejecución de prueba.

Cualquiera de estas señales es motivo para detener la ejecución de inmediato, y no para añadirle la condición «omitir en producción».

La regla «la clave de prueba no debe existir en producción» y el checklist antes de la primera ejecución

La regla más fiable es más simple que cualquier monitoreo: la clave del staging físicamente no debe existir en el entorno de producción, ni la clave real en el de prueba. No «desactivada por defecto», sino ausente: así una llamada errónea falla por autorización y no llega al servicio real.

Antes de la primera ejecución automática conviene comprobar cuatro cosas: que la dirección de la API y la clave de acceso en la configuración del staging no estén copiadas de producción; que el pool de números y buzones para la ejecución sea independiente y esté marcado como de prueba; que en el staging haya un límite de operaciones, para que un error no se multiplique en cientos de solicitudes antes de que alguien lo note; y que los logs de la ejecución estén disponibles de inmediato, y no solo tras una solicitud manual.

Preguntas frecuentes

¿Cómo comprobar rápidamente que el staging no apunta a producción?

Haz una llamada de prueba claramente visible, por ejemplo, crea un recurso con un nombre único, y comprueba si aparece en el panel real. Si aparece, la configuración está mezclada.

¿Se pueden usar números reales para una ejecución corta?

No: incluso una ejecución corta ocupa un recurso del pool real, y si falla la limpieza, el recurso no vuelve a la venta a tiempo.

¿Qué hacer si una ejecución de prueba ya creó cuentas reales?

Exportarlas por un rasgo identificable, como el prefijo del nombre o una fecha de creación fuera del tráfico habitual, eliminarlas o desactivarlas manualmente y después cerrar la causa: una clave compartida o una dirección de API compartida.

Si para las pruebas necesitas un pool aparte de números y buzones reales sin riesgo para los datos de producción, en la sección de alquiler de números y correos los recursos se entregan por unidad y, por defecto, no se cruzan con los entornos de otros.