Qué tareas SÍ puede hacer una mano remota y cuáles NUNCA deberías delegar (la línea que tu proveedor no te va a marcar)

Contratas manos remotas y el proveedor te dice “sí lo hacemos, no te preocupes”. La pregunta que deberías estar haciendo es: ¿qué tareas específicas estoy autorizando a una persona que no es parte de mi plantilla, que no reporta a mi CISO, y que tiene acceso físico a mis servidores? Este artículo no es sobre el catálogo genérico. Es sobre dónde está la línea exacta entre lo que puedes delegar con confianza y lo que NUNCA deberías delegar aunque el proveedor te diga que sí, porque tiene SLA, porque tiene certificaciones, o porque te ofrece descuento.

La división que sigue aplica a data centers con personal de campo en sitio (colocation, proveedor de site, o tu propio DC con técnicos de campo subcontratados). Si tu operación es 100% remota sin presencia física en el site, este artículo sigue siendo válido pero con menos opciones del lado del SÍ.

Lo que SÍ puedes delegar a una mano remota (con confianza operativa)

Son tareas físicas, repetitivas, auditables y con bajo riesgo de afectar disponibilidad. Una mano remota competente, con briefing adecuado, puede ejecutarlas sin que tu equipo intervenga:

• Rack & stack de equipo nuevo: recibir cajas, desembalar, montar en rack, etiquetar puertos y cables de parcheo. El briefing previo debe incluir el slot en U específico, el torque de los tornillos del rack (típicamente 8-12 in-lbs para tuercas cage nut), y el orden de los cables de red.
• Cambio de discos duros o SSDs hot-swap: si tu arreglo de storage está en RAID tolerante a fallos, el cambio es trivial. La mano remota necesita la etiqueta del disco a reemplazar (serie, slot, número de parte) y un video de 30 segundos antes/después. Si el arreglo NO tiene tolerancia, considera que un disco fallido puede tirar el arreglo entero si la mano remota saca el disco equivocado.
• Swap de fuentes de poder redundantes: si tu servidor tiene 2 PSUs en redundancia 1+1, una mano remota puede cambiar la PSU fallida sin afectar operación. Briefing: confirmar que la PSU restante sostiene el equipo (verificar consumo actual vs capacidad), apagar la PSU fallida antes de remover, esperar 30 segundos para descarga de capacitores antes de remover el cable.
• Cambio de módulos de memoria RAM: solo si el servidor tiene ranuras vacías y la operación está bien documentada. La mano remota debe recibir el número de ranura específico (no “una memoria más”) y la marca/modelo exactos. Riesgo: si la memoria no es idéntica a la existente, puede haber incompatibilidad o forzar el bus a menor velocidad.
• Conexión de cable de consola KVM o serial para acceso out-of-band: la mano remota conecta el cable, tú tomas control remoto. La mano remota nunca debería tipear comandos en tu sesión, solo hacer la conexión física.
• Etiquetado físico de cables, racks y puertos: si tienes un estándar de etiquetado (TIA-942-B recomienda códigos alfanuméricos de 4 caracteres por puerto), la mano remota puede aplicar etiquetas, fotografiar antes/después y entregar un mapa final.
• Inspección visual de equipos: parpadeos de LED anormales, polvo en filtros de equipo, manchas de líquido, cables sueltos. Reporte fotográfico con timestamp + coordenadas U del rack.
• Lectura de displays y medidores: temperatura del aire de retorno del CRAC, humedad relativa, presión de filtros, voltaje del UPS, estado de baterías. Sin intervenir nada, solo leer y reportar.

La regla común: si la tarea es mecánica, repetitiva, reversible y no toca credenciales ni configuración lógica, es delegable. La mano remota nunca debe tipear comandos en tu equipo, nunca debe tener contraseñas, y nunca debe tomar decisiones sobre qué hacer cuando algo no sale como esperaba.

Lo que NUNCA deberías delegar (aunque el proveedor diga que sí)

Hay tareas que por su naturaleza abren vectores de riesgo que no se cierran solo con un SLA. Si las delegas, el incidente resultante será tuyo, no del proveedor, sin importar lo que diga el contrato:

• Manejo de contraseñas, llaves SSH o tokens de API: la mano remota nunca debe tipear credenciales en tu equipo. Si tu proveedor de site requiere que le des acceso al BIOS o al iLO/iDRAC para arrancar un servidor, tienes un problema de arquitectura, no de manos remotas. La solución es KVM over IP con permisos de tu lado, no credenciales compartidas.
• Cambios de configuración de red: agregar VLANs, mover puertos entre VLANs, modificar ACLs, tocar tablas de routing. Un cambio de VLAN mal aplicado puede aislar un servidor o, peor, exponer un servicio interno a Internet. Estos cambios los haces tú con acceso remoto out-of-band, no presencialmente.
• Acceso físico a medios de almacenamiento con datos sensibles: si necesitas reemplazar un disco que tiene datos encriptados o datos en claro que requieres destruir, la mano remota debe presenciar pero no manipular el medio sin tu presencia o grabación. Compliance: SOX, HIPAA, GDPR/LFPDPPP tienen requisitos específicos sobre destrucción de medios que difícilmente se cumplen sin tu participación directa.
• Configuración de firewall, VPN o control de acceso lógico: cualquier cambio en la superficie de ataque de tu infraestructura. La mano remota no debe tener acceso a interfaces de gestión de seguridad ni a consolas de firewall. Estos son cambios que tu equipo de seguridad aprueba y ejecuta, no terceras partes.
• Reinicio forzado de equipos de producción: si un servidor no responde y necesitas reiniciarlo, la mano remota puede oprimir el botón de power SOLO con autorización explícita en tiempo real (no por ticket abierto el día anterior). Y debe documentar: timestamp exacto, razón, persona que autorizó, y video de 10 segundos antes/después.
• Manipulación de switches de core o de distribución: cualquier cambio físico en switches que cargan tráfico de producción. La mano remota puede hacer cambio de transceiver SFP o reemplazar el switch en fail-over, pero no debe tocar configuración ni cables de trunk entre switches sin tu presencia.
• Acceso a bóvedas físicas de almacenamiento o cajas de seguridad: si tienes bóveda o caja fuerte para llaves SSH offline, passwords raíz, o tokens de recuperación, la mano remota NO debe tener acceso. Punto.
• Diagnóstico de fallas complejas: si el ticket dice “el servidor X no responde”, la mano remota NO debe empezar a cambiar componentes al azar para “ver si funciona”. El diagnóstico es tuyo, la mano remota ejecuta la acción específica que tú le indicas basada en tu diagnóstico.

La regla común: si la tarea toca credenciales, configuración lógica, o requiere juicio sobre qué hacer cuando algo no sale como se planeó, NO se delega. La mano remota ejecuta instrucciones específicas, no resuelve problemas abiertos.

Cómo documentar el acuerdo para que funcione en la práctica

Si tu proveedor de manos remotas es serio, va a aceptar un AOE (Acuerdo de Operación Estándar) por escrito con la lista exacta de tareas autorizadas y prohibidas. Si no lo acepta, tienes un proveedor que después te va a decir “es que eso no estaba en el contrato” cuando algo salga mal. Cómo estructurarlo:

• Anexo A: lista numerada de tareas delegables (las del primer apartado de este artículo, ajustadas a tu equipo específico).
• Anexo B: lista numerada de tareas prohibidas (las del segundo apartado).
• Procedimiento de autorización: cada tarea fuera de Anexo A requiere ticket con autorización en tiempo real (vía Slack, Teams, llamada, o sistema de tickets) por una persona específica de tu equipo. La mano remota documenta: ticket ID, hora de autorización, persona que autorizó, evidencia fotográfica.
• Procedimiento de rollback: cada tarea que la mano remota ejecute debe tener un camino de rollback documentado. Si era cambiar un disco, ¿cómo se vuelve al estado anterior? Si era etiquetar cables, ¿cuál era el etiquetado previo? La mano remota documenta el estado previo con foto antes de tocar nada.
• Procedimiento de incidente: si durante la ejecución algo sale mal, la mano remota para, te contacta por canal primario, y espera instrucciones. No improvisa. El SLA de respuesta a incidente (no del trabajo programado) debería ser de máximo 15 minutos para confirmar comunicación.
• Revisión trimestral: cada 3 meses tú y el proveedor revisan el AOE, los incidentes del trimestre, y ajustan si hay tareas recurrentes que deberían pasar de prohibidas a delegables o viceversa.

Si tu proveedor actual no acepta este nivel de detalle, tienes dos opciones: cambiar de proveedor, o aceptar que cada ticket va a ser una negociación. La segunda opción es insostenible cuando tienes un incidente real en producción y necesitas que la mano remota ejecute rápido sin ambigüedad.

El caso real que nadie te cuenta: lo que pasa cuando la línea se cruza

En 2024, en un site mexicano de tamaño mediano, una mano remota fue instruida por ticket abierto 3 días antes para “reemplazar el módulo de memoria del servidor X”. El ticket decía “módulo de memoria” sin más detalle. La mano remota llegó al rack, abrió el servidor, y removió una memoria del slot equivocado. Resultado: el servidor, que estaba en producción, se cayó porque tenía 4 DIMMs en pares y al sacar uno rompió el par. Downtime: 3 horas. La causa raíz no fue la mano remota. Fue el briefing ambiguo del ticket. La memoria correcta estaba en mi caja. La mano remota hizo lo que pudo con la información que le dieron.

Lecciones operativas de ese incidente: (1) los tickets de manos remotas deben incluir coordenadas U exactas y número de slot, no “la memoria del servidor”; (2) el briefing para tareas delicadas debe ser verbal en tiempo real, no asincrónico; (3) si tu servidor tiene configuración de memoria en pares, los cambios de RAM los haces tú con KVM over IP, no presencialmente.

Cómo elegir proveedor si estás empezando desde cero

Si no tienes proveedor de manos remotas y estás por contratar uno, los filtros objetivos:

• Acepta firmar el AOE con listas específicas de tareas autorizadas y prohibidas. Si dice “depende del caso”, es proveedor improvisado.
• Tiene técnicos certificados por al menos un fabricante mayor (Vertiv, Schneider, HPE, Dell, Cisco). La certificación es señal de que el proveedor invierte en capacitación formal.
• Tiempo de respuesta documentado y medido: para tickets urgentes, máximo 2 horas. Para tickets programados, dentro de la ventana acordada (típicamente 24-48 horas hábiles).
• Genera reportes con timestamp, fotos, lecturas de instrumentos, y firma del técnico en cada visita. El reporte no debe ser genérico.
• Tiene seguro de responsabilidad civil profesional que cubra errores operativos. Si tu proveedor causa un daño por mala ejecución, el seguro paga. Si no tiene seguro, tu incidente es tuyo.
• Provee kit de herramientas documentado. Si te dice “los técnicos traen sus propias herramientas”, pregunta cuáles. La lista de 12 herramientas del kit estándar de manos remotas (multímetro, torque screwdriver, etiquetadora, USB boot, etc.) la publiqué en este blog y debería ser el mínimo.

La línea entre “puedo delegar” y “nunca delegues” no es fija. Evoluciona con tu equipo, con tu proveedor, con la madurez operativa de tu DC. Lo que no debería evolucionar es la disciplina de tenerla documentada por escrito y revisada trimestralmente. El día que la necesitas clara, no es el día para negociarla.

Fuentes

• TIA-942-B-2023 — Telecommunications Infrastructure Standard for Data Centers (ANSI/TIA-942-B-2023) — https://www.tia.org/standards/tia-942
• Uptime Institute — Operational Sustainability Tier Certification: Smart Hands scope definition — https://datacenter.uptimeinstitute.com/
• SOC 2 Type II — Common criteria for service organizations (AICPA Trust Services) — https://www.aicpa.org/topic/soc-2-reporting
• ISO/IEC 27001:2022 — Information security controls for physical and logical access — https://www.iso.org/standard/27001
• BICSI 002-2024 — Data Center Operations and Maintenance Best Practices — https://www.bicsi.org/standards/data-center