Cómo operar IA local en producción: monitorización, copias e incidencias

Documenta servicios, estado, propietario y dependencia

Ficha por servicio

service: open-webui
owner: plataforma-ia
business_owner: soporte
host: ia-node-01
endpoint: https://ia.intranet.ejemplo
healthcheck: https://ia.intranet.ejemplo/health
upstream: http://127.0.0.1:3000
identity: oidc-corporativo
secrets: secret-store/open-webui
state:
  - postgres database
  - application data volume
backup_policy: daily + pre-change
restore_runbook: RB-IA-004
monitoring_dashboard: OBS-IA-WEBUI
rollback: previous image digest + database snapshot

Define qué debe estar disponible y en cuánto tiempo

Indicadores

• Disponibilidad: porcentaje de peticiones atendidas dentro de la ventana.
• Latencia: tiempo hasta primer token y respuesta completa por percentil.
• Capacidad: peticiones y tokens procesados sin superar cola o error.
• Calidad: regresión, errores críticos, citas y herramientas.
• Frescura: tiempo desde que cambia una fuente hasta que el índice la refleja.
• Recuperación: tiempo máximo aceptable para restablecer el servicio (RTO) y cantidad máxima de datos que se admite perder (RPO).

Plantilla SLO

Un SLO es una meta operativa medible: indica qué disponibilidad, velocidad, capacidad y recuperación debe alcanzar el servicio. No es una promesa genérica; debe asociarse a una métrica, un periodo de medición, un responsable y una acción cuando se incumple.

Servicio: asistente interno de soporte
Horario: jornada laboral definida por la empresa
Disponibilidad objetivo: ...
Latencia p95 para consulta representativa: ...
Cola máxima antes de degradar: ...
RTO: ...
RPO: ...
Frescura documental: ...
Errores críticos permitidos: cero
Modo degradado: búsqueda documental sin generación
Canal de incidente: ...
Responsable de decisión: ...

No fijes un objetivo sin presupuesto de capacidad y soporte. Un servicio no crítico puede aceptar recuperación manual; una plataforma compartida necesita automatización, redundancia o soporte acorde.

Observa infraestructura, inferencia, RAG y experiencia

Comandos de diagnóstico rápido

date -Is
uptime
free -h
df -h
df -i
nvidia-smi
docker compose ps
docker compose top
docker compose logs --since=30m --tail=300
ss -lntup
journalctl -p warning --since "30 minutes ago"

Ejecuta comandos con la cuenta autorizada. Los logs pueden contener datos; limita quién puede leerlos y evita copiarlos a canales no aprobados.

Alertas accionables

Cada alerta debe indicar impacto, umbral, ventana, propietario y runbook. Evita alertar por cada pico instantáneo. Ejemplo: memoria GPU por encima del margen durante varios minutos junto con cola creciente y errores de asignación.

Planifica por demanda, contexto y concurrencia

Datos que debes conservar

• Peticiones por hora y patrón diario.
• Usuarios activos y simultáneos.
• Tokens de entrada y salida por percentil.
• Modelos y tiempo residentes en memoria.
• Tiempo de cola, prefill y generación.
• Trabajos batch y ventanas.
• Crecimiento de documentos, índice y logs.

Modos de degradación

1. Reducir contexto o resultados RAG manteniendo evidencia mínima.
2. Enrutar tareas sencillas a un modelo compacto evaluado.
3. Limitar salidas y concurrencia por usuario.
4. Poner trabajos batch en cola fuera del pico.
5. Desactivar temporalmente una función no crítica.
6. Ofrecer búsqueda con fuentes sin generación cuando sea posible.

Señales para ampliar hardware

• La cola supera el objetivo con uso legítimo y configuración optimizada.
• La carga representativa no cabe sin degradar calidad.
• El p95 permanece fuera de objetivo tras ajustar contexto y motor.
• No existe margen para actualización o fallo de una réplica.
• Los trabajos visuales compiten con el chat y requieren aislamiento.

Una GPU adicional puede servir réplicas o separar cargas. DGX Spark aporta memoria coherente para modelos que exceden VRAM; DGX Station o servidores profesionales se justifican cuando capacidad, servicio y soporte lo demuestran. No uses petaFLOP FP4 como sustituto de mediciones de tu carga.

Copia fuentes de verdad y prueba una restauración completa

Backup lógico de Postgres

set -euo pipefail
umask 077
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
DEST="/srv/ia/backups/postgres/${STAMP}"
install -d -m 0700 "$DEST"

docker compose exec -T postgres \
  pg_dump --format=custom --no-owner --no-acl \
  --username="${POSTGRES_USER}" "${POSTGRES_DB}" \
  > "${DEST}/ia.dump"

sha256sum "${DEST}/ia.dump" > "${DEST}/SHA256SUMS"
test -s "${DEST}/ia.dump"

No guardes contraseña en el script. Cárgala desde un entorno o secreto con permisos limitados. Cifra y replica fuera del host según política.

Snapshot de una colección vectorial

curl -fsS -X POST \
  "http://127.0.0.1:6333/collections/COLECCION/snapshots" \
  -H "api-key: ${QDRANT_API_KEY}"

El endpoint debe estar en localhost o red administrativa. Verifica el procedimiento de la versión fijada y copia el snapshot fuera del contenedor.

Regla de tres copias

Conserva la fuente operativa, una copia separada del host y otra protegida frente al mismo incidente. Cifra, controla acceso, prueba integridad y aplica retención. Una réplica sincronizada no sustituye una copia frente a borrado o corrupción.

Practica la recuperación en un entorno distinto

Orden recomendado

1. Provisiona un host limpio

   Misma arquitectura o compatible, red aislada y sin usuarios.

2. Restaura configuración y secretos

   Desde fuentes autorizadas; rota credenciales si el incidente pudo exponerlas.

3. Arranca dependencias

   Base, vectorial y almacenamiento antes de aplicaciones.

4. Restaura estado

   Importa Postgres, snapshots y datos persistentes.

5. Recupera modelos

   Verifica hashes, licencia y compatibilidad.

6. Valida identidad y permisos

   Prueba usuarios, grupos, baja y aislamiento RAG.

7. Ejecuta evaluación mínima

   Smoke test, regresión crítica, herramienta en modo prueba y carga breve.

8. Decide el retorno

   Documenta RPO alcanzado, diferencias y aprobación.

Restaurar un dump lógico

sha256sum -c SHA256SUMS

docker compose exec -T postgres \
  createdb --username="${POSTGRES_USER}" ia_restore_test

docker compose exec -T postgres \
  pg_restore --clean --if-exists --no-owner --no-acl \
  --username="${POSTGRES_USER}" --dbname=ia_restore_test \
  < ia.dump

Prueba sobre una base separada. No ejecutes --clean contra producción sin un plan y aprobación.

Acta de restauración

• Inicio y fin.
• Copia utilizada y hashes.
• RPO y RTO reales.
• Servicios recuperados.
• Pruebas ejecutadas.
• Diferencias y acciones.
• Responsables y aprobación.

Cambia una variable, evalúa y conserva volver a la versión anterior

Qué puede alterar la conducta

• Modelo, cuantización o adaptador.
• Programa que ejecuta el modelo, driver o librería CUDA.
• Prompt de sistema, plantilla o parámetros.
• Embeddings, fragmentación, índice o reranker.
• Open WebUI, n8n, nodos o extensiones.
• Herramientas, schemas, permisos o APIs.
• Documentos, metadatos y políticas.

Proceso de cambio

1. Registrar

   Motivo, versión actual, objetivo, propietario y riesgo.

2. Respaldar

   Copia consistente y verificación de espacio y restauración.

3. Probar

   Entorno de preproducción con dataset y seguridad.

4. Desplegar gradualmente

   Grupo pequeño o réplica canaria.

5. Observar

   Calidad, latencia, errores, memoria y feedback.

6. Confirmar o revertir

   Criterios definidos antes del cambio.

Actualización de Compose

cd /srv/ia/compose
cp env.production "env.production.backup.$(date -u +%Y%m%dT%H%M%SZ)"
docker compose --env-file env.candidate config > rendered-candidate.yaml
docker compose --env-file env.candidate pull
docker image inspect IMAGEN@sha256:DIGEST
docker compose --env-file env.candidate up -d
docker compose ps
docker compose logs --since=10m --tail=300
# Ejecutar smoke tests y regresión crítica antes de ampliar usuarios.

Para volver a la versión anterior, conserva la configuración anterior, digest, copia de base compatible y procedimiento. Una migración de esquema puede impedir volver solo cambiando la imagen.

Clasifica impacto, contiene y conserva evidencia mínima

Runbook de primera respuesta

1. Confirma hora, alcance, usuarios y primera señal.
2. Asigna responsable y canal de coordinación.
3. Detén la función o acceso que puede aumentar el daño.
4. Preserva IDs, métricas, versiones y cambios recientes.
5. No copies datos sensibles a chats no autorizados.
6. Aplica volver a la versión anterior o recuperación conocida.
7. Verifica con pruebas y comunica el estado.
8. Analiza causa y crea acciones y regresión.

Comando para recoger estado sin contenido

set -euo pipefail
OUT="ops-state-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -m 0700 "$OUT"
date -Is > "$OUT/time.txt"
uptime > "$OUT/uptime.txt"
df -h > "$OUT/disk.txt"
free -h > "$OUT/memory.txt"
nvidia-smi > "$OUT/nvidia-smi.txt" 2>&1 || true
docker compose ps > "$OUT/compose-ps.txt"
docker inspect $(docker compose ps -q) \
  --format '{{.Name}} {{.Image}} {{.State.Status}}' > "$OUT/containers.txt"
tar -czf "${OUT}.tar.gz" "$OUT"
sha256sum "${OUT}.tar.gz" > "${OUT}.sha256"

No incluye logs ni cuerpos. Añádelos solo según necesidad y política.

Calendario operativo recomendado

Matriz RACI mínima

Un servicio listo para ser mantenido

• Inventario y propietario de cada componente.
• SLO, RTO, RPO y modo degradado.
• Panel de host, GPU, programa que ejecuta el modelo, RAG y aplicación.
• Alertas con responsable y runbook.
• Capacidad medida con percentiles y concurrencia.
• Backups de configuración, base, índice y fuentes.
• Restauración probada en entorno separado.
• Imágenes y modelos fijados por digest o hash.
• Proceso de cambio, canario y volver a la versión anterior.
• Dataset de regresión antes de cada cambio.
• Severidades y canal de incidente.
• Accesos y secretos revisados.
• Retención de logs y documentos aplicada.
• Otra persona ha ejecutado el runbook.