El botón "Implementar" es verde. El director del proyecto anuncia el lanzamiento online a las dos de la tarde. A las 2:20 p.m., el sitio responde, pero los correos electrónicos transaccionales aún provienen del servidor anterior, el certificado cubre el dominio incorrecto y nadie ha notificado al soporte que se avecina un nuevo flujo de tickets. A las seis de la tarde, la dirección solicita un retroceso que nadie sabe cómo ejecutar en menos de dos horas.
Pasar a producción es un evento organizacional, no una inserción de código. Esta lista de verificación vincula lo que hace la tecnología y lo que la empresa necesita comprender, sin jerga innecesaria, sin olvidar las partes que hacen daño: DNS, registros MX, cookies, facturación.
Antes del gran día: alineación empresarial
Una reunión de treinta minutos es suficiente si produce un documento compartido de una página. Cada línea debe tener una respuesta escrita: la ventana de mantenimiento (fecha, hora, zona, que permanece disponible durante cuatro horas), tres criterios de éxito mensurables (conexión correcta, pago de prueba correcto, tasa de error del servidor inferior al uno por ciento), quien toma las decisiones y el procedimiento de reversión, el plan de comunicación (correo electrónico del cliente, página de estado, resumen de soporte) y las limitaciones de los datos (migración básica, congelación de escrituras).
Si la empresa no puede explicar el retroceso en una frase, no está preparado.
Este documento no es un trámite: es lo que impide a un director anunciar “todo está online” mientras los correos electrónicos de confirmación aún no salen.
Lista de verificación técnica: infraestructura y DNS
En el lado de la infraestructura, verifique que exista una copia de seguridad de producción reciente y que se haya probado una restauración en los últimos siete días. El entorno de producción debe coincidir con el ensayo (versiones de PHP, extensiones, tareas programadas). Los secretos de producción deben estar separados y nunca copiados de un archivo de desarrollo. La supervisión debería alertar sobre errores del servidor, espacio en disco y caducidad de certificados. Los registros deben estar centralizados o ser accesibles sin tener que buscar en tres servidores.
En el lado de DNS y certificados, baje el TTL entre veinticuatro y cuarenta y ocho horas antes del cambio. Documente los registros A, AAAA y CNAME con un plan para volver a la dirección IP anterior. Si el correo electrónico cambia de servidor, verifique MX, SPF, DKIM y DMARC. El certificado TLS debe cubrir todos los nombres de host (www y dominio raíz).
En el lado de la aplicación, aplique migraciones básicas con un script de reversión en caso de falla. Borre o caliente el caché según la estrategia elegida. Utilice indicadores de funciones para habilitarlas gradualmente. Exponer un punto de control de estado (/health) para el balanceador de carga.
Día D: secuencia y roles
Sesenta minutos antes del cambio: congelación de contenidos, copia de seguridad final, confirmación del equipo de guardia. A la hora H: conmutación de DNS o conmutación de tráfico; supervise la propagación con herramientas externas, no solo desde su escritorio. Quince minutos después: pruebas automatizadas y proceso comercial manual (pedido, registro). Una hora después: revisión de métricas y decisión de continuar o retroceder. Veinticuatro horas después: aumente el TTL de DNS y realice una breve autopsia, incluso si tiene éxito.
Nombra los roles: comandante de incidentes (decide la reversión), gerente técnico, comunicaciones, validador de negocios. Sin nombres, todos esperan que alguien más decida.
Lo que la persona no técnica necesita escuchar
Explique sin infantilizar: "Estamos cambiando dónde se encuentra el sitio en Internet, no solo el diseño. » "La propagación de DNS puede tardar hasta X horas a pesar de un TTL bajo. » “El retroceso devuelve el sitio antiguo, no una versión intermedia. » “La primera hora es monitoreo mejorado, no una interrupción garantizada. »
Estas frases evitan malentendidos como “el sitio está en línea, así que todo funciona” mientras el proceso de pago o correo electrónico aún no funciona.
La cumbre: puesta en marcha exitosa = nadie se da cuenta – puesta en marcha fallida = todos
El marketing cuenta el confeti. La operación incluye los viajes completos: registro, pago, correo electrónico, administración, API de socio.
Decide y avanza sin puntos ciegos
Redactar un documento de una página para la empresa y una lista de verificación técnica firmada por el equipo. Pruebe la reversión en la puesta en escena cronometrándola; si demora más de una hora, corríjala antes del gran día. Breve soporte con probables incidencias y respuestas típicas. Elaborar un plan de comunicaciones si el deterioro supera los treinta minutos. Realizar una autopsia cuarenta y ocho horas después: tres puntos que conservar, tres que mejorar.
Consulte implementación azul-verde y verificación del estado de la aplicación. Compare hosts a través del directorio.
Preguntas frecuentes
¿Cuál es la diferencia entre puesta en escena y producción?
La producción brinda servicios a usuarios reales con un compromiso de tiempo de actividad, copias de seguridad probadas, monitoreo de alertas y un procedimiento de reversión documentado. La puesta en escena reproduce la configuración, no la carga real ni los datos siempre anonimizados correctamente.
¿Cuánto tiempo antes de la entrada en funcionamiento debería reducir el TTL de DNS?
De veinticuatro a cuarenta y ocho horas antes del cambio, aumente el TTL a 300 segundos. Vuelva a montarlo después de la estabilización para reducir la carga en los servidores DNS.
¿Qué debe entender un director de proyectos no técnico?
La ventana de mantenimiento, el riesgo residual, quién decide cuándo retroceder, el canal de comunicación en caso de incidente y criterios de éxito mensurables, no un simple "se ve bien".
¿Se requiere un runbook de reversión escrito?
Sí: pasos numerados, personas responsables nombradas, duración estimada y probados al menos una vez durante la puesta en escena. Una reversión improvisada cuesta más que el incidente inicial.
La producción comienza cuando el recorrido completo del cliente se mantiene, no cuando el proceso de integración continua está en verde.