Cómo decidir si un sistema de operaciones está listo para producción.

1. Define la unidad del release y el estado esperado

Nombra exactamente qué cambia: código, configuración, datos, permisos, comportamiento de una integración, contenido o un procedimiento operativo. Un release puede incluir varios elementos, pero cada uno necesita responsable y método de verificación. “Desplegar la plataforma” es demasiado amplio para sostener una decisión confiable.

Describe el estado esperado en producción con lenguaje de negocio. Identifica quién puede hacer qué, qué sistema gobierna cada dato crítico, qué acción ocurre después y cómo se ve una transacción o un flujo terminado. Esa descripción será la referencia para las pruebas y la verificación posterior.

• Cambios incluidos y cambios excluidos de forma explícita.
• Personas usuarias, sistemas, datos y dependencias externas afectadas.
• Comportamiento de negocio esperado después del release.
• Responsable de la decisión y responsable de cada área operativa.
• Ventana de trabajo, condiciones de congelamiento y ruta de comunicación.

Pregunta de preparación: ¿una persona de operaciones podría distinguir el nuevo estado del anterior sin leer el código fuente?

2. Concilia fuentes oficiales y cambios de estado

Muchas fallas operativas parecen exitosas en un sistema e incompletas en otro. Enumera cada transición y el sistema con autoridad sobre ella. Luego verifica que los identificadores, significados de estados, marcas de tiempo y reglas de responsabilidad permanezcan coherentes entre límites.

Si hay migración o carga retrospectiva, define conteos y muestras antes del release. Compara el total de origen, registros aceptados, rechazados, duplicados y diferencias sin explicación. Conserva un reporte que otra persona pueda repetir en vez de depender de una captura de una tarea verde.

• Sistema con autoridad para cada campo y estado crítico.
• Identificadores estables para relacionar o deduplicar registros.
• Conteos y tolerancias esperadas, con excepciones explicadas.
• Idempotencia o prevención de duplicados durante reintentos.
• Evidencia para identificar y reparar una ejecución parcial.

3. Prueba el recorrido completo, incluida la falla

Una prueba unitaria aprobada o una respuesta correcta de una API no demuestran el recorrido de la persona usuaria. Ejecuta casos representativos desde el primer disparador hasta el resultado visible final. Confirma qué ve la persona, qué registra cada sistema y qué recibe la siguiente responsable.

Prueba fallas controladas: dependencias no disponibles, permisos vencidos, campos ausentes, eventos duplicados, tiempos de espera, archivos inválidos, aprobaciones rechazadas y reintentos interrumpidos. El sistema debe fallar de forma veraz, conservar el trabajo recuperable y evitar multiplicar acciones.

• Caso normal con datos representativos del entorno real.
• Casos de borde en valores mínimos y máximos válidos.
• Intentos de acceso no autorizados o con alcance incorrecto.
• Tiempo de espera, servicio no disponible y comportamiento del reintento.
• Envíos duplicados y eventos fuera de orden.
• Recuperación manual después de interrumpir el flujo de forma deliberada.

Pregunta de evidencia: conserva para cada prueba crítica la condición de entrada, resultado esperado, resultado real, entorno y persona revisora; no solo una etiqueta de aprobado.

4. Revisa acceso, privacidad y exposición de datos

Verifica el acceso con límites reales de roles, no únicamente con una cuenta administradora. Cada persona debe ver lo mínimo necesario y cada servicio debe recibir solo los permisos requeridos. Revisa URL directas, archivos exportados, registros, notificaciones, herramientas de soporte y analítica, además de la interfaz principal.

Confirma que los datos de producción no se copian a entornos inseguros y que los secretos no aparecen en código, capturas, trazas o archivos enviados al navegador. Si el release cambia el manejo de datos personales o sensibles, pausa para la revisión de privacidad, seguridad, legal o cumplimiento que corresponda a la organización.

• Acceso y denegación para cada rol.
• Almacenamiento de secretos y responsabilidad sobre su rotación.
• Datos enviados a registros, analítica, soporte y terceros.
• Retención, eliminación y exportación afectadas por el cambio.
• Revisión especializada requerida y su resultado registrado.

5. Prepara la observabilidad y la responsabilidad operativa

Un release no es operable si la primera señal de falla es una queja. Define los eventos, señales de salud, profundidad de colas, diferencias de conciliación, categorías de error o excepciones de negocio que muestran si el flujo está sano. Cada alerta necesita responsable y una siguiente acción útil.

Escribe antes del lanzamiento una nota operativa breve: cómo verificar la salud, dónde consultar evidencia, cómo pausar el flujo, quién decide una reversión y cómo comunicar un incidente. Confirma que las personas nombradas tienen acceso a las herramientas y entienden el procedimiento.

• Señales de salud vinculadas a resultados de usuario o negocio.
• Registros e identificadores para rastrear una transacción de forma segura.
• Umbrales de alerta con responsable y ruta de respuesta.
• Cola o reporte de excepciones que requieren acción humana.
• Contactos de soporte e incidentes durante la ventana del release.

6. Demuestra la reversión y la recuperación

Una instrucción de reversión es creíble cuando nombra la versión anterior exacta, la configuración, las consecuencias sobre datos, el comando o control, la persona que decide y los pasos de verificación. En cambios con estado, restaurar código puede no restaurar registros que ya fueron transformados o enviados.

Elige la recuperación más segura para cada cambio: volver de versión, apagar una función, mover tráfico, restaurar configuración, ejecutar una compensación o aplicar una corrección controlada hacia adelante. Prueba el mecanismo en un entorno apropiado y registra lo que todavía exige coordinación manual.

• Versiones conocidas y estables de aplicación y configuración.
• Punto de recuperación y consecuencias sobre datos.
• Permiso para ejecutar la reversión y persona que la autoriza.
• Tiempo para detener el impacto y recuperar un servicio útil.
• Verificaciones que demuestran que la recuperación funcionó.

7. Decide avanzar o no avanzar a partir de evidencia

Reúne en un registro la evidencia de alcance, pruebas, riesgos pendientes, preparación operativa, recuperación y aprobaciones realmente necesarias. Clasifica cada punto abierto como bloqueo, riesgo aceptado con responsable y vencimiento, o seguimiento que no afecta la condición del release.

Avanzar con condiciones solo es útil si las condiciones se pueden medir y monitorear. Si el equipo no puede observarlas ni actuar cuando cambian, no son controles. Registra quién decidió, cuándo vence la decisión y qué evento activa una pausa o reversión.

Pregunta de decisión: si una afirmación crítica solo está respaldada por “debería funcionar”, trátala como no verificada. Aplaza, reduce el alcance o reúne la evidencia faltante.