Skip to main content
La Gestión de Cambios es donde se planifica, revisa, aprueba y ejecuta bajo control cada cambio en tu entorno. Cada cambio se registra como un GMUD (Gestão de Mudança — un registro de cambio), y nada que toque un sistema se ejecuta hasta que las personas adecuadas lo hayan aprobado. Es el mismo principio que el resto de Myrmex — la IA propone, tú apruebas — aplicado al momento en que un cambio realmente ocurre.
Un GMUD es una única solicitud de cambio: qué cambiará, por qué, en qué sistemas, cuándo, cómo se revertirá y quién dio el visto bueno. Lleva el cambio desde un borrador hasta una ejecución completada y auditada.

​
Dos tipos de cambio

La Gestión de Cambios maneja dos tipos de cambio, y la diferencia está principalmente en cómo se ejecuta cada uno:

Cambio estándar

Un cambio que tú (o la IA) planificas — una edición de configuración, un cambio de regla de firewall, una tarea de mantenimiento. Tiene un plan de implementación y un plan de reversión, y una vez aprobado lo inicias explícitamente con Execute. Los agentes entonces llevan a cabo los pasos.

Parche de actualización

El despliegue de un parche del sistema operativo que se origina en el área de Updates. La IA programa los parches pendientes en una ventana de mantenimiento; una vez aprobado, el agente los instala automáticamente en esa ventana — sin Execute manual.
Ambos tipos comparten el mismo ciclo de vida, la misma puerta de aprobación, la misma ventana de cambio y el mismo registro de auditoría. Solo difieren en el momento de la ejecución: un cambio estándar se dispara bajo demanda, un parche se ejecuta dentro de su ventana programada. El flujo de aprobación cubre ambos.

​
El ciclo de vida de un cambio

Un GMUD atraviesa un conjunto fijo de estados. El camino feliz tiene seis etapas; un puñado de estados de excepción cierran un cambio que no se completó normalmente.
1

Borrador

El cambio se está redactando — identificación, justificación, riesgo, ventana y los pasos de implementación/reversión. Totalmente editable.
2

Enviado

Enviado para aprobación. Ahora espera a los aprobadores según la regla de aprobación correspondiente.
3

Aprobado

Se registraron suficientes aprobaciones. Un cambio estándar ya está listo para Execute; un parche está listo para ejecutarse en su ventana.
4

Programado

El cambio está en cola para su ventana de cambio. Mientras está programado, el registro se actualiza automáticamente cada 60 segundos.
5

Ejecutando

Los agentes están ejecutando los pasos. Para un parche, los paquetes se están instalando en los hosts de destino.
6

Completado

Todos los pasos finalizaron con éxito. El cambio se cierra y queda totalmente auditado.
Fuera del camino feliz, un cambio también puede terminar como:
Editar un cambio después de haberlo enviado lo reinicia. Editar un cambio que está enviado, aprobado o programado cancela cualquier ejecución despachada y lo revierte a Borrador — debe enviarse y aprobarse de nuevo. Esto es deliberado: un cambio aprobado se aprueba tal como está escrito.

​
Anatomía de un cambio

Cada GMUD es un documento estructurado. Cuando abres uno, está organizado en las secciones que esperaría un comité asesor de cambios:

Identificación del cambio

Título, estado, tipo de cambio, categoría técnica y clase (cambio estándar o parche).

Contexto y justificación

El problema o la motivación, el objetivo y el resultado esperado, y qué está explícitamente dentro del alcance y fuera del alcance.

Evaluación de riesgo e impacto

Probabilidad, impacto y el nivel de riesgo final; servicios y usuarios impactados, tiempo de inactividad esperado, riesgos de seguridad/cumplimiento y dependencias.

Sistemas afectados (CIs)

Los dispositivos e integraciones que el cambio toca, cada uno vinculado como afectado o dependiente — para que el radio de impacto sea explícito.

Ventana de cambio

Inicio y fin de la ventana de mantenimiento, además de la comunicación con las partes interesadas. El registro muestra cuándo se abre y se cierra la ventana.

Planes de implementación y reversión

Los pasos ordenados para hacer el cambio y los pasos para deshacerlo — ver más abajo.

​
Pasos de implementación y reversión

El plan es una lista de pasos ordenados, cada uno etiquetado como Implementación o Reversión. Un paso registra la actividad, su orden, un responsable, una duración esperada y — opcionalmente — un destino (un dispositivo o integración específico) y una acción a ejecutar allí. Durante la ejecución, cada paso muestra su propio estado, para que puedas ver exactamente hasta dónde llegó el cambio y qué queda si algo debe deshacerse.
Un buen plan de reversión es lo que hace que un cambio sea seguro de aprobar. Pídele a la IA que lo redacte por ti — “agrega un plan de reversión que revierta este cambio de regla de firewall.”

​
Cómo llegar ahí

Abre la Gestión de Cambios desde el Directory a la izquierda de la consola. Lista tus cambios para el contexto que tengas seleccionado — los cambios estándar y los cambios de parche se muestran con iconos distintos — y cada uno se abre como una pestaña en el Workspace. Verlo requiere el permiso gmuds.read. También puedes traer un cambio a una conversación: menciona con @ un cambio (o un parche) como entidad de contexto y pregúntale a la IA sobre él, o pídele que redacte o ajuste uno.

​
Dónde encaja la IA

La Gestión de Cambios está profundamente ligada a los agentes:
  • Redacción — pídele a Centurion que prepare un cambio y completará la identificación, el riesgo, la ventana y un primer plan de implementación/reversión para que lo revises.
  • Proponer parches — la IA revisa las actualizaciones pendientes y propone un cambio de parche (un GMUD de clase parche) con una ventana de mantenimiento (consulta Gestión de parches y actualizaciones).
  • Ejecución — una vez que apruebas (y, para un cambio estándar, haces clic en Execute), los agentes ejecutan los pasos, dirigidos desde el Workspace.
En todo momento, tú controlas la puerta: ningún cambio abandona la etapa de aprobación sin una decisión humana, y cada acción — humana, de un agente o del sistema — se escribe en el historial del cambio.

​
Traza de actividad y exportación

Cada GMUD lleva una línea de tiempo de Actividad: cuándo se creó y quién lo hizo, cada aprobación o rechazo (con el motivo dado), cada paso a medida que se ejecutó y la última actualización. Responde “¿quién hizo qué, y cuándo?” en el propio registro. También puedes exportar el cambio como PDF — para un comité asesor de cambios o un auditor — directamente desde el registro.

​
Siguiente

Flujo y reglas de aprobación

Cómo funciona enviar → aprobar → ejecutar, y cómo gobernar quién debe aprobar qué.

Gestión de parches y actualizaciones

Revisa las actualizaciones del SO pendientes y aprueba los cronogramas de parches que propone la IA.