Skip to main content
La aprobación es el corazón de la Gestión de Cambios. Todo lo que vaya a alterar un sistema pasa por una puerta humana antes de ejecutarse — ya sea un cambio estándar escrito a mano o un lote de parches del sistema operativo. Esta página cubre esa puerta de principio a fin y cómo gobernarla con reglas de aprobación.

La puerta, paso a paso

1

Submit

El autor termina el borrador y lo envía con Submit. El cambio pasa a Enviado y la regla de aprobación correspondiente determina quién debe dar el visto bueno y cuántas aprobaciones se necesitan.
2

Revisar y decidir

Los aprobadores abren el cambio, revisan la justificación, el riesgo, la ventana y el plan, y eligen Approve o Reject. El panel de Aprobaciones rastrea el progreso en vivo — por ejemplo 2 de 3 — y muestra qué regla está en vigor.
3

Aprobado

Una vez alcanzado el número requerido de aprobaciones, el cambio pasa a Aprobado y está listo para ejecutarse.
4

Execute: los dos caminos

Un cambio estándar se inicia explícitamente con Execute (Aprobado → Ejecutando), y los agentes ejecutan los pasos. Un parche de actualización no necesita disparo manual — se instala automáticamente dentro de su ventana de mantenimiento programada.
5

Cerrado y auditado

El cambio finaliza como Completado (o Parcial / Fallido), y toda la traza de decisiones queda registrada en su historial.

Aprobar y rechazar

  • Approve registra tu decisión a nombre de tu usuario. Cuando el cambio alcanza el número requerido de aprobaciones, avanza automáticamente.
  • Reject finaliza el flujo de aprobación — el cambio pasa a Rechazado. Puedes adjuntar un motivo para que el autor sepa qué corregir; luego puede editar el cambio (lo que lo devuelve a Borrador) y volver a enviarlo.
Cada aprobación y rechazo se atribuye al usuario que la realizó, con una marca de tiempo, y aparece en el historial de Actividad del cambio — de modo que el registro responde por sí solo “¿quién aprobó esto, y cuándo?”.

Los dos caminos de ejecución

La puerta de aprobación es idéntica para ambos tipos de cambio; solo difiere lo que sucede después de la aprobación.

Cambio estándar — tú ejecutas (Execute)

Tras la aprobación, una persona hace clic en Execute para iniciar el cambio. Esto mantiene a un humano en control de cuándo comienza el trabajo, incluso después del visto bueno. Los agentes entonces ejecutan los pasos de implementación desde el Workspace, y el plan de reversión está a mano por si se necesita.

Parche de actualización — se ejecuta en la ventana

Aprobar un grupo de parches autoriza al agente a instalarlo en la próxima ventana de mantenimiento. No hay Execute manual — el despliegue comienza cuando se abre la ventana y avanza elemento por elemento. La aprobación queda registrada a nombre de tu usuario.
Para los parches, aprobar es el compromiso. La confirmación es explícita: “Esto autoriza al agente a instalar las actualizaciones de este grupo en la próxima ventana de mantenimiento.” Hasta entonces, la vista de parches pendientes es de solo lectura y no instala nada.

Reglas de aprobación

Por defecto, un cambio necesita una aprobación, y el solicitante puede aprobar su propio cambio. Eso está bien para un equipo pequeño, pero la mayoría de las organizaciones quieren una gobernanza más fuerte. Las reglas de aprobación te permiten definir, por contexto, exactamente quién debe aprobar qué cambios — una política que se evalúa automáticamente cada vez que se envía un cambio. Una regla se compone de: Cuando se envía un cambio, Myrmex encuentra la regla correspondiente (por el tipo del cambio, prefiriendo una regla nombrada para ese tipo sobre una general) y la aplica. El panel de Aprobaciones muestra entonces la regla en vigor y el progreso hacia su mínimo — por ejemplo, mín. 2.
Las reglas son una capa de política, no un cuello de botella: si ninguna regla coincide con un cambio, se aplica el valor por defecto — 1 aprobación, y el solicitante puede aprobar. Eliminar una regla simplemente hace que sus cambios vuelvan a ese valor por defecto.

Gestionar las reglas

Abre la vista de Reglas de aprobación desde la Gestión de Cambios para crear, editar, activar/desactivar o eliminar reglas. Gestionar las reglas es una acción de gobernanza, separada de aprobar cambios individuales — está protegida por el permiso gmuds.admin.
Eliminar una regla no bloquea nada — los cambios en su alcance vuelven a la política por defecto (1 aprobación, el solicitante puede aprobar). Si necesitas un control más estricto, desactiva una regla en lugar de dejar un vacío, o reemplázala antes de eliminarla.

Quién puede hacer qué

La Gestión de Cambios se rige por un conjunto dedicado de permisos, para que puedas separar a las personas que redactan los cambios de las que los aprueban y las que gobiernan las reglas:
Otorga gmuds.create / gmuds.update a los ingenieros que planifican los cambios, reserva gmuds.approve para los responsables del cambio o un comité asesor de cambios, y mantén gmuds.admin con tu equipo de gobernanza. Junto con los aprobadores nombrados en una regla, esto te da una separación de funciones limpia. Consulta Control de acceso.

Relacionado

Descripción general de la Gestión de Cambios

El módulo, los dos tipos de cambio y el ciclo de vida completo.

Gestión de parches y actualizaciones

Consulta las actualizaciones pendientes y aprueba los cronogramas de parches que propone la IA.