Rack & Stack paso a paso: cómo escribirle a una mano remota para que el montaje, desempaque y cableado salga bien a la primera

El rack & stack remoto (montar un servidor nuevo en un rack, desempaquetarlo, conectarlo y dejarlo operativo) es uno de los tickets más críticos para manos remotas. Si el procedimiento está mal escrito, el técnico en sitio improvisa, pierde tiempo, y el resultado es un servidor mal instalado o con cables desordenados. Si el procedimiento está bien escrito, el trabajo sale a la primera y queda documentado para auditoría. Este artículo te da la plantilla exacta con las 7 secciones obligatorias que tu ticket debe incluir, los 4 errores típicos que cuestan tiempo, y el checklist de verificación post-instalación.

La plantilla aplica a cualquier servidor 1U o 2U típico. Para servidores más grandes (4U, blade chassis), se requieren secciones adicionales que se especifican al final.

Por qué el procedimiento escrito importa más de lo que crees

El rack & stack es la operación donde más improvisación ocurre, por 3 razones:

1. Cada servidor es diferente (marca, modelo, ubicación física). El técnico en sitio no puede memorizar todas las variantes.
2. El técnico opera bajo presión de tiempo (SLA del proveedor). Si no tiene procedimiento claro, va a hacer lo más rápido, no lo más correcto.
3. El cliente (tú) está lejos y no puede verificar en tiempo real. La única defensa es procedimiento escrito + verificación post-trabajo.

El costo de la improvisación: 30-60 minutos de tiempo extra del técnico, posible daño al equipo por mal manejo, posible incumplimiento del SLA del proyecto, y necesidad de segundo ticket para corregir lo que salió mal. Un procedimiento bien escrito cuesta 30 minutos prepararlo, ahorra $5,000-15,000 MXN por incidente.

Sección 1: Identificación del equipo a instalar

Lo primero que el técnico necesita saber es QUÉ está instalando:

1. Marca y modelo exacto del servidor. Ejemplo: ‘Dell PowerEdge R750xs’ (no genérico ‘servidor Dell’). El técnico busca el modelo en su documentación interna.
2. Número de serie del equipo. Lo trae en la caja o en el activo. Esto permite trazabilidad post-instalación.
3. Asset tag o identificador interno de tu empresa. Típicamente una etiqueta con número (ejemplo: ‘SRV-0042’). Se aplica al servidor durante el montaje.
4. Altura en U del servidor. Típico 1U o 2U. Define el slot que va a ocupar.

Esta sección es la ‘tarjeta de identidad’ del servidor. Sin ella, el técnico no sabe qué manipular ni cómo etiquetarlo.

Sección 2: Ubicación física destino

Dónde va a quedar el servidor:

1. Identificación del rack destino. Típicamente número del rack (ejemplo: ‘Rack B07’) o número de fila (ejemplo: ‘Fila 3’).
2. Slot exacto en U dentro del rack. Ejemplo: ‘U14 a U15’ para servidor 2U, o ‘U22 a U23’ para 1U adicional. Si se especifica slot exacto, no hay ambigüedad.
3. Posición frontal vs trasera en el rack. Aunque la mayoría de servidores van al frente, blade servers y algunos servidores especiales pueden ir al fondo o en orientación invertida.
4. Foto del rack destino con el slot marcado. Si tienes cámara en sitio, envía una foto del rack con el slot U marcado con cinta o tag. El técnico confirma que el slot está libre.

Si no especificas slot exacto, el técnico elige uno y puede no ser el que esperabas. El reordenamiento posterior cuesta tiempo. Mejor especificar de inicio.

Sección 3: Procedimiento de desempaque

Cómo desempacar el servidor:

1. Ubicación de la caja. Indicar dónde está la caja con el servidor (almacén, oficina, etc.) y si tiene packaging abierto o sellado.
2. Verificación de contenido. El servidor, manuales, accesorios (cables de poder, rack rails, screws), packing list. Confirmar todo está presente ANTES de empezar.
3. Inspección visual. ¿El equipo tiene daño visible en la caja? Si sí, documentar con foto ANTES de abrir. Si el daño es significativo, NO desempacar y escalar.
4. Disposición del empaque. Cartón y foam deben quedar en lugar designado para recolección posterior. No dejar en el piso del DC.

El desempaque es donde más daño físico ocurre por mal manejo. El procedimiento debe ser explícito: abrir con cutter por la cinta designada, NO forzar, levantar el equipo con dos manos por la base metálica, NUNCA por los componentes frontales.

Sección 4: Instalación física en el rack

Cómo montar el servidor:

1. Instalar rack rails si aplica. La mayoría de servidores 1U/2U vienen con rieles laterales que se atornillan al rack. El técnico debe seguir las instrucciones del fabricante del servidor, no improvisar.
2. Fijar el servidor al rack con 4 tornillos (típicamente 2 por lado). Usar los tornillos correctos (10-32 o 12-24 según estándar). NO usar tornillos más largos que pueden dañar componentes internos.
3. Verificar nivelación. El servidor debe quedar paralelo al resto del rack, no inclinado. Si el rack tiene inclinación, documentar con foto (puede indicar rack dañado).
4. Foto post-instalación. Foto del servidor instalado en su slot con el asset tag visible.

Si el técnico no tiene rack rails y el servidor no se puede montar de otra forma, el ticket escala. NO improvisar con métodos que comprometan la integridad física del rack.

Sección 5: Conexión de cables

Cómo conectar cables de poder y datos:

1. Cables de poder. Identificar qué PDU alimenta el servidor (PDU-A, PDU-B, según redundancia). Cada fuente de poder a una PDU distinta. Especificar si la conexión es a UPS directo o a PDU de rack.
2. Cables de red. Especificar puertos: ‘NIC1 a switch SW-CORE-1 puerto 24’, ‘NIC2 a switch SW-CORE-2 puerto 24’. Si el servidor tiene 4 NICs, especificar las 4 conexiones.
3. Etiquetado de cables. Cada cable (poder y red) debe etiquetarse en ambos extremos con el ID del servidor y el destino. El técnico debe tener etiquetas pre-impresas o label printer en sitio.
4. Organización de cables. Usar velcro o cable ties para agrupar cables. NO usar zip ties apretados que pueden dañar el aislamiento del cable. Ruta de cables por el lateral del rack, no por el frente.

Esta sección es donde más problemas ocurren en manos remotas. Sin especificación exacta de puertos, el técnico conecta a puertos disponibles y el resultado es un cableado que después nadie puede mantener.

Sección 6: Pruebas de operación

Cómo verificar que el servidor quedó operativo:

1. Power-on self-test. Encender el servidor y verificar que pasa POST sin errores. Los LEDs de poder deben estar en verde.
2. Acceso a consola. El técnico debe poder acceder a la consola del servidor (KVM, iLO, iDRAC, IPMI según marca) y verificar que ve el BIOS o sistema operativo.
3. Conectividad de red. Hacer ping desde el servidor a un destino conocido (gateway, servidor de monitoreo). Si el ping responde, la red está OK.
4. Reporte de métricas. Capturar foto del display o pantalla con lecturas de: temperatura CPU, estado de discos, estado de fuentes de poder. Enviar al cliente con el ticket.

Si cualquiera de las 4 pruebas falla, el ticket NO está completo. El técnico debe reportar el fallo ANTES de cerrar el ticket. Si cierra sin reportar, el cliente asume que está bien y el problema aparece 3 días después.

Sección 7: Reporte final y documentación

Lo que el técnico entrega al cerrar el ticket:

1. Fotos: caja cerrada con packing list, desempaque, servidor instalado, slot final, cables conectados y etiquetados, display de operación.
2. Confirmación de asset tag aplicado. Foto del asset tag visible en el servidor instalado.
3. Confirmación de empaque retirado. Foto del lugar donde quedó el empaque (almacén, contenedor de reciclaje).
4. Bitácora con timestamps. Hora de inicio, cada paso significativo, hora de fin. Si la operación tomó 2 horas pero el ticket era para 1 hora, documentar por qué.

Sin estos 4 elementos, el ticket no se considera completo. Si el técnico cierra el ticket sin fotos y bitácora, reclamar antes de aceptar la factura.

Los 4 errores típicos del ticket mal escrito

Lo que veo en tickets mal escritos:

1. Error #1: ‘Instala el servidor nuevo en el rack’. Sin marca, modelo, slot, ni nada específico. Resultado: técnico improvisa todo.
2. Error #2: Especificar slot pero no numeración de U. ‘Ponlo en el rack B07’ sin decir ‘U14-U15’. Resultado: técnico elige slot disponible que puede no ser el correcto.
3. Error #3: Sin especificación de cables de red. ‘Conéctalo a la red’ es insuficiente. Resultado: NICs conectadas a puertos disponibles, no a los puertos del diseño.
4. Error #4: Sin criterio de éxito definido. ‘Instala el servidor’ sin ‘verificar que responda ping a 10.0.0.1’. Resultado: ticket cerrado sin verificar que el servidor realmente quedó operativo.

Los 4 errores juntos: ticket de 1 hora se convierte en 3-4 horas con resultado incierto. El CAPEX ahorrado en no tener plantilla se pierde en tiempo de operación.

Plantilla lista para copiar

Copia y adapta para cada rack & stack:

1. EQUIPO: [Marca] [Modelo] – S/N [número] – Asset Tag [tu ID]
2. UBICACIÓN: Rack [número], Slot U[X] a U[Y]
3. DESEMPAQUE: Caja en [ubicación], packing list completo, inspección visual antes de abrir, empaque a [destino]
4. MONTAJE: Rack rails instalados según manual, 4 tornillos [10-32/12-24], verificar nivelación
5. CABLES: PDU-A puerto [X] y PDU-B puerto [Y], NIC1 puerto [X], NIC2 puerto [Y], etiquetar ambos extremos
6. PRUEBAS: POST OK, consola accesible, preset de modelos, ping a [IP destino] responde
7. REPORTE: 6 fotos (caja, desempaque, instalado, cables, display, asset tag), bitácora con timestamps

Esta plantilla es el mínimo. Para servidores especiales (blade, GPU, storage), se añaden secciones específicas que dependen del modelo.

Casos especiales: blade servers y GPU servers

Variaciones para hardware complejo:

1. Blade servers: requieren inserción en chassis específico. El técnico debe verificar que el slot del blade esté libre, que la conexión backplane quede firme, y que el blade sea reconocido por el chassis manager.
2. GPU servers: típicamente 4U, pesan 30-50 kg. Requieren 2 personas para levantar. Instalación en rack es más lenta (4-6 horas vs 1-2 horas de 1U típico).
3. Storage arrays: pesan 50-150 kg. Requieren rack rails reforzados y a veces elevación mecánica. Instalación es proyecto de medio día, no ticket simple.

Para estos casos, la plantilla de 7 secciones aplica pero las sub-secciones de ‘Cables’ y ‘Pruebas’ se expanden significativamente. Esperar 4-8 horas de trabajo para estos tickets.

Cómo verificar el trabajo después

Una vez que el técnico cierra el ticket, tú verificas:

1. Recibir las 6 fotos prometidas. Si falta alguna, reclamar antes de aceptar.
2. Verificar conectividad desde tu lado. Ping al servidor, acceso a la consola remota (iLO/iDRAC), verificación del sistema operativo o hypervisor.
3. Verificar el inventario. ¿El servidor aparece en tu sistema de gestión de activos (CMDB, DCIM)? Si no, el asset tag no se aplicó correctamente.
4. Verificar el cableado. Pide foto del patch panel con las conexiones del nuevo servidor. ¿Están en los puertos correctos?

Si todo verifica OK, el ticket está cerrado y el servidor está operativo. Si hay diferencias, reclamar al proveedor con la evidencia específica (foto de cable mal conectado, slot incorrecto, etc.).

El CAPEX de hacer bien el rack & stack

Lo que cuesta hacerlo bien vs hacerlo mal:

1. Procedimiento escrito: 30 minutos del operations manager. Costo: $500-1,000 MXN (a tarifa interna).
2. Ticket mal escrito: 2-4 horas extra del técnico en sitio. Costo: $3,000-12,000 MXN por incidente.
3. Resultado: cada $1 invertido en plantilla ahorra $5-10 en tiempo de operación.

El cálculo es directo. El gerente de operaciones que no invierte 30 minutos en plantilla está aceptando gastar $5-10 cada vez que se haga un rack & stack. Multiplica por 20 racks & stack al año y el costo hundido es $100,000-200,000 MXN anuales.

Cuándo NO usar manos remotas para rack & stack

Hay 3 escenarios donde rack & stack remoto no aplica:

1. Servidor crítico que requiere configuración in-situ con personal de aplicaciones. El técnico no puede decidir la configuración del OS, solo instalación física.
2. Servidor con problemas físicos anticipados (caja dañada, falta de accesorios). Mejor revisar antes de enviar al técnico.
3. Sitio con personal técnico in-house que puede hacer rack & stack ellos mismos. La mano remota es para sitios donde no tienes personal local.

Si tu caso está en estos 3 escenarios, evalúa si rack & stack remoto es la decisión correcta o si requieres otro approach (envío de tu propio técnico, o esperar a próxima visita programada).

Fuentes

1. TIA-942-B-2023 — https://www.tia.org/standards/tia-942
2. BICSI 002-2024 — https://www.bicsi.org/standards/data-center
3. Dell PowerEdge R750xs — https://www.dell.com/support
4. HPE ProLiant DL380 Gen11 — https://support.hpe.com/
5. ITIL 4 Foundation — https://www.axelos.com/certifications/itil-service-management/itil-4-foundation