Lista de comprobación de preparación para producción

Usa esta lista como registro de aprobación, no como una lista que un operador marca en silencio. El responsable del servicio define los caminos críticos para el negocio, el responsable de la plataforma demuestra la recuperación de la infraestructura, el responsable de seguridad aprueba la identidad y la exposición, y los responsables de las aplicaciones demuestran los datos y la reversión. Asigna cada sección antes de la revisión de preparación.

Una instalación lista para producción tiene responsables conocidos, recuperación probada, caminos de cliente observables y pruebas de que los fallos habituales no obligan a improvisar en el host. Que un build termine bien o ver tarjetas en verde en la interfaz es necesario, pero no suficiente.

Plano de control

• La URL HTTPS canónica, las cookies, los WebSockets y las redirecciones OAuth funcionan.
• PostgreSQL, Redis, la identidad de Relay, las claves de cifrado y los artefactos subidos son persistentes y tienen copia de seguridad.
• Relay es el responsable del puerto público 9443/tcp y se recupera tras un reinicio.
• Al menos dos Relays se ejecutan en hosts distintos del host de Opfield, en dominios de fallo diferentes (host, alimentación, ruta de red); consulta Cuántos Relays.
• El estado de la licencia y los derechos de plan necesarios están en orden.

Identidad

• Existen dos vías independientes de recuperación de administradores.
• MFA y los ámbitos de grupo están probados con usuarios reales sin privilegios de administrador.
• Las credenciales de API/OAuth/MCP tienen el mínimo privilegio y están inventariadas.

Nodos gestionados

• Cada rol informa de las capacidades y el canal de actualización esperados.
• Se han probado el comportamiento sin conexión, el reinicio del daemon, el reinicio del nodo y la reconexión.
• Los cortafuegos solo permiten el tráfico documentado.
• Los nodos Storage llegan a ghcr.io, y un nodo Storage en LXC tiene un pool de dispositivos loop dimensionado para cada instancia gestionada y para las copias de seguridad simultáneas.
• Los nodos Docker que tienen leases de Availability ejecutan el lease watchdog y llegan a todos los Relays.

Cargas de trabajo y datos

• Se han demostrado el despliegue, la comprobación de estado, la reversión, los logs, la copia de seguridad y la restauración.
• Las vinculaciones de bases de datos gestionadas superan las pruebas de recreación de Opfield, Relay, el daemon, el nodo y la carga de trabajo.
• No hay credenciales de propietario en la configuración de las cargas de trabajo.

Tráfico de clientes

• Se han probado el DNS, la renovación de TLS, la migración de ingress, el modo de mantenimiento y el fallo de un upstream.
• Las notificaciones y la comunicación de la página de estado llegan a sus destinatarios.

Operaciones

• Los runbooks de actualización y reversión tienen responsables.
• Están activas las alertas de disco, certificados, bases de datos, colas, Relay y nodos.
• Se ha completado un simulacro de incidente sin depender de cambios en la shell sin documentar.

Paquete de pruebas

No apruebes la puesta en producción solo con una inspección visual. Conserva pruebas de:

• la versión de la instalación y los digests de las imágenes;
• la finalización de las copias de seguridad y una prueba de restauración reciente;
• la verificación externa de DNS/TLS/HTTP;
• las pruebas de permisos sin privilegios de administrador;
• las pruebas de reinicio y reconexión de nodos para cada rol desplegado;
• el comportamiento de Opfield, Relay, el daemon y las cargas de trabajo al reiniciarse;
• los resultados de consultas a través de vinculaciones de bases de datos antes y después de la recreación;
• la apertura y recuperación de alertas y la entrega de notificaciones;
• un ensayo de actualización y reversión;
• las excepciones sin resolver, con responsable y fecha de caducidad.

Decisión de seguir o no seguir

El despliegue es no-go cuando la recuperación de administradores no está probada, las claves persistentes no tienen copia de seguridad, el tráfico de producción depende solo del Relay local, Relay tiene una ruta de recuperación desconocida, se ignoran errores de capacidades de nodos, el tráfico de clientes no se puede verificar desde fuera o una vinculación de base de datos requiere reparar a mano un contenedor o un rol.

Una excepción temporal aceptada debe indicar el impacto en los clientes, el control compensatorio, el responsable, el plazo y el desencadenante de la reversión. «Funciona en el host actual» no es un argumento de preparación para producción.

Observación del primer día

Tras activar el tráfico de negocio, vigila el estado de las Routes, TLS, la presión sobre Relay, la actualidad de los datos de los nodos, los reinicios de cargas de trabajo, las conexiones a bases de datos, el crecimiento del disco, las colas de notificaciones y la actividad de auditoría. Mantén disponible al responsable de la reversión durante la ventana de observación y evita cambios de plataforma no relacionados.

Formato de la revisión de preparación

Haz la revisión sobre una versión y una instalación concretas. Para cada área, registra pass, excepción aceptada o no-go, junto con un enlace a las pruebas y un responsable. No arrastres pruebas de una versión anterior cuando haya cambiado el componente de ciclo de vida, daemon, Relay, base de datos o ingress correspondiente.

Usa una fila por cada comprobación de aceptación para que un revisor con menos experiencia vea qué se probó y un usuario avanzado pueda reproducirlo:

Área	Responsable	Comprobación realizada	Resultado	Pruebas	Excepción o seguimiento
Ejemplo: aplicación pública	Equipo de la aplicación	DNS externo, TLS y camino principal del usuario	Pass	Enlace al Task, a la petición o al informe	Ninguna

No escribas solo «funciona» o «comprobado». Las pruebas deben identificar el recurso exacto, la versión, el lugar desde el que se probó, la hora y el resultado esperado.

Empieza por los tres recorridos que tendrían un impacto inmediato en el negocio: la recuperación de administradores, el tráfico público de clientes y el acceso de las aplicaciones a los datos persistentes. Después revisa las capacidades de apoyo, como los builds, Pages, las notificaciones, la IA y las integraciones opcionales, según lo que la instalación vaya a usar realmente. Las funciones no usadas y sin probar no bloquean el lanzamiento; las funciones críticas activadas, sí.

Escenarios mínimos de aceptación

1. Un nuevo usuario autorizado inicia sesión, completa MFA y se le deniega un recurso fuera de su ámbito.
2. Una carga de trabajo compatible se despliega, se observa, se reinicia y se revierte sin editar el host.
3. Una Route pública se verifica desde una red externa con el certificado y el comportamiento de estado esperados.
4. Un nodo gestionado se desconecta y se vuelve a conectar sin perder el estado deseado.
5. Opfield se reinicia mientras las cargas de trabajo de los clientes permanecen en su estado documentado.
6. Una copia de seguridad se restaura en un entorno limpio y compatible, y los secretos necesarios se descifran.
7. Las alertas se abren y se recuperan durante un fallo controlado, y el destinatario previsto las recibe.

La aprobación debe indicar el alcance que se probó. No afirmes que todo el producto está validado cuando solo se ha ejercitado un rol de nodo, un motor de bases de datos, un perfil de ejecución o una ruta de actualización.