El aviso llegó de noche. La base de datos de la web de un cliente trabajaba muy por encima de lo normal y su proveedor de hosting había localizado el motivo: las búsquedas tardaban de media 82 segundos en resolverse, mientras varios robots lanzaban una tras otra. A la mañana siguiente, el caso estaba en nuestra mesa.
Menos de una hora después de abrirse el ticket, habíamos respondido con la causa real, una medición que la demostraba y la lista exacta de lo que había que comprobar en producción.
El fallo en sí es lo de menos: dos piezas de la base de datos que llevaban años sin entenderse, y una avalancha de búsquedas que lo hizo evidente. Lo que merece contarse es el trabajo, porque es la parte del soporte que no se ve cuando todo funciona.
El primer sospechoso tiene derecho a coartada
Todo caso llega con una primera hipótesis. Esta señalaba una parte concreta de la base de datos, era razonable y venía de quien mejor conoce los servidores. Lo cómodo habría sido retocar esa parte y esperar a ver qué pasaba.
La comprobamos antes, y estaba bien. Así lo dijimos en el ticket, junto con el motivo: tocarla no iba a arreglar nada. El cliente se ahorró un cambio inútil en una web en producción, con su coste y su riesgo. Eso no aparece en ningún informe, y también es trabajo de soporte.
La escena del crimen no se toca
Investigamos en nuestro entorno de desarrollo, con el mismo código y una copia de los datos reales. Mientras tanto, la web siguió atendiendo a sus visitantes sin enterarse de nada.
Ahí reprodujimos el problema, lo aislamos y probamos la solución. Las mismas búsquedas pasaron a ser entre 8 y 12 veces más rápidas y devolvieron exactamente los mismos resultados. Lo segundo importa tanto como lo primero, porque una búsqueda muy rápida que encuentra otra cosa es otra avería.
Con esa prueba en la mano ya no estábamos pidiendo a nadie que confiara en nuestra intuición.
Una investigación, un solo hilo
El hosting ve sus servidores y nosotros vemos la web por dentro. Nadie lo ve todo desde su lado, así que un caso así solo se resuelve si los dos trabajan juntos.
Fue un buen ejemplo. El proveedor había dado el aviso a tiempo y con datos. Nosotros le indicamos en el ticket qué mirar y qué tenía que salir si estábamos en lo cierto. Lo comprobó en sus dos entornos y lo confirmó. Propuso una prueba controlada de la corrección y le añadimos cómo volver atrás si algo iba mal. También le propusimos frenar a los robots antes de que llegaran a la base de datos, porque la protección que había no bastaba.
El cliente estuvo en ese hilo desde el principio. Pudo ver qué pasaba y quién lo llevaba, y no tuvo que reenviar un solo correo entre un proveedor y otro.
Si la respuesta a todo es «hemos reiniciado y ya va», el caso sigue abierto.
Hasta el final del rastro
Cuando los robots se fueron, la carga volvió a la normalidad. A efectos prácticos, ya no había incidencia, y muchas se cierran justo en ese momento. La causa seguía allí, esperando a los siguientes robots.
Quedaba además la pregunta que separa arreglar algo de entenderlo: ¿por qué ha pasado y cómo evitamos que vuelva a pasar? La respondimos en el ticket el mismo día que se planteó, después de seguir el rastro por el historial del software hasta su origen. El culpable llevaba años en casa. Venía de la versión con la que se construyó la web, y esa web la construimos nosotros, así que lo dijimos tal cual.
Conocer el origen nos dio lo que un parche nunca da: saber qué hay que corregir exactamente, confirmar que una actualización rutinaria no lo habría resuelto y poder asegurar que lo que se cree a partir de ahora ya saldrá bien.
Sentencia pendiente de ejecución
Mientras escribimos esto, la corrección entra en prueba controlada en preproducción. Antes de dar ese paso ya comprobamos que el cambio era seguro y dejamos por escrito qué hacer si algo se torcía. Cuando llegue a producción, se medirá antes y después, porque esa será la cifra que cuente.
Para reunir todo lo anterior no hemos tenido que tocar producción ni una sola vez.
Cuatro preguntas para tu soporte
Valen para cualquier incidencia en tu web, la lleve quien la lleve.
¿Te han explicado qué falla, o solo qué han hecho para que deje de notarse?
¿Hay una medición del antes y el después, o solo la sensación de que ahora va mejor?
¿Sabes desde cuándo pasa y por qué? Sin esa respuesta, nadie puede decirte si volverá.
Cuando intervienen el hosting y el equipo de la web, ¿hablan entre ellos o eres tú quien reenvía los correos?
Si la respuesta a todo es «hemos reiniciado y ya va», el caso sigue abierto.
Fuentes
Para quien quiera entrar en el detalle técnico.
- MySQL, 8.0 Reference Manual, 12.1 «Character Sets and Collations in General»: qué es una collation, el conjunto de reglas con el que la base de datos compara caracteres.
- Drupal.org, Search API, issue #3227268, «Search API full text queries do not use an index when used via views due to utf8mb4 / utf8 mismatch on PRIMARY»: el problema en el módulo y la decisión de corregirlo primero para los índices nuevos.
- Search API, commit caff9cac, 2022: el parche, que actúa al crear tablas nuevas.
- Drupal.org, search_api 8.x-1.24: versión publicada el 7 de julio de 2022 que incluye esa corrección.
- IETF, RFC 9309, «Robots Exclusion Protocol», 2022: las reglas para robots son una petición que los rastreadores deben respetar por su cuenta, no un control de acceso.