Els sistemes no fallen de cop

Els sistemes no fallen de cop.

L’alerta de les 3 de la matinada, l’error en cascada, l’incident que deixa un producte fora de servei durant quatre hores — tot això sembla sobtat. No ho és. És la superfície visible d’alguna cosa que ja era certa, revelada pel conjunt particular de condicions que la van fer inevitable.

Entendre això canvia com construeixes, com operes i què fas després que alguna cosa es trenqui.

L’acumulació lenta

La majoria de les fallades tenen una llarga prehistòria.

Un índex de base de dades que mai es va crear perquè la consulta era prou ràpida en desenvolupament. Un valor de timeout configurat “temporalment” que mai es va revisar. Un procés de desplegament manual que va funcionar bé fins que no ho va fer. Un runbook que era precís el 2022 i porta equivocat des de llavors.

Res d’això és dramàtic. Res d’això sembla risc en el moment en què s’introdueix. Sembla feina normal sota restriccions normals — una drecera presa perquè el termini era real, una decisió ajornada perquè el sistema funcionava, un document no actualitzat perquè actualitzar-lo semblava menys urgent que tota la resta.

Les fallades són l’interès compost de decisions ordinàries preses en temps ordinaris.

El desencadenant no és la causa

El que desencadena una fallada rarament n’és la causa.

Un pic de trànsit. Un canvi de configuració. Una actualització de dependència. Un cap de setmana festiu amb guàrdia reduïda. Aquests són desencadenants. La causa ja era present. El desencadenant és la condició que va fer visible la debilitat existent.

Això importa perquè els post-mortems sovint se centren en el desencadenant. “Vam desplegar un divendres.” “El trànsit era inusualment alt.” “El disc estava ple.” Això és cert, però no és on és l’aprenentatge.

L’aprenentatge és en què va fer el sistema susceptible a aquell desencadenant en primer lloc. Per què el volum de trànsit va revelar aquell bug? Per què un canvi de configuració va exposar aquella assumpció? Per què la guàrdia reduïda va significar que ningú se n’adonés fins que el dany estava fet?

El desencadenant explica quan. La prehistòria explica per què.

El manteniment com a pràctica

La manera d’evitar fallades no és respondre-hi millor. És reduir contínuament la superfície de risc acumulat.

Això és el manteniment — no en el sentit estricte de mantenir els servidors funcionant, sinó com una disciplina d’observació i reducció. Identificar els índexs que no existeixen. Revisar els timeouts que es van configurar temporalment. Revisar els runbooks després que les condicions que descriuen hagin canviat.

El manteniment no és una feina glamurosa. Rarament produeix un ticket que algú estigui emocionat d’escriure. El benefici és negatiu: el nombre d’incidents que no ocorren, les fallades detectades abans que es propaguin, l’enginyer que no passa el seu dissabte desfent sis mesos de fragilitat acumulada.

Els millors equips operacionals tracten el manteniment com una pràctica de primer nivell, no com el que fas quan no hi ha res més programat.

El que realment fa un bon post-mortem

Un post-mortem que acaba en el desencadenant no ha fet la seva feina.

Un post-mortem útil pregunta: on més al sistema existeix aquest tipus d’assumpció? Què va fer que aquest mode de fallada fos invisible fins ara? Què en els nostres processos va normalitzar ajornar la correcció?

L’objectiu no és documentar l’incident específic. L’objectiu és entendre les condicions que van permetre que la fallada s’acumulés, perquè aquelles condicions probablement estan generant altres fallades que encara no han emergit.

L’output més valuós d’un post-mortem no són els punts d’acció. És el model mental actualitzat d’on el sistema és fràgil.

Operar amb honestedat

Els equips que operen bé no assumeixen fiabilitat — la mesuren.

Saben quines parts del sistema són fràgils, no perquè ho hagin dissenyat així, sinó perquè han estat honestos sobre on viu el risc. Han executat simulacions de fallada abans que producció les executés. Han llegit el codi que ningú entén. Han preguntat què passa quan aquest servei particular és lent, no només quan està caigut.

Això no és pessimisme. És honestedat operacional. El risc existeix tant si algú l’ha mirat com si no. Mirar-lo no crea el problema; el revela en un moment en què encara es pot fer alguna cosa.

Sobre el temps

El temps és l’única variable de la qual cap sistema escapa.

Cada decisió té una data. L’esquema triat l’any u és encara allà l’any cinc. El servei que era “temporal” és crític per a producció l’any tres. L’abstracció que tenia sentit amb cent mil usuaris no en té sentit amb deu milions.

Els sistemes envelleixen. No amb elegància, a menys que algú treballi contínuament contra l’entropia. Els equips que construeixen sistemes duradors no són els que van prendre millors decisions inicials — són els que revisen les decisions a mesura que el context al seu voltant canvia.

La fallada sovint és simplement el temps fent visible una decisió que s’hauria hagut de revisar abans.

La pregunta que val la pena fer-se no és “per què s’ha trencat això?” És “què més hem estat massa ocupats per mirar?”