Documentación técnica: Kepler estaba curado y nadie conservó la receta

Antares podía pasar horas sano siempre que se le concediera el privilegio de no hacer nada exigente. Durante una transferencia intensa desaparecía primero la respuesta útil y después todo lo demás. Reiniciar devolvía el servicio con esa eficacia obscena que tienen los reinicios: arreglan la tarde y limpian parte de la escena del crimen.

Kepler, pariente técnico, había practicado meses antes una avería parecida. Desde cierto ajuste permanecía estable. La memoria conservaba tres sustantivos —Intel, controlador, Proxmox— y una vaga impresión de triunfo. Del cambio exacto, la causa y la prueba posterior no quedaba material apto para declarar ante un tribunal.

El hueco admitía explicaciones de buena familia: offloads, módulo, parámetro del controlador, actualización. Todas sonaban familiares y ninguna tenía pruebas. Aplicar una al azar podía estabilizar Antares, lo cual habría sido cómodo y epistemológicamente lamentable: una explicación falsa premiada por un resultado correcto.

La investigación cambió de objeto. Había que diagnosticar Antares y exhumar Kepler al mismo tiempo: comparar configuración, paquetes, parámetros persistentes y registros del kernel. Cada hallazgo debía llevar etiqueta de procedencia. «Observado ahora» y «me parece recordar» no pueden compartir columna sin que el segundo acabe vestido de hecho.

Una vez localizado el cambio —o inventada una hipótesis nueva con la debida etiqueta—, no bastaba mirar el nodo durante un rato y apreciar su compostura. La carga que provocaba el bloqueo debía volver: transferencia sostenida, observación del controlador, mensajes del kernel y tiempo suficiente para que la suerte perdiera interés.

Kepler necesitaba la misma prueba. Compartir modelo y síntoma no garantiza compartir causa; las máquinas también coinciden por casualidad. Si ambas resisten bajo condiciones comparables y las trazas acompañan, empieza a existir una solución reproducible. Antes solo hay dos ordenadores que han decidido portarse bien el mismo día.

El fallo posterior vale más que muchas horas tranquilas. Si Antares se bloquea con el supuesto arreglo, esa ejecución debe conservar volumen transferido, tiempo y trazas cercanas. El resultado negativo no es material vergonzoso: es la única parte del ensayo que ha demostrado tener dientes.

No hacía falta redactar las memorias completas del controlador Intel. Bastaban seis cosas: síntoma, hipótesis, cambio exacto, evidencia anterior, prueba posterior y reversión. Si falta una, el arreglo puede seguir funcionando y estar técnicamente desaparecido, como ocurrió con notable éxito en Kepler.

Resolver no termina cuando el equipo deja de fallar. Termina cuando el siguiente operador puede repetir, discutir o retirar el cambio sin practicar espiritismo. Antares no heredó solamente una posible avería; heredó los intereses de una explicación que nadie cerró.

La documentación útil conserva la bifurcación: por qué se eligió ese ajuste y qué observación permitió abandonar los demás. No necesita cada comando ni una novela de mantenimiento. Necesita impedir que dentro de un año «la cosa de Intel» vuelva a ser el principal repositorio de conocimiento.