Skip to content

Runbook de operaciones

El handoff para el operador: cómo se despliega, se ejecuta y se vigila el sistema, descrito a nivel de arquitectura. Los comandos exactos del operador viven en la referencia privada de comandos de operador; esta página es la referencia pública de la forma operativa, y cada sección enlaza a la página que la documenta en profundidad.

El sistema está construido para que ningún paso de release dependa de que un operador recuerde hacer lo correcto a mano.

  • El despliegue es automático, no manual. Un release es un tag vX.Y.Z; una matriz de CI verde sobre ese tag exacto es la compuerta, y el despliegue corre del lado del servidor solo después de que la matriz pasa. Ningún operador publica un release de producción a mano. Consulta Despliegue.
  • La vigilancia es continua. Cada nodo, llamada al modelo, recuperación y barrera de seguridad emite una traza, y los presupuestos de costo y latencia se imponen por turno. Consulta Observabilidad.
  • La respuesta es una operación de tráfico. El rollback desvía el tráfico a la revisión sana anterior al instante, sin reconstrucción; una revisión fallida nunca toma tráfico.
  • Los cambios aplicados por el operador son aditivos y explícitos. Los pocos ajustes que un operador aplica - habilitar la revisión humana durable, o cambiar scale-to-zero por una instancia caliente - son aditivos, nunca un reinicio completo del entorno.

Listo para producción: definición de hecho

Section titled “Listo para producción: definición de hecho”

“Listo para producción” aquí es una lista con evidencia, no una sensación. Un release está listo cuando:

  • La matriz completa de CI está verde en el commit etiquetado exacto: esta es la compuerta de despliegue; una matriz en rojo significa que no se publica nada.
  • El despliegue es sin claves (un token federado de corta vida, sin clave almacenada) y preserva secretos (la reconstrucción desde la fuente mantiene el entorno y los enlaces de secretos existentes del servicio). Consulta Despliegue.
  • La documentación pública pasa su verificación de fugas fail-closed, de modo que ninguna ruta interna, identificador privado ni constante afinada llega al sitio público.
  • La compuerta de evaluación pasa: puntuadores deterministas en cada cambio, los umbrales del corpus respaldados por el juez en la corrida nocturna, y la compuerta de calibración del juez armada en fail-closed sobre las dos dimensiones de seguridad (escalamiento y autolesión).
  • El piso de seguridad se sostiene: las categorías deterministas de emergencia aguda hacen cortocircuito antes de cualquier llamada al modelo y nunca se condicionan detrás de la revisión humana.
  • Las compuertas de accesibilidad y de regresión visual del frontend pasan.
  • Los rieles de seguridad se imponen en la revisión en ejecución: origin-lock en el edge, la verificación de bots, el consentimiento por clave, y los limitadores de tasa y de concurrencia. Consulta Seguridad.
  • Cadencia de despliegue. Tag, luego la compuerta de CI vuelve a correr la matriz completa sobre ese tag, luego el despliegue corre solo en verde, luego el tráfico se desvía cuando la nueva revisión está sana.
  • Qué vigilar. Spans de OpenTelemetry a lo largo de cada nodo y llamada al modelo; la señal de salud del juez en la evaluación nocturna; las señales de drift del Plan de detección de drift; y el rastro del Plan de audit logging.
  • Keep-warm. Un planificador externo hace ping a una ruta keep-warm de tiempo constante para suavizar los arranques en frío sin mantener una instancia siempre encendida.
  • El costo en estado estable es un objetivo de diseño. El servicio corre scale-to-zero, así que el tráfico a escala de demo se mantiene dentro de la asignación siempre-gratuita del host y el gasto en estado estable se mantiene cerca de $0 / mes. Esta es una postura de portafolio deliberada; un SLA de producción y el escalado multi-tenant están fuera de alcance para la demo pública.
  • El costo se contabiliza como si se pagara. El costo de tokens y cómputo por turno se tarifa a precios reales de pago-por-uso y se mide del lado del servidor; un cortacircuitos duro de gasto diario y un techo mensual detienen el gasto desbocado y se reinician con una cadencia fija.
  • Los presupuestos por turno se imponen. Los presupuestos de tokens y latencia acotan cada turno; un turno que los excedería se detiene en lugar de servirse sin límite.
  • Existe un camino de UX de producción. Un operador que necesita eliminar el arranque en frío puede correr una instancia caliente y siempre encendida por un pequeño costo mensual fijo; es un ajuste aditivo, aplicado por el operador, nunca auto-aplicado a la demo. El blueprint con costos está en el enterprise agent stack.

La revisión humana de un borrador de alto riesgo pero no agudo es una capacidad opt-in, desactivada por defecto. Se compila en el grafo del agente solo cuando se habilita, y habilitarla en producción requiere un checkpointer durable (un almacén de conversación respaldado por Postgres) y una instancia caliente, para que un turno en pausa sobreviva a un reciclaje de scale-to-zero. Las emergencias agudas nunca dependen de ella: las categorías agudas deterministas se manejan antes de que el modelo corra y evitan la revisión humana por completo.

  • El rollback es instantáneo y sin reconstrucción: desvía el tráfico a la revisión sana anterior.
  • Rueda hacia adelante un arreglo revirtiendo el commit ofensor y cortando un nuevo tag, que vuelve a correr la compuerta y, en verde, redespliega.
  • Los cortacircuitos de gasto fallan seguro: se disparan sobre el gasto medido y se reinician con una cadencia fija, así que un incidente de costo queda acotado automáticamente.
  • El endpoint público de topología no lleva secretos: devuelve solo los nombres de nodo del grafo compilado, las aristas y los booleanos de feature, y una prueba de CI permanente bloquea ese contrato.