Imagini una caixa de medicaments que travessa tres camions, dos magatzems, un dipòsit regional i finalment arriba a la nevera d'una clínica. En algun punt del trajecte, la temperatura supera els 8°C durant quaranta minuts: potser en un moll de càrrega en ple juliol, mentre algú signa un albarà, o perquè un compressor va fallar durant la nit i ningú ho va notar. Quan el producte arriba, l' etiqueta es veu bé, el codi de barres s' escaneja i el sistema el registra com a disponible. La infermera extreu la dosi, però el medicament ja està deteriorat. Poden passar hores abans que algú el descobreixi, si és que algú el descobreix. Aquesta escena no és un cas aïllat. L'Organització Mundial de la Salut estima que fins a la meitat de les vacunes del món es desperten cada any, i els problemes en la cadena de fred són una de les causes principals. Alguns estudis indiquen que aproximadament una quarta part de les dosis ja arriben degradades, i la indústria perd desenes de milers de milions de dòlars anuals per això. La resposta habitual és comprar contenidors millors, aïllament més gruixut o un congelador intel·ligent amb una aplicació. Però aquesta reacció passa per alt el veritable problema. La cadena de fred no falla perquè la refrigeració sigui difícil. Falla com fallen els sistemes distribuïts.
Si alguna vegada ha estat responsable d'un sistema d'aquest tipus, la història anterior probablement li resulti incòmodament familiar. Una cadena de subministrament és un sistema distribuït, però amb encara menys visibilitat. Deixem les caixes de costat un moment i observem l'estructura. Cada part —la planta de producció, els dipòsits, els camions, les neveres i els consultoris— actua com un node independent amb la seva pròpia informació local. Es comuniquen a través d' una xarxa poc fiable amb retards impredictibles i sense un rellotge compartit. Ningú té la visió completa. Les actualitzacions es mouen lentament d'un lloc a un altre, si és que arriben, i qualsevol node pot fallar mentre continua reportant que tot està bé. Això no és només una metàfora. Aquesta descripció és la definició d' un sistema distribuït, només que amb diferent terminologia. Quan es mira així, el llenguatge que fem servir en el programari encaixa sorprenentment bé amb el món físic. Un prestacle buit és com una lectura obsoleta. Un medicament deteriorat que encara s'escaneja com a bo és com un node que passa la seva comprovació de salut mentre està realment corrupte. La confusió entre els registres de compres i l'inventari de la farmàcia és com dues rèpliques que no coincideixen. Quan el model de pronòstic dona mals resultats, és perquè està preguntant a un sistema que no pot proporcionar una resposta fiable. Res d'això és nou. Només que tendim a pensar en aquests problemes quan el que es mou és un payload JSON, no una caixa d'insulina.
El problema de les tres realitats és en el fons un problema de consistència. Si dedica un dia a mapejar com un hospital rastreja un sol article, veurà que té tres identitats separades. Compres ho veu com un cas amb una unitat de compra. L'historial clínic electrònic el veu com un article clínic, de la manera com una infermera ho sol·licitaria. Facturació ho veu com un codi d'assegurança. No són visions diferents d'un sol registre; són tres còpies separades, cadascuna feta per a una audiència diferent i cadascuna convençuda de ser correcta. En poques paraules, les seves dades estan repartides entre sistemes sense un identificador compartit ni res que els connecti. No és d'estranyar que es desviïn. Escriure'l en codi deixa el problema evident: el sistema de compres retorna un número, el sistema clínic en retorna un altre i el sistema de facturació no sap res. Mentrestant, l'article físic a l'estant és zero. Tots els sistemes reporten el que creuen que és veritat, però l'estant segueix buit. No es pot resoldre això només amb models. Si se li dona el problema a un optimitzador o a un agent d'intel·ligència artificial i se li demana que mogui inventari, no se li està donant un desafiament difícil. Se li està donant un d'impossible, perquè no hi ha res a conciliar a sota. El sistema donarà una resposta amb confiança, perquè això és el que fan aquestes eines. Però la confiança construïda sobre dades dolents no és intel·ligència. És simplement equivocar-se més ràpid. La solució no és la intel·ligència artificial. És el treball bàsic que rara vegada rep atenció: donar a cada objecte físic una identitat única, assegurar-se que cada sistema s' hi refereixi i executar un procés en segon pla que verifiqui les discrepàncies i alerti quan s' esdevinguin. No és glamurós, però és essencial.
La base de dades d' inventari no és una imatge en temps real del que hi ha a l' prestant. És una caixet del que hi havia l'última vegada que algú la va actualitzar. Les caixetes poden quedar obsoletes silenciosament, i una caixeta desactualitzada pot retornar la mateixa resposta que una fresca. La consulta es veu igual, però la realitat pot haver canviat sense que vostè ho sàpiga. Qualsevol que hagi treballat amb sistemes distribuïts coneix bé aquesta compensació. No es pot tenir consistència, disponibilitat i tolerància a particions alhora. Cal triar i viure amb les conseqüències. Les cadenes de subministrament també fan aquesta elecció, sovint sense adonar-se'n, i gairebé sempre trien la disponibilitat. Quan pregunta pels nivells d'estoc, sempre obté un número, però ningú garanteix que sigui correcte. Així s'acaba amb un sistema que només és eventualment consistent, encara que sembli sòlid. En el programari, la consistència eventual significa que les còpies acaben coincidint si s'espera prou. En el món físic, això no passa. Si una nevera falla i no es desencadena cap esdeveniment, el sistema mai s'assabenta. Res s'actualitza perquè no arriba cap missatge. La veritat simplement roman a l'estany, inadvertida, fins que algú la comprova. No es pot arreglar el que no s'observa. Aquest és el veritable problema subjacent: l'observabilitat. Ningú dirigiria un servei de producció com dirigim una cadena de fred i esperaria conservar la seva ocupació. Imagini enviar alguna cosa sense registres, mètriques, traces ni comprovacions de salut, on el primer signe de problema és un client que arriba hores després per reportar una fallada. En el programari, això li costaria el lloc. En la logística sensible a la temperatura, és un altre dia més. El problema només apareix quan algú fa servir el producte, molt després que algú pogués haver-ho solucionat.
Per això els sensors IoT importen més del que semblen. Una sonda que transmet dades de temperatura des de l'interior d'un enviament no és només una millora de maquinari. És telemetria. És com afegir monitoratge al seu codi: converteix una caixa negra que només informa al final en una cosa que proporciona una transmissió en viu que es pot veure i sobre la qual es poden configurar alarmes. Però la telemetria per si sola no n'hi ha prou. Si té lectures sense llindars, alertes ni ningú responsable de respondre, és només un registre car que ningú revisa. L'observabilitat no és només el sensor. És el sensor, l'objectiu de nivell de servei (SLO), l'alerta i el runbook treballant junts. Mesurar la temperatura mai va ser la part difícil. El veritable desafiament és decidir per endavant què compta com a problema i a qui notificar quan passi. Si això és realment un sistema distribuït, el manual adequat ja existeix, i no és la gestió de la cadena de subministrament. És l'enginyeria de fiabilitat de llocs (SRE). La majoria dels mateixos principis s' apliquen: triar una única font de veritat i protegir-la, donar a cada objecte físic una identitat única, assegurar-se que tot ho referenciï i establir un procés de conciliació que tracti les discrepàncies com a incidents, no com a errors d' entrada de dades. Monitoritzar tot el trajecte, no només els punts d' inici i fi. Una bona lectura a la planta i una altra a la farmàcia no diuen res sobre els quaranta minuts problemàtics intermedis. El rastreig importa perquè les fallades més interessants ocorren entre els nodes. Usar event sourcing: registrar el trajecte com un registre de només afegiment (enviat, escanejat, desviació, quarantena) en lloc d'un camp d'estat únic que se sobrescriu. En reproduir el registre, es pot veure exactament per què l'estant va acabar buit. Redactar SLO per al món real: per exemple, el percentatge de dosis que sempre es van mantenir entre 2 i 8 °C és un objectiu de nivell de servei vàlid. Tractar qualsevol incompliment com un excés de pressupost d' error: disparar una alerta al responsable, no només una nota per al proper informe trimestral. Dissenyar per a la partició, perquè la partició és l' estat per defecte. El camió perd senyal. La clínica es desconnecta. Emmagatzemar localment, sincronitzar quan torni la connexió i mai llegir silenci com una bona notícia.
Res d'això és revolucionari. És el treball bàsic i fiable que manté el programari en funcionament, però aquí s'aplica a un sistema on el que està en joc és la salut d'algú, no només una visita a un lloc web. Un prestacle buit és una comprovació de salut fallida. Tornem a la infermera i la dosi malmesa. El pronòstic no era incorrecte, i la base de dades no mentia. Només va repetir l'última informació que va rebre. Res va fallar dins de cap sistema individual. La decisió va ocórrer en els buits: sense identificador compartit, sense telemetria en viu, sense res a conciliar les dades i sense cap comprovació que indiqués si "està aquí" també significava "continua sent bo". Si alguna vegada ha enviat un producte real, coneix aquest tipus de fallada de forma instintiva. Tot sembla bé en les proves, però després s'ensorra a les 2 del matí en condicions reals, en el buit entre el que va planejar i el que realment succeeix. Un prestable buit és com aquesta fallada de les 2 del matí en el món real, només que amb més conseqüències i pitjors eines. La gent sempre vol preguntar pel pròxim model: quin model, quin proveïdor, quin algoritme predirà finalment l'escassetat. Aquesta és la pregunta equivocada, i ho ha estat durant molt de temps. La pregunta real és més antiga, més difícil i completament respondible: ¿coincideix l'estat del sistema amb la realitat, i si es desvia, algú se'n donarà compte? Ja sabem com construir sistemes que puguin respondre afirmativament a aquesta pregunta. Ho fem tots els dies per a programari molt menys important que una vacuna.
La cadena de subministrament no necessita un algoritme més intel·ligent. Necessita que reconeguem que sempre ha estat un sistema distribuït i que comencem a tractar-la com a tal. En Q2BSTUDIO entenem aquesta analogia perquè portem anys aplicant els principis de fiabilitat i observabilitat en el desenvolupament d' aplicacions a mida per a sectors crítics. El nostre equip dissenya programari a mesura que integra intel·ligència artificial, ciberseguretat i serveis cloud AWS i Azure per garantir que la informació flueixi de forma coherent i segura. A més, oferim serveis intel·ligència de negoci amb Power BI que permeten visualitzar en temps real l'estat de la seva cadena, i desenvolupem ia per a empreses i agents IA que automatitzen la detecció d'anomalies. Però la tecnologia per si sola no n'hi ha prou si la base no és sòlida. Per això treballem amb cada client per establir aquesta identitat única dels objectes, aquest procés de conciliació i aquesta telemetria que converteix un sistema opac en un d'observable. Perquè al final, la diferència entre una cadena de subministrament que funciona i una que falla no està en la sofisticació de l'algoritme, sinó en l'honestedat de les dades. I aquesta honestedat comença per tractar cada caixa, cada lot i cada dosi com el que són: nodes en un sistema distribuït que mereixen la mateixa fiabilitat que un servei al núvol.
