En el desenvolupament de programari, els errors silenciosos són els més perillosos. Aquells que no generen una excepció, no llancen un codi d'error i no trenquen l'execució, sinó que simplement falsegen la sortida. El cas d'un rastrejador de posicionament web que durant setmanes va mostrar dades incorrectes a tots els seus usuaris és un exemple perfecte de com un canvi aparentment menor en una API upstream pot provocar una catàstrofe operativa sense que ningú ho noti. I el pitjor és que aquest tipus de fallades no només afecten eines de SEO, sinó qualsevol sistema que depengui de tercers per obtenir dades crítiques.
El problema va començar quan Google, sense previ avís, va eliminar el suport per al paràmetre num=100 en els seus resultats de recerca. Durant anys, les APIs de SERP (pàgines de resultats de motors de recerca) acceptaven aquest paràmetre per retornar fins a 100 resultats orgànics per consulta. Però, en algun moment, el motor va deixar de respectar-lo. Les APIs construïdes sobre aquests serveis, en rebre la petició amb num=100, simplement retornaven un conjunt reduït de resultats – normalment entre 9 i 10 – sense llançar cap error. El codi, en veure que la resposta era un èxit (codi 200) i que contenia una llista, continuava la seva lògica com si tot estigués bé. El resultat: per a paraules clau que realment estaven en les posicions 11 a 100, el sistema registrava 'no està en el top 100'. I així, durant setmanes, els dashboards s'actualitzaven, els correus d'alerta no es disparaven i cap usuari –ni tan sols els fundadors– es donava compte de la mentida.
La lliçó tècnica aquí va més enllà de les APIs de recerca. Qualsevol integració que assumeixi que un paràmetre continuarà sent respectat per sempre corre el mateix risc. Les plataformes grans com Google, AWS o Azure actualitzen els seus APIs constantment; de vegades de forma documentada, de vegades de forma silenciosa. Per això, en Q2BSTUDIO, quan desenvolupem aplicacions a mida per als nostres clients, un dels principis fonamentals és no confiar cegament en cap font externa. Implementem comprovacions creuades, alarmes d'incoherència i, sobretot, sistemes que verifiquen la fiabilitat de les dades rebudes abans d'usar-les per prendre decisions de negoci.
L'equip darrere del rastrejador va haver de redissenyar la lògica de paginació. Al principi, van assumir que si una pàgina retornava menys de 10 resultats, era perquè no n'hi havia més. Error. En els resultats de recerca actuals, la presència de snippets destacats, panells de coneixement, anuncis i altres elements d' interfície fan que la primera pàgina pugui retornar només 9 orgànics. El senyal real de fi no és una pàgina curta, sinó una pàgina completament buida. Això va obligar a implementar una paginació que iterara fins a obtenir una pàgina sense resultats, i a més ajustar les posicions absolutes: la pàgina 2 no retorna posicions 11-20, sinó que torna a començar en 1. Sense aquest càlcul, les dades continuarien sent incorrectes.
Però el cost era un altre problema. Verificar que una paraula clau NO està en el top 100 requereix escanejar les 100 posicions, mentre que una que està en el top 5 es resol amb una sola petició. Les paraules clau no trobades es converteixen en les més cares, i els nous usuaris solen afegir-ne moltes. La solució va ser implementar una profunditat adaptativa: si una paraula clau ja va ser avaluada i no estava en el top 100, la següent verificació només escaneja les primeres 30 posicions, i un cop al mes es fa una escombrada completa per detectar escalades tardanes. Aquesta estratègia va reduir el cost d'API a la meitat sense alterar la promesa del producte.
L'interessant d'aquest cas és que la decisió no estava en la lògica interna del programari a mesura que havien desenvolupat, sinó en una suposició sobre el comportament d'un servei extern. Això passa sovint en projectes que integren serveis cloud aws i azure, o qualsevol altra infraestructura com a servei. La solució a llarg termini no és només arreglar el codi, sinó incorporar una cultura de monitoratge basada en fonts independents. Per exemple, comparar les dades del rastrejador amb les de Google Search Console, o fer servir una segona API de recolzament per validar les mètriques.
En el món empresarial actual, on les decisions es prenen sobre la base de dades automatitzades, un error silenciós d'aquest tipus pot tenir conseqüències milionàries. Imagina una empresa que fa servir intel·ligència artificial per predir la demanda, i el model s'entrena amb dades de posicionament web incorrectes. O un sistema de serveis intel·ligència de negoci que alimenta un Power BI amb xifres irreals. La confiança en les dades és el pilar de qualsevol estratègia de dades. Per això, en Q2BSTUDIO oferim serveis cloud aws i azure que inclouen capes de validació de dades i alarmes proactives, evitant que aquestes fallades passin desapercebudes.
Un altre aspecte que sovint es passa per alt és la necessitat de comptar amb ia per a empreses que no només automatitzi processos, sinó que també pugui detectar anomalies. Els agents IA especialitzats en monitoratge poden comparar fonts, calcular desviacions i notificar quan un indicador se surt de l'esperat. En el cas del rastrejador, una vegada que es va implementar l'alerta d'execució fallida, el sistema va començar a enviar correus automàtics si l'API no responia correctament o si els resultats diferien d'una font de referència. Aquest simple afegit va convertir un producte que mentia en silenci en un que avisava de les seves pròpies limitacions.
La ciberseguretat també juga un paper aquí, encara que no sigui evident. Quan una API externa canvia el seu comportament, pot ser un vector d'atac si el sistema no està preparat. Un actor malintencionat podria manipular les dades retornades per enganyar els algoritmes de decisió. Tenir mecanismes de verificació, com un segon instrument de mesurament, és també una pràctica de seguretat bàsica. En Q2BSTUDIO integrem protocols de validació en tots els nostres desenvolupaments, tant en solucions de programari a mida com en infraestructures cloud, per garantir que les dades siguin fiables i segures.
L'epíleg d'aquesta història és revelador: quan el fix es va desplegar, les alertes van començar a disparar-se per primera vegada de veritat. Un usuari va rebre un correu informant-lo que la seva paraula clau principal havia pujat al lloc #2. Aquest correu era el producte fent exactament el que prometia. Però sense la validació creuada, aquest usuari hauria seguit creient que la seva pàgina estava fora del top 100, perdent oportunitats de negoci durant setmanes. La moraleja per a qualsevol empresa que desenvolupi tecnologia: mai dones per assegut que una API va a comportar-se com esperes. Sempre has de tenir un pla B, un segon sensor i una alarma que soni quan els dos sensors no hi estiguin d'acord.
Si la teva organització està construint sistemes que depenen de dades externes –ja sigui per a analítica web, automatització de processos, serveis intel·ligència de negoci o power bi–, et convidem a revisar els teus pipelins amb ulls crítics. Tens una font alternativa per validar els resultats? Els teus dashboards t'estarien mentint sense que ho sabéssís? En Q2BSTUDIO ajudem empreses a dissenyar arquitectures robustes, amb redundància de dades, alarmes intel·ligents i processos de verificació contínua. Perquè un error silenciós no perdona, però una bona enginyeria pot detectar-lo abans que causi dany.
