Un benchmark de 808 sitios no es un problema difícil. Es un problema largo, y los problemas largos fallan a la mitad. El nuestro falló, en silencio, en el sitio 327. Así está construido ahora el arnés y por qué existe cada decisión.
La tubería
- Sondeo. Una revisión HTTP rápida de cada dirección de la lista. 807 de 1.000 respondieron, lo que eliminó 193 enlaces muertos antes de cualquier trabajo costoso.
- Captura. Un navegador sin interfaz abre cada sitio en escritorio y móvil, lo recorre, hace clic en la llamada a la acción principal, abre algunas páginas internas y corre un escaneo de accesibilidad. Doce sitios en paralelo, unos seis sitios por minuto.
- Lighthouse. Rendimiento móvil de cada sitio, un proceso por sitio, ejecutado después de la captura para que nunca compitan por la misma CPU.
- Evaluación. Modelos de IA leen las capturas y los datos del rastreo contra una rúbrica escrita y devuelven JSON. Un validador rechaza cualquier respuesta con un criterio faltante o fuera de rango, y la tarea se repite hasta que pasa.
- Agregación. Los puntajes medidos y los juzgados se combinan, se ordenan y se escriben en un informe.
Qué se rompió
- El orquestador desapareció. Una cadena en segundo plano que debía correr captura, luego evaluación y luego el informe se detuvo tras 327 sitios. Sin error, sin línea en el registro, sin proceso. El único síntoma fue que la carpeta de resultados dejó de crecer.
- El script de captura no podía reanudar. No tenía lógica para saltar lo hecho, así que reiniciar repetía el trabajo terminado. En su lugar reconstruimos una lista de “pendientes” con los sitios que no tenían archivo de resultados.
- Un comando de apagado no hizo nada. Programamos el apagado del equipo al terminar. El intérprete reescribió la opción como una ruta de disco, el comando mostró un mensaje de uso y no se programó nada. Lo supimos solo porque el equipo seguía encendido.
- Un evaluador se comportó distinto a los demás. Nuestro sitio lo juzgaron tres evaluadores promediados, mientras que cada otro sitio tuvo uno. Eso es un sesgo, y lo corregimos en la verificación cruzada usando un evaluador por sitio.
Las reglas que conservamos
- Cada etapa es reanudable. Una etapa lee “qué falta” de los archivos en disco, no de la memoria, así que un reinicio solo hace el trabajo pendiente.
- Verifique el resultado, no el código de salida. Una tarea está lista cuando su archivo de resultados existe y pasa el validador, no cuando el proceso devolvió cero.
- Corra las cadenas largas donde algo las vigile. Una cadena iniciada en segundo plano sin supervisor puede morir sin que nadie lo note. Una tarea vigilada avisa cuando termina.
- Nunca deje que un aviso implique un resultado. La alerta final se envía solo después de que el informe exista y tenga el encabezado esperado. Si falta, la alerta lo dice y el equipo sigue encendido.
Nada de esto es ingenioso. Es la diferencia entre una corrida que le cuesta una tarde cuando algo muere y una que le cuesta el día. Si construye algo que corre por horas, construya el reinicio antes que la corrida.