Proyectos destacados

Validar primero: una residencia multisitio de Hyper-V y SCVMM

Para el cliente final — la administración de un estado de EE. UU. — de una firma global de servicios TI · entregada bajo un contrato de residencia de Dell

Los ingenieros del cliente ya habían hecho el trabajo pesado: hosts desplegados, clústeres de conmutación por error formados, la red construida entre dos sitios. Lo que pedían no era una reconstrucción — era certeza. ¿Se había construido bien? ¿Aguantaría en operación? ¿Y qué aspecto debía tener la capa de gestión?

Estructuramos la residencia en torno a esa pregunta. Las tres primeras semanas fueron validación pura: configuración de hosts, comportamiento de los clústeres, rutas de almacenamiento y de red — probadas metódicamente, documentando los hallazgos sobre la marcha. Sin suposiciones heredadas, sin dar por bueno el «debería estar bien».

Sobre esa base validada diseñamos el estado objetivo de SCVMM y lo construimos en ambos sitios, seguido de sesiones de capacitación para que el equipo del cliente pudiera operar lo que ahora era suyo.

El momento por el que contamos esta historia llegó a mitad del proyecto: el equipo de ingeniería del cliente revisó nuestro diseño de estado objetivo y cuestionó una de sus decisiones centrales — dónde debía situarse la frontera de responsabilidad entre Network ATC y SCVMM para la configuración de red. Hicieron bien en insistir. Revisamos el diseño, y la versión 1.1 lleva su revisión: un reparto más limpio de quién gestiona qué, acordado línea por línea con las personas que operan la plataforma.

Algunas consultoras lo llamarían fricción de alcance. Nosotros lo llamamos el proyecto funcionando tal y como se diseñó — diseñamos con el cliente, no a sus espaldas. Un diseño que supera a los propios ingenieros del cliente vale más que uno que nunca fue cuestionado.

Lo que quedó cuando nos fuimos: informes de validación, el diseño de estado objetivo revisado, documentación de construcción y un equipo capacitado para operar la plataforma. Cada hora de la residencia dejó un artefacto.

Una metodología de migración de aplicaciones, industrializada

Proyecto activo de migración de aplicaciones con Dell · entrega B2B2B

Las migraciones de aplicaciones rara vez fracasan por las herramientas. Fracasan en los huecos — entre el discovery y la planificación, entre el runbook en la cabeza de alguien y el que se ejecuta a las dos de la madrugada, entre «podemos volver atrás» y un plan de rollback real y probado.

En nuestro proyecto con Dell tomamos la metodología de migración en tres fases de Dell y la industrializamos: no un marco de diapositivas, sino una fábrica de migración gobernada.

Así funciona la fábrica:

• Puertas de fase. Cada fase termina en una puerta con criterios de entrada y salida definidos. Nada avanza por inercia.
• Runbooks generados — y planes de rollback generados. Para cada grupo de migración, la fábrica produce el camino de ida y el de vuelta, en un formato consistente y revisable. El plan de rollback no es un añadido posterior; se genera junto con el runbook, todas las veces.
• Go/no-go humano. Los agentes de IA preparan la evidencia — síntesis del discovery, mapa de dependencias, comprobaciones de validación, documentación. Cada decisión de puerta la toma una persona. Ningún paso de migración se ejecuta porque lo diga un agente.
• Trazabilidad completa. Cada decisión y cada acción queda registrada y es atribuible: qué se hizo, cuándo, quién y con qué aprobación.

Somos deliberadamente prudentes con lo que esta página afirma. Esta es una historia de metodología y capacidad: la fábrica está productizada dentro de un proyecto activo con Dell y se entrega en modelo B2B2B a los clientes de Dell. Publicaremos resultados cuando las migraciones de los clientes terminen — no antes.

Si su backlog de migración parece una larga fila de proyectos heroicos e irrepetibles, el modelo de fábrica es la alternativa: consistencia industrial en los artefactos y juicio humano en cada puerta.

Delivery agéntico, supervisado por ingenieros

Nuestro modelo de entrega · así funciona cada proyecto de Gus IT

La primera pregunta que un comprador serio hace sobre el delivery impulsado por IA es la correcta: ¿es seguro dejar que agentes de IA se acerquen a infraestructura productiva?

Nuestra respuesta es una división del trabajo estricta, aplicada en cada proyecto.

Qué hacen nuestros agentes de IA: la ingeniería repetitiva que consume tiempo sénior e invita al error humano. Ejecutan discovery sobre entornos completos, sintetizan configuraciones en documentación, generan runbooks y planes de rollback, ejecutan comprobaciones de validación y mantienen el expediente al día — con consistencia, a cualquier hora, sin fatiga.

Qué no hacen nunca: aprobar un diseño. Tocar un sistema productivo sin supervisión. Tomar una decisión de go/no-go.

Cada proyecto tiene un ingeniero sénior con nombre y apellidos que responde de la aprobación del diseño y de cada acción que cambia el estado de los sistemas. Nuestra automatización está construida para el dry-run: puede ensayarse sin tocar sistemas reales, y cada fase lleva un plan de rollback antes de llevar un cambio. Cada acción — humana o de agente — queda registrada y es atribuible: usted siempre sabe quién decidió y quién actuó.

Por qué le importa: obtiene la consistencia de una fábrica en los artefactos — documentación realmente completa, runbooks realmente actualizados — sin entregar el juicio a una máquina. El ingeniero no corrige los deberes de la IA a posteriori; el ingeniero es la puerta por la que pasa el trabajo.

Esto no es un concepto de laboratorio. Es como entregamos hoy nuestro trabajo contratado, incluidos los proyectos bajo contratos de partner y de canal.

Si está sopesando si la IA tiene sitio en su cadena de delivery — o cómo gobernarla una vez dentro —, traiga sus preguntas más difíciles a la llamada de evaluación. Este modelo está construido para ser interrogado.