Guía completa del servicio posventa de servidores de IA, parte 2: tres modelos de suministro, atribución de responsabilidades muy distinta

        Tomando DGX como ejemplo, según la hoja de datos de servicios de soporte empresarial publicada por el fabricante original en 2020, debe acompañarse del contrato de servicios de soporte del fabricante, que abarca soporte de hardware y software durante todo el ciclo de vida, sustitución anticipada (Advanced RMA) con entrega al siguiente día hábil (según la región) y soporte para el sistema operativo, los controladores y el firmware [3]. Por ello, la determinación de responsabilidad se concentra en el fabricante original, y los plazos y el método de reparación o sustitución dependen de su programa. Las piezas de repuesto también se proporcionan según el programa: tomando como ejemplo el DGX-1 de 2018, el programa de repuestos del fabricante original cubre piezas específicas como fuentes de alimentación, ventiladores y memoria, y que se suministren o no lo decide cada distribuidor o socio [4].

➤     El proceso de envío a reparación debe coincidir con el del fabricante original

        Los equipos deben enviarse a reparación siguiendo el proceso que especifica el fabricante original, y los registros del lado del cliente deben ser coherentes con las órdenes de trabajo del fabricante. Si una empresa gestiona a la vez sistemas del fabricante original y equipos de otras marcas, los registros quedan dispersos y los períodos de garantía y el avance de las reparaciones pueden desajustarse con facilidad. Las piezas de repuesto sustituidas tienen además su propio período de garantía: por ejemplo, en el programa de repuestos del DGX-1, si una pieza de repuesto se envía dentro de los últimos 90 días del período de soporte, recibe 90 días de soporte de hardware (si se envió antes, la cobertura llega hasta el final del período de soporte) [4], y esto también debe registrarse pieza por pieza.

        Para atender estas necesidades, el enfoque consiste en estandarizar el envío a reparación y registrar el número de serie de cada equipo, su período de garantía y el número de orden de trabajo del fabricante original, de modo que el envío a reparación, la devolución y el estado de la garantía queden documentados (véase la Figura 1).

Figura 1: Esquema del proceso de reparación del fabricante original y de los registros del lado del cliente

        Desde la perspectiva del OEM, los defectos de la propia placa base y de las piezas son atribuibles al proveedor (VID), el diseño inadecuado del ensamblaje o de la selección de componentes es atribuible al proceso (PID), y el uso indebido es atribuible al cliente (CID). Tomando HGX como ejemplo, la parte de GPU tiene una topología fijada por la placa base, mientras que el resto de periféricos los diseña cada fabricante [1]; por ello, el diagnóstico de averías debe distinguir primero si el problema está en la placa base o en la alimentación, la refrigeración o el ensamblaje elegidos por el OEM; por ejemplo, si un nodo no detecta la GPU tras arrancar, se requiere una verificación cruzada para llegar a una conclusión. Cuando la atribución no está clara, el resarcimiento y la garantía generan fácilmente disputas.

➤     Cada fabricante tiene SOP distintos

        Incluso entre modelos de integración por OEM, las condiciones de garantía y los procesos de envío a reparación varían de un OEM a otro. Tomando como ejemplo condiciones públicas, la garantía estándar de un OEM para sistemas de GPU es de 3 años de mano de obra, 1 año de piezas y 1 año de envío anticipado de reemplazo, y las devoluciones requieren obtener antes un número RMA [5]; las condiciones públicas de otro OEM establecen que el período de garantía limitada de hardware depende del producto y puede ser de 90 días, de 1 a 5 años u otros plazos, y que se pueden adquirir por separado períodos de servicio más largos mediante servicios de soporte avanzado [6]. Los períodos de garantía de mano de obra y de piezas de un mismo equipo también pueden diferir (como los 3 años de mano de obra y 1 año de piezas del OEM mencionado), por lo que los registros de garantía deben poder llevarse por separado para determinar si una pieza sustituida sigue en garantía [5]. Si una empresa compra a varios OEM, no puede aplicar un único proceso a todos; de lo contrario, el método y el plazo del envío a reparación no coincidirán con el contrato.

        Para atender estas necesidades, deben establecerse SOP de reparación y tipos de garantía por separado para cada marca de OEM, y conservarse los resultados de la determinación de atribución y los documentos RTV, de modo que los problemas de la placa base o de las piezas puedan rastrearse hasta el origen y que la responsabilidad y las cantidades cuadren (véase la Figura 2). Los datos del envío a reparación también deben prepararse con antelación: tomando como ejemplo el OEM anterior, primero debe obtenerse el número RMA y marcarse en la caja exterior del artículo devuelto [5]; si el modelo del producto, el número de serie y la descripción de la avería ya constan en el mismo registro, pueden verificarse rápidamente en el momento del envío.

Figura 2: Esquema de la determinación de responsabilidad entre tres partes en modelos de integración por OEM

        Bajo un mismo nombre de modelo, las combinaciones de CPU, GPU, tarjeta de red y refrigeración pueden ser todas distintas; el fabricante original explica que MGX admite cientos de combinaciones de GPU, DPU, CPU, almacenamiento y red [8]. Si las piezas de repuesto y las reparaciones se gestionan solo por modelo, es fácil almacenar la pieza equivocada o aplicar un proceso erróneo, y además al cliente le resulta difícil confirmar exactamente qué configuración tiene su equipo.

➤     La mezcla de generaciones es difícil de gestionar con un único estándar

        Una arquitectura modular puede ser compatible con hardware de varias generaciones, por lo que en una misma sala de servidores pueden coexistir equipos de distintas generaciones, con requisitos de firmware y de compatibilidad diferentes que un único estándar de reparación difícilmente puede abarcar. Tomando como ejemplo el rack MGX, la bandeja de cómputo se compone de combinaciones de CPU y GPU, entre otras, e incluye componentes de refrigeración como placas frías de refrigeración líquida [8], por lo que las condiciones de nueva prueba tras sustituir una pieza también deben ajustarse a la configuración.

        Para atender estas necesidades, es preciso definir los productos y las piezas según la configuración real, y gestionar las piezas de repuesto en dos categorías, piezas compartidas y piezas dedicadas: las piezas compartidas, comunes a distintas configuraciones, se almacenan de forma centralizada, mientras que las piezas dedicadas, usadas solo en configuraciones específicas, se almacenan por configuración (véase la Figura 3). Las investigaciones de teoría de inventarios señalan que, bajo restricciones de nivel de servicio, el uso de piezas compartidas beneficia al inventario, pero no existe una conclusión de aplicación general sobre cómo varía el nivel de inventario de cada pieza [9]; por ello, los niveles de existencias de ambas categorías de piezas de repuesto deben seguir fijándose uno por uno según el uso real y el coste.

Figura 3: Esquema de la configuración modular y la gestión de piezas de repuesto

Tabla 1: Atribución de responsabilidad de los tres modelos de suministro y enfoques correspondientes de wareconn

        Los SLA y la estrategia de piezas de repuesto también pueden configurarse con flexibilidad según el modelo de suministro y las necesidades del cliente, sin necesidad de crear un sistema distinto para cada modelo. Por ejemplo, los sistemas del fabricante original deben acompañarse del contrato de servicios de soporte del fabricante [3], y el período del contrato también debe conservarse junto con el número de serie del equipo y su período de garantía. Una vez que la atribución de responsabilidad y los registros de reparación se conservan de forma estructurada, también pueden servir de base para el análisis continuo y para mejorar los costes de garantía y la fiabilidad del producto [10].