A 08-02 el sistema de TechCorp va quedar complet com a codi: sis serveis, un gateway, una llibreria i les seves proves. Aquesta lliçó el porta a un clúster i l'opera. La primera meitat respon a "com aixeco tot això des de zero?": el repositori techcorp/plataforma complet, el compose.yaml local amb els sis serveis i tota la infraestructura, l'ordre d'arrencada en un clúster nou, l'script que ho aplica, els Job de migració i la prova de fum amb un token de Keycloak. La segona meitat respon a "i què faig cada dia?": un desplegament normal de servei-comandes de punta a punta, la campanya de Black Friday, un incident en una DLQ pas a pas, la rotació d'un secret, l'actualització de Node i una evolució de contracte aplicada a tot el sistema, més una taula d'operacions freqüents i el cost mensual aproximat.

No reexpliquem cap YAML de 05-02 ni cap codi: quan aparegui un Deployment, un ServiceMonitor o un ExternalSecret, remetrem a la lliçó on es va escriure i mostrarem només el que canvia en passar d'un servei a sis.

1. El repositori techcorp/plataforma complet
2. compose.yaml: el sistema sencer en un portàtil
3. Ordre d'arrencada en un clúster nou
4. scripts/desplegar-tot.sh i els Job de migració
5. Verificació i prova de fum
6. Operació: un desplegament normal de servei-comandes
7. Operació: la campanya de Black Friday
8. Operació: un incident a pagaments.estoc.dlq, pas a pas
9. Operació: rotar un secret, actualitzar Node i evolucionar un contracte
10. Runbook ràpid d'operacions freqüents
11. Cost mensual aproximat i com reduir-lo

És el repositori de l'equip de Plataforma i la font de veritat de producció (Argo CD el llegeix, 05-03 §6). Tot el que hi hem anat deixant al llarg del curs, ordenat:

Dues decisions que sostenen l'arbre: una base per servei, un overlay per entorn (05-02 §12: la base d'Inventari és la de Comandes amb noms, port 3006 i el seu ScaledObject en lloc d'HPA), i els tercers per Helm amb values versionats aquí, mai instal·lats a mà. Quan l'equip de Pagaments necessita un Secret nou, obre un PR contra aquest repositori; ningú no executa kubectl create secret a producció.

El compose.yaml de 05-01 §8 tenia PostgreSQL, MongoDB, RabbitMQ, la llavor, les migracions de Comandes, Catàleg, Comandes, l'stub de Clients i el gateway. Les addicions per al sistema complet, resumides (els serveis nous segueixen exactament el patró de servei-comandes a 05-01: image + build, variables de la taula de config.js de 08-02, depends_on amb condicions, stop_grace_period: 15s):

Amb això, docker compose up -d --wait aixeca una vintena de contenidors (disset en execució més les tasques d'un sol ús) en uns 90 segons en un portàtil normal, i les quatre E2E de 08-02 §9 passen contra http://localhost:8080 amb un token obtingut d'http://localhost:8180. És l'entorn amb què l'alumne pot reproduir tot el curs (08-04).

Sigui un clúster kind (plataforma/local/kind.yaml, 05-02 §4) o un de gestionat, l'ordre importa: cada capa depèn de l'anterior, i diverses peces (ESO, cert-manager, KEDA, l'operador de Prometheus) instal·len CRDs que els manifestos posteriors fan servir.

Sobre el pas 8: l'ordre "per la saga" no és estrictament necessari —els serveis arrenquen encara que falti un col·laborador (/health/ready no comprova Catàleg ni Clients, 04-04 §9) i les cues duradores guarden missatges— però desplegar primer els consumidors i al final Comandes i el gateway evita que les primeres comandes de la prova de fum esperin que algú declari inventari.comandes.

A dev i en un clúster de proves s'aplica tot amb un script; a producció els passos 8-9 els fa Argo CD (app-of-apps.yaml), i l'script només es fa servir per a la infraestructura dels passos 1-7 (o Terraform/Helmfile, si Plataforma ho prefereix).

Cada servei amb base de dades porta el seu Job de migracions a la base/ (05-02 §6) amb argocd.argoproj.io/hook: PreSync per a producció (05-03 §6): servei-comandes-migracions, servei-inventari-migracions, servei-pagaments-migracions, servei-notificacions-migracions, servei-clients-migracions (Catàleg té servei-cataleg-llavor només a dev; Notificacions sí que té BD per a enviaments). Tots executen node scripts/migrar.js des de la imatge del servei i són idempotents, per això el delete + apply és segur. I tots són expand-only (05-04 §3): l'script mai no necessita "esperar que no quedi cap pod vell" per aplicar una migració.

La prova de fum és l'E2E de 04-05 feta a mà a través de l'Ingress, amb un token de debò. scripts/token-keycloak.sh n'obté un per a la usuària de proves amb password grant (activat només al client proves-e2e del realm de dev/staging; a producció aquest client no existeix, 07-01 ex. 1):

I les tres comprovacions d'observabilitat, que són la raó d'haver muntat els mòduls 6 i 7: (1) a Jaeger (kubectl -n observabilitat port-forward svc/jaeger-query 16686), cercar servei=gateway, etiqueta comandaId=$COM: una traça amb els spans del gateway, Comandes, Clients, Catàleg, PostgreSQL, i —enllaçats per links des del traceparent de l'outbox (06-02 §6)— Inventari, Pagaments (amb l'span de la passarel·la) i Notificacions; (2) a Grafana, panell "Saga de comandes": comandes_creades_total +1, saga_durada_segons amb una observació de ~3 s, outbox_pendents a 0 als quatre serveis amb outbox; (3) a Loki, {namespace="techcorp"} | json | comandaId="com-…" retorna les línies dels sis serveis ordenades per temps, amb el mateix requestId a la part síncrona.

Si l'estat es queda en ESTOC_RESERVAT, la taula de l'apartat 10 diu on mirar (gairebé sempre: pagaments.estoc sense consumidor, o PASSARELLA_URL malament al ConfigMap de Pagaments).

El Luis fusiona un PR que afegeix la cancel·lació pel client (exercici 1 de 08-02). El que passa, amb cada peça a la seva lliçó:

Total: uns 50 minuts de rellotge, dels quals uns 12 són màquina; la resta és la revisió humana i l'observació del canary, i són deliberats. Davant del dijous a la nit de 01-05 (dues hores de desplegament, quatre reversions de dotze), això passa a les 11 del matí d'un dimarts, onze vegades al dia en el conjunt de serveis, i si el burn rate puja durant el canary, canary-weight: 0 deixa el 100 % a l'estable en segons: MTTR de minuts sense que ningú hagi escrit un kubectl a mà.

La campanya es prepara amb una llista que Plataforma i els quatre equips repassen tres setmanes abans (la primera versió es va escriure per al Black Friday de 2025, 08-01 §3; avui és un issue amb plantilla a plataforma):

El que es veu el dia D en un bon any (com el 2025): Catàleg entre 6 i 16 rèpliques seguint la corba de navegació; Inventari a 4-7 per longitud d'inventari.comandes; saga_durada_segons p95 en 4 s (la passarel·la també va més lenta); pressupost d'error consumit en el dia: 6 % del mensual. I el que la llista impedeix: un kubectl scale manual que Argo CD reverteixi al cap de tres minuts (05-03 §6, selfHeal: true), per això l'escalat de campanya també va per PR.

Un dimarts de setembre de 2026, 15:20. Diferent d'INC-2031 (missatge verinós per un bug): aquest cop la causa és externa i les eines de 06-03/06-05 ja existeixen. Segueix la cronologia com si fossis la persona de guàrdia:

1. 15:31 — Alerta DlqAmbMissatges{cua="pagaments.estoc.dlq"} (warning: 10 min amb missatges, 06-05 §12) arriba al canal de l'equip de Pagaments; no desperta ningú (no és critical), però és horari laboral i la guàrdia la reconeix i obre #inc-2047-pagaments-dlq.
2. 15:33 — Runbook comu/dlq: "quants, des de quan, de quin tipus?". kubectl -n infra exec rabbitmq-0 -- rabbitmqctl list_queues name messages | grep dlq → pagaments.estoc.dlq 14. A la consola de RabbitMQ, els 14 són estoc.reservat amb x-intents: 5: van esgotar els reintents, no són verinosos.
3. 15:36 — Loki: {app="servei-pagaments"} | json | nivell="error" | line_format "{{.esdevenimentId}} {{.err.codi}} {{.missatge}}" → DEPENDENCIA_NO_DISPONIBLE passarella: timeout des de les 15:12; CircuitObert{dependencia="passarella"} també és en warning des de les 15:15 (06-03 §4). Jaeger: l'span POST passarella/cobraments amb error=true i 5.000 ms exactes: la passarel·la no respon, no rebutja.
4. 15:38 — Impacte: panell "Saga de comandes": 41 comandes en ESTOC_RESERVAT amb més de 5 minuts; el vigilant començarà a cancel·lar-les per TIMEOUT_PAGAMENT als 10 (06-03 §9). Severitat SEV2 (part del flux trencat, sense workaround per al client); s'avisa a #estat-plataforma: "des de les 15:12 els cobraments no es completen per un problema del proveïdor de pagaments; les comandes s'estan retenint; propera actualització a les 16:00".
5. 15:40 — Estabilitzar abans que entendre: la pàgina d'estat de la passarel·la confirma incident. Decisió de Pagaments: pujar temporalment el límit del vigilant de 10 a 30 minuts (ConfigMap VIGILANT_LIMIT_MIN de Comandes + rollout restart; PR exprés a plataforma amb l'etiqueta incident, perquè Argo no ho reverteixi) i així no cancel·lar 41 comandes amb estoc reservat per una caiguda de 20 minuts aliena. Les reserves caduquen als 15 min per expira_en… tret que es pugi també RESERVA_TTL_S; es puja a 2.400 s de la mateixa manera. Dos canvis de configuració, zero codi.
6. 15:52 — La passarel·la es recupera. El breaker passa a semiobert i tanca; els missatges de pagaments.estoc.reintent (els que encara tenien intents) es cobren sols en 2 minuts. Queden els 14 de la DLQ.
7. 15:55 — Reprocessar: kubectl -n techcorp run reprocessar --rm -it --image=ghcr.io/techcorp/servei-pagaments:1.4.2 --env-from=secret/pagaments-rabbitmq -- node scripts/reprocessarDlq.js --cua pagaments.estoc --max 50 (06-03 §8): 14 missatges tornen a la cua amb x-intents: 0 i x-reproces; cobrarComanda els troba EN_CURS (pas 1 de 08-02 §4) i consulta per clau d'idempotència abans de cobrar: 3 ja s'havien cobrat al primer intent (la passarel·la va cobrar i el timeout va arribar abans que la resposta) i es marquen CAPTURAT sense cobrar dos cops; 11 es cobren ara. pagament.confirmat ×14, sagues tancades.
8. 16:02 — Panell: 0 comandes en ESTOC_RESERVAT antigues; es reverteixen els dos canvis de configuració (PR de tornada); es tanca l'incident. Durada: 50 min des de la primera fallada, 31 des de l'alerta; 0 comandes cancel·lades, 0 cobraments duplicats.
9. Postmortem breu (SEV2, 06-05 §10): causa externa; va funcionar tot el que s'havia dissenyat (reintents, breaker, DLQ, alerta, runbook, idempotència de la passarel·la); accions: (a) l'alerta DlqAmbMissatges va trigar 10 min per disseny, però CircuitObert va saltar als 3: afegir al runbook de CircuitObert{passarella} el pas "pujar el vigilant"; (b) fer VIGILANT_LIMIT_MIN i RESERVA_TTL_S flags recarregables en calent (04-03 §7) per no reiniciar; (c) preguntar a la passarel·la pel seu SLA. I la pregunta fixa: "quina alerta ho hauria detectat abans?" —CircuitObert ja ho va fer; el que faltava era l'enllaç entre aquesta alerta i l'acció.

Compara amb INC-2031 (40 min, 61 comandes afectades, 38 cancel·lades): mateix símptoma ("la saga no avança"), la meitat d'impacte i cap acció destructiva, perquè el sistema ja tenia reintents diferits, DLQ, alertes per símptoma, runbook i un script. És exactament per a això que es va escriure 06-05.

Rotar comandes-db. És el procediment de 07-04 §4, executat el primer dilluns de cada semestre per Plataforma amb l'equip amo: (1) nova contrasenya de svc_comandes a Vault (techcorp/prod/comandes/db), amb l'usuari svc_comandes_b per tenir-ne les dues vàlides; (2) kubectl -n techcorp annotate externalsecret comandes-db force-sync=$(date +%s) → el Secret canvia; (3) kubectl -n techcorp rollout restart deploy/servei-comandes (rolling maxUnavailable: 0, 05-04) i rollout status; (4) comandes-migracions no cal; (5) revocar l'antiga i vigilar password authentication failed a Loki durant una hora. Quinze minuts, sense finestra de manteniment; es repeteix per a *-db i *-rabbitmq dels sis serveis el mateix matí amb un bucle a scripts/rotar-secrets.sh. L'auditoria de qui va rotar què és el git log del PR i l'audit log de Vault.

Node 20 → 22. Node 20 acaba el seu manteniment l'abril de 2026; l'actualització es fa un sol cop a la plantilla i es propaga per la regla del Luis: (1) plantilla-servei-node: FROM node:22-alpine a les dues etapes del Dockerfile (05-01 §3), engines.node: ">=22", @types/lint; (2) servei-node-ci.yml@v2: actions/setup-node amb node-version: 22 i una matriu temporal [20, 22] perquè cada servei comprovi totes dues abans de canviar; (3) @techcorp/comu-http es publica i es prova en 22 (05-03 §10); (4) cada equip, quan vol dins d'un termini (un mes), obre un PR al seu servei amb dues línies: uses: …/servei-node-ci.yml@v2 i el FROM; CI, Testcontainers, pactes i staging validen; producció amb l'estratègia habitual (canary a Comandes i Pagaments, rolling a la resta); (5) al cap d'un mes, @v1 es retira. Sis PRs de dues línies en lloc d'una migració coordinada; i si Notificacions s'endarrereix una setmana, ningú més no espera.

v2 de productes amb preu: { import, moneda }. És el canvi incompatible de 03-06 §10, ara executat de punta a punta:

Cap pas no talla res: en cada moment conviuen dues versions del contracte, de l'esdeveniment i de l'esquema, i cada equip desplega quan vol dins del termini. És la mateixa disciplina que a l'apartat 6, aplicada a un canvi que al monòlit hauria estat "cercar preu a tot el repositori i creuar els dits el dijous".

Xifres fictícies, orientatives, per a un clúster gestionat de producció amb 3.000 comandes/dia (sense campanya), arrodonides a l'alça. Serveixen per tenir l'ordre de magnitud i per a l'argument de FinOps de 08-04:

Davant del monòlit (tres servidors grans + PostgreSQL + deu servidors durant un mes l'any ≈ 1.900 €/mes de mitjana), és un 45 % més car en infraestructura pura… i un 30 % més barat en campanya, i no inclou el que s'estalvia en hores de desplegament i incidents (08-01 §10). Com reduir-lo, per ordre de retorn: (1) requests reals mesurats amb Prometheus (06-04 §4) i right-sizing de nodes: la majoria de serveis de TechCorp demanen 250 m de CPU i en fan servir 60 m; (2) apagar staging fora d'horari (ja es fa) i fer servir minReplicaCount: 0 de KEDA per a consumidors esporàdics com analítica; (3) mostreig de traces al 10 % i retenció de logs de 30 dies (ja), sample_limit i revisió trimestral de cardinalitat (08-01 §11); (4) reservar capacitat de nodes base a un any (−30 %); (5) revisar si Redis, amb la càrrega real, compensa davant de la memòria cau HTTP del gateway; (6) no estalviar en còpies de seguretat, TLS ni rèpliques de les bases de dades de Comandes i Pagaments.

• Instal·lar la infraestructura a mà i els serveis per GitOps. Al cap de tres mesos ningú no sap quina versió de RabbitMQ hi ha ni amb quins values. Tot a k8s/infra/ i aplicat per script o per Argo, encara que sigui Helm.
• Saltar-se l'ordre dels CRDs. Un ExternalSecret aplicat abans que ESO o un ServiceMonitor abans que l'operador fallen amb "no matches for kind": l'script espera amb --wait cada operador abans de continuar.
• Prova de fum sense token o amb el token d'admin. Ha de fer servir un usuari amb rol client i el seu clientId: és l'única manera de comprovar la regla del propietari i el 404 de la comanda aliena.
• Escalar a mà a producció amb Argo CD en selfHeal. Ho reverteix en minuts i, pitjor, enmig d'una campanya. Per PR, sempre.
• Reprocessar la DLQ abans d'entendre la causa. Si el missatge és verinós, torna a la DLQ i consumeix cinc reintents; si la dependència continua caiguda, igual. Primer Loki/Jaeger, després l'script.
• Rotar un secret sense rollout restart i creure que ha funcionat perquè kubectl get secret mostra el nou. Els pods vells continuen amb la contrasenya antiga fins que reinicien (o fins que es llegeix com a fitxer).
• Consell: executa desplegar-tot.sh dev en un clúster kind net un cop al mes. Si triga més de 15 minuts o falla en algun pas, alguna cosa de l'arbre de plataforma s'ha desactualitzat; millor descobrir-ho un dimarts que en la recuperació davant de desastres.

El clúster de producció es perd del tot (regió caiguda). Amb el repositori plataforma, les còpies de les bases de dades gestionades i les imatges a ghcr.io, escriu la seqüència de recuperació en un clúster nou en una altra regió, indicant quins passos de l'apartat 3 canvien, què cal restaurar abans de què, quines dades es podrien perdre (pensa en l'outbox i les cues) i una estimació de temps. Què caldria tenir preparat per endavant perquè fos d'una hora en lloc d'un dia?

Durant el canary al 10 % de servei-comandes 1.6.0 el burn rate és perfecte, però en passar al 100 % saga_durada_segons p95 puja de 3 a 40 s. Explica quin tipus de fallada no detecta un canary per pes de trànsit HTTP en un servei que a més consumeix esdeveniments, com ho hauries detectat durant el canary (mètriques i etiquetes concretes), i què canviaries en el procediment de l'apartat 6.

La Marta demana abaixar la factura mensual un 25 % sense tocar la disponibilitat de Comandes ni de Pagaments. Amb la taula de l'apartat 11, proposa una llista concreta de mesures amb el seu estalvi estimat i el seu risc, i digues quines no acceptaries encara que estalviïn.

Exercici 1. Seqüència: passos 1-2 iguals (namespaces, operadors) al clúster nou; el pas 3 canvia: restaurar les bases de dades gestionades des de còpia (PostgreSQL de Comandes i Pagaments primer, amb point-in-time recovery a l'instant més proper; MongoDB del catàleg; RabbitMQ no es restaura: es crea buit amb definitions.json, i els missatges en vol es perden); pas 4 Keycloak des de la seva BD restaurada; 5-6 iguals; 7 els ExternalSecret apunten al mateix Vault (que ha de ser fora de la regió o replicat); 8-9 iguals, canviant el DNS d'api.techcorp.example al nou balancejador i esperant el certificat. Dades en risc: els esdeveniments que eren a RabbitMQ sense consumir (cues duradores d'un clúster perdut) i els segons entre l'última còpia i la caiguda. L'outbox és la salvació parcial: en arrencar, els relays dels quatre serveis republiquen tot el que tingui publicat_en IS NULL, així que els esdeveniments generats i no publicats es recuperen; els ja publicats i no consumits es perden → les comandes en ESTOC_RESERVAT o PENDENT sense avançar les tanca el vigilant (TIMEOUT_PAGAMENT) i la reconciliació de reserves (06-03 §9), i cobrarComanda consulta la passarel·la abans de cobrar (EN_CURS), de manera que no hi ha cobraments dobles. Temps: amb tot a mà i provat, 2-4 hores; sense pràctica, un dia. Per a una hora: clúster secundari "calent" amb la infraestructura dels passos 1-7 ja aplicada i Argo CD apuntant al mateix repositori (només canviar la destinació), rèpliques de les BD gestionades a l'altra regió, Vault multiregió, i un exercici de recuperació trimestral (el consell de l'apartat anterior).

Exercici 2. El canary per pes de l'Ingress reparteix peticions HTTP, però les rèpliques canary també consumeixen comandes.saga en igualtat de condicions amb les estables (cues competidores, 06-04 §9): al 10 % de trànsit HTTP, el canary ja processa potser el 33 % dels esdeveniments (1 rèplica de 3), i si el seu consumidor és lent (una consulta sense índex sobre comandes afegida a 1.6.0), l'efecte es dilueix entre les estables i apareix "de cop" al 100 %. Detecció durant el canary: mirar mètriques etiquetades per version (l'etiqueta service.version de 06-02, que les mètriques de comu-http inclouen): histogram_quantile(0.95, sum by (le, version) (rate(saga_durada_segons_bucket[5m]))), la durada de processarUnCop per versió, pg_stat_statements o la latència de les consultes del consumidor, i x-intents/missatges a comandes.saga sense ack per pod. Canvi de procediment: afegir a l'apartat 6 un panell "canary vs estable" que compari també les mètriques de consumidors i de base de dades per version, no només RED HTTP; i, per a serveis amb consumidors, allargar el canary o fer canary per rèplica amb una cua de prova (o mesh, quan arribi) —és un dels senyals que 02-05 va fixar per replantejar l'orquestració de la saga i que 05-05 va deixar com a argument a favor del mesh.

Exercici 3. Mesures: (1) requests reals i nodes de 6 a 4 fora de campanya (l'autoescalat continua): −250 €, risc baix si els PDB i l'HPA estan bé; (2) staging a 1/4 i només en horari laboral amb arrencada sota demanda: −200 €, risc baix (l'E2E de cd.yml triga 5 min més si és apagat); (3) capacitat reservada un any per a 4 nodes base: −180 €, risc de compromís; (4) traces al 5 % amb mostreig per cua d'errors al 100 %, logs de Catàleg a info (avui debug en un overlay oblidat), 15 dies de logs: −80 €, risc mitjà en depuració; (5) MongoDB a la instància inferior amb la memòria cau de Redis (que ja absorbeix el 85 %): −60 €, risc baix, mesurar amb k6; (6) KEDA a zero per a analítica i bff-mobil de nit: −30 €. Total ≈ −800 € (29 %). No acceptaria: treure la rèplica o les còpies de PostgreSQL de Comandes/Pagaments, passar RabbitMQ a un node, treure el TLS intern de RabbitMQ/BD, o reduir minReplicas de Comandes/Pagaments a 1 (un sol pod trenca el rolling sense talls de 05-04 i el PDB): estalvien 100-200 € i posen en joc l'SLO del 99,9 % i la seguretat de 07-02.

El sistema de TechCorp ja no és només codi: viu en un clúster i s'opera amb procediments escrits. Hem recorregut el repositori techcorp/plataforma complet (bases i overlays per servei, k8s/xarxa/, k8s/infra/ amb els values de Helm de RabbitMQ, PostgreSQL, MongoDB, Redis, Keycloak i l'observabilitat, SLOs, Argo CD, dashboards, runbooks, proves E2E i de càrrega, el workflow reutilitzable i SEGURETAT.md), el compose.yaml que aixeca els sis serveis amb Keycloak, Jaeger, Prometheus, Grafana i Loki en un portàtil, l'ordre d'arrencada d'un clúster nou (namespaces → operadors i CRDs → dades i missatgeria → identitat → observabilitat → xarxa → secrets → serveis en l'ordre de la saga → Ingress) plasmat a desplegar-tot.sh amb els seus Job de migració idempotents, i la verificació amb una prova de fum real —un token de Keycloak, una comanda a través de l'Ingress que arriba a CONFIRMADA, la seva traça a Jaeger, la seva marca al panell "Saga de comandes" i els seus logs a Loki—. I hem operat: un desplegament de servei-comandes de PR a 100 % passant per CI, pactes, imatge signada, staging, can-i-deploy, revisió humana, Argo CD i canary observat; la llista de Black Friday amb overlay de campanya, KEDA, pressupost d'error i congelació; l'incident INC-2047 a pagaments.estoc.dlq resolt amb alerta, runbook, Loki, Jaeger, dos canvis de configuració i reprocessarDlq.js sense cap cobrament duplicat; la rotació de comandes-db amb ESO, l'actualització a Node 22 propagada per plantilla i workflow reutilitzable, i la v2 de productes amb preu {import, moneda} aplicada de punta a punta amb expand/contract; més el runbook ràpid i una factura mensual amb les seves palanques.

Amb això, la història de TechCorp és completa: monòlit, migració, implementació, desplegament i operació. Queda el més valuós d'un cas d'estudi, que és destil·lar-lo: què vam fer, què va sortir malament i què faríem diferent en cada dimensió, quins antipatrons vam aprendre a reconèixer, una llista consolidada de bones pràctiques amb la seva lliçó de referència, què faria TechCorp a la seva fase 2 i com pots aplicar tot això al teu propi context. És l'última lliçó del curs.