Runbook de incidentes

Este runbook ayuda al responsable del incidente a proteger el servicio a los clientes, determinar a qué subsistema corresponde el fallo y elegir un camino de recuperación reversible. El responsable del incidente se ocupa de las prioridades y de la comunicación; el operador de la plataforma, de las pruebas de Opfield y de los nodos gestionados; y los responsables de las aplicaciones y de las bases de datos validan sus servicios. No dejes que la persona que escribe los comandos sea la única que decide sobre el riesgo.

El éxito significa que se entiende el impacto en los clientes, que los cambios posteriores están controlados, que el estado de ejecución autoritativo está conciliado y que la recuperación se verifica desde el camino de cara al usuario. Un Dashboard en verde por sí solo no es una prueba de recuperación.

Los primeros cinco minutos

1. Registra la hora de inicio, el camino de cliente afectado y los cambios recientes.
2. Comprueba el estado de Opfield, PostgreSQL, Redis y Relay.
3. Identifica si el impacto está en el plano de control, en el tráfico entrante, en un nodo, en una carga de trabajo o en una dependencia compartida.
4. Congela los cambios no relacionados.
5. Usa el modo de mantenimiento o un incidente en la página de estado cuando se confirme el impacto en los clientes.

Relay no disponible

Inspecciona el servicio de Relay, el volumen de identidad, la accesibilidad de la base de datos, la versión de la imagen y el puerto público 9443/tcp. En Settings > Relay, comprueba el estado de confianza de la política y del certificado de cada miembro: Opfield recupera automáticamente la confianza del Relay local, y un miembro remoto marcado para volver a registrarse o con un certificado caducado se puede recuperar con Re-enroll o Renew certificate; consulta Recuperación de Relay en la 2.11. No devuelvas el puerto a la aplicación ni eludas la autorización con un nuevo listener público.

Nodo desconectado

Las cargas de trabajo existentes pueden seguir funcionando. Las políticas de Availability en modo lease trasladan por sí solas los slots del nodo a otros candidatos; comprueba Lease mode y los titulares en el resumen de Availability de la carga de trabajo antes de actuar. Comprueba la alimentación y la red del host, el servicio del daemon, la hora, la identidad del certificado y la accesibilidad saliente hacia Relay. No hagas cambios a partir de un inventario desactualizado.

Versión defectuosa

Para los Deployments, revierte al slot anterior en buen estado. Para Pages, mueve el Tag. Para los contenedores construidos desde Git, vuelve a desplegar el último digest aprobado. Si el destino informa de BUILD_ROLLOUT_IN_PROGRESS, espera a que el despliegue en curso termine o falle antes de volver a desplegar. Conserva los logs y el historial de operaciones.

Fallo de una vinculación de base de datos

Comprueba Relay, ambos nodos, el estado de la base de datos, el estado deseado de la vinculación, el enlace de la vinculación en el conector de Secure Links del nodo de destino y el principal del motor. Reintenta la conciliación antes de cambiar identidades a mano; no hay un contenedor conector por vinculación ni un listener en el host que reiniciar o sustituir.

Usa las comprobaciones capa por capa de Vinculaciones de bases de datos para aplicaciones y conserva el Task fallido antes de reintentar. Cuando los clientes informan de Connection terminated unexpectedly o ECONNRESET bajo carga, sobre todo durante un despliegue, lee primero el estado de ejecución del enlace: un throttledTotal creciente, registrado en el nodo como managed link connection rejected con reason=link_limit, significa que los pools de los contenedores superan la capacidad del enlace, que es el propio límite de conexiones de la base de datos compartido por todos sus enlaces; consulta Capacidad de los enlaces y pools de conexiones.

Cierre

Confirma la recuperación desde un cliente externo, retira el mantenimiento de forma intencionada, documenta la causa raíz y el hueco de detección, y crea trabajo de seguimiento para cada mitigación temporal.

Plano de control no disponible

Comprueba el contenedor o el proceso de Opfield, PostgreSQL, Redis, los volúmenes persistentes, la presión de disco, las migraciones y los logs de la aplicación. Mientras la API siga respondiendo, el asistente o un cliente MCP con diagnostics:view puede leer todo esto con manage_opfield_diagnostics, y diagnostics:logs añade los logs de los contenedores; consulta Diagnóstico de Opfield. Conserva las claves de cifrado y la base de datos existentes antes de intentar una instancia sustituta. Si las cargas de trabajo de los clientes siguen funcionando, evita cambios amplios en el host mientras restableces el plano de control.

Determina primero si Relay sigue siendo accesible. Si Relay está en buen estado, la configuración de nginx ya aplicada, los contenedores, las bases de datos y los flujos privados existentes permitidos pueden seguir funcionando mientras las nuevas decisiones de gestión y de autorización esperan. Los Relays siguen admitiendo nuevas conexiones de Secure Link y de enlaces de bases de datos con su última política firmada durante el lease de la política, las políticas de Availability en modo lease siguen conmutando por error y la página de estado pública se sirve desde la caché del nodo Ingress. Si el único Relay es local al host de Opfield que ha fallado, los Secure Links y las sesiones de los nodos gestionados también pierden su transporte; las cargas de trabajo locales ordinarias de cada host pueden seguir funcionando, pero los flujos existentes que dependen de Relay no están garantizados. Los miembros externos e independientes de Relay reducen este fallo compartido solo cuando los nodos pueden llegar a ellos y usarlos realmente.

Cuando Opfield vuelva, verifica el inicio de sesión, el descifrado, el estado de Relay, los trabajos en segundo plano, el descubrimiento de actualizaciones, las notificaciones y que haya instantáneas nuevas de los nodos. No supongas que los daemons se han conciliado solo porque el Dashboard cargue.

Usa Disponibilidad, compatibilidad y límites para clasificar los caminos afectados y Actualizaciones y copias de seguridad antes de restaurar una instancia sustituta o cambiar el estado persistente.

Caída del tráfico entrante

Sigue Solución de problemas del tráfico entrante desde el DNS, pasando por la red, TLS, la aplicación en nginx y el estado de la Route, hasta el upstream. Usa el modo de mantenimiento cuando el host virtual deba permanecer estable durante la reparación. Conserva los errores de validación de la configuración generada y las pruebas de las peticiones externas.

Operación de una carga de trabajo atascada

Inspecciona el Task duradero, la conexión del nodo propietario, el historial de operaciones del daemon, el recurso en ejecución y el ID de petición u operación. Un tiempo de espera agotado en el navegador no demuestra que el comando haya fallado. Concilia la primera operación antes de iniciar una creación, recreación, migración o eliminación duplicadas.

Si Force Cancel está disponible, entiende si cancela solo el seguimiento de Opfield o si también envía la cancelación al propietario. Tras la cancelación, actualiza el estado de ejecución y elimina cualquier marcador de operación interrumpida solo a través del camino de conciliación compatible.

Usa Tasks, eventos y auditoría para distinguir el trabajo aceptado, en ejecución, cancelado y completado, y continúa después con el recurso de Docker propietario.

Base de datos no disponible

Separa los fallos de estado del motor, de almacenamiento, de publicación directa, de vinculación gestionada y de consultas de la aplicación. Verifica el nodo Storage, el contenedor del motor, la imagen o el montaje del almacenamiento, la instantánea de monitorización, el camino de Relay, el nodo Docker de destino, el conector de Secure Links del nodo, la identidad de la vinculación y la configuración de la aplicación.

No elimines la base de datos ni el principal del motor como paso de diagnóstico. Conserva el almacenamiento y el historial de operaciones y reintenta la conciliación concreta que falló.

Continúa con Operaciones con bases de datos para las comprobaciones del motor, el almacenamiento, las copias de seguridad y la restauración, o con Vinculaciones de bases de datos para aplicaciones cuando solo esté afectado el camino privado de la aplicación.

Comunicación y pruebas

Mantén una única cronología del incidente con marcas de tiempo UTC, los recursos afectados, el impacto visible para los usuarios, los cambios, los ID de Tasks, los ID de peticiones, las decisiones y la verificación. Las actualizaciones públicas describen el impacto y el progreso sin exponer la topología ni detalles de seguridad.

Condiciones para dar por recuperado

La recuperación requiere que:

• el camino de cara al cliente funcione desde fuera de la red gestionada;
• el estado deseado de Opfield coincida con el estado actual del propietario;
• las alertas se recuperen por el motivo correcto;
• se entiendan las operaciones y las entregas en cola;
• se retiren las exposiciones o los atajos temporales;
• exista un responsable y un plazo de seguimiento para cada riesgo pendiente.

Marco de decisión para el responsable del incidente

Prefiere las acciones que conservan las pruebas y reducen el radio de impacto. Pausa la automatización no relacionada antes de reiniciar servicios compartidos. Si el plano de control no está disponible pero las cargas de trabajo siguen sirviendo tráfico, restablece la gestión sin recrear los recursos que están en buen estado. Si el tráfico entrante está en mal estado, mantén estable el nombre de host con el modo de mantenimiento o con una reversión probada en lugar de cambiar el DNS repetidamente. Si la integridad de los datos es incierta, detén las escrituras antes de optimizar la disponibilidad.

Escala de inmediato cuando el incidente implique una posible divulgación de credenciales, almacenamiento dañado, un estado desconocido de una migración de esquema, la pérdida de la identidad de Relay, una propiedad incoherente de las vinculaciones de bases de datos o un artefacto de versión que no se puede verificar. Estas condiciones pueden convertir un reinicio rutinario en una pérdida permanente o en un acceso no autorizado.

Tabla de pruebas del operador

Prueba	Por qué importa
DNS externo, TLS y respuesta de la aplicación	Confirma el impacto real en los clientes
Estado de Opfield, PostgreSQL, Redis y Relay	Separa los fallos del plano de control de los del plano de datos
Última conexión del nodo, estado de las capacidades y logs del daemon	Identifica al propietario de la ejecución y el inventario desactualizado
ID de Tasks, operaciones y peticiones	Evita cambios duplicados o ambiguos
Última versión aprobada y digest del artefacto	Proporciona un destino de reversión conocido
Estado de las copias de seguridad de bases de datos y volúmenes	Define las opciones de recuperación seguras

Tras la recuperación, haz una revisión breve mientras las pruebas siguen disponibles. Registra el cambio que lo desencadenó, por qué la detección funcionó o no, qué pasos manuales fueron necesarios y qué verificación habría detectado antes el problema. Convierte las instrucciones temporales en un cambio probado del runbook en lugar de conservar un historial de shell sin documentar.