El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

L'alta disponibilitat (HA, High Availability) és la propietat d'un sistema que continua prestant servei encara que fallin alguns dels seus components. Al món real el maquinari es trenca, les xarxes es tallen i el programari té errors: la pregunta no és si alguna cosa fallarà, sinó quan. Un sistema ben dissenyat assumeix la fallada com una cosa normal i es prepara per sobreviure-hi. En aquesta lliçó aprendràs a mesurar la disponibilitat amb SLA, SLO i SLI, entendràs què signifiquen "els nous" de disponibilitat, i veuràs les tècniques que fan possible que un sistema resisteixi fallades: redundància, failover automàtic, degradació elegant i comprovacions de salut (health checks).

Contingut

SLA, SLO i SLI: el llenguatge de la disponibilitat
Els nous de disponibilitat
Redundància: eliminar els punts únics de fallada
Failover: commutació automàtica davant de fallades
Degradació elegant (graceful degradation)
Health checks: detectar que alguna cosa va malament
Errors habituals i consells
Exercicis

SLA, SLO i SLI: el llenguatge de la disponibilitat

Per parlar de disponibilitat amb rigor necessitem tres conceptes que sovint es confonen:

Terme	Què és	Qui el fixa	Exemple
SLI (Indicator)	La mètrica que mesures	Equip tècnic	% de peticions amb resposta < 300 ms
SLO (Objective)	L'objectiu intern sobre l'SLI	Equip/Producte	"99,9% de peticions OK al mes"
SLA (Agreement)	El compromís contractual amb el client	Negoci/Legal	"99,5% o retornem els diners"

La relació és jeràrquica: l'SLI és el mesurament en brut, l'SLO és la meta que et poses internament, i l'SLA és la promesa formal al client (amb penalitzacions si s'incompleix). Per prudència, l'SLA sempre es fixa per sota de l'SLO: si el teu objectiu intern és 99,9% però promets 99,5%, tens marge de seguretat.

D'aquí neix un concepte clau: el pressupost d'error (error budget). Si el teu SLO és 99,9% mensual, et "permets" un 0,1% de fallades. Aquest 0,1% és pressupost que pots gastar en desplegar canvis arriscats. Si l'esgotes, congeles els desplegaments i et centres en l'estabilitat.

Pressupost d'error mensual amb SLO = 99,9%
  Temps total del mes:      30 dies = 43.200 minuts
  Disponibilitat exigida:   99,9%
  Temps de caiguda permès:  0,1% de 43.200 = 43,2 minuts/mes

És a dir, amb un SLO de 99,9% pots estar caigut com a màxim 43 minuts al mes sense incomplir el teu objectiu.

Els nous de disponibilitat

La disponibilitat s'expressa com a percentatge de temps en servei, i col·loquialment es compta per "nous". Cada nou addicional redueix dràsticament el temps de caiguda permès i multiplica el cost.

Disponibilitat	"Nous"	Caiguda a l'any	Caiguda al mes	Caiguda a la setmana
90%	un nou	36,5 dies	72 hores	16,8 hores
99%	dos nous	3,65 dies	7,2 hores	1,68 hores
99,9%	tres nous	8,76 hores	43,2 min	10,1 min
99,99%	quatre nous	52,6 min	4,32 min	1,01 min
99,999%	cinc nous	5,26 min	25,9 seg	6,05 seg

Els cinc nous (99,999%) són llegendaris en telecomunicacions, però exigeixen una inversió enorme: redundància total, diversos centres de dades, automatització completa. La pregunta d'arquitectura no és "quants nous puc aconseguir?" sinó "quants nous necessita realment el negoci i està disposat a pagar?". Passar de 99,9% a 99,99% pot multiplicar el cost per deu per estalviar unes poques hores a l'any.

Redundància: eliminar els punts únics de fallada

Un punt únic de fallada (SPOF, Single Point Of Failure) és qualsevol component la caiguda del qual tomba tot el sistema. La base de l'alta disponibilitat és eliminar els SPOF mitjançant redundància: tenir més d'una còpia de cada component crític.

Hi ha dos models de redundància:

Model	Descripció	Avantatge	Inconvenient
Actiu-Passiu	Una rèplica activa i una altra en espera	Senzill, sense conflictes	La rèplica passiva està ociosa
Actiu-Actiu	Totes les rèpliques atenen trànsit	Aprofita tots els recursos	Més complex (sincronització)

graph TD
    LB[Balancejador] --> A[Node A - actiu]
    LB -.standby.-> B[Node B - passiu]
    A --> DBp[(BD Primària)]
    DBp -.replicació.-> DBs[(BD Rèplica)]

En aquest esquema actiu-passiu, el node B només entra en joc si A cau, i la base de dades rèplica rep una còpia contínua de les dades per poder substituir la primària. La regla pràctica: identifica cada component i pregunta't "què passa si això cau?". Si la resposta és "es cau tot", tens un SPOF que has de replicar.

Failover: commutació automàtica davant de fallades

Tenir redundància no serveix de res si ningú no l'activa quan cal. El failover és el procés de detectar la fallada d'un component i commutar automàticament a la seva rèplica. Dues mètriques defineixen la seva qualitat:

RTO (Recovery Time Objective): quant de temps trigem a recuperar el servei. Segons? Minuts?
RPO (Recovery Point Objective): quantes dades ens podem permetre perdre, mesurat en temps. L'última transacció? Els últims 5 minuts?

                  Fallada
                    |
   ----[ dades a resguard ]----X----[ servei caigut ]----[ servei recuperat ]----
        <----- RPO ----->                  <-------- RTO -------->
        (dades perdudes)                     (temps sense servei)

Un RPO de zero significa "no perdre cap dada" (requereix replicació síncrona, més lenta). Un RTO de segons requereix failover totalment automatitzat.

# Exemple: failover gestionat per health checks en un balancejador (HAProxy)
backend servidores_web
  option httpchk GET /health        # Comprova la salut amb GET /health
  default-server inter 2s fall 3 rise 2
  server web1 10.0.0.1:8080 check   # Comprovat activament
  server web2 10.0.0.2:8080 check backup   # Només es fa servir si web1 cau

Explicació: option httpchk GET /health indica que HAProxy cridarà periòdicament l'endpoint /health de cada servidor. inter 2s comprova cada 2 segons; fall 3 marca el servidor com a caigut després de 3 fallades seguides; rise 2 el reactiva després de 2 encerts. El web2 ... backup només rep trànsit quan web1 està caigut: això és failover automàtic actiu-passiu.

Degradació elegant (graceful degradation)

De vegades no es pot mantenir tot el servei, però sí una part. La degradació elegant consisteix a continuar oferint la funcionalitat essencial encara que es perdin funcions secundàries, en lloc de caure per complet. És preferible un servei "a mig gas" que una pantalla d'error.

Exemple: si el servei de recomanacions d'una botiga cau, el web ha de continuar venent, simplement sense mostrar recomanacions.

// Patró de degradació amb un valor de reserva (fallback)
public List<Producto> obtenerRecomendaciones(String userId) {
    try {
        // Intentem cridar el servei de recomanacions
        return servicioRecomendaciones.recomendar(userId);
    } catch (ServicioNoDisponibleException e) {
        // Si falla, NO trenquem la pàgina: retornem els més venuts.
        log.warn("Recomanacions no disponibles, fent servir el fallback", e);
        return catalogo.masVendidos();
    }
}

Aquí, si el servei de recomanacions no respon, capturem l'excepció i retornem una llista alternativa (els més venuts) en lloc de propagar l'error a l'usuari. La pàgina continua funcionant, només que amb una experiència lleugerament reduïda.

Aquest patró es combina sovint amb el Circuit Breaker (tallacircuits): si un servei falla repetidament, el tallacircuits "s'obre" i deixa de cridar-lo durant un temps, retornant directament el fallback. Així s'evita saturar un servei ja malalt i s'accelera la resposta.

Health checks: detectar que alguna cosa va malament

No pots reaccionar a una fallada que no detectes. Els health checks (comprovacions de salut) són endpoints que informen de l'estat d'una instància. Es distingeixen dos tipus essencials en orquestradors com Kubernetes:

Tipus	Pregunta que respon	Què passa si falla
Liveness	Està viu el procés?	Es reinicia el contenidor
Readiness	Està a punt per rebre trànsit?	Se li deixa d'enviar trànsit (sense reiniciar)

La distinció és crucial: una instància pot estar viva però no a punt (per exemple, arrencant o reconnectant a la base de dades). En aquest cas no volem reiniciar-la (liveness OK), però sí deixar d'enviar-li peticions (readiness KO).

# Sondes de salut en un Pod de Kubernetes
livenessProbe:
  httpGet:
    path: /health/live      # El procés continua viu?
    port: 8080
  initialDelaySeconds: 10    # Espera 10s després d'arrencar abans de la 1a sonda
  periodSeconds: 5           # Comprova cada 5 segons
readinessProbe:
  httpGet:
    path: /health/ready     # Pot atendre peticions?
    port: 8080
  periodSeconds: 5

Línia a línia: la livenessProbe crida /health/live; si falla, Kubernetes reinicia el contenidor. L'initialDelaySeconds: 10 evita reinicis prematurs mentre l'app arrenca. La readinessProbe crida /health/ready; si falla, Kubernetes retira aquest Pod del balanceig però el deixa viu perquè es recuperi. Un bon /health/ready ha de comprovar les dependències crítiques (base de dades, cues) i no limitar-se a retornar "OK" sempre.

Errors habituals i consells

Confondre SLA, SLO i SLI. Recorda: SLI mesures, SLO et proposes, SLA promets. L'SLA va sempre per sota de l'SLO.
Perseguir nous innecessaris. Cada nou addicional costa moltíssim més. Ajusta la disponibilitat a la necessitat real del negoci.
Redundància que comparteix un SPOF ocult. Dos nodes al mateix rack, amb la mateixa font d'alimentació o el mateix proveïdor cloud comparteixen un punt de fallada. La veritable redundància distribueix els riscos.
Health check trivial. Un /health que sempre retorna 200 és inútil: ha de comprovar de debò les dependències crítiques.
No provar mai el failover. Un mecanisme de failover que no s'assaja periòdicament probablement no funcionarà el dia real. Practica amb simulacres (Chaos Engineering).
Consell: assumeix que tot fallarà i dissenya per a això. La fiabilitat es construeix, no s'espera.

Exercicis

Càlcul de disponibilitat. El teu sistema va estar caigut 4 hores en un any. Quina disponibilitat percentual vas oferir i a quants "nous" equival aproximadament?
Disseny de health checks. Un servei es reinicia en bucle contínuament. En investigar-ho, veus que la seva livenessProbe apunta a un endpoint que comprova la connexió a una base de dades lenta que triga a arrencar. Què està malament i com ho arreglaries?
Estratègia de continuïtat. Defineix un RTO i un RPO raonables per a (a) un blog corporatiu i (b) un sistema de pagaments bancari, justificant-ne la diferència.

Solucions

Hi ha 8.760 hores en un any. Disponibilitat = (8.760 - 4) / 8.760 = 8.756 / 8.760 = 99,954%. Això supera els tres nous (99,9% permetia 8,76 h) però no arriba als quatre nous (99,99% només permetia 52,6 min). Està, per tant, entre tres i quatre nous.
L'error és que la liveness probe comprova una dependència externa lenta. Mentre la base de dades arrenca, la sonda falla, Kubernetes creu que el procés està mort i el reinicia, entrant en bucle. Solució: la liveness només ha de comprovar que el procés respon (una cosa trivial i ràpida); la comprovació de la base de dades pertany a la readiness probe, que retira el Pod del trànsit sense reiniciar-lo. Convé, a més, ajustar initialDelaySeconds.
(a) Blog corporatiu: un RTO d'hores i un RPO d'hores (fins i tot un dia) són acceptables; perdre l'últim article o estar caigut una estona no és crític, prima el baix cost. (b) Pagaments bancari: un RTO de segons/minuts i un RPO de zero; no es pot perdre cap transacció ni deixar d'operar, la qual cosa justifica replicació síncrona i failover automàtic encara que sigui car. La diferència reflecteix l'impacte de negoci de cada caiguda.

Conclusió

Has après a mesurar la disponibilitat (SLI/SLO/SLA i els nous), a entendre el seu cost creixent, i a aplicar les tècniques que fan un sistema resistent: redundància per eliminar SPOF, failover per commutar automàticament, degradació elegant per no caure del tot, i health checks per detectar els problemes a temps. L'alta disponibilitat és, en essència, assumir que la fallada és inevitable i dissenyar perquè l'usuari amb prou feines la noti.

Un sistema disponible però insegur és un sistema vulnerable. A la lliçó següent, Seguretat per Disseny i Autenticació/Autorització, veurem com protegir l'aplicació davant d'atacs des del primer moment del disseny.

Alta Disponibilitat i Tolerància a Fallades

Contingut

SLA, SLO i SLI: el llenguatge de la disponibilitat

Els nous de disponibilitat

Redundància: eliminar els punts únics de fallada

Failover: commutació automàtica davant de fallades

Degradació elegant (graceful degradation)

Health checks: detectar que alguna cosa va malament

Errors habituals i consells

Exercicis

Solucions

Conclusió

Curs d'Arquitectura d'Aplicacions

Mòdul 1: Fonaments de l'Arquitectura d'Aplicacions

Mòdul 2: Principis i Tàctiques de Disseny

Mòdul 3: Estils i Patrons Arquitectònics

Mòdul 4: Arquitectures Distribuïdes i Microserveis

Mòdul 5: Arquitectures Dirigides per Esdeveniments i Missatgeria

Mòdul 6: Disseny Dirigit pel Domini (DDD)

Mòdul 7: Dades i Persistència

Mòdul 8: Arquitectura al Núvol i Desplegament

Mòdul 9: Qualitat, Seguretat i Observabilitat

Mòdul 10: Evolució, Governança i Casos Pràctics