Introducción

Aborde primero los riesgos de seguridad inmediatos y las interrupciones de infraestructura compartida. Después, priorice las reparaciones de ASIC individuales que ofrezcan un retorno creíble a un servicio estable y un margen operativo recuperable suficiente para justificar su coste. Una reparación rápida y de alta confianza puede merecer prioridad, pero la rapidez o el hashrate nominal por sí solos no son motivo suficiente para colocarla al frente de la cola.

Los operadores que gestionan una flota de mineros ASIC acumulan inevitablemente un backlog de unidades fuera de línea. Reparar la máquina que lleva más tiempo caída, o la unidad con el hashrate nominal más alto, pasa por alto si el fallo está relacionado con el hardware, si comparte una causa raíz con otras unidades fuera de línea, y si la reparación recuperará su coste en un plazo razonable.

Este marco es una ayuda práctica para la toma de decisiones dirigida a operadores de sitios y equipos de mantenimiento, no un procedimiento de auditoría formal. Los riesgos de seguridad inmediatos tienen prioridad sobre la secuencia siguiente: cuando sea evidente un fallo eléctrico o una condición térmica insegura, ponga el equipo afectado en condición segura antes de continuar con el diagnóstico. Para el resto de unidades, verifique el estado, investigue causas compartidas, estime el valor recuperable y priorice las reparaciones.

Paso 1: Confirmar que el ASIC realmente está fuera de línea

Antes de añadir una unidad a la cola de reparación, debe comprobarse su estado en ambos lados de la conexión. Los indicadores del lado del minero incluyen la pantalla local de hashrate, los registros del kernel o del sistema, la detección de hashboards, el estado de los ventiladores, las temperaturas de chips y placas, el estado de la fuente de alimentación y la conectividad de red. Los indicadores del lado del pool incluyen el estado del worker, el hashrate reportado por el pool en una ventana de tiempo comparable, y la tasa de rechazo de los shares enviados.

La ventana de tiempo importa porque las cifras del lado local y del lado del pool rara vez se calculan de la misma manera. La documentación de ViaBTC explica que su visualización de hashrate en tiempo real se basa en los últimos 10 minutos, mientras que su estadística de hashrate diario refleja las 24 horas anteriores; la interfaz local de un minero puede actualizarse cada pocos segundos y no está garantizado que use el mismo método de promediado (Centro de Ayuda de ViaBTC). Un minero que acaba de reiniciarse, se desconecta de forma intermitente, o no ha completado un ciclo completo de 24 horas puede, por tanto, mostrar una cifra del lado del pool considerablemente más baja sin que exista ningún fallo físico. Una discrepancia entre ambas lecturas es una señal para revisar las ventanas de promediado, la estabilidad de la conexión y la compatibilidad del firmware, no una evidencia de fallo de hardware por sí sola.

La tasa de rechazo merece una precaución similar. Una tasa de rechazo elevada puede reflejar latencia de red, problemas de firmware, una configuración incorrecta del pool, o un problema de hardware genuino, y debe interpretarse junto con los registros y las comprobaciones de conectividad, en lugar de tratarse como una medida directa del estado del hardware.

Una discrepancia del lado del pool sin un fallo corroborado del lado del minero sigue siendo una tarea de diagnóstico. No debe entrar en la cola de reparación de hardware hasta que las comprobaciones identifiquen un fallo que requiera reparación.

Paso 2: Separar los fallos de causa compartida de los fallos individuales

Una vez confirmado que una unidad está realmente fuera de línea y no mal reportada, la siguiente pregunta es si el fallo está aislado a esa máquina o compartido con otras cercanas. Un fallo que afecte a varios mineros en el mismo rack, circuito, switch o zona de refrigeración debería, en general, investigarse antes de reparar fallos aislados a nivel de placa.

Las comprobaciones relevantes en esta etapa incluyen la URL stratum, el nombre del worker y la configuración de conexión del pool; el estado de los switches de red, routers y cableado; la distribución de energía y las entradas de la PSU; la temperatura de entrada de aire, la vía de escape, la acumulación de polvo y el estado de los ventiladores; y si el firmware instalado coincide con el modelo del minero. La documentación de resolución de problemas de BITMAIN para unidades ANTMINER enumera la inestabilidad de red, problemas de la placa de control, fallos de ventiladores, fallos de PSU, protección por temperatura, excepciones de firmware, hashboards ausentes y chips inestables entre las causas documentadas de hashrate nulo o bajo (Soporte de BITMAIN). Varias de estas causas —la protección por sobretemperatura activada por un flujo de aire bloqueado, o un switch averiado o un enlace ascendente compartido que afecta a toda una fila— pueden producir algo que parece múltiples fallos de placa no relacionados cuando la causa real es infraestructura compartida o condiciones operativas.

Una reparación que restaura varios mineros a la vez, o que elimina una condición que probablemente cause más daño térmico o eléctrico, generalmente merece prioridad sobre la reparación de una sola unidad de alto hashrate, incluso cuando el ingreso esperado individual de esa unidad es mayor. Abordar primero la causa compartida también evita el esfuerzo desperdiciado de reparar una placa solo para que vuelva a fallar una vez que la condición subyacente se repita.

Paso 3: Estimar si vale la pena realizar una reparación individual

Después de haber abordado los problemas de seguridad y los fallos de causa compartida, las unidades restantes fuera de línea pueden clasificarse según el caso económico de reparar cada una. Este paso requiere un horizonte de planificación: el período durante el cual la operación espera seguir utilizando la unidad antes de una decisión de flota, un cambio de hosting, un período de recorte (curtailment) o un reemplazo de hardware. El horizonte es un supuesto operativo elegido por el operador, no un período estándar de la industria.

Una forma de organizar esta comparación, presentada aquí como una ayuda práctica para la toma de decisiones y no como un KPI estándar de minería, es:

Valor esperado de la reparación = p × H × m − C_reparación

Esto estima el valor incremental en comparación con dejar la unidad fuera de línea durante el mismo horizonte de planificación:

• p es la probabilidad estimada de que la reparación devuelva la unidad a un servicio estable.\n- H son las horas de operación productiva disponibles dentro del horizonte si la restauración tiene éxito, después de considerar el tiempo de diagnóstico, reparación, envío y reinstalación, así como los periodos de inactividad previstos. No reduzca H nuevamente por el mismo riesgo de fallo de reparación que ya está contemplado en p.\n- m es el margen operativo neto incremental estimado por hora productiva.\n- C_repair es el costo total esperado del intento de reparación, incluidas las piezas, los cargos de reparación externos, el envío y la mano de obra cuando corresponda. Incluya los costos incurridos incluso si la reparación falla.\n\nUtilice una sola moneda en todo momento. Por ejemplo, si m se expresa en USD por hora, H debe estar en horas y C_repair en USD. Bajo este modelo simplificado, una reparación fallida no produce margen operativo recuperado. Un resultado positivo respalda la reparación frente a dejar el minero fuera de línea; no establece que la reparación sea mejor que la reventa o el reemplazo.\n\nEl margen operativo en sí puede estimarse como:\n\nm = R_net − C_electricity − C_other incremental\n\nAquí R_net es el ingreso esperado de minería por hora productiva después de las comisiones del pool; C_electricity es el costo de electricidad medido o esperado de la unidad por hora productiva; y C_other incremental cubre los costos de alojamiento o enfriamiento por hora productiva únicamente cuando dichos costos realmente cambian según si la unidad está funcionando o no. Las tres entradas deben usar la misma moneda y la misma base horaria. Una tarifa de alojamiento pagadera independientemente del estado del minero no debe restarse nuevamente aquí, y una comisión del pool ya reflejada en R_net no debe deducirse una segunda vez.\n\nEl método de pago afecta la forma en que se debe estimar R_net. La documentación de ViaBTC indica una comisión del 4% sobre el componente de recompensa de bloque PPS de PPS+ y una comisión del 2% sobre su componente de comisiones de transacción basado en PPLNS; el PPLNS independiente conlleva una comisión del 2% (ViaBTC Help Center). Aplique cada comisión a su componente de ingresos correspondiente. Si utiliza una única tasa de comisión efectiva para PPS+, pondere las tasas de los componentes según sus participaciones esperadas en los ingresos brutos en lugar de sumarlas. Utilice una estimación de ingresos esperados adecuada al horizonte de planificación; los ingresos de PPLNS a corto plazo pueden fluctuar y no deben tratarse como un flujo de ingresos por hora garantizado.\n\nCuando el tiempo del técnico, en lugar de las piezas o el costo, es la restricción vinculante, una operación puede usar el valor esperado de reparación dividido entre las horas de técnico requeridas como criterio de desempate entre trabajos de prioridad similar. Esto debe complementar, no reemplazar, la clasificación por seguridad y causa común. Una reparación rápida aún necesita un caso económico aceptable antes de recibir prioridad como trabajo de restauración ordinario.\n\n## Un marco práctico de prioridades\n\nLa siguiente tabla resume cómo estas preguntas se traducen en una cola de trabajo. Es una estructura inicial, no una regla fija; los umbrales específicos de costo, tiempo de inactividad o confianza dependen del modelo de ASIC, de las condiciones de electricidad y alojamiento, de la disponibilidad de reparación y del horizonte de planificación propio de la operación.\n\nLa verificación es una puerta de entrada antes de que las reparaciones de hardware individuales ingresen a esta cola. Las discrepancias del lado del pool sin fallos corroborantes permanecen en diagnóstico, en lugar de convertirse en un nivel de reparación de baja prioridad.\n\n| Nivel de prioridad | Tipo de fallo | Justificación | Próximo paso típico |\n|---|---|---|---|\n| 1. Problema de seguridad inmediato | Condiciones térmicas inseguras o fallos eléctricos | Requiere atención antes del diagnóstico o la restauración rutinarios | Haga que el equipo afectado quede seguro y aísle el peligro antes de continuar con el trabajo |\n| 2. Problema de infraestructura compartida | Fallo de switch, enlace ascendente compartido, PDU o enfriamiento que afecta a varios mineros | Restaurar una dependencia compartida puede recuperar varios mineros y prevenir fallos recurrentes | Identifique y corrija la causa común, luego verifique las unidades afectadas |\n| 3. Restauración rápida y de alta confianza con economía aceptable | Cable suelto, ventilador averiado, configuración de pool incorrecta, discrepancia de firmware o fallo conocido de la fuente de alimentación (PSU) | Puede devolver una unidad al servicio rápidamente cuando el beneficio esperado justifica el costo | Corrija la conexión, la configuración o el firmware, o reemplace el componente defectuoso según corresponda; confirme con registros y actividad del lado del pool |\n| 4. Reparación individual de alto valor | Unidad fuera de línea con margen favorable y una vía de reparación creíble | Restaurar la máquina puede recuperar un margen operativo significativo dentro del horizonte | Obtenga un presupuesto de reparación y estime el tiempo de respuesta, la probabilidad de éxito y el valor esperado de la reparación |\n| 5. Revisión de reparación condicional o retiro | Unidad más antigua, ineficiente o con fallos repetidos | Es posible que la reparación no recupere su costo antes de que finalice el horizonte | Compare la reparación con dejar la unidad fuera de línea, el reemplazo, la reventa o el uso como fuente de repuestos |\n\nLos niveles de reparación ordinarios no constituyen una clasificación absoluta por velocidad de reparación. Un trabajo más lento con un valor recuperable sustancialmente mayor puede merecer prioridad sobre una solución rápida; utilice la estimación económica y la restricción de recursos real para resolver esa disyuntiva.\n\n## Reparar frente a reemplazar: por qué importa la generación de la flota\n\nLa generación del hardware importa porque un reemplazo más eficiente puede ofrecer una mejor economía al precio de energía del sitio. Su disponibilidad, por sí sola, no reduce el margen operativo de un minero existente. Ese margen cambia cuando los ingresos o los costos operativos de la unidad más antigua cambian; por ejemplo, cuando el ingreso por unidad de potencia de cómputo cae, los precios de la energía suben o el rendimiento operativo de la unidad se deteriora.\n\nUtilice el rendimiento medido de la unidad existente y el costo real de energía del sitio para estimar el valor de la reparación. Luego compare la reparación y el reemplazo durante el mismo horizonte de planificación, teniendo en cuenta los costos de adquisición e instalación, el tiempo de respuesta, la compatibilidad de infraestructura y cualquier valor de reventa relevante para cada opción. Un valor esperado de reparación positivo en comparación con dejar la unidad fuera de línea es una primera verificación útil, pero la mejor decisión para la flota depende de las alternativas disponibles.\n\n## Conclusión

Una cola de mantenimiento debe atender primero los riesgos inmediatos, verificar qué unidades necesitan atención, investigar causas compartidas y, después, clasificar las reparaciones individuales según el valor recuperable y los recursos necesarios. Esto evita tratar una discrepancia de medición como un fallo de hardware o reparar máquinas en un orden que ignora la infraestructura compartida y la economía realista de las reparaciones.

Las cifras concretas variarán según el sitio, la generación del hardware y el método de pago. La decisión sigue siendo práctica: priorizar las restauraciones creíbles que justifiquen su coste dentro del horizonte operativo, y comparar las reparaciones inciertas o marginales con las alternativas disponibles.

Preguntas frecuentes

¿Una computing power más baja en el lado del pool es siempre evidencia de un fallo de hardware?

No. Las cifras del lado del pool y las del lado de la minera a menudo se calculan en ventanas de tiempo diferentes y se actualizan con distintos intervalos, por lo que una discrepancia por sí sola no confirma un fallo físico. Confirme que las ventanas de tiempo sean comparables y revise la tasa de rechazo, la conectividad y los registros antes de abrir el hardware.

¿Debería repararse siempre primero un único ASIC de alta computing power antes que varias unidades de menor computing power?

No necesariamente. Si las unidades de menor computing power comparten una causa común, como un switch averiado o un problema de refrigeración que afecta a toda una fila, abordar esa causa compartida puede restaurar más computing power total y evitar más daños, lo que puede justificar atenderla antes que una reparación individual de alta computing power.

¿Es la fórmula de valor de reparación esperado una métrica estándar en la industria minera?

No. Es una ayuda simplificada para la toma de decisiones que permite comparar candidatos a reparación frente a dejarlos fuera de línea durante un horizonte elegido, no un indicador clave de rendimiento establecido en la minería. Los operadores deben adaptar sus parámetros a sus propios costes y supuestos operativos, y evaluar por separado la reventa o el reemplazo.

¿Afecta el método de pago a la forma en que debe estimarse la economía de las reparaciones?

Sí. Los métodos de pago difieren en la estructura de comisiones, el momento de pago y la varianza. Aplique las comisiones a los componentes de ingresos pertinentes y utilice una estimación de ingresos esperados adecuada al horizonte de planificación, en lugar de asumir que los ingresos recientes representan un flujo de caja horario garantizado.

Referencias

• Centro de Ayuda de ViaBTC, "¿Por qué la computing power mostrada en el pool de minería es más baja que la de la máquina minera?"
• Centro de Ayuda de ViaBTC, "¿Cómo se calculan las ganancias?"
• Soporte de BITMAIN, "Solución de problemas y soluciones para fallos de ANTMINER"