Fiabilidad y autorreparación

Sondas

La mayoría de las sondas deben fallar dos veces seguidas antes de que se abra una incidencia; un contenedor detenido o una base de datos corrupta actúan al primer fallo. Una sonda superada pone a cero el contador de todos los tipos de incidencia que puede plantear.

El manual de actuación

• Servicio o escucha caído: reiniciar el contenedor y esperar a la salud; si los registros muestran un token de chat no válido, escalar con el extracto en lugar de reescribir un token en silencio.
• Escucha obsoleto dos veces en una hora: escalar, porque eso parece una regresión y no un tropiezo.
• Flujo de eventos o API caídos: recargar la configuración del proxy si valida, reiniciar el contenedor y, si hubo un despliegue en las últimas 24 horas, marcarlo como candidato a reversión.
• Presión de disco: compactar el diario, rotar los registros, purgar el estado del guardián.
• Certificado a punto de caducar: renovar y recargar el proxy.
• Antioscilación: la misma incidencia repetida más veces que el número configurado en 24 horas detiene la autorreparación y escala.

Más allá de los reinicios

• Un resumen diario recopila incidencias y acciones.
• Una ejecución sintética semanal de extremo a extremo ejercita los flujos reales contra staging.
• Una vigilancia lógica ejecuta la propia batería de pruebas del producto contra el código desplegado en un contenedor de solo lectura y compara con la línea base verde: una prueba que estaba verde y ahora está roja es una regresión; una prueba roja que no está en la línea base es una notificación, no una acción.
• Un pipeline de corrección autónomo puede llevar una regresión confirmada por un parche acotado, pruebas locales, una rama, CI, staging, la ejecución sintética, fusión y producción con una compuerta de salud y reversión automática. Los secretos sensibles se eliminan de su entorno y las rutas prohibidas se rechazan.
• El guardián se ejecuta bajo un supervisor de servicios con un vigilante, de modo que un bucle bloqueado se reinicia, no solo uno que ha fallado.

Dentro del producto

• Una bandeja de salida duradera del bot: los mensajes de aprobación, los avisos de sala y sus retiradas se escriben en la base de datos y el bucle los vacía, de modo que una decisión tomada mientras el bot está caído se entrega igualmente.
• Los webhooks se reintentan con retroceso y un circuito por endpoint.
• Un barrido nocturno concilia la lista de eventos del homeserver con el propio registro de mensajes del bot y anota cada mensaje que nunca llegó a entrar; un hueco se retira cuando el mensaje aparece más tarde, y un barrido parcial se registra como incompleto y no como limpio.
• Un vigilante de materialización alerta a los administradores cuando la puntuación en caché más reciente tiene más de 26 horas o la ventana está insuficientemente cubierta.
• La tarea a prueba de fallos de la IA cambia de proveedor cuando el activo deja de responder.
• Cada tarea que puntúa se ejecuta fuera del bucle de eventos, de modo que una pasada larga nunca puede congelar el bot; una prueba lo garantiza.