Cinquanta-cinc lliçons. srv-tramontana està instal·lat, enfortit, monitorable, copiat, automatitzat, xifrat en trànsit i amb una base de dades que ja no corre amb la configuració de fàbrica. Saps reconstruir-lo en cinquanta minuts, recuperar la base de dades a un segon concret, diagnosticar una latència amb eBPF i decidir amb números si cal alta disponibilitat.

I tot i així hi falta alguna cosa, perquè «funciona» i «està en producció» no són el mateix. Un sistema en producció és aquell del qual altres persones depenen sense saber que existeix: té un propietari, un objectiu de servei acordat, algú que el mira cada matí, alertes que s'atenen, un procediment quan es trenca i un registre de per què està com està. Res d'això no és programari; tot això és operació.

Aquesta lliçó tanca el curs posant aquella capa. La checklist completa amb la seva evidència, el monitoratge amb Prometheus i Grafana que va quedar ajornat des de 05-07, alertes que es puguin atendre sense odiar-les, la rutina diària, la revisió posterior a l'incident sense culpables, i el pressupost d'error que converteix el 99,8 % de 07-07 en una decisió executable. I els tres deutes que continuen oberts des del Mòdul 5, que es tanquen avui.

1. Què significa estar en producció
2. La checklist de posada en producció
3. Monitorar i alertar: no són el mateix
4. Prometheus i node_exporter
5. PromQL de l'imprescindible
6. Mètriques pròpies: les que ja tens sense saber-ho
7. Grafana i el panell mínim
8. Alertes que es poden atendre
9. Registres centralitzats: el deute de 05-06
10. Operació diària, setmanal i mensual
11. El quadern de guàrdia i el registre de canvis
12. La revisió posterior a l'incident sense culpables
13. Gestió del canvi i finestres de desplegament
14. SLI, SLO i pressupost d'error
15. Tancament dels deutes pendents
16. Compliment: RGPD i retenció de dades
17. Tancament del curs

L'última fila és la que resumeix la lliçó. La diferència entre un sistema aficionat i un de professional no és la tecnologia: és que davant de «va bé?» hi ha una dada, no una impressió.

I hi ha una prova pràctica, més útil que qualsevol definició:

Podries anar-te'n dues setmanes de vacances sense ordinador?

Per respondre que sí calen sis coses: que el sistema s'autorepari en les fallades previstes, que algú rebi les alertes, que aquell algú tingui procediments escrits que pugui seguir sense ser tu, que les còpies es verifiquin soles, que hi hagi un camí d'escalat, i que existeixi un registre de què s'ha canviat i per què. Aquesta lliçó construeix les sis.

Cada fila porta evidència comprovable: una ordre que retorna un resultat, no una casella de consciència. Sense evidència, una checklist és una llista de bones intencions.

Resum: 30 files complertes de 42. Nou es tanquen en aquesta lliçó; tres queden com a feina planificada amb data. Aquella xifra és en si mateixa l'evidència número 43: saber exactament què falta.

És la distinció que evita l'error més car d'aquesta àrea.

Monitora tot el que puguis; alerta de gairebé res. És contraintuïtiu i és l'única manera que les alertes serveixin. Un sistema que envia quaranta notificacions al dia és un sistema sense alertes, perquè ningú no les llegeix.

De 05-07, ara amb instrumentació real:

Dos matisos que fan la diferència entre mesurar i mesurar bé:

La latència es mesura en percentils, mai en mitjana. Una mitjana de 80 ms pot amagar que l'1 % dels usuaris espera 4 segons. I cal separar la latència de les peticions correctes de la de les errònies: un error 500 retornat en 2 ms millora la mitjana i empitjora el servei.

La latència dels errors s'exclou de l'SLI. Si no, una caiguda total —on tot falla ràpid— apareixeria com una millora de rendiment.

I el mètode USE, complementari, per a cada recurs: Utilització, Saturació i Errors.

Prometheus és una base de dades de sèries temporals que recol·lecta mètriques: en lloc que els serveis li enviïn dades, ell les demana periòdicament a extrems HTTP.

Aquella segona fila és un avantatge enorme: amb recol·lecció, un servei caigut produeix immediatament up == 0, que és un senyal explícit.

Les unitats del paquet són raonables però no compleixen l'estàndard del curs. Drop-ins, com sempre:

promtool check config és el nginx -t de Prometheus, i es fa servir igual: sempre abans de recarregar.

Sobre la retenció i el disc, que és la pregunta que sempre surt:

Trenta dies basten per investigar incidents i veure tendències mensuals. Per a històric d'anys existeixen Thanos o Mimir, i per a Tramontana són innecessaris.

PromQL espanta al principi i es redueix a cinc patrons que cobreixen el 90 % dels casos.

1. up: el més important i el més simple.

2. rate() sobre comptadors. Un comptador només puja. El seu valor absolut no diu res; el que importa és a quin ritme creix.

rate() gestiona correctament els reinicis: si el comptador torna a zero perquè el procés s'ha reiniciat, ho detecta i no produeix un valor negatiu absurd.

Regla: rate() només sobre comptadors (_total). Per a mesuradors —memòria, temperatura, connexions— es fa servir el valor directament.

3. Agregacions i proporcions.

4. histogram_quantile(): els percentils de latència.

L'etiqueta le (less or equal) defineix els cubells de l'histograma i s'ha de conservar al by. És l'error més comú de PromQL: agregar sense by (le) i obtenir resultats sense sentit.

5. Predicció, que és el que converteix una alerta en útil.

Alertar de «disc al 90 %» és alertar tard o alertar en va —un disc estable al 91 % no és un problema—. Alertar de «a aquest ritme s'omple en quatre hores» és accionable, que és la propietat que defineix una bona alerta.

Els node_exporter i companyia donen mètriques tècniques. Les que de debò importen són les que responen a preguntes del negoci, i la majoria ja les estàs calculant als scripts del curs — només cal exposar-les.

El mecanisme és el recol·lector de fitxers de text: qualsevol script deixa un .prom en un directori i node_exporter el publica.

Quatre decisions de disseny de l'script:

1. Escriptura atòmica amb mktemp i mv. node_exporter pot llegir el fitxer en qualsevol moment; un de truncat fa que en descarti tot el contingut.
2. umask 022, en contra de la convenció general del curs: node_exporter corre com un altre usuari i necessita llegir-lo. És una excepció justificada, i per això està comentada.
3. La mètrica 8, la marca de frescor, és la que fa fiables les altres set. Sense ella, si aquest script deixa d'executar-se, Prometheus continuaria publicant els últims valors coneguts indefinidament i tot semblaria correcte per sempre. Amb ella es pot alertar que les mètriques estan rances.
4. La mètrica de negoci, tramontana_bookings_total, és la que a la Marta li importa i la que detecta la fallada més perillosa: la que no trenca res. Si el sistema respon 200 a tot però ningú no aconsegueix reservar, cap mètrica tècnica no ho revelarà.

I per a l'aplicació, el que el Luis ha d'exposar a /metrics:

I l'accés, aprofitant el que ja està muntat: per la VPN de 08-04, sense publicar res de nou.

El panell mínim, sis panells i ni un més:

Un consell que contradiu l'instint: un panell amb quaranta gràfiques no es mira. El panell principal ha de cabre en una pantalla i respondre en tres segons a «va bé?». El detall viu en panells secundaris als quals s'arriba quan cal.

Tota alerta ha de requerir una acció humana immediata. Si el receptor no pot fer res, o pot esperar a demà, no és una alerta: és un panell o un informe.

La fatiga d'alertes és el mode de fallada característic del monitoratge, i la seva progressió és sempre la mateixa:

1. Es configuren alertes per a tot, «per si de cas».
2. N'arriben deu al dia, gairebé totes irrellevants.
3. La gent comença a ignorar-les.
4. Es crea un filtre de correu que les arxiva.
5. Arriba l'alerta important i ningú no la veu.

El sistema queda pitjor que sense alertes, perquè hi ha una falsa sensació de vigilància. I el remei és contraintuïtiu: esborrar alertes.

Regla: alerta de símptomes, diagnostica amb causes. Un for: 5m sobre la taxa d'errors detecta qualsevol fallada que afecti l'usuari, incloses les que ningú no va anticipar. Una alerta de CPU al 90 % dispara quan s'executa la còpia nocturna i el servei va perfectament.

Amb dues excepcions legítimes, que són alertes de causa i han d'existir perquè el seu símptoma arriba massa tard:

• El disc s'omplirà. Quan el símptoma apareix, el servei ja està caigut.
• El certificat caducarà. Quan el símptoma apareix, el web ja no carrega.

Totes dues comparteixen la propietat clau: avisen amb hores o dies d'antelació i l'acció és evident.

Les inhibit_rules mereixen atenció: quan el servei cau, es dispararien també les alertes de latència, d'errors i de connexions a la base de dades. Rebre cinc notificacions del mateix incident és fatiga d'alertes en la seva forma més pura. La inhibició n'envia una: la causa.

I el silenci programat durant el manteniment, sense el qual la finestra de desplegament genera una allau de notificacions:

Els silencis es posen amb caducitat, sempre. Un silenci indefinit posat un dimarts és una alerta que no tornarà a sonar mai, i ningú no se'n recordarà.

A 05-06 va quedar una peça pendent: el journal és persistent i local. Amb un sol servidor funciona; així que n'hi ha dos —els nodes d'aplicació de 07-07, el balancejador, la rèplica— diagnosticar exigeix entrar a cada màquina i correlacionar a mà.

Per què cal centralitzar:

Aquella segona fila és de seguretat pura i enllaça amb 06-04: si els registres només viuen a la màquina atacada, l'atacant els edita. És el mateix raonament pel qual la base de dades d'AIDE viu fora del servidor.

Loki com a opció lleugera:

Loki és l'elecció per a Tramontana per dues raons: no indexa el text complet —que és el que fa car Elasticsearch— i comparteix etiquetes i sintaxi amb Prometheus, de manera que es pot saltar d'una gràfica de latència als registres d'aquell mateix instant al mateix panell. Aquella correlació és el que fa útil un sistema de registres.

I l'advertiment obligatori: els registres contenen dades personals —IP, identificadors d'usuari, de vegades correus—. Centralitzar-los multiplica l'abast d'una fuita. Retenció acotada, accés restringit i el mateix tractament que la base de dades.

El quadern de guàrdia és un fitxer de text on s'anota el que passa. Sona trivial i és l'eina que més temps estalvia en un incident, perquè respon a «això ja ens havia passat?».

Quatre regles perquè funcioni:

1. S'escriu en el moment, no al final del dia. El que es posposa no s'escriu.
2. Marques de temps sempre, per poder correlacionar amb les gràfiques.
3. Les observacions valen tant com els incidents. L'entrada de les 16:10 és la que explicarà una alerta d'aquí a dos mesos.
4. Viu fora del servidor —al repositori d'Ansible— perquè caldrà precisament quan el servidor no hi sigui.

El registre de canvis ja existeix: és el git log de ~/tramontana-infra. La disciplina és que tot canvi de configuració hi passi, perquè es pugui respondre a «què va canviar abans que comencés a fallar?».

Un incident és una fallada del sistema, no d'una persona. Si algú va poder esborrar 40.000 files amb una ordre, el problema és que el sistema ho permetés sense fricció, no que aquella persona s'equivoqués.

Això no és amabilitat corporativa: és l'única manera d'obtenir informació verdadera. En una cultura on es busquen culpables, la gent amaga els errors, i aleshores els incidents es repeteixen perquè ningú no sap que van passar. La revisió sense culpables és una decisió d'enginyeria.

Revisió posterior a l'incident: esborrat accidental de reserves

Incident: INC-2026-003 · Data: 2026-08-18 · Severitat: Alta Durada de l'impacte: 34 min · Dades perdudes: cap Redactat per: Operacions · Revisat amb: Marta, Luis

1. Què va passar

Durant una neteja rutinària de dades antigues, es va executar a la base de dades de producció un DELETE la clàusula WHERE del qual no era la prevista, i va eliminar 40.218 reserves històriques. Es va detectar 19 minuts després i es van recuperar mitjançant recuperació a un punt en el temps. No hi va haver pèrdua de dades ni interrupció del servei.

2. Impacte

Dimensió	Impacte
Disponibilitat del servei	Cap: el web va continuar funcionant
Dades perdudes definitivament	Cap
Dades temporalment inaccessibles	40.218 reserves històriques, 34 min
Clients afectats	Cap (dades de consulta interna)
Pressupost d'error consumit	0 %

3. Línia temporal

Hora	Succés
14:30	S'inicia la neteja de dades anteriors a 2024
14:32	S'executa el DELETE amb la condició incorrecta
14:51	Un informe retorna xifres anòmales: es detecta
14:53	S'atura tota escriptura addicional. S'obre l'incident
14:58	Es localitza la marca temporal exacta a pg_stat_statements
15:02	Comença la restauració PITR a srv-tramontana-proves
15:19	Recuperació completada i verificada a proves
15:24	Dades reimportades a producció amb psql -1
15:26	Verificació final. Incident tancat

4. Causa arrel: els cinc perquès

#	Pregunta	Resposta
1	Per què es van esborrar 40.218 reserves?	Un DELETE amb WHERE incorrecte
2	Per què es va executar amb la condició incorrecta?	Es va escriure a mà, sense SELECT previ
3	Per què es va escriure a mà?	No existeix procediment per a neteges de dades
4	Per què no existeix?	Mai no s'havia fet una neteja massiva
5	Per què va caldre ara?	La taula d'auditoria va créixer sense política de retenció

Causa arrel: l'absència d'una política de retenció de dades va obligar a una neteja manual improvisada, sense procediment ni salvaguardes.

I una observació sobre el mètode: els cinc perquès travessen la resposta fàcil —«algú es va equivocar en teclejar»— fins a arribar a una causa sistèmica i accionable. Quedar-se al perquè número 2 hauria produït la conclusió inútil de «cal anar amb més compte».

5. Què va funcionar bé

Aquesta secció és obligatòria i s'oblida sempre:

• La recuperació a un punt en el temps va funcionar exactament com es va assajar (RB-BD-02, 08-02). L'assaig trimestral va demostrar el seu valor al cap de tres dies.
• La restauració en màquina a part va preservar les transaccions posteriors. Restaurar sobre producció hauria perdut 19 minuts de reserves reals.
• La detecció en 19 minuts va ser raonable, encara que millorable.
• Es va avisar immediatament, sense amagar-ho. Això va permetre actuar de pressa.

6. Què es canvia

#	Acció	Responsable	Data	Estat
1	Política de retenció d'auditoria acordada amb la Marta	Marta + Ops	25/08	Pendent
2	Manual de neteges: SELECT count(*) obligatori abans de qualsevol DELETE	Ops	22/08	En curs
3	Rol svc_neteja amb statement_timeout i sense permís de DELETE massiu	Ops	25/08	Pendent
4	Purga programada com a temporitzador idempotent i provat, no manual	Ops	31/08	Pendent
5	Alerta si una taula perd més del 10 % de files en 5 min	Ops	25/08	Pendent
6	psql de producció amb \set ON_ERROR_ROLLBACK off i avís al prompt	Ops	22/08	Fet

Cap acció no és «anar amb més compte». Una acció correctiva que depèn de l'atenció humana no és una acció correctiva: és una expressió de desig.

7. Lliçons

1. Els assaigs de recuperació es paguen sols. El de 08-02 es va fer el dia 15; el dia 18 va caldre de debò, i ningú no va haver d'improvisar.
2. Una taula que creix sense política de retenció acaba forçant una operació arriscada. El creixement silenciós és un deute que es cobra de cop.
3. Detectar en 19 minuts és molt per a un esborrat massiu. L'acció 5 ho baixarà a menys de 5.

La majoria de les interrupcions no vénen de fallades de maquinari: vénen de canvis. I tanmateix el canvi és necessari. Gestionar-lo és posar-hi fricció proporcional al risc, no impedir-lo.

La finestra de Tramontana: dimarts i dimecres, de 10:00 a 12:00. I les raons de per què no es desplega el divendres a la tarda, que és la regla més famosa del sector:

1. Els problemes apareixen amb càrrega real, hores després. Un divendres a les 18:00, aquella càrrega arriba el dilluns.
2. La gent se'n va. Si alguna cosa falla a les 20:00 del divendres, qui ho va desplegar ja no hi és.
3. El cap de setmana és quan més reserves es fan a Tramontana: el pitjor moment possible per a una fallada.
4. Un incident el divendres s'arrossega el cap de setmana, amb la persona de guàrdia treballant en un canvi que no va fer.

La regla, formulada correctament: no es desplega si no hi ha temps suficient per endavant per detectar i revertir el problema amb l'equip disponible. El dimarts al matí ho compleix; el divendres a la tarda no.

Llista de verificació prèvia a cada desplegament:

Tres conceptes que es confonen i són diferents:

L'SLO es posa sempre més exigent que l'SLA, per tenir marge abans d'incomplir el contracte.

Recollint el 99,8 % proposat a 07-07 i convertint-lo en números concrets:

SLI: proporció de peticions HTTP a reserves.tramontana.example respostes amb codi < 500 i en menys de 2 segons.

SLO: ≥ 99,8 % d'aquelles peticions, mesurat en finestra mòbil de 30 dies.

Aquí hi ha la idea que canvia la manera de treballar:

Pressupost d'error = 100 % − SLO. És la quantitat de fallada que et pots permetre. No és un residu: és un recurs que es gasta.

Tramontana pot estar caiguda 1 h 26 min cada 30 dies i continuar complint el seu objectiu. Aquell temps és un pressupost que es pot gastar deliberadament: en desplegaments arriscats, en actualitzacions, en experiments.

I d'aquí surt una regla de gestió que substitueix les discussions eternes entre «cal anar més ràpid» i «cal ser més estables»:

31,4 % consumit: hi ha marge. Aquell número va al panell principal, i és el que converteix «despleguem?» d'una discussió d'opinions en una consulta de dades.

El més valuós del pressupost d'error, i sol sorprendre: és tan dolent esgotar-lo com no gastar-lo. Un equip que acaba el mes amb el 5 % consumit està sent massa conservador — podria haver desplegat més, lliurat més valor i assumit més risc dins del que s'ha acordat. La fiabilitat excessiva també té un cost: el de les funcions que no es van fer.

El problema. restic puja les còpies amb un testimoni que també pot esborrar. Un atacant amb accés a srv-tramontana pot executar restic forget --prune i destruir tot l'històric. És exactament la manera d'operar del programari de segrest modern: primer esborra les còpies, després xifra les dades.

La solució: un testimoni de només afegir, més un restic en mode --append-only al costat del repositori.

El principi general, aplicable molt més enllà d'això: el sistema copiat no ha de poder destruir les seves còpies. Si pot, no són còpies: són una rèplica amb retard.

Checklist fila 23: tancada.

Què és. authorized_keys2 és un fitxer obsolet d'OpenSSH 2.x, quan hi havia fitxers separats per a claus SSH-1 i SSH-2. Les versions modernes d'OpenSSH l'ignoren completament, tret que AuthorizedKeysFile l'esmenti explícitament.

I aquí hi ha el problema: la configuració per defecte d'Ubuntu sí que l'inclou. Aquella clau RSA de 2048 bits, d'un proveïdor amb qui ja no es treballa, dona accés al servidor avui mateix.

És un exemple perfecte d'un risc real: no és una vulnerabilitat de programari, és un fitxer que ningú no va mirar en divuit mesos.

I a Ansible, perquè sigui permanent i verificat:

La lliçó de mètode: a l'inventari d'accessos, un fitxer que no es pot explicar és un fitxer que es retira. I l'error de fons va ser no tenir mai una revisió periòdica d'accessos — que ara és la fila mensual de la taula de l'apartat 10.

Checklist fila 40: tancada.

Es tanca formalitzant el que es va proposar a 07-07:

Acord de nivell de servei intern · Tramontana Reserves Acordat el 18/08/2026 entre Operacions i Direcció (Marta Vidal). Revisió: agost de 2027.

Concepte	Valor
SLI	Peticions amb codi < 500 i latència < 2 s
SLO	99,8 % en finestra mòbil de 30 dies
Pressupost d'error	1 h 26 min cada 30 dies
Finestra de manteniment	Dimarts i dimecres, 10:00-12:00
RPO	15 minuts
RTO	2 hores
Horari de guàrdia	Laborable 8:00-20:00; crítiques 24×7
Revisió del compliment	Mensual, al panell

Checklist fila 33: tancada.

Tramontana guarda dades personals de clients: nom, contacte i dates d'estada. Això activa obligacions concretes del Reglament General de Protecció de Dades, i algunes són tècniques i són teves.

I el punt que connecta directament amb l'incident de l'apartat 12: la taula auditoria ocupa 1.204 MB, més que totes les dades de reserves juntes, i ningú no ha decidit quant de temps es conserven. Això no és només un problema d'espai: conservar dades personals sense termini definit és un incompliment del principi de limitació del termini de conservació.

Anonimitzar en lloc d'esborrar conserva la utilitat estadística —quantes reserves hi va haver, de quines cases— sense conservar les dades personals. És la solució tècnicament correcta i la que més es passa per alt.

L'advertiment final, i és important: el RGPD no és un assumpte tècnic, és un assumpte legal amb implicacions tècniques. Res d'aquest apartat no substitueix l'assessoria professional. El que sí que és responsabilitat teva com a administrador és: que existeixin les mesures tècniques, que la retenció sigui aplicable amb una ordre, que hi hagi traçabilitat d'accessos, i que qui decideix —la Marta— tingui la informació per decidir. Un administrador que implementa una purga sense que ningú hagi decidit els terminis està prenent una decisió legal sense autoritat per fer-ho.

• Confondre monitorar amb alertar. Monitora-ho tot; alerta de gairebé res.
• Alertar de causes en lloc de símptomes. «CPU al 90 %» dispara quan corre la còpia. «Més del 5 % d'errors» detecta qualsevol fallada real.
• No podar alertes. Deu notificacions al dia equivalen a cap. La revisió mensual d'alertes és tan important com crear-les.
• Alertes sense acció. Si el receptor no pot fer res, és un panell, no una alerta. Tota alerta porta la seva accio i el seu enllaç al manual d'operació.
• Silencis sense caducitat. Un silenci indefinit és una alerta apagada per sempre.
• No monitorar el monitoratge. Un script de mètriques mort fa que tot sembli correcte indefinidament. La marca de frescor ho resol.
• Mitjanes de latència en lloc de percentils. Una mitjana de 80 ms amaga que l'1 % espera 4 segons.
• Incloure els errors a la latència. Una caiguda total, on tot falla ràpid, apareixeria com una millora de rendiment.
• rate() sobre un mesurador. Només té sentit sobre comptadors (_total).
• Agregar histogrames sense by (le). És l'error clàssic de PromQL: els percentils surten sense sentit.
• Etiquetes d'alta cardinalitat. Una etiqueta amb l'ID de reserva crea una sèrie per reserva i rebenta la memòria de Prometheus.
• Un panell amb quaranta gràfiques. No es mira. El principal ha de cabre en una pantalla.
• Revisions posteriors a l'incident que busquen culpables. Garanteixen que el següent incident s'amagui.
• Accions correctives del tipus «anar amb més compte». No són accions: són desitjos. Han de canviar el sistema.
• Desplegar el divendres a la tarda. Els problemes apareixen amb càrrega real i aleshores no hi ha ningú.
• Un SLO sense pressupost d'error. L'objectiu sense la seva conseqüència operativa no canvia cap decisió.
• Gastar el 5 % del pressupost d'error. Estàs sent massa conservador: podries haver lliurat més valor.
• Còpies que el mateix servidor pot esborrar. No són còpies: són una rèplica amb retard, i el programari de segrest ho sap.
• No revisar els accessos periòdicament. Un authorized_keys2 d'un proveïdor de fa any i mig dona accés avui.
• Guardar dades personals sense termini definit. És un incompliment del RGPD, no només un problema d'espai.
• Consell de mètode. Davant de «va bé el sistema?», si la resposta no és un número, no estàs en producció.

A les 03:47 es dispara HighErrorRate. Documenta la resposta completa a l'incident —des de la notificació fins al tancament— i redacta la revisió posterior a l'incident resultant.

Dissenya la revisió mensual d'alertes: què es mesura de cada alerta, amb quins criteris es decideix eliminar-la, ajustar-la o mantenir-la, i aplica el mètode a les alertes configurades en aquesta lliçó.

La Marta demana un informe d'estat del sistema per a la reunió anual amb els socis: què s'ha fet aquest any, en quina situació està i què es necessita. Redacta'l.

Solució 1

03:47 — Notificació.

03:49 — Confirmar que el problema és real, abans de tocar res.

Confirmat: un de cada tres usuaris rep un error. No és una falsa alarma.

03:51 — Acotar l'abast amb el panell, no endevinant.

La latència va pujar tres minuts abans que els errors, i hi ha 47 clients esperant connexió. El coll d'ampolla és a la base de dades, no a l'aplicació ni a Nginx.

03:53 — El registre de canvis, que és la pregunta obligatòria.

Sense canvis recents. No és un desplegament: és alguna cosa que ha passat sola.

03:55 — Diagnòstic a la base de dades.

Causa arrel trobada en vuit minuts. Un VACUUM FULL sobre app.disponibles té un blocatge ACCESS EXCLUSIVE que impedeix tota lectura i escriptura d'aquella taula. Les peticions s'acumulen esperant, esgoten el conjunt de connexions de PgBouncer, i l'aplicació retorna 502.

application_name = psql i arrencat a les 03:30: algú el va llançar a mà. La consulta al quadern de guàrdia ho confirma —una nota de la tarda anterior: «disponibles amb 31,7 % de tuples morts, mirar».

03:58 — Mitigació.

04:00 — Verificar i tancar.

04:05 — Anotar al quadern mentre està fresc.

Revisió posterior a l'incident: errors 502 per blocatge de VACUUM FULL

Incident: INC-2026-004 · Data: 2026-08-19 · Severitat: Crítica Durada de l'impacte: 17 min (03:41-03:58) · Detecció: 6 min

1. Què va passar

Un VACUUM FULL executat manualment sobre app.disponibles va adquirir un blocatge exclusiu que va impedir tota lectura i escriptura de la taula durant 28 minuts. Les peticions es van acumular, es va esgotar el conjunt de connexions i l'aplicació va retornar errors 502 al 34 % de les peticions durant 17 minuts.

2. Impacte

Dimensió	Valor
Durada de l'impacte	17 min
Peticions fallides	~2.100 (34 % de 6.200)
Reserves perdudes estimades	1-2 (matinada, trànsit baix)
Pressupost d'error consumit	19,7 % del mes (17 de 86 min)
Dades perdudes	Cap

3. Línia temporal

Hora	Succés
03:30	Es llança VACUUM FULL app.disponibles manualment
03:38	El p95 de latència puja a 8 s (símptoma primerenc, sense alerta)
03:41	Primers 502: el conjunt de connexions de PgBouncer s'esgota
03:47	Es dispara HighErrorRate i arriba la notificació
03:49	Es confirma el problema
03:51	S'acota amb el panell: la base de dades
03:55	S'identifica el blocatge i el VACUUM FULL
03:58	pg_cancel_backend. Servei restablert
04:00	Verificat. Incident tancat

4. Causa arrel: els cinc perquès

#	Pregunta	Resposta
1	Per què hi va haver 502?	L'aplicació no va poder consultar la base de dades
2	Per què no va poder?	Un blocatge ACCESS EXCLUSIVE sobre app.disponibles
3	Per què hi havia aquell blocatge?	Un VACUUM FULL manual
4	Per què es va executar a mà en producció?	Es va detectar 31,7 % de tuples morts i es va voler resoldre ràpid
5	Per què hi havia tant d'inflament?	autovacuum no està ajustat per a aquella taula

Causa arrel: autovacuum amb els valors per defecte (llindar del 20 %) no segueix el ritme d'escriptura d'app.disponibles. L'inflament resultant va motivar una intervenció manual amb una eina el blocatge de la qual no es va anticipar.

Causa contribuent: no hi havia cap control que impedís executar una operació bloquejant en producció, ni alerta que avisés abans que els usuaris se'n veiessin afectats.

5. Què va funcionar bé

• L'alerta era de símptoma i va funcionar: va detectar una fallada que ningú no havia anticipat. Una alerta de causa sobre VACUUM no existia i no hauria calgut.
• El panell va acotar el problema en dos minuts. Sense ell, el diagnòstic hauria estat a cegues.
• El registre de canvis va descartar un desplegament en trenta segons.
• La mitigació va ser reversible: cancel·lar en lloc d'acabar la connexió.
• El quadern de guàrdia va donar el context —la nota del dia anterior— que va explicar qui i per què.

6. Què es canvia

#	Acció	Responsable	Data	Estat
1	Ajustar autovacuum d'app.disponibles al 2 % (08-02)	Ops	19/08	Fet
2	lock_timeout = 5s per defecte a la sessió de psql de producció	Ops	20/08	Fet
3	Instal·lar pg_repack i documentar-lo com **l'**eina per a l'inflament	Ops	26/08	Pendent
4	Alerta LongLockWait (> 30 s) — avisa abans del símptoma	Ops	22/08	Pendent
5	Manual d'operació RB-BD-03: manteniment de base de dades, amb la llista d'operacions bloquejants	Ops	26/08	Pendent
6	Panell amb tuples morts per taula, per no descobrir-ho per casualitat	Ops	22/08	Pendent
7	Cap operació de manteniment manual en producció fora de finestra	Equip	20/08	Acordat

# Accio 2: /etc/postgresql/16/main/conf.d/50-proteccio.conf
# Si una consulta no aconsegueix un blocatge en 5 s, falla en lloc
# d esperar. Una consulta que falla rapid es infinitament preferible
# a una que bloqueja el servei sencer.
lock_timeout = 5s

7. Lliçons

1. La latència va pujar 9 minuts abans que els errors. Aquell és el marge que vam perdre per no tenir una alerta primerenca. L'acció 4 el recupera.
2. La intenció era bona i el resultat va ser una caiguda. No és una fallada de la persona: és una fallada del sistema, que permetia executar una operació bloquejant en producció sense cap fricció. Les accions 2, 5 i 7 hi afegeixen aquella fricció.
3. El 19,7 % del pressupost d'error en un incident de 17 minuts demostra per què l'SLO canvia decisions: amb dos incidents així, el mes entra en zona de precaució i els desplegaments es moderen.
4. VACUUM FULL no és «un vacuum més gran». Bloqueja la taula sencera. Mereix ser en un manual d'operació amb aquell advertiment en majúscules.

Solució 2

Per què existeix aquesta revisió. Les alertes es creen després de cada incident i gairebé mai no s'eliminen. En un any, un sistema acumula trenta alertes de les quals en serveixen cinc. La revisió mensual és el contrapès.

Les quatre mètriques que es mesuren de cada alerta:

L'arbre de decisió, aplicat a cada alerta:

Aplicació a les alertes d'aquesta lliçó:

Anàlisi i correcció de les dues problemàtiques:

BackupTooOld: 412 dispars, 0,2 % de precisió. És el cas de llibre de fatiga d'alertes: es disparava cada 30 minuts, totes les nits, entre l'execució de la còpia i la seva verificació. Quatre-centes dotze notificacions que ningú no llegia, i que a més van entrenar l'equip a ignorar el canal.

LatencyDegraded: 38 dispars, 21 % de precisió, 45 minuts fins a la reacció. Els 45 minuts són la dada reveladora: l'equip ja l'estava ignorant. Es dispara cada tarda durant l'informe de facturació de la Marta, que és lent i esperat.

I per als informes, que sí que convé vigilar però amb un altre llindar:

Resultat de la revisió:

Quatre principis que resumeix aquesta revisió:

1. Una alerta amb precisió baixa és pitjor que cap, perquè entrena l'equip a ignorar el canal on també arriben les bones.
2. El temps de reacció mesura si l'alerta s'atén. Quaranta-cinc minuts signifiquen que s'ignora, i aquella dada és més honesta que qualsevol opinió.
3. Una alerta que no es dispara mai no és inútil, si cobreix un risc greu i el seu cost és zero. ServiceDown no s'ha disparat en un any i ha de continuar sent-hi.
4. Ajustar abans que eliminar. Les dues problemàtiques cobrien riscos reals; el problema era al llindar, no a la idea.

I una nota final de mètode: aquesta revisió s'anota al quadern de guàrdia, amb l'abans i el després de cada alerta modificada. D'aquí a sis mesos, quan algú es pregunti per què el llindar de BackupTooOld és 26 hores i no 8, la resposta estarà escrita.

Solució 3

Informe anual de sistemes · Tramontana Reserves

Per a: Marta Vidal i socis · De: Operacions de sistemes Exercici: 2026 · Data: 18 d'agost de 2026

---

Resum executiu

El sistema que sosté Tramontana Reserves ha passat, en l'últim any, de ser una màquina configurada a mà que ningú més que jo sabia reconstruir a una infraestructura documentada, automatitzada, vigilada i amb procediments escrits que una altra persona podria seguir.

Els tres canvis més importants, en una línia cadascun:

• Les dades dels nostres clients ja viatgen xifrades. Fins al juny no ho feien.
• Podem recuperar la base de dades a qualsevol instant concret, i ho hem assajat: 24 minuts.
• Reconstruir el servidor sencer va passar de 8 hores a 50 minuts, i està mesurat, no estimat.

Disponibilitat mesurada en els últims 30 dies: 99,94 %, per damunt de l'objectiu del 99,8 % que proposem formalitzar.

---

1. On érem i on som

	Fa un any	Avui
Configuració del servidor	Al meu cap	En codi, versionat
Reconstruir després d'un desastre	8 h estimades	50 min mesurats
Dades que podríem perdre	Fins a 24 h	15 minuts
Recuperar un esborrat accidental	Impossible sense perdre un dia	Al segon anterior
S'han provat les còpies?	Mai	Assaig trimestral documentat
Xifratge del trànsit web	No	Sí
Accés remot segur	Només des de l'oficina	Des de qualsevol lloc, per túnel xifrat
Sabem si va bé?	«Crec que sí»	99,94 %, en un panell
Si alguna cosa falla de matinada	Ens n'assabentem al matí	Alerta al telèfon
Documentació operativa	Cap	6 procediments escrits i assajats

---

2. El que s'ha fet, agrupat

Fiabilitat. Automatització completa de la configuració: el servidor es reconstrueix des de zero amb una ordre, i això ha reduït el temps de recuperació davant d'un desastre de vuit hores a cinquanta minuts. És la millora que més ha augmentat la disponibilitat, i no ha costat un euro en equipament.

Protecció de dades. Còpies automàtiques verificades, xifrades, guardades fora del servidor i —des d'aquest mes— impossibles d'esborrar des del mateix servidor durant 30 dies, que és la defensa concreta contra un atac de segrest de dades. I la capacitat de rebobinar la base de dades a qualsevol instant, assajada.

Seguretat. Tallafocs restrictiu, detecció d'intrusions, auditoria d'accessos, contrasenyes i certificats guardats xifrats, i el servei funcionant amb els mínims permisos possibles. Una avaluació automàtica independent puntua el nostre nivell d'enfortiment en 82 sobre 100, quan la instal·lació per defecte ronda el 60.

Rendiment. Ajust de la base de dades a la màquina real, que ha reduït els accessos a disc un 93 %. I una consulta d'informes que trigava 3,8 segons ara triga 0,18.

Visibilitat. Aquest és el canvi més recent i el que més canvia el dia a dia: un panell que respon en tres segons a «va bé?», amb històric de 30 dies, i alertes que avisen abans que el problema afecti els clients.

---

3. Incidents de l'any

Data	Què va passar	Impacte	Estat
17/08	El disc de còpies es va omplir i va bloquejar el registre de la base de dades	Cap: detectat abans	Resolt + alerta nova
18/08	Esborrat accidental de 40.218 reserves històriques	Cap: recuperades en 34 min	Resolt + 6 mesures
19/08	Errors durant 17 min per una operació de manteniment	~2.100 peticions fallides	Resolt + 7 mesures

Cap incident no va causar pèrdua de dades. Els tres es van analitzar amb el mateix mètode —què va passar, per què, què es canvia— i van generar quinze millores concretes, totes aplicades o amb data.

Vull destacar el del 18 d'agost: es van recuperar 40.000 reserves sense perdre res, fent servir un procediment que havíem assajat tres dies abans. Aquell assaig, que semblava burocràcia, es va pagar sol en 72 hores.

---

4. El que proposem acordar

Un objectiu de servei. Fins ara no en teníem cap, i sense ell no es pot decidir quant invertir. Proposem:

Concepte	Proposta	Què significa a la pràctica
Disponibilitat	99,8 % mensual	Com a màxim 1 h 26 min de fallada cada 30 dies
Dades recuperables	15 minuts	En el pitjor cas es perdrien 15 min de reserves
Temps de recuperació	2 hores	Des d'un desastre total fins al servei restablert
Finestra de canvis	Dimarts i dimecres al matí	Mai divendres a la tarda ni cap de setmana

Estem per damunt d'aquell objectiu avui (99,94 %). El proposem així a propòsit: un objectiu que ja es compleix amb folgança permet desplegar millores amb tranquil·litat, i un de massa exigent obligaria a frenar el desenvolupament del producte.

I una idea que vull explicar perquè canvia com decidim. Aquell 0,2 % de marge és un pressupost: el podem «gastar» en canvis i millores. Si un mes el consumim per sota de la meitat, continuem desplegant amb normalitat. Si ens acostem al límit, es congelen les funcions noves i es dedica l'esforç a estabilitzar. Converteix la discussió «anem massa ràpid?» en una consulta a un número. Aquest mes en portem consumit el 31 %.

---

5. El que fa falta

Prioritat alta, decisió de direcció:

1. Política de retenció de dades. Guardem l'històric d'activitat de l'aplicació sense termini definit, i ja ocupa més que totes les reserves juntes. A més de ser un problema d'espai, conservar dades personals sense termini determinat no és defensable davant del Reglament de Protecció de Dades. Necessito que es decideixi quant de temps guardem cada cosa; ho aplico en una setmana. Recomano assessoria legal per fixar els terminis.
2. Registre d'activitats de tractament. És un document que el RGPD exigeix i que no tenim. No és feina tècnica, però necessita la meva aportació.

Prioritat mitjana, inversió moderada:

3. Segon servidor d'aplicació amb repartiment de càrrega. És la recomanació que vaig analitzar en detall: eliminaria les interrupcions per desplegament i per fallada d'una màquina, que són la majoria. Cost: dues màquines i una setmana de feina, més tres o quatre setmanes de desenvolupament previ amb el Luis. Ens portaria del 99,8 % actual a un marge molt més folgat.
4. Rèplica de la base de dades. Justificada sobretot perquè permetria executar els informes pesants sense afectar el web, i de passada actualitzar sense tallar servei.

El que NO recomano, i vull deixar-ho per escrit:

• Arquitectura d'alta disponibilitat completa (cinc màquines, canvi automàtic de servidor). Analitzat amb números: costa diverses vegades més que l'opció 3 i aporta amb prou feines 670 € addicionals d'estalvi anual. I afegiria una complexitat que amb la plantilla actual no podem vigilar bé — un sistema sofisticat mal mantingut és menys fiable que un de senzill ben cuidat.
• Kubernetes, que és la tecnologia de moda. L'he muntat i avaluat a l'entorn de proves: per a la nostra mida consumiria entre dues i quatre setmanes de feina l'any només a mantenir-lo, per resoldre problemes que no tenim.

---

6. Riscos que assumim conscientment

Prefereixo que estiguin escrits que no pas que es descobreixin el dia dolent:

Risc	Conseqüència	Per què l'acceptem
Una sola màquina d'aplicació	Una fallada de maquinari = servei caigut fins a 2 h	La proposta 3 ho resoldria
Canvi manual de base de dades	5-15 min addicionals en aquell cas	Automatitzar-ho exigeix 5 màquines i crearia un risc més gran
Una sola persona amb coneixement operatiu	Vacances o baixa = resposta lenta	Mitigat en part: procediments escrits
Dependència d'un proveïdor	Una caiguda seva ens afecta sencers	Habitual a la nostra escala

El tercer és el que més em preocupa a mitjà termini, i és la raó que aquest any hagi dedicat tant d'esforç a escriure procediments: avui, algú amb coneixements tècnics generals podria seguir la majoria d'ells sense haver treballat mai al nostre sistema. Fa un any, no.

---

7. Conclusió

El sistema està en una situació considerablement millor que fa un any, i —el que més importa— està en una situació que puc demostrar amb dades en lloc d'afirmar amb confiança. Hem passat de «crec que va bé» a «99,94 %, aquí tens el panell».

El que queda pendent són sobretot decisions, no feina tècnica: quant de temps guardem les dades, quin nivell de servei ens comprometem a donar, i si invertim en el segon servidor. Amb aquelles tres decisions preses, tenim un sistema del qual es pot dependre.

El curs acaba on havia d'acabar: no en una eina més, sinó en la capa que converteix un servidor que funciona en un servei del qual es pot dependre. Tens una checklist de quaranta-dues files amb evidència comprovable a cadascuna, i saps exactament quines falten, que és una manera de saber més valuosa que creure que hi són totes. Tens monitoratge amb històric de trenta dies, alertes que es poden atendre perquè són poques i són de símptoma, i un panell que respon en tres segons a l'única pregunta que importa.

Sobretot tens criteri operatiu. Saps que monitorar i alertar no són el mateix i que cal fer molt del primer i molt poc del segon. Saps que una alerta amb precisió del 2 % és pitjor que cap, perquè entrena l'equip a ignorar el canal per on també arriben les bones. Saps que una revisió posterior a l'incident que busca culpables garanteix que el següent s'amagui, i que una acció correctiva del tipus «anar amb més compte» no és una acció sinó un desig. I saps que el pressupost d'error converteix «despleguem?» en una consulta a un número, amb la conclusió que sorprèn: gastar només el 5 % del pressupost significa haver estat massa conservador.

Els tres deutes estan tancats. La còpia externa ja no la pot esborrar el servidor que es copia, perquè un sistema que pot destruir les seves còpies no té còpies. L'authorized_keys2 va resultar ser el que solen ser aquestes coses: no una vulnerabilitat exòtica, sinó un fitxer d'un proveïdor de fa any i mig que continuava donant accés perquè ningú no l'havia mirat — i el que s'ha corregit no és el fitxer, és l'absència de revisió periòdica que va permetre que hi fos. I l'objectiu de disponibilitat existeix per fi, amb el seu número, la seva finestra i el seu pressupost.

I amb això es tanca el curs complet. Vuit mòduls.

Vas començar al Mòdul 1 sense saber què era un nucli, i vas muntar el sistema des d'una imatge d'instal·lació. Al 2 vas deixar de témer el terminal: permisos, inodes, enllaços i man com a primera parada. Al 3 el shell va deixar de ser un intèrpret d'ordres soltes i va passar a ser un llenguatge: canonades, find, awk, processos, senyals. Al 4 vas escriure scripts que no es trenquen —set -euo pipefail, trap, flock, idempotència—, i desplegar.sh amb la seva marxa enrere atòmica continua en producció cinquanta lliçons després. El 5 va ser l'administració de debò: usuaris, paquets amb fixació de versions, LVM, systemd enfortit, journal persistent, i unes còpies amb RPO i RTO acordats en lloc d'improvisats. El 6 va posar la seguretat com a disciplina i no com a llista de trucs: model d'amenaces, tallafocs de llista blanca, AIDE amb la seva base de dades fora, secrets xifrats i aquell certificat TLS que va esperar dos mòduls. El 7 va mirar sota el capó —arrencada, strace, perf, eBPF, el nucli, KVM, contenidors, Ansible— i va acabar amb l'anàlisi honesta de si calia alta disponibilitat. I el 8 ho va aplicar tot a construccions completes, de principi a fi.

El que t'endús d'aquí no és una llista d'ordres. És un mètode: mesurar abans i després, perquè un ajust sense mesurament és superstició. Provar a proves abans que a producció. --dry-run abans d'actuar. Còpia i diff -u abans d'editar. Validar abans de recarregar, sigui nginx -t, promtool check, testparm -s o pg_hba_file_rules. No tanquis mai la porta per la qual estàs entrant. Silenci si tot va bé. I dir sempre què protegeix i què no protegeix una mesura, que és el que separa un informe honest d'un argument de venda.

I una idea que ha aparegut a cada mòdul amb roba diferent: la resposta professional no sempre és que sí. No a l'arquitectura completa d'alta disponibilitat, no a Kubernetes, no a pujar max_connections, no a copiar sis terabytes al núvol. Saber dir que no, amb números i amb alternativa, val tant com saber-ho muntar.

Sobre com continuar. Les certificacions LPIC-1 i LPIC-2 o la RHCSA ordenen i acrediten el que ja saps; la RHCSA és pràctica i exigent, i preparar-la ensenya de debò. Les especialitzacions naturals des d'aquí són quatre: enginyeria de fiabilitat, que és aquesta última lliçó portada a escala; plataforma i núvol, on Kubernetes i la infraestructura com a codi són el dia a dia; ciberseguretat, prolongant el Mòdul 6; i bases de dades, prolongant 08-02. Participa a la comunitat —llistes, fòrums, un informe d'error ben escrit, una correcció de documentació— perquè explicar alguna cosa és la millor manera de descobrir si l'entens. I llegeix els canvis de les versions del nucli i de la teva distribució: és la manera més barata de no quedar-se enrere.

Però si només pots conservar una cosa, que sigui aquesta: mantén el laboratori. Aquella VM de proves, o el servidor multimèdia de 08-03, o el clúster de k3s que vas decidir no portar a producció. Un lloc propi on trencar coses a propòsit, provocar les fallades en horari laboral en lloc d'esperar-les, i provar el que encara no saps. Tot el que has après en aquest curs ho has après fent-ho, i aquella és l'única manera que hi ha. La diferència entre qui llegeix sobre sistemes i qui els administra no és el que ha estudiat: és el que ha trencat i ha tornat a aixecar. Encén la màquina i continua.