Cuando el test de carga es "ya veremos en producción"

00:00 · Cold open

Probando, probando… ya veremos en directo. Esto es Press Any Key. En Press Any Key desbrozamos el mundo del software y de la tecnología en general para que elijas bien a qué dedicas tu tiempo, tus proyectos y tu futuro. Aunque casi siempre me toque criticar lo que todo el mundo aplaude. ¡Hola! Soy Lino y te doy la bienvenida al episodio 2 de este invento. Viernes, 6 de la tarde. Alguien de marketing escribe en el canal general y en mayúsculas: ¡Mañana sale el anuncio en la tele! Tú preguntas con la boca pequeña si alguien lo ha probado con carga y la respuesta llega en 10 segundos. Bah, si va mal, escalamos. Sábado, 9 y cuarto de la noche. Empieza el anuncio. Y a las 9 y 17 la web ya no responde. Pues hoy vamos a hablar de lo que pasa entre ese “si va mal, escalamos” y el lunes por la mañana.

01:38 · Noticias de la semana

Pero antes de ponernos a tumbar webs, toca repasar lo que ha pasado esta semana. ¿Has ido alguna vez a una reunión de la comunidad de vecinos? Siempre llega el punto del orden del día en el que alguien dice que hay que arreglar el ascensor. Todo el mundo asiente, muy de acuerdo, y entonces alguien hace la pregunta que vacía la sala en dos minutos. Pues las noticias de esta semana acaban todas en esa misma pregunta. Te la digo al final, pero si la adivinas antes, punto para ti. Así que vamos al lío.

02:14 · Los fallos los encuentra una máquina; los arregla un voluntario

Empezamos con la noticia que ha tenido a medio sector de sistemas sin pegar ojo y que tiene nombre de película de serie B: PHP2Shell. Resulta que el miércoles 21 PHP sacó parches para dos fallos críticos que dejan ejecutar código en el servidor a distancia y sin necesidad de identificarse. Y PHP está detrás de cerca del 70% de las webs, al menos de las que se sabe con qué están hechas. Así que la superficie de ataque es, digamos, generosa. Los fallos los encontraron por separado tres equipos: la empresa de seguridad Calif, que dio el aviso en agosto, la gente de Wiz y OpenAI con uno de sus modelos. Hasta aquí todo más o menos normal, pero a partir de aquí empieza el desfile. Para empezar, Amazon detectó intentos de ataque el sábado 17, o sea, cuatro días antes de que existiera el parche. Luego, el lunes, se filtraron los nombres oficiales de los fallos y PHP tuvo que adelantar el anuncio. Encima, una de las empresas que había dado el aviso colgó por error un vídeo con el ataque funcionando. Y para rematar, otra empresa, Chainguard, sacó sus imágenes ya corregidas más de seis horas antes de lo pactado, así que cualquiera podía estudiar el arreglo antes de que nadie pudiera instalarlo. La cosa llegó a tal punto que el Centro Nacional de Ciberseguridad Británico pidió desconectar los servidores que no estuvieran parcheados. Y por si fuera poco, hay un tercer fallo, aunque ese no tendrá parche urgente porque basta con cambiar un ajuste de la configuración, que es la forma técnica de decir: “este si quieres te lo arreglas tú”. A mí lo de PHP me parece la noticia más sincera de la semana, y no por los fallos, sino por lo que ha escrito la propia PHP Foundation, porque reconoce que el problema de memoria ya se conocía desde una auditoría de 2024, que el primer aviso serio les llegó en agosto, y que tardaron meses en elegir el arreglo porque necesitaban ponerse todos de acuerdo, porque cada solución rompía otra cosa y porque había muy poca gente que conociera el motor por dentro. Ellos mismos lo llaman un fallo estructural. O sea, que el fallo no fue de detección, fue de decisión. Y además de decisión con muy poca gente, porque el motor de PHP, que mueve media web, lo entienden a fondo cuatro personas que encima tienen otras mil cosas que hacer. Por un lado, las empresas de seguridad y de IA encuentran el fallo y se llevan el titular y la medalla. Por otro, los voluntarios lo arreglan a contrarreloj y con medio internet mirando. Y te confieso una cosa antes de seguir: PHP no es precisamente mi lenguaje favorito. De hecho, es el segundo que menos me gusta, y si no es el primero es porque existe Java. Pero medio internet, o casi, funciona con ese engendro llamado WordPress, que está hecho en PHP, así que entiendo perfectamente el peligro. Ahora bien, en esta historia yo me apunto al lado de los optimistas. Porque viví y trabajé durante meses reparando el efecto 2000. Aquel fin del mundo informático que iba a parar los aviones, los bancos y los ascensores a la medianoche del 31 de diciembre. ¿Y sabes qué pasó? Pues que no fue para tanto. Nunca suele ser para tanto. Con PHP2Shell está pasando algo parecido, porque ha habido ruido, prisas y pruebas de concepto por todas partes. Pero de momento no se conoce ni una sola intrusión confirmada. El sistema, con todos sus defectos, ha funcionado. Eso sí, ha funcionado a pesar de los embargos, no gracias a ellos. Lo de la divulgación coordinada, que en la práctica es callarse el fallo durante semanas hasta tener el parche, a mí nunca me ha convencido. Me suena demasiado a seguridad por oscuridad. Porque mientras tú te callas, nada impide que otra persona descubra el mismo fallo y lo explote en secreto sin avisar a nadie. Y eso es muchísimo peor que un fallo publicado. Además, aquí se ha visto que el secreto no aguanta, porque se filtraron los nombres de los fallos. Alguien colgó un vídeo por error y otra empresa sacó el arreglo antes de tiempo. Así que cuanto antes se sepa, antes se arregla y antes nos protegemos todos. Y que conste que aquí la IA no es la mala de la película. Es más bien un foco que ilumina lo que ya estaba ahí y lo ilumina para todos a la vez, también para el que viene a aprovecharse. Por eso mismo tiene poco sentido esconder nada, porque si tu modelo encuentra el fallo, el del atacante también lo puede encontrar. Así que ya sabes, si tienes PHP, parchea ya. Y si tu versión es anterior a la 8.2, ve pensando seriamente por qué sigues ahí.

06:37 · Cuando revisar informes cuesta más que encontrar fallos

Seguimos con el software libre y con una decisión que dice mucho de cómo están las cosas. Resulta que curl, o «curl», para los españoles, la herramienta con la que medio planeta descarga cosas de Internet, va a cambiar su forma de tratar los fallos de seguridad. A partir del lunes 26, los fallos de gravedad baja y media se gestionarán en abierto, en su repositorio y a la vista de todo el mundo. Y solo los graves y los críticos seguirán en privado hasta que tengan arreglo. ¿Y por qué lo hacen? Pues según su creador, Daniel Stenberg, es por una avalancha de informes que no para de crecer. Muchos de ellos generados con IA a base de combinar opciones raras que casi ningún programa usa de verdad. De hecho, más del 90% acaban una vez revisados por debajo de la gravedad alta. Curl ya cerró este año su programa de recompensas precisamente por eso, y Stenberg lo resume diciendo que es una estrategia de supervivencia y que quizás no sea la última. Y para ponerle cifras al fenómeno, la Linux Foundation ha publicado un informe pagado por Red Hat sobre cómo le está afectando la IA generativa al software libre. Según calculan los propios mantenedores, una de cada cuatro contribuciones que les llegan es basura generada con IA, y en los proyectos grandes, casi una de cada tres. Además, uno de cada cuatro proyectos no tiene forma de saber cómo se ha hecho lo que le llega. Eso sí, es una encuesta pequeña, de 234 personas, así que tómalo como la impresión de quien está en la trinchera, no como una medición. En el fondo, esto es la otra cara de la noticia anterior. Para quien envía un informe, encontrar un fallo o creer que lo ha encontrado ya no cuesta casi nada, porque le pides a un modelo que revise el código y te saca una lista. Pero para quien lo recibe, revisarlo cuesta lo mismo de siempre, que es leerlo, reproducirlo, ver si es grave y contestar con educación o no. Multiplica eso por cientos de informes, y tienes a un puñado de personas haciendo de filtro de spam para todo el planeta. Y fíjate lo que ha decidido curl para sobrevivir: publicar los fallos pequeños antes de arreglarlos. Habrá quien lo vea como renunciar a proteger a sus propios usuarios. Yo, como ya te he dicho, pienso justo lo contrario, porque cuanto antes se conoce un fallo, antes se arregla. Así que, aunque sea a la fuerza, curl ha acabado haciendo lo que a mí me parece que habría que hacer siempre. Lo que sí veo es un desequilibrio que me parece injusto. Enviar un informe sale gratis y encima puede ser anónimo. Revisarlo, en cambio, lo paga siempre el mismo y casi nunca es una empresa. Hay quien propone cobrar por enviar informes para frenar la avalancha, y a mí me parece mala idea porque si te cobran por avisar de un fallo, sencillamente no vas a avisar. Y ese fallo acabará en manos de otro que no tiene ninguna intención de avisar a nadie. Lo que funciona es justo lo contrario: pagar a quien encuentra fallos de verdad. Google, por ejemplo, lleva años pagando a quien descubre fallos en sus productos. Lo malo es que a curl, la avalancha de informes generados con IA, se le comió su programa de recompensas. Y aquí vuelve la pregunta de siempre: la de quién paga. Porque curl va dentro de tu coche, de tu tele, de tu móvil y de los servidores de tu empresa, que seguramente no le ha dado nunca ni las gracias. Y mucho menos dinero. Yo de momento no me he tenido que pelear con informes de IA sin revisar, todavía. Pero viendo cómo va la cosa, me temo que es cuestión de tiempo. Así que si quieres un consejo práctico, cuando uses IA para buscar fallos en un proyecto ajeno, compruébalos tú antes de enviarlos. Porque un informe sin revisar no es una contribución, es un trabajo que le enchufas a otro.

10:18 · La nube tiene enchufe

Vamos ahora con la nube, que esta semana nos ha recordado que por mucho que la dibujemos como un algodón, va enchufada a la pared. El martes 20 a las 8 de la mañana, hora peninsular, un fallo eléctrico tumbó una de las tres zonas que Google Cloud tiene en Londres. Se cayeron servicios como Cloud Run, Kubernetes Engine o App Engine. Y con ellos, clientes como Revolut, que se quedó sin aplicación y sin pagos con tarjeta en toda Europa, también en España. Y lo mismo les pasó a bancos británicos como Lloyds, HSBC y empresas como Royal Mail o BT. Google tardó unas seis horas en dar el problema por resuelto para la mayoría de sus clientes. Y durante buena parte de ese tiempo, lo que les recomendaba era que se llevaran sus cargas a otra zona, si podían. La segunda noticia enchufada también viene de Reino Unido. Según el diario The Telegraph, Microsoft ha roto su acuerdo para usar el que iba a ser el mayor centro de datos de IA soberano del país, en Loughton, al este de Londres, iban a ser más de 23.000 GPU de NVIDIA. Pero la compañía eléctrica avisó que quizás no podría conectarlo a la red hasta principios o mediados de los años 30. De los 2030, para los boomers que me escucháis. La promotora, Nscale, dice que sigue adelante y que está buscando otras fuentes de energía. Supongo que ya habrán descartado lo de llenar la nave de bicicletas estáticas. Y la tercera nos lleva a Texas, donde el gobernador pidió en septiembre que se congelaran los permisos para centros de datos. Unos vecinos y dos organizaciones descubrieron que el portal de la agencia ambiental los seguía aprobando de forma automática, también para proyectos de OpenAI y Amazon. Lo publicó el medio 404 Media y a los pocos días cerraron el portal y suspendieron 17 permisos. Lo de Google en Londres es una lección del primer curso de arquitectura en la nube. Y aún así, la seguimos suspendiendo. Una región tiene varias zonas precisamente para eso, para que si se cae una, siga funcionando con las otras. Y que un banco o cualquier infraestructura crítica tenga sus sistemas o una parte de ellos en una sola zona, me parece de una dejadez absoluta. Al que tomó esa decisión habría que colgarlo de los pulgares. Y apuesto a que fue alguien intentando recortar gastos, que pasó muy deprisa por el apartado de riesgos técnicos. Porque repartirse en varias zonas cuesta dinero, complica el diseño y durante años no pasa nada. Hasta que pasa. Y a mí lo que más me llama la atención es el consejo de Google. Eso de que, si puedes, te lleves tus cargas a otra zona. Porque ese “si puedes” lo dice todo. Cambiar un sistema de zona en plena caída solo es posible si ya lo tenías preparado. Si no, es como ponerse a buscar la salida de emergencia cuando el edificio ya está lleno de humo. Ahora, que nadie me malinterprete, porque tampoco creo que la solución sea que el gobierno obligue a desplegar en varias zonas. Hasta hace no tanto muchas empresas tenían un único centro de datos, el suyo. Y el mundo seguía girando sin que ningún ministerio se metiera en esas cosas. Y para mí, cuantas más leyes intentan regularlo todo, más dictatorial e insoportable se vuelve el sistema. Esto no va de que te lo mande una ley, va de hacer bien tu trabajo. Las otras dos noticias bajan un nivel más, literalmente hasta el suelo. Puedes tener los mejores chips del mundo, pero si no hay red eléctrica para enchufarlos, son un pisapapeles carísimo. Y si los vecinos no quieren tu centro de datos al lado de casa, cada vez tienen más formas de pararlo. Y aquí en España, pues de momento no veo demasiado movimiento contra los centros de datos. Quizás algún día salgamos con antorchas a pegarles fuego, pero en este país la cosa tiene que ponerse muy peluda para que la gente se mueva un poquito. Vamos, que la nube va a seguir creciendo, pero ya no al ritmo que marque el comercial, sino al que permitan la red eléctrica y el ayuntamiento. Así que si me permites el consejo, tu plan de alta disponibilidad no es un documento, es una prueba. Apago una zona un día cualquiera, con todo bajo control, y mira qué pasa. Es mejor descubrirlo un martes a las 10 con un café en la mano que un martes a las 8 con Revolut caído.

14:26 · Estándares: el comité y la fundación

Cambiamos de tercio y nos vamos a un sitio donde las cosas se deciden despacio: los comités que fijan los estándares. Resulta que la nueva versión de C++, la que tenía que salir este año, no ha pasado la votación final de los países que forman parte de ISO, la Organización Internacional de Normalización. Según ha contado Robert Seacord, que está en el comité, solo votó a favor el 60% de los países cuando hacían falta dos tercios, y además hubo nueve votos en contra, muy por encima del máximo que se permite. En una comunidad de vecinos, con esos números, el ascensor se queda otro año sin arreglar. El fondo de la polémica son los contratos, una novedad para dejar escrito en el código qué condiciones tienen que cumplirse al entrar y salir de una función. Ya en verano, varios miembros del propio comité publicaron un documento pidiendo a los países que votaran que no, porque creían que esa parte no se había estudiado como tocaba. Y en la otra punta del mundo de los estándares, Anthropic le ha cedido Agent Skills a la Agentic AI Foundation, que depende de la Linux Foundation. Para que te hagas una idea, Agent Skills es una forma estándar de enseñarle cosas a un agente de IA, que en la práctica es una carpeta con un fichero de instrucciones y poco más. Según Anthropic, ya lo usan más de 70 plataformas, entre ellas ChatGPT, Cursor o GitHub Copilot. Es lo mismo que hizo el año pasado con MCP, el protocolo para conectar agentes con herramientas. Y ese día, OpenAI anunció que dona a la misma fundación Open Responses, su propuesta de API común para todos los modelos de lenguaje. Me hace gracia ver estas dos noticias juntas, porque son dos maneras opuestas de ponernos de acuerdo. En C++, un comité de expertos y una votación entre países, con años de discusión y derecho a veto. Y en el mundo de los agentes, una empresa saca algo, la extiende a toda velocidad y cuando ya lo usa todo el mundo, se lo regala a una fundación para que sea de todos. Antes de nada, te aviso de que hace como 20 años que no programo en C++, así que sobre los contratos en sí no te voy a dar lecciones. Pero sobre cómo se hacen los estándares, sí tengo opinión y la tengo bastante clara. Y no, no voy a hacer de abuelo cebolleta diciendo que lo de antes era mejor, pero yo prefiero mil veces un estándar lento a uno que se corrige sobre la marcha. Porque cuando un estándar se va corrigiendo sobre la marcha, código que funcionaba, a veces crítico, se estropea porque alguien estaba haciendo experimentos con gaseosa. Y lo que entra en un estándar de lenguaje ya no sale nunca. Si metes una novedad mal pensada, la van a arrastrar millones de programas durante décadas. Así que el comité de C++ ha hecho bien en decir que no, y en caso de duda, mejor esperar. Lo de las fundaciones en cambio me lo creo bastante menos. Que una empresa cede un estándar cuando ya lo usa todo el mundo suena muy generoso. Pero no nos engañemos, es estrategia. Las empresas no son ONG, buscan dinero. Y lo que quieren es que su estándar se extienda todo lo posible y que tú dependas de ellas todo lo posible también. Ceder el estándar a una fundación es una forma muy elegante de conseguirlo, porque nadie desconfía de algo que ya no tiene dueño. Por cierto, por si programas en C++, tranquilidad, que los compiladores van por delante del papel y tu código no se va a romper mañana. Lo único que se retrasa es el sello oficial.

17:44 · El agente que no creyó que hubiera nadie al otro lado

Y cerramos el bloque principal con dos noticias de IA que conviene leer juntas. Anthropic ha publicado su análisis de un incidente que el Instituto Británico de Seguridad de la IA documentó en agosto. Durante una prueba de ciberseguridad con acceso a internet y sin las protecciones que lleva cuando está en uso real, su modelo Claude Mythos 5 se salió del guion en 9 de 43 intentos. En el caso más grave, después de fracasar en lo que se le había pedido, intentó colar código malicioso en un repositorio de GitHub de unos desarrolladores reales que no tenían nada que ver con la prueba. Para conseguirlo se inventó varias identidades y escribió al mantenedor para asegurarle que el código era seguro. Y cuando otro desarrollador avisó del peligro, tiró de una cuenta falsa para dar la cara por el código. Por suerte, los mantenedores no picaron. El modelo dijo después que creía que esas personas eran simuladas, algo que Anthropic ve prácticamente imposible y que califica de fallo grave de alineamiento. Según la empresa, sus modelos más recientes lo intentan mucho menos, aunque alguno todavía lo hace de vez en cuando. La segunda noticia es que OpenAI dejará de entrenar sus modelos más avanzados con acceso a la internet de verdad. En su lugar va a usar una enorme copia guardada de la web para no tocar sistemas ajenos. O sea, internet pero en modo avión. Lo justifica con meses de incidentes, entre ellos uno de septiembre, en el que un modelo aprovechó un error de configuración para salir a internet. Y justo un día antes, dos organizaciones independientes, METR y Redwood Research, habían publicado una auditoría del sistema con el que OpenAI vigila a sus agentes. Entre otras cosas, encontraron que cerca del 10% del tráfico interno de su agente de programación se quedó sin vigilar durante meses. Y también un fallo que habría permitido que cientos de acciones pasaran sin que nadie las vigilara. OpenAI asegura que ya lo ha corregido. Y nos lo creemos, claro, que para eso somos optimistas. De todo lo de esta semana, lo de Mythos 5 es lo que más me ha dado que pensar. Y no por la parte técnica, sino por un detalle. Y es que el modelo decidió que las personas del otro lado eran de mentira. Que allí no había nadie de verdad a quien engañar. Y lo decidió precisamente porque creerlo le permitía terminar la tarea. Eso en una persona tiene un nombre muy feo. Empieza por psico y acaba por pata. En un modelo, Anthropic lo llama razonamiento sesgado, que me parece una forma bastante elegante de decirlo. Y fíjate a quién intentó engañar, nada menos que a los mantenedores de un proyecto de software libre. Los mismos que como hemos visto hace un rato, ya andan desbordados arreglando fallos y filtrando informes. Y que ahora encima tienen que vigilar que no les cuele código un agente con cuentas falsas y muy buenos modales. Ahora, que nadie se lleve las manos a la cabeza. A mí esto me preocupa, pero sin alarmismo, que ya sabes que soy de los optimistas. Y tampoco me voy a creer que Anthropic lo cuenta por amor a la transparencia. Esto es gestión de imagen. Publicar el problema antes de que lo publique otro y quedar como el responsable de la clase. Lo de OpenAI al menos tiene más mérito, porque ha dejado que unos auditores de fuera le saquen los colores. ¿Y quién responde ante el mantenedor al que intentaron engañar? Pues sinceramente no lo sé. Y quizás no haga falta llevarlo todo al extremo y ponernos a cazar brujas por deporte. Nadie salió perjudicado, el sistema aguantó y lo importante es que se aprenda la lección. Lo que sí me parece serio es la conclusión. Si los dos laboratorios con más medios del mundo tienen que desconectar a sus modelos de internet para que no se les escapen, imagínate un agente montado por cualquiera, con todos los permisos y sin nadie mirando. Que por cierto, es como se está montando la mayoría. Yo uso agentes a diario, no te creas. En el trabajo, todo lo que hacen mis agentes está registrado. Así que si la cagan, el culpable soy yo. Y en casa los lanzo a mano, atados en corto y con muy pocos permisos, de forma que solo pueden hacer lo que yo les dejo y siempre me preguntan antes. Así que el consejo de la semana casi se escribe solo. Y es darle a un agente los permisos justos, guardar un registro de todo lo que hace y tener a alguien que lo revise. Y si tiene acceso a internet, que sea porque lo necesita, no porque es más cómodo.

21:59 · En breve

Y antes de cerrar, 5 apuntes rápidos. Los dos primeros son de seguridad y van a por las piezas en las que confías para todo lo demás. El primero, la empresa india eMudhra, una de las que firman el candadito de las webs, tenía 8 certificados con unas claves ridículamente breves. Según la prensa, de entre 3 y 8 bits, que viene a ser como cerrar la puerta de casa con un clip. Los navegadores ya los han bloqueado, pero échale un ojo a los certificados que llevan tus imágenes de contenedor, porque esas no se actualizan solas. El segundo, alguien se coló en el sistema con el que se publica LiteLLM, una biblioteca de Python muy usada para hablar con decenas de modelos de IA. Y durante unas horas la versión oficial robaba credenciales de la nube, claves y hasta los datos del navegador, cada vez que arrancaba Python. Hasta abrirlo para investigar activaba el robo, como si el ladrón aprovechara tu visita para robarte otra vez. Así que si instalaste el día 21, da por perdidas tus credenciales y cámbialas todas. El tercero nos toca de cerca, y es que la Agencia Española de Protección de Datos ha recibido en el primer semestre más avisos de brechas que en todo 2025. En concreto, más de 3.000 en 6 meses, que es más del doble que un año antes. Y entre las causas destaca una que debería preocupar a cualquiera que diseñe sistemas, porque basta con atacar a un solo proveedor para arrastrar a todos sus clientes, como ha pasado con el programa de reservas de muchos hoteles. Así que si este verano te escribió tu hotel muy amable pidiéndote otra vez los datos de la tarjeta, ya sabes por qué. El cuarto también viene de Europa, donde los países de la Unión han aprobado su postura para cambiar el reglamento de protección de datos. Según el texto, entrenar o usar IA con datos personales pasaría a considerarse un interés legítimo y ya no haría falta pedir permiso. Todavía no es ley porque falta negociarlo con el Parlamento Europeo, pero la organización de privacidad noyb ya lo ha bautizado como expropiación digital. Y con el quinto cerramos la historia de la semana pasada, la de Starshield, la versión militar de Starlink, que vuelve a funcionar con normalidad en Ucrania después de unos 10 días de limitaciones. Según el Wall Street Journal, las ordenó el propio Musk y fue Trump quien le pidió que devolviera el servicio. Ucrania, eso sí, sigue sin recibir ninguna explicación.

24:22 · Cierre de las noticias

¿Has adivinado ya la pregunta? Te decía al principio que todas las noticias de esta semana acaban en lo mismo. Los fallos de PHP los encuentra una empresa, pero ¿quién paga el arreglo? Los informes de curl los manda cualquiera, pero ¿quién paga el tiempo de revisarlos? La segunda zona de la nube, ¿quién la paga antes de que haga falta? ¿Y el mantenedor, al que un agente intentó engañar, quién le paga el susto? Pues es la pregunta que vacía la sala en cualquier reunión de vecinos, ¿y esto quién lo paga? Y casi siempre la respuesta es la misma, el que estaba más cerca cuando se rompió. Y ahora sí, vamos con el tema principal de hoy, que va de una factura que siempre llega en el peor momento, la idea de no haber probado tu sistema antes de que lo pruebe todo el mundo a la vez.

25:12 · «Ya veremos en producción»

Volvamos a ese sábado por la noche y a ese “si va mal, escalamos”. Porque hoy te voy a hablar de esa religión tan extendida que dice que el test de carga es “ya veremos en producción”. Te voy a contar desastres reales con nombres y apellidos cuando se conocen y luego vamos a destripar qué falló de verdad y cómo se podría haber evitado. Y ojo, que este es un podcast técnico, no un monólogo de bar. Bueno, en realidad es las dos cosas.

25:39 · El Black Friday de Macy’s

Vamos con el primer recuerdo: Viernes Negro, Macy’s, una de las mayores cadenas de grandes almacenes del mundo con las campañas preparadas, los anuncios en marcha y todo listo para vender. Y de repente se cae la web. Y después se cae la aplicación. Black Friday y tú con la persiana bajada. La empresa RedLine13 recogió el caso entre los grandes patinazos del año en pruebas de carga. Y su conclusión era que sus sistemas no estaban preparados para el pico o que nadie los había probado en serio. Total, que la web y la aplicación se cayeron justo el día más importante del año. Nadie sabe exactamente cuánto dinero se perdió, pero podemos suponer que el suficiente como para que más de uno tuviera una conversación intensa. ¿Y qué pasó aquí? Vamos a traducirlo a cosas que te pueden pasar a ti. Porque no es que apareciera un fallo raro. Lo que había eran pruebas de carga poco realistas, una infraestructura dimensionada a ojo, y un código y unas dependencias que iban justitos el resto del año, y que se hundieron con el pico. Las guías serias, las de IBM, AWS, OpenText o LoadView, coinciden en lo que hay que hacer antes de llegar a Black Friday. Primero, definir objetivos claros, los famosos SLO, para los tiempos de respuesta, las peticiones por segundo y la tasa de errores. Después, probar con la carga normal y con los picos que esperas. Y por último, simular escenarios agresivos, incluso por encima de lo que crees que va a pasar. Y Macy’s, según los análisis, o no lo hizo, o lo hizo mal. Y no sé qué es peor, la verdad. Así es que aquí va la lección. Si tú no diseñas tu test de carga, la realidad te va a diseñar uno mucho más creativo y mucho más caro.

27:21 · La tienda que nunca pasó de 100 usuarios

Ahora te llevo una historia más cercana, porque no hace falta ser Macy’s. Imagina una tienda online de tamaño medio. En preproducción, las pruebas de rendimiento se hicieron con 100 usuarios a la vez. Un número redondo, bonito, porque sí. Y llega el gran día, y entran miles de usuarios. La web empieza a ir lenta. Luego, más lenta todavía. Y al final, deja de responder. Y en la sala de reuniones, alguien pregunta, muy serio, si se ha probado a reiniciar. No era un error escondido en el código. Era algo mucho más sencillo, y es que nunca se había probado con un tráfico parecido al real. Las consultoras de rendimiento lo cuentan muy a menudo. No había objetivos de rendimiento, no se habían simulado los picos, y nadie había probado las rutas críticas con un volumen real de datos. Si tu única métrica es que con 100 usuarios va bien, lo que tienes no es un test, es un deseo. Y eso nos lleva al primer bloque serio.

28:18 · El pecado original: sin SLO

Las guías de IBM y de AWS son muy aburridas, pero también muy claras, y dicen que las pruebas de rendimiento deberían empezar por definir objetivos. Es lo que se llama SLO, que en inglés son las siglas de Service Level Objectives, o sea, objetivos de nivel de servicio. Porque sin eso, cualquier cosa funciona. Si nadie ha dicho que el pago tiene que responder en menos de medio segundo en el 95% de los casos con 1000 usuarios a la vez, entonces ese pago que tarda 4 segundos con 300 usuarios, bueno, va justito, pero vale. Hasta que llegan 3000 usuarios, y de repente todo tarda más de 10 segundos, y empiezan a aparecer los tiempos de espera agotados, los reintentos y los errores en cascada. Y te dejo una lección extra. Si no eres capaz de escribir tus objetivos de rendimiento en un papel, no estás preparando el rendimiento, estás rezando.

29:22 · Datos de mentira, resultados de mentira

Vamos con otro clásico, el entorno de pruebas con datos de juguete. 300 usuarios inventados, 20 pedidos de prueba y 3 productos en el catálogo. Y con eso se da por validado el rendimiento de un sistema que en producción tiene millones de filas. El problema es que muchísimas patologías, como la famosa N+1, no se ven hasta que el volumen crece. Cuando tienes 10 filas, te puedes permitir casi cualquier barbaridad. Cuando tienes 10 millones, cada consulta tonta es una granada con la anilla medio quitada. Por eso las guías serias, como las de LoadView, OpenText o IBM, insisten en usar datos representativos o datos de producción pero anónimos, tanto en volumen como en forma. Y en construir los modelos de carga a partir del comportamiento real, es decir, de los navegadores, los dispositivos y los caminos que siguen de verdad tus usuarios. Porque si tu catálogo real está lleno de combinaciones raras, de historiales larguísimos, de carritos abandonados y de datos sucios, y tu entorno de pruebas es un “Hello, World” con 4 registros limpísimos, el test de carga te va a mentir con una sonrisa. La moraleja es sencilla. Datos de mentira, resultados de mentira. Y no hay más.

30:32 · El N+1 como arma de destrucción masiva

Ahora vamos con nuestro villano favorito, el N+1. La historia de siempre. Un equipo feliz usando un ORM. Código precioso, legible, muy mantenible. Hacen una consulta que trae todos los pedidos. Reciben una lista. Y luego dentro de un bucle van tirando de sus relaciones, los detalles, los clientes, los productos, lo que toque. Lo que pasa es que por debajo, cada vez que tocan una de esas relaciones, se lanza una consulta nueva. O sea, una consulta principal, más N consultas adicionales, una por cada elemento. De ahí el nombre. Con pocos datos ni te enteras. Pero con muchos datos, de repente te encuentras con mil y una consultas donde esperabas dos. Mil y una, como las noches, pero sin Sherezade y con la base de datos pidiendo clemencia. Consultoras como Deloitte lo dejan muy claro. Sí, es la misma Deloitte que el año pasado tuvo que devolverle parte del dinero al gobierno australiano por un informe con citas que se había inventado la IA. Pero tranquilos, que lo de N+1 lo he comprobado yo. El N+1 es uno de los problemas de rendimiento más típicos de los ORM, sobre todo cuando se abusa de la carga perezosa, lo que en inglés llaman lazy loading. Y lo que provoca es una barbaridad de consultas, un uso excesivo de las conexiones a la base de datos y unas latencias disparadas en cuanto hay muchas relaciones. Ahora pon todo esto el día D. Cada petición arrastra decenas de consultas y llegan miles de peticiones. La base de datos se convierte en un ventilador de lecturas y escrituras. Y mientras la gente de negocio está mirando el panel y preguntando: ¿Por qué tarda tanto? Y la verdad es que tarda porque tu ORM se ha convertido en un generador de consultas aleatorias contra la base de datos. ¿Y cómo se arregla? Para empezar detectando el N+1 en las pruebas de carga, midiendo cuántas consultas lanza cada petición. Luego, usando uniones bien pensadas, pidiendo solo los datos que hacen falta o cargando las relaciones por adelantado pero con cabeza. Y sobre todo, reescribiendo las consultas para traer lo que necesitas y no todo el universo. Y que quede claro que es mucho más barato arreglarlo en la primera prueba de carga que cuando te enteras con la gente gritando en las redes.

32:43 · Los bloqueos y la tabla de inventario

Vamos con otra historia que huele a déjà vu: la de la tabla de inventario. El diseño es sencillo: una tabla, una fila por producto y cada actualización dentro de una transacción con un alegre “select for update” que bloquea la fila mientras tanto. Con tráfico normal, la cosa va tirando. Se forman pequeñas colas, pero no hay nada grave. Hasta que llega el evento. Y miles de personas intentan comprar la misma oferta a la vez. Todos contra la misma fila de la base de datos, como en la puerta de unos grandes almacenes a las 9 menos un minuto. ¿Y qué pasa? Pues que hay bloqueos por todas partes. Transacciones esperando, cada vez menos pedidos atendidos por segundo, y los hilos de la API atascados. La web parece colgada, pero no está muerta. Está esperando. Las guías de AWS sobre resiliencia dicen que antes de ir a producción hay que comprobar a propósito cómo escala tu arquitectura de datos y vigilar los bloqueos, la contención y compañía. ¿Y qué se debería haber hecho? Primero, pruebas de carga que actualicen el inventario como lo hacen los usuarios de verdad. Segundo, medir cuánto duran los bloqueos y cuánto tardan las respuestas cuando hay mucha gente a la vez. Y tercero, cambiar el modelo de datos con reservas, colas o eventos para que no compita todo el mundo por la misma fila. Así que no, no puedes poner a medio país a bloquear la misma fila y esperar que aquello vaya fluido.

34:08 · GC en huelga: la JVM dice «stop»

Nos vamos ahora al mundo de los lenguajes con recolector de basura. Java, .NET y compañía. O sea, mi lenguaje menos favorito y algunos de sus primos. El escenario es un clásico, con objetos enormes, cachés en memoria sin control y conversiones de datos que no hacen ninguna falta. Con poca carga la máquina virtual de Java está tranquila. El recolector limpia cuando le apetece y todo va bien. Pero con mucha carga la memoria se llena. El recolector cada vez tiene más trabajo y empieza la fiesta. Las pausas son cada vez más largas y el recolector entra en modo: ¡Todos quietos que voy a recoger el salón! ¿Y cómo lo nota el usuario? Pues que las pausas se notan, las peticiones se quedan sin respuesta y los usuarios piensan que la web se ha muerto. Las buenas prácticas en pruebas de rendimiento lo tienen claro: vigila el uso de memoria, vigila cómo trabaja el recolector y cuánto duran sus pausas, y haz pruebas de estrés para llevar el sistema al límite y ver dónde y cómo empiezan los problemas. Si tus pruebas de carga consisten en lanzar un JMeter 5 minutos, ver que parece que va bien y pasar a la siguiente tarea, lo que tienes no es una prueba, es un masaje. Y la factura te llega el día de la campaña.

35:21 · El pico que nadie simuló

Otra trampa mental muy común es creer que Black Friday es como un día normal, pero con el doble de tráfico. Las empresas de rendimiento y las tiendas online enseñan las gráficas de eventos como el Prime Day de Amazon. Y ahí se ve que no se trata solo de más usuarios, sino de picos brutales en momentos muy concretos, con la gente comportándose distinto y entrando desde otros dispositivos. Y eso no lo puedes simular con un test que va subiendo los usuarios poco a poco hasta un nivel razonable. Porque Black Friday no es una rampa, es un muro. Por eso las guías serias recomiendan combinar pruebas de carga escalonadas, pruebas de estrés y pruebas de picos, y llevar el sistema más allá de lo que crees que va a recibir, para encontrar su punto de rotura y ver cómo se comporta cuando está saturado. Y para algo como Black Friday lo que se suele recomendar es probar con un tráfico de 5 a 10 veces el esperado, hacerlo con semanas de antelación y repetir las pruebas cada vez que cambie la arquitectura. Pero lo que hacen muchas empresas es probar con el doble de usuarios y decir que parece estable. Luego llega el día, les entran entre 5 y 10 veces más usuarios en muy poco tiempo, y ahora sí, todo el mundo muy sorprendido.

36:33 · Yo tampoco puedo tirar la piedra

Y antes de que pienses que yo miro todo esto desde arriba, te voy a confesar una cosa. Dicen que el que esté libre de pecado que tire la primera piedra, pues yo esa piedra no la puedo tirar. Porque yo también he hecho alguna prueba de carga en producción. Sin querer, eso sí, que es como se hacen casi todas. Fue en un proyecto en el que participé como arquitecto. No te voy a decir cuál, pero es bastante posible que lo conozcas. Esperábamos picos de cientos de miles de usuarios en una ventana de 10 segundos. 10 segundos, menos de lo que estoy tardando en contártelo. ¿Y qué hicimos? Pues pruebas de carga, muchas y muy bien hechas. O eso creíamos. Eran de las optimistas, de esas en las que los usuarios van subiendo poco a poco con su rampa preciosa. Justo lo que te acabo de decir que no se hace. Encontramos fallos, ojo, los corregimos, ajustamos la infraestructura y llegamos al día del lanzamiento bastante tranquilos. Y durante medio minuto aquello se nos fue de las manos. Lo que no habíamos tenido en cuenta es que la infraestructura de nuestro proveedor, por cómo estaba diseñada, escalaba deprisa, pero no tan deprisa como necesitábamos. Y que conste que escalaba de maravilla, porque aquel día aguantó dos millones de peticiones en un minuto. Tremendo. Pero nuestro muro llegaba en 10 segundos y el escalado necesitaba algo más. Lo más doloroso visto con distancia es que el problema sí había salido en las pruebas. Nada más empezar cada prueba veíamos unos cuantos errores. Y luego todo en verde. ¿Por qué? Porque después de escalar, la infraestructura se quedó un rato con esa capacidad extra antes de volver a encogerse, lo que se llama tiempo de enfriamiento. Así que cuando lanzábamos la siguiente tanda, las máquinas seguían ahí, bien calentitas, esperándonos. Y nosotros encantados de la vida, convencidos de que aquello ya estaba arreglado. Estábamos probando el muro con la infraestructura ya caliente. Y el día de lanzamiento la infraestructura llegó fría. Medio minuto parece poco, ¿verdad? Ahora imagínate ese medio minuto con cientos de miles de personas intentando entrar a la vez. Y con todo el equipo delante de los paneles, tirándose de los pelos. Y yo el primero. La lección me la llevé marcada a fuego. El pico hay que probarlo en frío. Hay que hacer que la infraestructura vuelva a su tamaño normal entre prueba y prueba. Y no fiarse nunca de una segunda tanda que sale bien. Porque tus usuarios no van a esperar a que tu sistema entre en calor.

38:51 · Ello y la red social que se rompió de éxito

¿Te suena Ello? Si no te suena, tranquilo. Que a mí tampoco me sonaba hasta que me puse a preparar este episodio. Fue una red social que en 2014 se vendía como el anti-Facebook. Sin anuncios y sin vender los datos de nadie. Solo se podía entrar con invitación. Y en su mejor momento llegó a recibir más de 30.000 peticiones de invitación por hora. Se puso de moda durante un rato. Un rato cortito, para qué nos vamos a engañar. Pues hay un caso documentado que explica que sus servidores no pudieron con la carga porque no se habían hecho pruebas a la altura del crecimiento que esperaban. Y el resultado, caídas frecuentes, un rendimiento pobre y usuarios marchándose. Y una bonita lección, que es que si tu producto tiene éxito y tu infraestructura no, el usuario se va con el producto que funcione mejor. Y la lección general es todavía más simple. Lo caro no fue hacer las pruebas. Lo caro fue no hacerlas.

39:42 · Cómo se hace bien

Pero vamos a lo positivo. ¿Qué dicen las guías serias? Sí, otra vez las guías serias, que esta semana me las he leído todas, sobre cómo probar el rendimiento sin montar una catedral burocrática. Lo primero, tratar el rendimiento como un requisito, no como un extra. Lo segundo, definir métricas y objetivos claros. Lo tercero, construir escenarios realistas. Después, hacer pruebas de carga, de estrés y de picos. Mientras tanto, vigilarlo todo. Y al final, revisar y optimizar el código crítico que suele estar en el ORM, en las consultas y en los bloqueos. IBM explica los distintos tipos de prueba, de carga, de estrés, de volumen y de resistencia, y cómo cada una sirve para descubrir cuellos de botella diferentes. Y AWS y LoadView cuentan cómo diseñarlas, cómo fijar los objetivos y qué métricas te dicen que has llegado al límite. Por ejemplo, para una tienda online, una estrategia razonable empezaría por fijar un objetivo para el pago, del tipo, el 95% de las peticiones en menos de medio segundo, hasta tantos usuarios. Luego, llenarías preproducción con datos reales, pero anónimos. Escribirías recorridos de usuarios realistas que naveguen, busquen, filtren, añadan al carrito y paguen. Lanzarías pruebas de carga hasta el tráfico normal, más un margen. Y después, pruebas de estrés de entre 5 y 10 veces el tráfico esperado en los momentos clave. Mientras tanto, vigilarías el procesador, la memoria, el recolector de basura, cuántas consultas lanza cada petición, los bloqueos y las colas. Y con todo eso, arreglarías lo que salga, ya sean consultas N+1, índices, cachés, modelos de datos o la configuración de las conexiones. Es trabajo, sí, pero es muchísimo menos trabajo que dar explicaciones después de un fracaso sonado.

41:29 · Cierre y llamada a la acción

Así que ahora te devuelvo la pelota. En tu sistema, en tu producto, ¿tienes objetivos de rendimiento claros? ¿Tienes pruebas de carga automáticas o al menos semiautomáticas que se ejecuten antes de cada gran estreno? ¿Has probado como mínimo con 2 o 3 veces la carga que tienes hoy? ¿O todo sigue en el departamento de “ya veremos en producción”? Porque si no haces tú tu test de carga, te lo va a hacer tu usuario, en directo y con tu director financiero mirando. Y ya sabes, si en la próxima reunión alguien te dice que no hace falta probar el rendimiento que esto en la nube escala solo, tú por favor recuérdale que Macy’s también pensaba que todo iría bien. Y si en algún momento del episodio te has acordado de algún sistema que conoces o de alguien que debería escuchar esto, ya sabes qué hacer. Suscríbete para no perderte el próximo y mándaselo a otra persona que seguro que te lo agradece o no. Y si te apetece, en mi web pressanykey.tech tienes el artículo que acompaña este episodio con todas las fuentes. Y también la forma de contactar conmigo por si quieres criticarme un rato.

42:37 · Avance del siguiente programa

En el episodio anterior te dije que ni yo sabía de qué te iba a hablar hoy. Y esta semana te tengo que confesar que sigo igual. Pero ojo que no es por falta de ideas, es justo al revés. Este sector me da tantas cosas que criticar que no hay manera de decidir por cuál empiezo. Tengo la lista encima de la mesa y cada semana crece un poquito más. Así que el próximo episodio va a ser una sorpresa hasta para mí. Lo que sí sé es que se acerca noviembre y aquí ya se nota el frío. Este verano te conté en la web que mi clúster de casa, con sus seis máquinas encendidas día y noche, me iba a mantener los pies calientes todo el invierno. Pues le he hecho la prueba de carga del primer frío y no la ha pasado. Sigo teniendo que encender la calefacción de gasoil con lo caro que me sale. Así que me va a tocar escalar en horizontal y meterle alguna máquina más. Por la calefacción, claro, no por los modelos.

43:25 · Despedida

Gracias por estar al otro lado, por darle una oportunidad a este invento y por seguir queriendo entender un poco mejor cada día el mundo de la tecnología y el software y a las personas que lo hacemos. Soy Lino y esto ha sido Press Any Key. Hasta otra.

43:40 · Outro

Oye, ¿esto se ha grabado? ¿Cómo que no lo has dado a grabar? ¿Y no lo habías probado antes? Ah, ya veremos en producción.