Provar el sistema viu evitava 26 caigudes de 40; comprar més redundància, 9

Hi ha un número del 2003 que hauria de sortir en més comitès de direcció que en cap altre. Tres investigadors de Berkeley —David Oppenheimer, Archana Ganapathi i David Patterson— van agafar els informes interns de caiguda de tres grans serveis d'internet, els van llegir un per un i després van fer la pregunta que ningú no fa després d'un postmortem: quina tècnica, concretament, hauria evitat aquesta caiguda? Per al servei del qual tenien el material més complet, amb quaranta caigudes analitzades, el rànquing va sortir així: provar el sistema en marxa n'hauria evitat 26; exposar i vigilar millor les fallades hauria escurçat la detecció o la reparació en més de deu casos; afegir més redundància n'hauria evitat 9.

Vint-i-tres anys després, el pressupost d'infraestructura de gairebé qualsevol empresa espanyola està construït al voltant del 9. El segon node, la segona font, la segona línia, la segona cabina. I el 26 —provar de debò el que ja està encès— continua essent el que es fa quan sobra temps, que és mai.

Què van mesurar exactament, i què no

Convé acotar-ho abans d'usar-ho, perquè un número així és fàcil d'estirar. L'estudi es diu Why Do Internet Services Fail, and What Can Be Done About It? i es va presentar al simposi USITS d'USENIX el 2003. Analitza tres serveis anonimitzats: Online («un portal d'internet madur»), Content («un servei global d'allotjament de contingut capdavanter») i ReadMostly («un servei madur de lectura majoritària»). Dels dos primers tenien 296 i 205 informes de fallada de component respectivament, que es van traduir en 40 i 56 caigudes de servei —les que l'usuari nota—. Del tercer, 21.

El rànquing de tècniques que obre aquest post és del primer servei, sobre aquelles quaranta caigudes. No és una llei universal ni una estadística del sector: és el compte d'una casa concreta, fet per gent que tenia els informes al davant. I hi ha una altra precisió que toca fer, perquè canvia el significat de la paraula. El que l'estudi anomena online testing no és exactament trencar coses a propòsit. Ho defineixen així: «la prova prèvia al desplegament evita fallades de component al sistema desplegat, i la prova en marxa detecta components defectuosos abans que fallin durant l'operació normal». És a dir, comprovar que allò que ja està encès fa el que diu que fa. I hi afegeixen un matís que explica per què gairebé ningú no ho té muntat: perquè serveixi, la prova necessita «informació semàntica de l'aplicació», i el seu exemple literal és «publicar un article de notícies i comprovar que apareix». No n'hi ha prou que el port 443 contesti.

I un advertiment sobre l'ús que li donarem, perquè ningú no s'emporti una idea que l'estudi no sosté: el 26 no és la xifra de la injecció de fallades. Trencar coses a propòsit apareix en aquell mateix apartat com una tècnica diferent i sense número, només amb l'etiqueta de «benefici potencial significatiu». Tot el que proposem més avall —apagar un node, treure un cable, revocar una credencial— és una extrapolació nostra des del 26, no una conclusió seva. Ho diem ara i no a la nota de fonts.

El 9 es compra; el 26 s'ha de fer

L'asimetria entre aquells dos números no és tècnica, és comercial. La redundància té factura, albarà i número de sèrie: s'aprova en un comitè, s'amortitza en tres anys i es pot ensenyar. La prova del sistema viu no té res d'això. És temps de gent competent fent una cosa que, si surt bé, no produeix cap lliurable visible —només la confirmació que el que creies continua essent veritat—. És, literalment, el més difícil de vendre i el més difícil de defensar quan cal retallar.

I, tanmateix, el mateix estudi explica per què la redundància rendeix menys del que sembla. La causa número u de caiguda de servei en dos dels tres serveis no va ser el ferro: va ser l'operador. Els autors ho diuen sense adorns —«operator error is the leading cause of service failure in two of the three services»— i afinen encara més: «més del 50 % (i en un cas gairebé el 100 %) dels errors d'operador que van provocar caigudes de servei van ser errors de configuració», i aquests errors «van sorgir quan els operadors estaven fent canvis al sistema, per exemple escalant o reemplaçant maquinari, o desplegant o actualitzant programari».

Llegeix-ho a poc a poc: escalar o reemplaçar maquinari és a la llista d'activitats que provoquen caigudes. Comprar el segon node no és gratis en risc; el dia que el muntes, el toques. La redundància no és una assegurança que se signa i s'oblida, és una peça més que algú ha de mantenir, actualitzar i, cada cert temps, canviar. Hi ha una dada més de l'estudi que se cita poc i fa mal: els errors d'operador «sovint triguen significativament més a reparar-se» que els altres tipus d'error. La fallada del disc l'arregla un recanvi. El fitxer de configuració mal escrit a les vuit del vespre l'arregla algú que primer s'ha d'adonar que va ser això.

Aquí toca dir una cosa que ens treu la raó, perquè és al mateix apartat de l'estudi i ometre-la seria fer trampa. Els autors no conclouen que calgui comprar menys redundància. Quan fiquen el cost a l'equació escriuen el contrari: «observem que les tècniques d'afegir redundància addicional i exposar i vigilar millor les fallades ofereixen el bang for the buck més significatiu (...) incorrent en un cost relativament baix». I avisen d'una cosa més: Online ja feia servir una mica de redundància, monitorització, aïllament, reinici proactiu i prova prèvia i en marxa, de manera que la taula infraestima el que aquelles tècniques haurien aportat. El que no diuen enlloc és que et puguis saltar el 26.

El 2003 ja van posar nom a l'altra meitat

El paràgraf que tanca aquella anàlisi és el que ens interessa de debò, perquè anomena una cosa que aleshores no existia com a disciplina: «la comprovació automàtica de sanitat dels fitxers de configuració, i la injecció de fallades i de càrrega en marxa, també semblen oferir un benefici potencial significatiu». Injecció de fallades al sistema en producció. El 2003. Nou anys abans que Netflix alliberés Chaos Monkey com a codi obert, el 30 de juliol de 2012, i tretze abans que l'equip que el mantenia escrivís l'article que li va posar marc acadèmic.

Aquell article —Chaos Engineering, de Basiri i sis autors més, publicat a IEEE Software el 2016— defineix la idea en una frase que no té res d'èpica: «moltes organitzacions tecnològiques grans fan servir l'experimentació per verificar la fiabilitat d'aquests sistemes; fem servir el terme Chaos Engineering per referir-nos a aquest enfocament». Experimentació. Verificar. Són paraules de laboratori, no de demolició.

Chaos Monkey trenca coses de nou a tres, i ve apagat

La fama de l'eina ha fet més mal que bé, perquè el nom evoca un simi solt pel centre de dades. La documentació de Netflix, que és pública i es llegeix en deu minuts, descriu una cosa força més avorrida i força més llesta. Cada dia laborable, per cada grup d'instàncies, Chaos Monkey «llança una moneda ponderada» per decidir si en mata una; si surt cara, programa la terminació «en un moment aleatori entre les 9:00 i les 15:00 d'aquell dia». No de matinada. No en cap de setmana. En horari d'oficina.

Encara és més prudent. El fitxer de configuració, a l'apartat que la documentació mateixa titula «valors per defecte», arrenca amb enabled = false; continua amb el que més m'agrada, leashed = true, amb aquest comentari al costat: «si és cert, les terminacions només se simulen (només es registren)»; i tot seguit schedule_enabled = false. L'eina més famosa de trencar coses en producció ve de fàbrica desactivada, sense planificació i en mode simulacre. I té una peça més que gairebé ningú no esmenta: un outage checker, la documentació del qual comença així: «s'usa per desactivar automàticament Chaos Monkey durant caigudes en curs». És a dir, no trenca res si ja estàs trencat.

El paràmetre que s'ajusta, per cert, no és la brutalitat: és la freqüència. Es configura μ, la mitjana de dies laborables entre terminacions, i la probabilitat diària en surt (p = 1/μ). Amb μ=5, una de cada cinc jornades. L'agressivitat de Chaos Monkey és un número que decideix l'amo del servei, i per defecte és zero.

No ets Netflix, i no cal que ho siguis

Una empresa de programari de quaranta persones amb tres nodes Proxmox, un Ceph petit, un servidor de còpies i Microsoft 365 no necessita un dimoni matant màquines a l'atzar. Necessita l'altra part de la disciplina, la que sí que escala cap avall: el mètode. Els cinc principis publicats per qui la va formalitzar són construir una hipòtesi sobre el comportament en estat estable, variar successos del món real, executar en producció, automatitzar i minimitzar el radi d'impacte. D'aquests cinc, els que valen diners en una pime són el primer i l'últim.

La fitxa de l'experiment: sis camps en mitja cara de full

El que separa un simulacre d'una caiguda que t'has provocat tu no és l'eina: és haver escrit sis coses abans de tocar res. Si no estan escrites, no és un experiment; és un pressentiment amb testimonis.

• Hipòtesi. Una frase falsable i concreta, no un desig. «Si apago el node 2, les màquines que hi corren arrenquen en un altre node i l'ERP torna a donar login en menys de cinc minuts.» Si la frase no es pot desmentir amb un rellotge, no és una hipòtesi.
• Radi d'impacte. Què hi entra i què en queda fora, per escrit. Un node, no el clúster. Una bústia de proves, no la del director financer. Una seu, no les quatre.
• Senyal que es mira. La mètrica de negoci, no la de la màquina. Logins per minut, comandes confirmades, correus lliurats. L'estudi de Berkeley ja ho deia: la prova necessita semàntica d'aplicació. Que el node respongui al ping no vol dir res.
• Condició d'aturada. El número i el minut exactes a partir dels quals s'avorta i es reverteix. Escrit abans, quan ningú no té pressa. En calent, sempre sembla que aguanta una mica més.
• Qui pot dir prou. Un nom, no un càrrec. I que aquella persona sigui a la sala, no localitzable.
• Què hem après. Dues línies en acabar, fins i tot —sobretot— si no va passar res. Un experiment que confirma la hipòtesi també és un resultat, i és el que converteix el simulacre en una sèrie en comptes d'en una anècdota.

Quatre experiments, de menys a més radi

Això és el que posaríem sobre la taula en un parc petit i corrent. L'ordre importa: cadascun assumeix que l'anterior va sortir bé. No es comença pel tercer perquè soni més valent.

Fixa't que el primer no trenca res. És a propòsit. Si l'experiment número u no se supera, els altres tres no es fan: s'arregla la documentació i es torna el mes que ve. Ho vam escriure fa unes setmanes amb altres paraules a el pla de continuïtat que ningú no ha assajat, i continua essent el patró que més ens trobem: el pla existeix, està ben redactat i ningú no l'ha llegit amb un rellotge a la mà.

Per què en horari d'oficina i no a les tres de la matinada

El costum del sector és tocar de matinada, i per a un canvi planificat té tot el sentit: menys usuaris, menys cost si surt malament. Per a un simulacre, no. Un simulacre es fa quan està desperta la gent que sap arreglar-ho, que és exactament el motiu pel qual Netflix el programa de nou a tres. A les quatre de la matinada no hi ha ningú mirant la mètrica de negoci, ningú que noti que la comanda no entra, i la troballa es perd.

I hi ha un corol·lari incòmode. Si l'única resposta possible a «podem apagar un node dijous a les onze?» és «ni de broma», això ja és el resultat de l'experiment. Acabes de descobrir, sense apagar res, que el teu sistema no tolera perdre una peça en horari laboral. Que és precisament quan les peces es trenquen.

Quan NO fer res d'això

Ho diem perquè és la part que es calla als articles entusiastes, i perquè ens hem trobat les quatre situacions. Si falta alguna d'aquestes peces, un «dia del caos» no és enginyeria: és una caiguda que has programat tu i a sobre has pagat.

• No tens una còpia que hagis restaurat alguna vegada. Aleshores l'únic experiment que et toca és el número u de la taula, i fins que no es passi, els altres no existeixen. Una còpia sense provar no és una còpia: és un amulet.
• No tens manera de tornar enrere en un pas. Si revertir implica una reinstal·lació, el radi d'impacte no és el que vas escriure: és tot.
• No tens telemetria que et digui si estàs bé. Sense el senyal de negoci no pots distingir «va aguantar» de «ningú no ho estava fent servir en aquell moment». L'experiment no dona resultat: dona sensació.
• No hi ha ningú amb autoritat per aturar. Si la decisió d'avortar depèn de convèncer algú per telèfon, l'experiment dura exactament el que trigui aquella trucada, i aquella trucada és sempre més llarga que la condició d'aturada.

El que sol sortir malament quan surt malament

La fallada més freqüent en un simulacre no és que la peça no es recuperi. És la segona onada: tot el que estava connectat a la peça comença a reintentar alhora, i la càrrega dels reintents acaba de tombar el que la caiguda original només havia fregat. Ho expliquem sencer a la tempesta de reintents, on la segona caiguda la provoques tu, i és la raó per la qual la condició d'aturada s'escriu abans: enmig d'una tempesta de reintents, tothom alhora proposa esperar una mica més a veure si remunta.

El que mesurem nosaltres, i el que no prometem

El nostre últim simulacre de recuperació completa cronometrat va donar 14 minuts. És una dada interna i l'acotem amb la mateixa claredat amb què la diem: és una prova, no una promesa, i no és cap garantia contractual. Mesura el nostre sistema, amb la nostra documentació i la nostra gent, en una data concreta. Un client amb una altra arquitectura donarà un altre número, i el valor de l'exercici no és el número: és que existeixi i estigui datat.

I convé recordar contra què es mesura. Un 99 % de disponibilitat són 87,6 hores l'any a les fosques: més de dues setmanes laborables. Aquella xifra apareix als contractes com un adorn tranquil·litzador. Ningú no la compleix ni la incompleix per sort, i per descomptat ningú no la comprova el dia que se signa. L'única cosa que distingeix un número promès d'un número sabut és haver-lo cronometrat alguna vegada.

El que faríem aquest trimestre

Primer, l'experiment u: que algú que no va muntar el sistema restauri un fitxer de la còpia d'abans-d'ahir amb la documentació al davant, cronòmetre a la mà, un dimarts a les onze. Segon, escriure la fitxa de sis camps per a l'experiment dos abans de fer-lo —i deixar-la arxivada amb data, encara que el resultat sigui «no va passar res»—. Tercer, ficar el resultat a l'ordre del dia de la reunió mensual, al costat de la despesa, perquè és allà on això sobreviu o mor. I quart, repetir-ho. Un simulacre solt és una anècdota; quatre l'any, datats, són una sèrie que et diu si vas millorant o empitjorant.

Fonts (consultades el 16-10-2026): el recompte de tècniques sobre les 40 caigudes de servei del servei Online («online testing would have helped the most, mitigating 26 service failures», «simply increasing redundancy would have mitigated 9 failures», el «more than 10 instances» de la monitorització i la frase sobre «online fault and load injection»), la definició d'online testing, els 296 i 205 informes de fallada de component, les 40, 56 i 21 caigudes de servei, la descripció dels tres serveis, la frase «operator error is the leading cause of service failure in two of the three services», el «more than 50% (and in one case nearly 100%)» d'errors de configuració, el context de canvi (escalar o reemplaçar maquinari, desplegar o actualitzar programari) el major temps de reparació dels errors d'operador, la frase «we observe that the techniques of adding additional redundancy and better exposing and monitoring for failures offer the most significant bang for the buck (...) while incurring relatively low cost» i l'advertiment que Online ja feia servir algunes d'aquelles tècniques, de manera que la taula infraestima el seu efecte, surten d'Oppenheimer, Ganapathi i Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX USITS 2003. L'horari de 9:00 a 15:00, la moneda ponderada, la distribució geomètrica i el paràmetre μ de dies laborables, de la documentació de comportament de terminació de Chaos Monkey; els valors per defecte enabled = false, schedule_enabled = false, leashed = true i start_hour/end_hour, del seu format de fitxer de configuració; l'outage checker, de la seva documentació de complements. La definició de la disciplina i la citació de l'experimentació, de Basiri et al., «Chaos Engineering», IEEE Software 33(3), 2016; els cinc principis, de principlesofchaos.org. Els nous (87,6 h, 8,76 h i 52,6 min l'any) són aritmètica. El que és nostre, i ho acotem: la lectura del 26 enfront del 9 com a asimetria comercial, la fitxa de sis camps, la taula de quatre experiments, les quatre situacions en què NO fer-ho i els 14 minuts, que són una dada interna d'una prova datada i no cap garantia.