La lliçó anterior va donar a Reservalia estratègies perquè el relleu de versions sigui suau, però totes s'apuntalen en la mateixa suposició optimista: que la fallada es nota mentre el desplegament és en marxa. Moltes no. Apareixen tres hores després, quan el canary ja s'ha promocionat, o només per als negocis d'un país concret, o només el primer dia de mes. A més arrosseguem un problema anterior: avui a Reservalia desplegar i llançar són la mateixa acció, així que una funcionalitat a mig fer no pot arribar a main. Aquesta lliçó separa aquestes dues coses amb feature flags, construeix el botó de tornada enrere de Reservalia i converteix els 68 minuts de time to restore en un objectiu de deu.

1. Separar el desplegament del llançament
2. Tipus de feature flag, vida esperada i propietari
3. Una implementació mínima a apps/api
4. Fusionar codi incomplet a main sense branques de vida llarga
5. El deute de flags: per què caduquen i com es retiren
6. Rollback d'artefacte davant de roll-forward
7. El límit dur: la base de dades
8. El botó de tornada enrere: rollback.yml
9. Rollback automàtic disparat per mètriques
10. Recuperació d'incidents: mitigar primer, diagnosticar després
11. Post-mortem sense culpables
12. De 68 minuts a menys de 10
13. Errors Comuns i Consells
14. Exercicis
15. Conclusió

Són dos actes diferents que el costum ha fos en un:

• Desplegar és posar codi en producció: un acte tècnic, reversible, que pot passar vint vegades al dia.
• Llançar és fer que aquell codi sigui visible o efectiu per als usuaris: un acte de producte, amb data i amb màrqueting al darrere, que no ha de coincidir necessàriament amb l'anterior.

Quan tots dos coincideixen, apareixen les patologies que Reservalia coneix bé: branques de vida llarga esperant que la funcionalitat estigui "completa", desplegaments gegants carregats de canvis, i la impossibilitat d'apagar una cosa que va malament sense tornar a desplegar. Un feature flag (o toggle) és senzillament una condició al codi el valor de la qual es decideix en temps d'execució, fora de l'artefacte:

L'artefacte reservalia/api:a3f9c21 conté les dues implementacions. Quina s'executa ja no depèn de quina imatge està desplegada, sinó d'un valor que es pot canviar en segons i sense pipeline. Això converteix "apagar la funcionalitat trencada" en una operació de deu segons en lloc d'un desplegament.

No tots els flags són iguals, i tractar-los igual és la causa número u que un sistema de flags es podreixi. Reservalia adopta aquesta classificació:

Les dues columnes que més s'ignoren són les importants. La vida esperada distingeix el que s'ha d'esborrar del que s'hi queda: un flag de release que fa vuit mesos que és al codi és deute, un kill switch de vuit mesos és una eina. El propietari evita el flag orfe, aquell que ningú no gosa tocar perquè ningú no sap què passa si s'apaga.

No cal una plataforma comercial per començar. Reservalia desa els flags a la seva pròpia base de dades:

El mòdul d'avaluació viu a apps/api/src/flags/index.ts:

1. Un flag desconegut retorna false. El valor per defecte sempre és el comportament antic: si la taula no es pot llegir o algú ha escrit malament la clau, el sistema es comporta com abans del canvi, no com després.
2. La llista blanca permet activar la funcionalitat per a negocis concrets —els tres clients que van demanar la beta, o el negoci de proves intern— sense tocar el percentatge global.
3. El repartiment per percentatge es calcula amb un hash, no amb un número aleatori. És la diferència entre un desplegament progressiu i un caos: Math.random() < 0.1 donaria un resultat diferent a cada petició i el mateix negoci veuria la funcionalitat aparèixer i desaparèixer.
4. En incloure la clau al hash, dos flags al 10 % no afecten els mateixos negocis; si el hash fos només del negociId, sempre en sortirien els mateixos "escollits".
5. La memòria cau de 30 segons evita una consulta per petició. El preu és que un canvi triga fins a mig minut a propagar-se a totes les tasques: acceptable per a un kill switch, i cal saber-ho abans d'un incident.
6. L'avaluació és per negoci, no per usuari, i és una decisió de domini: a Reservalia tots els empleats d'un mateix saló han de veure la mateixa agenda. Activar per usuari faria que dues recepcionistes veiessin forats diferents, que és exactament el tipus d'incident irreproduïble que ningú no vol.

A la lliçó 02-07 va quedar establert que les branques de vida llarga són enemigues de la integració contínua: com més viuen, més divergeixen i més dolorós és el merge. Però l'equip tenia una objecció legítima: "no puc fusionar una funcionalitat a mig fer".

Els flags dissolen aquella objecció. En Diego pot fusionar calcularForatsV2 a main el primer dia, amb el flag agenda_nou_calcul en off: el codi viatja a producció a cada desplegament, es compila, passa el tsc --noEmit i les seves proves unitàries corren a la CI, però cap usuari no l'executa.

I una regla pràctica: les proves han de cobrir totes dues branques del flag; a la CI s'executa el conjunt crític amb el flag forçat a on i a off, perquè un flag la branca activa del qual no es prova mai és codi mort que es despertarà en el pitjor moment.

Cada flag de release afegeix una bifurcació al codi. Amb cinc flags convivint hi ha fins a 32 combinacions possibles de comportament, i ningú no prova 32 combinacions. Els flags no retirats produeixen símptomes concrets: codi il·legible, proves que depenen d'una configuració implícita, i el terror de tocar una cosa que "no se sap si encara es fa servir".

Reservalia estableix tres regles: tot flag de tipus release neix amb caduca_el obligatori, típicament a 30 dies vista; un job setmanal llista els flags caducats i obre una incidència assignada al seu propietari —no els esborra, perquè demanar una acció humana és diferent de trencar producció un dimarts—; i retirar el flag forma part de la tasca, no és una tasca futura: al tauler, una funcionalitat no està acabada fins que el seu flag ha desaparegut del codi.

La retirada té un ordre que evita ensurts: primer es posa el flag al 100 % i es deixa uns dies, després s'elimina la condició del codi deixant només la branca nova, i només al final s'esborra la fila de la taula. A l'inrevés —esborrar la fila primer— el flag passa a avaluar-se com a false i la funcionalitat ja llançada desapareix de cop.

Quan alguna cosa va malament en producció hi ha dos camins, i triar per reflex és un error.

Un equip madur no tria sempre el mateix. La regla que adopta Reservalia: si l'impacte és greu —usuaris que no poden reservar, errors 5xx, pèrdua de dades—, rollback sempre; l'arreglament es pensa després, amb calma i sense producció cremant. Si l'impacte és menor —un text mal traduït, una icona torta—, roll-forward, perquè un rollback també és un canvi i també pot fallar. Hi ha una condició que fa possible el rollback ràpid i que ja està pagada des de la 02-06: artefactes immutables identificats per digest. Tornar a b7e2d10 no vol dir reconstruir res, sinó apuntar el servei al digest que continua a ECR; reconstruir donaria una versió diferent amb les mateixes fonts, i això no és un rollback, és una loteria.

El rollback d'artefacte és reversible. La migració de base de dades que l'acompanyava, no. Si la versió c1d4a55 incloïa una migració que va reanomenar la columna duracio a duracio_min, tornar a b7e2d10 deixa corrent un codi que consulta una columna que ja no existeix: el rollback del contenidor triga tres minuts, el de l'esquema pot no existir.

D'aquí surt una regla que governa tot el disseny: una migració ha de ser compatible amb la versió anterior del codi i amb la següent. S'aconsegueix amb el patró expandir-contraure que vam veure a la 03-04 aplicat a les dades: afegir la columna nova, escriure a totes dues durant un temps, migrar lectures, i només molt després eliminar la vella. Mentre es respecti, qualsevol desplegament és reversible. El detall complet —migracions al pipeline, ordre respecte del desplegament, migracions llargues i bloquejos— és la lliçó 04-06, Bases de Dades al Pipeline: Migracions Segures.

La Nuria escriu el workflow que faltava. El seu requisit de disseny és explícit: qualsevol persona de guàrdia, sense conèixer AWS, ha de poder revertir en menys de cinc minuts des del mòbil.

Les decisions que fan que això funcioni sota pressió són aquestes:

1. workflow_dispatch amb entrades tipades. El type: choice elimina la possibilitat d'escriure produccio en lloc de prod a les tres de la matinada, i el motiu obligatori garanteix que el registre serveixi per al post-mortem.
2. El mateix grup de concurrency que cd.yml. Un rollback i un desplegament normal no es poden solapar; el segon espera en lloc de trepitjar el primer.
3. environment: ${{ inputs.entorn }} reutilitza les regles de protecció. Compte: si prod exigeix aprovació d'un revisor, el rollback també l'exigirà. Reservalia ho resol amb una llista d'aprovadors àmplia perquè sempre hi hagi algú disponible; bloquejar el rollback darrere d'una aprovació difícil d'aconseguir és pitjor que la fallada original.
4. Verificar que l'artefacte existeix abans de tocar res. Fallar de pressa amb un missatge clar és millor que deixar el servei a mig actualitzar. 5. Es reutilitza el mateix desplegar.sh del desplegament normal, que parteix de la definició de tasca vigent i només canvia la imatge pel digest indicat: així el rollback no reverteix canvis de configuració legítims fets des d'aleshores, i el camí d'emergència fa servir codi ja provat diàriament. 6. El smoke test contra /version converteix "em sembla que ha tornat" en "està servint b7e2d10"; sense ell, el rollback és una esperança.

La Marta hi afegeix una pràctica que sembla trivial i no ho és: assajar el rollback una vegada al mes a staging, cronometrat. Un botó que ningú no ha premut mai no és un botó, és un adorn.

Durant un canary no cal esperar que algú miri un panell; el mateix pipeline pot decidir:

El patró clau és if: failure(): el pas d'avortament s'executa precisament quan alguna cosa ha anat malament, i retorna el pes del canary a zero sense esperar un humà. A Reservalia, comprovar-metriques.sh compara el grup canary amb l'estable en taxa de 5xx i latència p95 durant els deu minuts de vigilància. Dues cauteles: l'automatisme necessita llindars amb marge, o un pic de soroll revertirà desplegaments sans i l'equip acabarà desactivant-lo; i ha d'existir sempre el camí manual, perquè si l'automatisme falla, rollback.yml continua sent-hi.

Un desplegament continu sa no presumeix de no fallar mai: presumeix de recuperar-se ràpid. L'ordre importa i és contraintuïtiu per a qui ve de la cultura del "cal entendre el problema abans de tocar res".

Mitigar primer, diagnosticar després. Mentre s'investiga la causa, els usuaris continuen sense poder reservar. Apagar el flag o revertir l'artefacte atura el dany i retorna el temps que cal per pensar: la causa arrel continuarà allà d'aquí a dues hores; els clients enfadats, no necessàriament. Reservalia fixa tres rols durant un incident: qui coordina (decideix i no tecleja), qui opera (executa les accions) i qui comunica (avisa el suport i els negocis afectats). En un equip de tres persones els rols es poden solapar, però la coordinació no pot faltar: sense ella, dues persones executen mitigacions contradictòries alhora. I la comunicació té una regla simple: abans poc i aviat que tard i complet; un missatge als cinc minuts dient "estem investigant problemes en crear cites" val més que un informe perfecte al cap d'una hora.

Un post-mortem blameless parteix d'una premissa: si una persona ha pogut trencar producció amb una acció raonable, el problema és el sistema que l'hi va permetre. Buscar culpables produeix ocultació, i l'ocultació produeix incidents que es repeteixen. Reservalia fa servir aquesta plantilla, a docs/postmortems/:

Dos apartats solen faltar i són els més útils: "què va funcionar bé", que evita desmuntar defenses que sí que van servir, i accions amb propietari i data, perquè un post-mortem sense accions assignades és un exercici literari. I una regla: les accions es fiquen al mateix tauler que la resta de la feina, o no es faran.

El time to restore no és un número màgic: és la suma de tres trams, cadascun atacat amb una eina diferent.

Val la pena assenyalar quin tram s'endú la millora més gran: la detecció. Es pot tenir el millor botó de rollback del món i continuar trigant mitja hora si ningú no s'assabenta que hi ha un problema; aquell tram és justament el que la lliçó següent s'encarrega de tancar. I hi ha un cas encara millor: quan la fallada és darrere d'un flag, l'execució baixa a segons i el total ronda els cinc minuts.

Error 1: fer servir flags com a configuració permanent. Si flags acumula 60 claus de les quals 50 són de release i ningú no les retira, el codi es torna inauditable. Error 2: flags sense propietari ni caducitat, que ningú no gosa apagar anys després. Error 3: avaluar per atzar en lloc de per hash, amb la qual cosa el mateix negoci veu la funcionalitat aparèixer i desaparèixer entre peticions. Error 4: no provar la branca activa del flag; la CI dona verd i la funcionalitat esclata el dia que s'encén.

Error 5: un rollback que reconstrueix la imatge des del commit anterior. Això no és tornar a una versió coneguda, és construir-ne una de nova sota pressió: es desplega el digest, sempre. Error 6: no assajar mai el rollback, i descobrir que el rol IAM havia caducat justament durant l'incident.

Consell 1: fes que el valor per defecte de tot flag sigui el comportament antic, perquè una fallada de lectura sigui innòcua. Consell 2: registra cada canvi de flag amb autor i data, perquè en un incident la pregunta "què ha canviat?" inclou els flags, no només els desplegaments. Consell 3: documenta al README les tres ordres d'emergència —apagar flag, llançar rollback.yml, posar el canary a 0— on el de guàrdia les trobi en vint segons.

Classifica aquests quatre flags de Reservalia per tipus, proposa vida esperada i propietari, i digues quin no s'ha de retirar mai: pagaments_stripe_v2 (nova passarel·la de pagament que substitueix l'antiga), recordatoris_sms (enviament d'SMS amb cost per missatge), panel_metriques_beta (panell disponible només per a clients del pla avançat) i experiment_horaris_suggerits (dues maneres d'ordenar els forats proposats).

Són les 22:40. El desplegament de c1d4a55 fa vint minuts ha disparat la taxa d'errors de l'endpoint de creació de cites al 30 %. La versió anterior era b7e2d10. El canvi incloïa una migració que va afegir la columna recordatori_enviat_el. Descriu els passos exactes en ordre i justifica si tries rollback o roll-forward.

Mateix escenari, però la migració va reanomenar duracio a duracio_min. Continua sent vàlid el teu pla? Descriu què faries i què s'hauria d'haver fet diferent setmanes abans perquè aquest escenari no existís.

Solució 1. pagaments_stripe_v2 és de release: el seu objectiu és substituir la passarel·la antiga, així que té data de caducitat (unes setmanes, potser més pel que té de delicat el pagament), el seu propietari és qui el desenvolupa, i es retira quan el 100 % porti temps estable. experiment_horaris_suggerits és d'experiment: propietari de producte, viu el que duri el mesurament i acaba triant una variant. panel_metriques_beta és de permisos: el seu propietari és producte/negoci, és permanent i en realitat no és un flag temporal sinó una regla de drets d'accés lligada al pla contractat. recordatoris_sms és operatiu (kill switch) i és el que no es retira mai: com que els SMS costen diners i depenen d'un proveïdor extern, la Nuria necessita poder apagar-los en calent si el proveïdor es degrada o si el cost es dispara. Un matís útil: pagaments_stripe_v2, encara que sigui de release, convé mantenir-lo un temps prudencial després del 100 % perquè de facto actua com a kill switch de la passarel·la nova.

Solució 2. Rollback, sense dubtar-ho: l'impacte és greu (un terç de les creacions de cita falla), la versió anterior era sana i la migració és compatible —afegir una columna no molesta b7e2d10, que simplement la ignora—. Passos: (1) declarar l'incident i nomenar coordinador; (2) si el canvi és darrere d'un flag, apagar-lo, que són deu segons davant dels cinc minuts del rollback; (3) si no ho és, llançar rollback.yml amb entorn=prod, sha=b7e2d10 i el motiu; (4) confirmar amb el smoke test que /version retorna b7e2d10 i comprovar que la taxa d'errors baixa; (5) comunicar-ho al suport i als negocis afectats; (6) l'endemà, diagnosticar amb calma, arreglar, afegir la prova que faltava i desplegar cap endavant; (7) post-mortem amb accions assignades. La columna nova queda òrfena un temps, cosa que és inofensiva.

Solució 3. No, el pla ja no val: b7e2d10 consulta duracio, que ja no existeix, així que el rollback canviaria un error del 30 % per un error del 100 %. Les opcions reals són pitjors: roll-forward urgent amb un arreglament escrit sota pressió, o revertir també l'esquema —reanomenar la columna cap enrere— amb el risc de perdre escriptures fetes entremig. El que és raonable és mitigar per una altra via (apagar el flag si existeix, degradar la funcionalitat afectada) mentre es prepara l'arreglament cap endavant. El que s'hauria d'haver fet setmanes abans és aplicar expandir-contraure: desplegament 1, afegir duracio_min i escriure a totes dues columnes; desplegament 2, llegir de duracio_min; desplegament 3, setmanes després i amb tot estable, eliminar duracio. Amb aquella seqüència, cada desplegament individual és reversible i l'escenari de l'enunciat no arriba a produir-se. Aquest és exactament el territori de la lliçó 04-06.

Separar el desplegament del llançament canvia la naturalesa del risc. Els feature flags permeten a Reservalia fusionar codi incomplet a main sense branques de vida llarga, activar per negoci i amb repartiment estable per hash, i apagar en calent el que es trenqui —sempre que cada flag neixi amb tipus, propietari i data de caducitat, perquè el deute de flags és real—. El rollback d'artefacte per digest, materialitzat a rollback.yml amb workflow_dispatch, retorna producció a un estat conegut en minuts, i el rollback automàtic per mètriques ho fa sense esperar un humà durant un canary. Tot això amb un límit dur que convé tenir sempre present: si la migració de base de dades no és compatible, no hi ha tornada enrere que valgui.

Amb això, dos dels tres trams del time to restore de Reservalia estan resolts: la decisió, per una regla escrita, i l'execució, per un botó assajat. Queda el més gran, la detecció: avui Reservalia s'assabenta que producció va malament perquè truca un client. I hi ha una mancança bessona: sense senyal de producció, ni el canary automàtic ni el pressupost de desplegaments tenen sobre què decidir. La lliçó següent, Monitoratge i Retroalimentació, tanca el bucle amb els tres pilars de l'observabilitat, els quatre senyals d'or, els SLO amb pressupost d'error i l'alimentació automàtica de les mètriques DORA des del mateix pipeline.