Si preguntes a la direcció d'AlpinaShop quin nivell de servei espera de la botiga, la resposta serà «que no caigui mai». És una resposta comprensible i completament inútil, per tres motius: no es pot complir, no es pot mesurar, i no permet decidir res.

No es pot complir perquè el 100 % de disponibilitat no existeix: falla el maquinari, falla la xarxa del client, falla el proveïdor de DNS, falla un desplegament, s'equivoca una persona. No es pot mesurar perquè ningú no ha definit què compta com a «caiguda». I no permet decidir res perquè si l'objectiu és la perfecció, qualsevol inversió en fiabilitat està justificada i cap no és suficient, cosa que a la pràctica significa que les decisions es prenen per intuïció.

La lliçó anterior va acabar assenyalant exactament això: AlpinaShop paga l'alta disponibilitat de Cloud SQL, ha duplicat els túnels VPN i manté el balancejador global sense cap objectiu declarat que justifiqui aquestes tres decisions amb números. I arrossega des de 07-04 un deute qualificat de crític: ningú no ha comprovat mai que les còpies de seguretat es puguin restaurar.

Aquesta lliçó converteix la fiabilitat en enginyeria. En acabar sabràs definir SLI, SLO i SLA amb precisió, calcular i fer servir un pressupost d'error per decidir quan es desplega i quan es para, crear SLO i alertes per consum de pressupost a Cloud Monitoring, triar el nivell d'alta disponibilitat de cada component sabent què costa i què aporta, dissenyar contra els modes de fallada reals, i tenir un pla de recuperació de desastres amb RTO i RPO — assajat, no escrit.

1. Què significa fiabilitat i per què la perfecció no és un objectiu
2. SLI, SLO i SLA: les tres sigles que tothom confon
3. Triar bons SLI per a AlpinaShop
4. Els SLO d'AlpinaShop, amb les seves consultes reals
5. Pressupost d'error: què és i per a què serveix de debò
6. SLO a Cloud Monitoring i alertes per consum de pressupost
7. Arquitectures d'alta disponibilitat per nivells
8. Modes de fallada i la seva mitigació
9. Recuperació de desastres: RTO, RPO i estratègies
10. El pla de recuperació d'AlpinaShop
11. Còpies que no s'han provat no existeixen
12. Pràctica operativa: guàrdies, runbooks i post mortem
13. Proves de caos a escala raonable

Fiabilitat és la probabilitat que un sistema faci el que s'espera d'ell durant un període determinat. No és una propietat binària: és una magnitud contínua que es tria, es paga i es gestiona.

La corba que cal tenir al cap:

Cada nou addicional multiplica el cost, i no de manera lineal. Passar de 99 % a 99,9 % sol ser qüestió de bones pràctiques. Passar de 99,99 % a 99,999 % requereix multiregió actiu-actiu, guàrdies 24×7, enginyeria dedicada i acceptar que desplegues molt més a poc a poc.

I l'altra meitat de l'equació, la que gairebé mai no es calcula:

Amb 1.200 comandes al mes i un tiquet mitjà de 65 €, passar de 99,9 % a 99,99 % estalviaria a AlpinaShop uns 70 € al mes en comandes no perdudes — i li costaria multiregió actiu-actiu, és a dir, diversos centenars d'euros mensuals més la feina d'enginyeria.

La conclusió incòmoda i correcta: per a AlpinaShop, 99,99 % seria una mala inversió. I saber dir això amb números a la mà, en lloc de perseguir nous per inèrcia, és de les coses més valuoses que pot aportar un enginyer.

Amb dos matisos que cal fer explícits:

1. No tot el temps val igual. Quaranta minuts de caiguda de matinada al febrer no costen gairebé res; quaranta minuts el divendres de la campanya de tardor poden costar vint vegades més. La disponibilitat importa ponderada per trànsit.
2. Hi ha costos que no són comandes perdudes: reputació, clients que no tornen, suport, i —en un incident llarg— el desgast de l'equip.

La relació entre els tres, que és el que cal interioritzar:

Tres regles que eviten gairebé tots els errors:

1. El SLO sempre és més exigent que el SLA. Si promets 99,5 % i el teu objectiu intern és 99,5 %, incompliràs el contracte la meitat de les vegades. La pràctica habitual és un marge folgat: SLA 99,5 %, SLO 99,9 %.
2. El SLI es mesura des d'on és l'usuari, no des d'on és còmode. Un servidor que respon perfectament mentre el balancejador retorna 502 té un SLI del 100 % i un usuari furiós.
3. Un SLO sense conseqüència és un adorn. Si en incomplir-lo no canvia res, no és un objectiu: és un número en un tauler.

I una definició precisa de SLI que resol la majoria dels dubtes:

SLI = esdeveniments bons / esdeveniments vàlids

Tot el que és difícil és definir aquests dos termes. Compta com a «dolent» un 404? (No: l'usuari va demanar una cosa que no existeix.) I un 429 del limitador de taxa? (Depèn: si és un atac, no; si és un client legítim, sí.) I una petició d'un robot rastrejador? (Probablement no hauria de ser un esdeveniment vàlid.) Aquestes decisions són el 80 % de la feina de definir un SLI, i cal prendre-les per escrit.

Un bon SLI compleix quatre condicions:

L'error més comú és mesurar el fàcil en lloc de l'important. La CPU és facilíssima de mesurar i no li importa a cap client. Els «quatre senyals d'or» —latència, trànsit, errors i saturació— són un bon punt de partida, però només els dos primers i el tercer són candidats a SLI; la saturació és una causa, no una experiència.

Els quatre SLI d'AlpinaShop, triats recorrent el viatge del client:

Esdeveniments vàlids: peticions HTTP al balancejador amb rutes de la botiga, excloent-hi rastrejadors coneguts. Esdeveniments bons: les que retornen codi < 500.

Decisions preses i anotades:

Esdeveniments vàlids: les mateixes peticions que al SLI 1. Esdeveniments bons: les que se serveixen en menys de 800 ms.

Compte amb l'error clàssic: un SLI de latència no és «el p95 és menor que X». És la proporció de peticions més ràpides que X. La diferència importa: un percentil no es pot combinar amb un pressupost d'error, i una proporció sí.

El llindar de 800 ms no es tria per intuïció: es mesura la distribució actual, es comprova on és el punt a partir del qual els usuaris abandonen, i es tria un valor que avui es compleixi folgadament però que detecti una degradació real.

El més important dels quatre, perquè és el que toca els diners.

Esdeveniments vàlids: intents de pagament iniciats. Esdeveniments bons: els que acaben en confirmació o en un rebuig legítim de la passarel·la (fons insuficients, targeta caducada).

El matís que el fa correcte: un rebuig de la passarel·la per fons insuficients no és una fallada nostra. Comptar-lo com a error faria que el SLI depengués de la solvència dels clients, no de la qualitat del sistema. El que sí que compta com a dolent: temps d'espera esgotats, errors 5xx, excepcions i transaccions que queden en estat indeterminat.

Diferent dels anteriors perquè no és una petició: és un procés.

Esdeveniments vàlids: execucions programades del pipeline de comandes. Esdeveniments bons: les que deixen les dades a BigQuery amb menys de 2 hores de retard.

Fixa't que no hi ha SLI de CPU, memòria, nombre d'instàncies ni mida de la cua. Tot això es monitora —cal per diagnosticar— però no és un objectiu de nivell de servei, perquè a cap client no li importa.

Per què 28 dies i no un mes natural: una finestra mòbil de 28 dies conté exactament quatre setmanes, així que sempre inclou el mateix nombre de caps de setmana i de dilluns. Amb mesos naturals, febrer i març no són comparables, i el pressupost es «reinicia» el dia 1, cosa que crea l'incentiu pervers d'esperar al canvi de mes per desplegar el que és arriscat.

Les consultes reals, sobre les mètriques de 06-04, en PromQL —que és el llenguatge que Cloud Monitoring admet avui juntament amb MQL:

Per al pagament, es fa servir la mètrica personalitzada que l'aplicació ja emet des de 06-04:

La separació entre rechazado_legitimo i error_tecnico és una decisió d'instrumentació que cal prendre al codi, i és exactament on es veu si algú ha pensat el SLI o l'ha copiat. Si l'aplicació només registra «èxit» i «fallada», el SLI de pagament és irreparablement ambigu.

Pressupost d'error = 100 % − SLO

Amb un SLO del 99,9 % en 28 dies, el pressupost és del 0,1 %: 40 minuts i 19 segons d'indisponibilitat, o el seu equivalent en peticions fallides.

La taula de «nous» traduïda a temps, que convé tenir a mà:

Aquí hi ha la part que transforma el concepte de curiositat en eina de gestió. El pressupost d'error resol la tensió permanent entre desenvolupament i operacions:

Sense un criteri objectiu, aquesta tensió es resol per autoritat, per cansament o per qui crida més. Amb pressupost d'error, es resol amb un número:

Mentre quedi pressupost, es desplega. Quan s'esgota, es para i s'estabilitza.

I això converteix la fiabilitat en una cosa que desenvolupament també vol, perquè un sistema fràgil consumeix el pressupost i li impedeix lliurar funcionalitats. L'incentiu deixa d'estar enfrontat.

Escrita, acordada i al README d'alpinashop-infra:

I la clàusula que fa que la política sigui creïble:

Si el pressupost s'esgota per una fallada de la plataforma de Google i no pels nostres canvis, es documenta i no es congela. L'objectiu és corregir el que està a la nostra mà, no castigar l'equip pel que no controla.

Sense aquesta clàusula, la primera caiguda regional de Google convertiria la política en una cosa que l'equip deixaria de respectar — i una política que s'ignora és pitjor que no tenir-ne.

El pressupost d'error no és un objectiu que calgui minimitzar. Si al final dels 28 dies n'has consumit el 5 %, no has guanyat: probablement eres massa conservador i podies haver lliurat més ràpid, o el teu SLO és massa lax i no reflecteix el que els usuaris noten.

Un pressupost que no es toca mai és tan mal senyal com un que sempre s'esgota. El consum sa ronda el 50-80 %.

Cloud Monitoring té suport natiu per a SLO, i val la pena fer-lo servir en lloc de construir-lo a mà.

I en Terraform, que és on ha de viure:

Dos tipus de SLI que cal distingir:

Per a AlpinaShop, basat en peticions. Amb un matís honest: de matinada, amb tres peticions per minut, un sol error és el 33 % d'aquell minut. Els SLI basats en peticions són sorollosos amb trànsit baix, i per això les alertes de l'apartat següent exigeixen finestres llargues per als llindars suaus.

Aquesta és la part més valuosa de l'apartat, i substitueix les alertes de llindar fix de 06-04.

La taxa de consum (burn rate) és quantes vegades més ràpid del que és sostenible s'està gastant el pressupost:

• Taxa 1 = a aquest ritme, el pressupost s'esgota exactament al final dels 28 dies. És el ritme sostenible.
• Taxa 14,4 = s'esgota en 2 dies.
• Taxa 6 = s'esgota en poc menys de 5 dies.

El problema d'alertar sobre un llindar fix d'errors és conegut: si el llindar és sensible, hi ha falses alarmes; si és lax, no detecta degradacions lentes. Les alertes de taxa de consum resolen les dues coses amb dues alertes complementàries.

Per què dues finestres per alerta. La finestra llarga (1 h) evita falses alarmes per un pic de trenta segons. La finestra curta (5 min) fa que l'alerta s'apagui ràpid quan el problema es resol — sense ella, una alerta amb finestra d'una hora continuaria sonant cinquanta minuts després d'arreglada la fallada. És un detall petit amb un impacte enorme en la vida de qui està de guàrdia.

El bloc documentation és el més important de la política, i el que gairebé tothom deixa buit. Una alerta que arriba al mòbil a les 3 de la matinada amb el text «Llindar superat» obliga la persona a reconstruir el context mig adormida. Una que arriba amb els tres primers passos i l'enllaç al runbook converteix quinze minuts de desorientació en dos d'acció. Es desenvolupa a l'apartat 12.

L'alta disponibilitat es construeix eliminant punts únics de fallada, i es fa per nivells, cadascun amb el seu preu.

La freqüència relativa de cada esdeveniment és el que hauria de guiar la decisió, i poques vegades es mira:

L'última fila és la que canvia les prioritats: la majoria de les caigudes no les provoca la infraestructura, sinó un canvi. Invertir en multiregió mentre no tens desplegament canari ni reversió ràpida és blindar la porta i deixar la finestra oberta. AlpinaShop va fer el correcte: primer pipeline i reversió (mòdul 6 i 07-02), després arquitectura.

Observació important: una part gran de l'arquitectura d'AlpinaShop ja és multiregió sense esforç, perquè els serveis globals de Google ho són per disseny. El balancejador, DNS, CDN, Armor, Firestore, BigQuery i Secret Manager no requereixen cap decisió. Els dos components que sí que són regionals i crítics són Cloud Run i Cloud SQL.

Mereix detall perquè es paga el doble i molta gent no sap què compra.

L'última fila és la que cal subratllar. HA regional protegeix contra fallades d'infraestructura. No protegeix contra un DELETE FROM pedidos sense WHERE, que es replica a l'instant a la instància en espera. Per a això hi ha les còpies de seguretat i la recuperació a un punt en el temps — apartat 11.

Documentat a alpinashop-infra com a disseny llest per activar:

Tres comandes. El balancejador global envia cada petició a la regió més propera amb capacitat, i si una regió falla, deixa d'enviar-li trànsit automàticament.

El que impedeix activar-ho avui no és Cloud Run: és Cloud SQL. Amb la base de dades només a europe-west1, les instàncies de Madrid haurien de creuar regió a cada consulta —latència i cost de trànsit— i si cau europe-west1, la base de dades cau igual. L'alta disponibilitat la determina el component menys disponible, i a AlpinaShop aquest és Cloud SQL.

Els sistemes distribuïts fallen de maneres concretes i conegudes. Dissenyar contra elles és més rendible que afegir redundància.

El primer és distingir dos tipus, perquè el tractament és oposat:

La fallada de disseny més comuna és tractar una dependència tova com si fos dura. Un recomanador que triga 5 segons no ha de fer que la pàgina de producte trigui 5 segons: ha de desaparèixer de la pàgina.

Tota crida de xarxa ha de tenir un temps d'espera. Sense excepcions.

Un temps d'espera absent o massa llarg és el mecanisme pel qual una fallada petita es converteix en una caiguda total: les peticions s'acumulen esperant, s'esgoten els fils, i el servei deixa de respondre a tot, inclòs el que no depenia del sistema lent.

Regla d'or: el temps d'espera d'una crida sempre ha de ser menor que el temps d'espera de qui la crida. Si Cloud Run talla als 60 s i la teva consulta espera 90 s, aquest codi no s'executa mai.

Reintentar està bé. Reintentar malament empitjora la fallada:

Els quatre elements, i per què cadascun:

1. Retrocés exponencial: donar temps que l'altre es recuperi.
2. Jitter: sense ell, mil clients que van fallar alhora reintenten alhora, creant una ona sincronitzada que torna a tombar el servei just quan s'estava aixecant. És una fallada real i freqüent, i el jitter costa una línia.
3. Límit d'intents: reintentar indefinidament converteix una fallada en un atac al teu propi sistema.
4. Només errors transitoris: reintentar un 400 o un 403 no ho arreglarà mai; només gasta temps i recursos.

Quan un servei porta una estona fallant, deixa de cridar-lo:

El benefici doble: qui crida deixa d'esperar (falla en microsegons en lloc de en segons) i qui falla deixa de rebre càrrega, cosa que li permet recuperar-se.

El principi que fa que una fallada parcial sigui invisible:

La botiga continua venent encara que el recomanador falli.

Els tres nivells són la clau del patró: pla A el recomanador; pla B alguna cosa simple i local —els més venuts de la categoria, que gairebé ningú no distingirà—; pla C res, i la pàgina se serveix igual. Un client pot comprar en els tres casos, que és l'única cosa que importa.

I el detall que fa possible mesurar-ho: el registre porta "degradado": true. Sense aquesta marca, el servei funciona degradat durant setmanes i ningú no se n'assabenta, perquè el SLI de disponibilitat continua en verd. Una alerta sobre el percentatge de peticions degradades és el que evita que la degradació elegant es converteixi en degradació silenciosa.

Quan la demanda supera la capacitat, hi ha dues opcions: degradar per a tothom o rebutjar-ne alguns i servir bé la resta. La segona és gairebé sempre millor.

L'últim és el més sofisticat i el més útil: quan hi ha saturació, no totes les peticions valen el mateix. Un usuari en el procés de pagament val molt més que un rastrejador indexant la pàgina 47 del catàleg.

Alta disponibilitat i recuperació de desastres no són el mateix, i confondre-les porta a arquitectures cares que no protegeixen del que de debò passa:

Una dada que reordena prioritats: la causa més freqüent de pèrdua de dades no és un desastre natural ni un atac. És algú executant alguna cosa a l'entorn equivocat. I contra això, l'alta disponibilitat no serveix de res: replica l'error fidelment.

Amb còpies diàries a les 3:00 i un desastre a les 10:15, el RPO real són 7 hores i 15 minuts de dades perdudes. Per a AlpinaShop, això serien les comandes de tot un matí: inacceptable.

Com es tria, i no és per la tecnologia: es calcula el cost d'una hora de caiguda i es compara amb el cost mensual de cada estratègia. Per a AlpinaShop, una hora de caiguda en un dia normal són uns 100 € de comandes; en campanya, potser 800 €. Amb aquests números, actiu-actiu —diversos centenars d'euros al mes, tots els mesos— no es justifica.

Escrit, amb responsables, i desat també fora de Google Cloud (perquè si el desastre és d'accés a Google Cloud, el pla ha de ser accessible).

L'escenari 2 és el més probable amb diferència, i el seu RTO de 5 minuts ja està resolt des de 07-02. És un bon recordatori que la feina de fiabilitat més rendible ja estava feta abans d'aquesta lliçó.

Les quatre línies que fan la feina:

• point_in_time_recovery_enabled = true és el que converteix un RPO de 24 hores en un RPO de minuts. Sense ella, només es pot restaurar al moment de l'última còpia; amb ella, a qualsevol instant dins de la finestra de registres de transaccions.
• location = "eu" desa les còpies fora de la regió. Còpies a la mateixa regió que mor amb la regió no són còpies: són una il·lusió.
• transaction_log_retention_days = 7 defineix la finestra de recuperació puntual. Set dies cobreixen el cas «algú va esborrar una cosa el dilluns i ens en vam adonar el dijous».
• deletion_protection impedeix l'esborrat accidental de la instància sencera.

Les dades no són l'única cosa que cal poder reconstruir:

Aquí es paga el deute que 07-04 va marcar com a crític.

Una còpia de seguretat no provada no és una còpia de seguretat: és una esperança amb nom tècnic.

Els motius pels quals una restauració falla el dia que cal, tots reals i tots freqüents:

Procediment complet, executat trimestralment per la Marta, i cronometrat.

Pas 1 — Preparar i anotar l'hora d'inici.

Pas 2 — Restaurar a una instància NOVA.

Mai sobre la de producció. La restauració crea una instància a part, cosa que fa l'assaig totalment segur:

Pas 3 — Verificar la integritat, que és el que gairebé ningú no fa.

Restaurar sense verificar només demostra que la comanda funciona:

Pas 4 — Arrencar l'aplicació contra la còpia restaurada.

Aquest és el pas que descobreix els problemes de debò:

Pas 5 — Cronometrar, netejar i documentar.

I aquí hi ha el valor de l'exercici, perquè el primer assaig no surt mai bé:

Cinc problemes que haurien convertit una restauració d'1 hora en una de 3 hores, amb la botiga aturada i tothom mirant. I cap no era detectable sense assajar.

Les cinc correccions es van escriure en un guió d'actuació (runbook), es va automatitzar la creació de l'usuari i el reajustament de seqüències en un script de post-restauració, i es va ajustar el RTO de l'escenari 3 d'1 hora a 90 minuts, que és un número honest.

L'assaig no serveix per confirmar que les còpies funcionen. Serveix per trobar els cinc problemes que impedeixen que funcionin.

La fiabilitat la sostenen persones, i un equip cremat és el risc de fiabilitat més gran que existeix. Amb tres persones tècniques, una guàrdia 24×7 tradicional és inviable: serien dues setmanes de cada tres de disponibilitat permanent.

El model realista d'AlpinaShop:

I les regles que ho fan sostenible, que importen tant com el calendari:

1. Només desperta el que cal arreglar ja. Si una alerta arriba de matinada i l'acció és «mirar-ho demà», aquesta alerta no ha de sonar de nit. És la regla que més redueix el desgast.
2. Compensació real. Hores o diners, acordat per escrit. La guàrdia no remunerada dura fins que algú se'n cansa.
3. Màxim dues nits interrompudes seguides. Si passa, es relleva.
4. Tota alerta nocturna es revisa l'endemà: era necessària? Si no, s'ajusta o s'elimina.
5. Menys alertes és millor. La fatiga d'alertes (06-04) és un problema de fiabilitat: una persona que ha après a ignorar el mòbil ignorarà també la que importava.

Un runbook és el document que diu què fer davant d'una alerta concreta. Viu a alpinashop-infra/runbooks/ i s'enllaça des del camp documentation de la política d'alerta.

gcloud run revisions list --service=alpinashop-web --region=europe-west1 --limit=5

gcloud run services update-traffic alpinashop-web --region=europe-west1
--to-revisions=REVISION_ANTERIOR=100

Les tres propietats d'un runbook útil: comença per confirmar (no per diagnosticar), posa primer la causa més probable —un desplegament recent, en el 70 % dels casos—, i diu explícitament quan escalar, perquè la persona de guàrdia no es quedi sola donant voltes a les 4 de la matinada.

I una quarta que es veu a la capçalera: «Provat en simulacre: sí». Un runbook que ningú no ha executat mai és una hipòtesi.

Després d'un incident significatiu, un document amb estructura fixa:

Sense culpables (blameless) no significa que no hi hagi responsabilitats. Significa una cosa molt concreta:

Si la resposta a «per què va passar» és el nom d'una persona, l'anàlisi s'ha aturat massa aviat.

Exemple aplicat:

La raó pràctica —no moral— de l'absència de culpa: en una cultura on es busca el culpable, la gent amaga els errors, i els errors amagats no es corregeixen. En una cultura sense culpa, la gent explica el que va passar i el sistema millora. És una decisió d'eficàcia.

Tots els post mortem en un lloc, amb etiquetes. Al cap d'un any permet veure patrons que cap incident aïllat no revela: «el 60 % dels nostres incidents són desplegaments» és una frase que canvia les prioritats d'un equip sencer.

Enginyeria del caos és provocar fallades a propòsit per verificar que el sistema les tolera. Netflix va popularitzar la idea matant instàncies en producció; una pime no necessita això, però sí que necessita alguna cosa.

Tot sistema té proves de recuperació de desastres. Uns les fan a propòsit; altres esperen que passin.

Els experiments d'AlpinaShop, ordenats de menys a més agressiu:

Les regles que fan això responsable en lloc de temerari:

1. Hipòtesi escrita abans. Si no saps què esperes, no és un experiment: és trencar coses.
2. Començar en desenvolupament.
3. Radi d'explosió petit, i ampliar-lo només quan l'anterior va sortir bé.
4. Un botó d'aturada i la capacitat d'avortar en qualsevol moment.
5. Mai en campanya. Ni el divendres a la tarda.
6. Avisar l'equip. El caos no anunciat amb guàrdies reals és una broma pesada.

L'experiment 3 mereix un comentari, perquè espanta i no hauria de fer-ho: la commutació de Cloud SQL passarà algun dia, triada per Google i en el pitjor moment. Provocar-la un dimarts a les 10 del matí, amb tothom davant i amb la possibilitat d'arreglar-ho, és infinitament millor que descobrir un divendres de campanya que l'aplicació no reconnecta perquè li falta pool_pre_ping (07-02).

I l'experiment 7 és el més subestimat: que només la Marta sàpiga revertir un desplegament és un punt únic de fallada humana. Que en Dani i la Lucía ho hagin fet almenys un cop cadascun val més que qualsevol redundància d'infraestructura.

• Posar com a objectiu «que no caigui mai». No es pot complir, mesurar ni fer servir per decidir. Tria un número i paga'l.
• Confondre SLO i SLA. El SLO sempre més exigent que el SLA, amb marge folgat.
• Mesurar el SLI des del servidor. Es mesura des d'on és l'usuari: el balancejador o una comprovació externa.
• Definir el SLI de latència com «el p95 < X». És «la proporció de peticions < X». Un percentil no es combina amb un pressupost d'error.
• Comptar els rebuigs legítims de la passarel·la com a errors. El SLI passaria a dependre de la solvència dels clients.
• SLO sobre CPU o memòria. No són experiència d'usuari. Es monitoren, no es converteixen en objectiu.
• Finestres de mes natural. Creen l'incentiu d'esperar al dia 1 per desplegar el que és arriscat. Finestra mòbil de 28 dies.
• Un SLO sense política associada. Si en incomplir-lo no canvia res, és un adorn.
• Congelar per esgotar el pressupost quan la culpa va ser de la plataforma. La política perd credibilitat i l'equip deixa de respectar-la.
• Perseguir un pressupost consumit al 5 %. Senyal d'excés de conservadorisme o d'un SLO massa lax.
• Alertes de llindar fix sobre errors. O són sorolloses o no detecten degradacions lentes. Fes servir taxa de consum amb dues finestres.
• Deixar buit el camp documentation de l'alerta. A les 3 de la matinada, aquest text val més que la mateixa alerta.
• Crides de xarxa sense temps d'espera. És el mecanisme pel qual una fallada petita es converteix en caiguda total.
• Reintents sense jitter. Mil clients reintentant alhora tomben el servei just quan es recuperava.
• Reintentar errors permanents. Un 403 no millora per insistir.
• Tractar una dependència tova com a dura. El recomanador no ha de poder tombar la fitxa de producte.
• Degradar sense marcar-ho als registres. El servei funciona a mitges durant setmanes i el SLI continua verd.
• Còpies a la mateixa regió. No són còpies: són una il·lusió.
• Creure que HA protegeix d'un esborrat accidental. El replica a l'instant a la instància en espera.
• No provar la restauració. És el deute més perillós perquè és invisible fins al dia que importa.
• Guàrdies sense compensació. Duren fins que algú se'n cansa, i llavors et quedes sense guàrdies i sense persona.
• Buscar culpables en un post mortem. Els errors s'amaguen, i els errors amagats no es corregeixen.
• Consell: comença per un SLO de disponibilitat i res més. Quatre SLO des del primer dia és massa. Un de bo val més que quatre de copiats.
• Consell: la reversió ràpida val més que la redundància. La causa més freqüent de caiguda és un canvi, no una fallada de maquinari.
• Consell: que tot l'equip sàpiga revertir un desplegament. És la redundància més barata que existeix.
• Consell: cronometra l'assaig de restauració. El número real sempre sorprèn, i és el que dona un RTO honest.

En Dani llançarà alpinashop-buscador (el servei de l'exercici de 07-02). Defineix el seu SLI i el seu SLO complets:

1. Quins esdeveniments són vàlids i quins bons, resolent explícitament almenys sis casos límit.
2. El SLO i la finestra, justificats.
3. El pressupost d'error resultant en minuts i en peticions.
4. Les dues alertes de taxa de consum amb els seus llindars.
5. La política de què es fa en cada estat del pressupost.

Considera que el cercador és una dependència tova del catàleg: si falla, es pot mostrar un enllaç a la navegació per categories.

AlpinaShop llança AlpinaPro, un servei de subscripció per a clubs de muntanya: quota mensual, contingut exclusiu i reserves de material. Dades:

• 400 subscriptors, 25 €/mes cadascun: 10.000 €/mes d'ingrés recurrent.
• Base de dades pròpia alpinapro-suscripciones (PostgreSQL).
• Integració amb la passarel·la per a cobraments recurrents el dia 1 de cada mes.
• Els clubs reserven material amb 48 h d'antelació; una reserva perduda és una queixa seriosa.
• Direcció diu que «no es pot caure mai», però el pressupost addicional és de 150 €/mes.

Dissenya: els SLI i SLO del servei, el RTO i RPO justificats amb números de negoci, l'estratègia de recuperació triada dins del pressupost, i la configuració concreta de còpies. Explica què li respons a direcció sobre el «no es pot caure mai».

Els fets. Dimarts, 18:42. Salta l'alerta de consum ràpid. Cronologia reconstruïda:

• 18:30 — Cloud Build desplega la revisió alpinashop-web-00051 amb canari al 10 %. Les proves de fum passen.
• 18:38 — La Marta aprova el pas al 100 % (tenia pressa, marxava a les 18:45).
• 18:42 — Alerta: taxa de consum 22×. Errors 500 en el 35 % de les peticions.
• 18:44 — La Marta veu l'alerta ja al cotxe. No pot actuar.
• 18:51 — En Dani, avisat per la Marta, es connecta i reverteix a la revisió 00050.
• 18:53 — Els errors desapareixen.
• Impacte: 11 minuts, ~230 peticions fallides, 4 comandes perdudes, 27 % del pressupost mensual consumit.
• Causa tècnica: la revisió nova llegia una variable d'entorn TARIFA_ENVIO que només estava definida a alpinashop-dev.

Escriu el post mortem complet seguint l'estructura de l'apartat 12, amb els cinc perquès portats fins a una causa sistèmica, i almenys cinc accions concretes amb responsable. Assenyala també què va fer bé l'equip.

Solució 1 — Definir el SLO d'alpinashop-buscador

1. Definició del SLI.

SLI de disponibilitat = peticions de cerca amb resposta útil / peticions de cerca vàlides

Casos límit, resolts i anotats:

El cas «0 resultats» és el que més discussió genera i és important encertar-lo. Comptar-lo com a dolent faria que el SLI mesurés la qualitat del catàleg en lloc de la fiabilitat del servei, i baixaria cada vegada que algú busca alguna cosa que no venem. La qualitat de la cerca es mesura a part, amb mètriques de producte —taxa de cerques sense resultat, taxa de clic— que no són un SLO.

SLI de latència = cerques servides en < 500 ms / cerques vàlides

500 ms i no 800 ms com el catàleg, perquè un cercador és interactiu: l'usuari escriu i espera. La percepció de lentitud apareix abans.

2. SLO i finestra.

La justificació del 99,5 % és la part interessant de l'exercici. El cercador és una dependència tova: si falla, el catàleg mostra un enllaç a la navegació per categories i el client pot continuar comprant. Un servei tou no necessita el mateix objectiu que un de crític, i posar-li 99,9 % significaria gastar diners i enginyeria en una fiabilitat que no canvia el resultat de negoci.

Aquest és el raonament que cal endur-se: el SLO es deriva de l'impacte de negoci de la fallada, no de l'estima que es tingui al servei.

3. Pressupost d'error.

Amb 99,5 % sobre 28 dies: 0,5 % = 3 h 21 min 36 s.

En peticions: si el cercador rep unes 150.000 cerques vàlides en 28 dies, el pressupost són 750 cerques fallides.

És còmode, i a propòsit: permet desplegar millores del cercador amb freqüència sense que una fallada puntual bloquegi l'equip.

4. Les dues alertes.

Cap de les dues no desperta ningú, i aquesta és la conseqüència lògica de ser una dependència tova amb SLO del 99,5 %. Aixecar-se a les 4 de la matinada perquè el cercador falla, quan la botiga continua venent, és exactament el tipus d'alerta que produeix fatiga i fa que s'ignori la que sí que importa.

L'excepció que cal preveure: si el cercador cau i a més el catàleg comença a fallar —perquè el temps d'espera no tallava i es van esgotar els fils—, l'alerta que sonarà és la del catàleg, que sí que és de pàgina. El disseny d'alertes ha de reflectir el disseny de dependències.

5. Política de pressupost.

La fila vermella és la clau de l'exercici. Quan un servei tou esgota el seu pressupost, la pregunta prioritària no és «com el faig més fiable» sinó «està ben aïllat?». Un cercador que falla el 2 % del temps sense afectar ningú és un problema menor; un cercador que falla el 0,5 % del temps i cada fallada degrada la fitxa de producte és un problema greu.

Solució 2 — Dissenyar un pla de recuperació per a AlpinaPro

Punt de partida: traduir el negoci a números.

I aquí hi ha el matís que distingeix una anàlisi bona d'una de superficial: en un servei de subscripció, l'ingrés no es perd per estar caigut. Els 400 subscriptors paguen igual. El que es perd és una altra cosa, i és pitjor:

Conclusió: una caiguda de 4 hores que provoqui 5 baixes costa 3.000 €, no 55 €. L'anàlisi per ingrés prorratejat subestima l'impacte en més d'un ordre de magnitud, i és un error molt comú en serveis de subscripció.

SLI i SLO proposats.

El tercer és el més interessant i el que se sol oblidar. El cobrament recurrent no és un servei continu: és un procés que s'executa un dia al mes. Un SLO mensual sobre ell no té sentit; el que cal és un objectiu diferent: «el 99,99 % dels cobraments programats s'executen correctament dins de les 24 hores següents», amb reintents. I un tractament arquitectònic específic: cua amb reintents i DLQ, no una execució única que o funciona o es perd.

RTO i RPO justificats.

Estratègia dins de 150 €/mes.

Pressupost molt just. Repartiment:

Estratègia triada: llum pilot. La base de dades replicada a la segona regió és l'única cosa que es manté encesa; el còmput a Cloud Run s'aixeca amb tres comandes (apartat 7) perquè la imatge ja existeix i Cloud Run escala des de zero. RTO estimat: 30-60 minuts, millor que l'objectiu de 6 h.

El que no es fa i per què: actiu-actiu costaria 400-600 €/mes per cobrir un esdeveniment de probabilitat molt baixa, quan el pressupost sencer són 150 €.

Configuració de còpies.

Dues decisions a assenyalar: la finestra de manteniment el dimecres, deliberadament lluny del dia 1 —un manteniment de Google durant el cicle de cobraments seria el pitjor moment possible—, i la rèplica de DR en mode ZONAL, perquè pagar HA per a una rèplica que només es fa servir en un desastre és duplicar el cost d'una assegurança.

Què se li respon a direcció.

«No podem garantir que no caigui mai, i qui ho prometi no diu la veritat. El que sí que podem fer és decidir quant estem disposats que caigui i pagar-ho.

Amb els 150 € al mes que tenim, el compromís és aquest: si falla una màquina o un centre de dades concret, es recupera sol en cinc minuts i sense perdre cap dada. Si algú esborra alguna cosa per error, ho recuperem en dues hores perdent com a màxim cinc minuts de reserves. I si caigués una regió sencera de Google —una cosa molt poc freqüent però possible—, estaríem funcionant en menys d'una hora des de Madrid.

Per al procés de cobrament del dia 1 tenim un tractament a part, perquè és el moment crític del mes: si alguna cosa falla, es reintenta automàticament durant 24 hores i cap cobrament no es perd.

El que no cobrim amb aquest pressupost és la caiguda simultània de dues regions o un problema global de Google. Cobrir-ho costaria entre tres i quatre vegades més, tots els mesos, per a un escenari que potser no passarà mai.

I hi ha una cosa que vull demanar a més del pressupost: provar tot això cada trimestre. Un pla de recuperació que no s'assaja no funciona el dia que cal, i ho sabem perquè ens va passar amb la botiga: la primera vegada que vam provar de restaurar la base de dades vam trobar cinc problemes que haurien triplicat el temps de recuperació.»

Solució 3 — Post mortem de l'incident de les 18:42

Post mortem: errors 500 al catàleg després del desplegament 00051

Data de l'incident: dimarts 2026-08-04, 18:42-18:53 Autora: Marta Ruiz · Revisat per: Dani, Lucía Estat: accions en curs · Classificació: sense culpables

Resum. Un desplegament promocionat al 100 % del trànsit contenia codi que depenia d'una variable d'entorn inexistent en producció, i va provocar errors 500 en el 35 % de les peticions durant 11 minuts.

Impacte.

Cronologia.

Causa arrel — els cinc perquès.

1. Per què van fallar les peticions? El codi llegia os.environ["TARIFA_ENVIO"], que no existia en producció, i llançava KeyError.
2. Per què no existia? Es va afegir a alpinashop-dev durant el desenvolupament i no es va propagar a producció.
3. Per què no es va propagar? Les variables d'entorn de producció es gestionen en Terraform, però el desenvolupament les configura amb gcloud a mà. No hi ha cap mecanisme que garanteixi la paritat.
4. Per què no ho va detectar el canari? Les proves de fum només comproven /salud i /producto/1, i cap d'aquestes rutes no fa servir TARIFA_ENVIO (només la del carret). A més el canari va durar 8 minuts amb trànsit baix.
5. Per què es va promocionar al 100 % amb aquesta cobertura? Perquè el procés permet aprovar manualment sense cap comprovació automàtica de la revisió candidata, i l'aprovació es va donar amb pressa al final de la jornada.

Causa arrel sistèmica: no existeix verificació automàtica que una revisió candidata tingui tota la seva configuració present a l'entorn de destinació, ni una comprovació objectiva que hagi de passar abans de la promoció al 100 %. L'aprovació manual és l'únic control i depèn de l'estat i la disponibilitat d'una persona.

Què va anar bé — i aquesta secció importa tant com l'anterior:

• L'alerta va funcionar: 4 minuts des del primer error fins a la notificació. Exactament el que 06-04 i les alertes de taxa de consum prometien.
• La reversió va ser trivial: una comanda, 2 minuts, sense reconstruir res. La feina de 07-02 es va pagar sola en aquest incident.
• L'escalat va funcionar: la Marta, sense poder actuar, va avisar en Dani en 3 minuts en lloc d'intentar arreglar-ho conduint.
• El pressupost d'error va fer la seva feina: va convertir «11 minuts, no va ser per tant» en «el 27 % del pressupost mensual», que és una dada que obliga a actuar.
• Ningú no va buscar culpables durant l'incident. Es va arreglar primer i es va analitzar després.

Accions.

Nota sobre l'acció 5. Podria semblar una regla burocràtica que alenteix l'equip, i val la pena justificar-la: no es prohibeix desplegar a la tarda —el canari pot córrer tota la nit al 10 %— sinó promocionar al 100 % quan no queda ningú disponible per reaccionar. La restricció no és sobre el risc del canvi, sinó sobre la capacitat de resposta. Aquesta distinció és la que fa que l'equip accepti la regla en lloc de saltar-se-la.

El que aquest incident NO va ser. No va ser un error d'en Dani per escriure codi que llegeix una variable, ni de la Marta per aprovar amb pressa. Va ser un sistema que permetia promocionar al 100 % del trànsit un canvi la configuració del qual ningú no havia verificat, en un moment en què ningú no podia reaccionar. Qualsevol dels tres hauria fet el mateix, i per això les set accions són sobre el sistema i cap sobre les persones.

AlpinaShop ha deixat d'aspirar a «que no caigui mai» i ha començat a gestionar la fiabilitat amb números.

Saps que cada nou multiplica el cost i has fet el càlcul que gairebé ningú no fa: passar de 99,9 % a 99,99 % estalviaria a AlpinaShop uns 70 € al mes en comandes i li costaria diversos centenars. Dir «99,99 % seria una mala inversió» amb la taula davant és una de les aportacions més valuoses d'un enginyer, i requereix haver calculat també els dos matisos: que no tot el temps caigut val igual i que hi ha costos que no són comandes perdudes.

Distingeixes SLI, SLO i SLA amb precisió, amb les tres regles que eviten gairebé tots els errors —el SLO sempre més exigent que el SLA, el SLI mesurat des d'on és l'usuari, i un SLO sense conseqüència no és un objectiu— i amb la definició operativa que resol els dubtes: esdeveniments bons / esdeveniments vàlids, on la feina de debò és decidir què és cada cosa.

Has triat quatre SLI recorrent el viatge del client —disponibilitat, latència, èxit del pagament i frescor analítica— resolent per escrit els casos límit: el 404 és bo, el 429 a un atacant ni tan sols és vàlid, i un rebuig per fons insuficients no és una fallada nostra, decisió que cal prendre al codi instrumentant rechazado_legitimo davant d'error_tecnico. I saps per què no hi ha SLI de CPU: perquè a cap client no li importa.

Domines el pressupost d'error: la taula de nous traduïda a minuts, la finestra mòbil de 28 dies que evita l'incentiu pervers del mes natural, i sobretot per a què serveix de debò — resoldre amb un número la tensió entre desplegar ràpid i no trencar res, amb una política de quatre estats i la clàusula de credibilitat de no congelar quan la fallada va ser de la plataforma. Amb l'ús que gairebé ningú no fa: un pressupost consumit al 5 % és tan mal senyal com un d'esgotat.

Saps crear SLO a Cloud Monitoring des de Terraform, distingir SLI basats en peticions de basats en finestres, i muntar alertes de taxa de consum amb dos llindars i dues finestres cadascun — la llarga per evitar falses alarmes, la curta perquè l'alerta s'apagui quan el problema s'arregla. I saps que el camp documentation, que gairebé tothom deixa buit, val més a les 3 de la matinada que la mateixa alerta.

Tens les arquitectures d'alta disponibilitat per nivells amb la taula component a component d'AlpinaShop, l'observació que bona part de la plataforma ja és multiregió sense esforç perquè els serveis globals de Google ho són, i les dues peces que sí que són regionals i crítiques. Saps exactament què compres amb l'HA de Cloud SQL —replicació síncrona de disc, una altra zona, commutació en 1-2 minuts— i què no cobreix: un DELETE sense WHERE es replica a l'instant. I saps que Cloud Run multiregió són tres comandes, però que no s'activa perquè la disponibilitat la determina el component menys disponible.

Dissenyes contra els modes de fallada: dependències dures i toves —amb la fallada de disseny més comuna, tractar-ne una de tova com a dura—, temps d'espera en tota crida de xarxa amb la regla que l'intern sempre sigui menor que l'extern, reintents amb retrocés exponencial i jitter per no crear ones sincronitzades, interruptors de circuit, degradació elegant en tres nivells amb la marca "degradado": true sense la qual la degradació es torna silenciosa, i limitació de càrrega amb descàrrega per prioritat.

Saps que alta disponibilitat i recuperació de desastres no són el mateix, i la dada que reordena prioritats: la causa més freqüent de pèrdua de dades és algú executant alguna cosa a l'entorn equivocat, i contra això l'HA no serveix perquè replica l'error. Manegues RTO i RPO i les quatre estratègies amb el seu cost, triant per comparació amb el cost real d'una hora de caiguda.

Tens el pla d'AlpinaShop amb set escenaris —on el més probable, un desplegament defectuós, ja estava resolt des de 07-02—, la configuració de còpies amb les quatre línies que fan la feina (point_in_time_recovery, location = "eu", retenció de registres i deletion_protection) i l'exportació de configuració, inclòs el pla de DR desat fora de Google Cloud.

I has pagat el deute crític de 07-04: l'assaig de restauració, cronometrat, amb verificació d'integritat i amb l'aplicació arrencada contra la còpia. Amb el resultat que importa: cinc problemes trobats —47 minuts en lloc d'«uns minuts», l'usuari de l'aplicació inexistent, permisos que faltaven, seqüències desincronitzades i cap procediment escrit— que haurien triplicat el temps de recuperació real. L'assaig no confirma que les còpies funcionen: troba els cinc problemes que impedeixen que funcionin.

Finalment, tens la pràctica operativa: guàrdies sostenibles per a tres persones amb la regla que més desgast evita —si l'acció és «mirar-ho demà», aquesta alerta no sona de nit—, runbooks enllaçats des de les alertes que comencen per la causa més probable i diuen quan escalar, post mortem sense culpables amb la raó pràctica i no moral d'aquesta cultura, i proves de caos a escala raonable amb les seves sis regles, on l'experiment més subestimat és que tot l'equip sàpiga revertir un desplegament.

Tot el d'aquesta lliçó funciona perquè hi ha tres persones que ho sostenen. I aquí hi ha el límit: els SLO viuen en un tauler que algú manté, la política de pressupost d'error es respecta perquè l'equip la va acordar, els runbooks s'actualitzen perquè la Marta se'n recorda, i res no impedeix tècnicament que demà algú creï una VM amb IP pública en una regió dels Estats Units, o desactivi un registre d'auditoria, o esborri per error un projecte sencer.

Això ja no és fiabilitat: és govern. I és l'única cosa que queda per construir. L'organització d'AlpinaShop té avui cinc projectes, tres carpetes, desenes de comptes de servei, quatre repositoris, un perímetre a mitges i cap política que governi el conjunt — més una llista de deutes de 07-04 que comença per «polítiques d'organització sense aplicar» i «registres d'auditoria sense retenció immutable».

L'última lliçó del mòdul tanca el cercle: estructura de l'organització, polítiques que s'hereten i s'apliquen soles, inventari de tot el que existeix, auditoria de debò amb retenció immutable, i zones d'aterratge desplegades amb Terraform — perquè el que s'ha construït seguint AlpinaShop no depengui que tres persones se'n recordin.