Fins ara, en tot el curs, hi ha hagut un clúster. Els namespaces rutas-norte-dev, rutas-norte-pre i rutas-norte-pro hi convivien, separats per quotes, polítiques de xarxa i RBAC. És una arquitectura perfectament defensable i és on comença gairebé tothom.

Però arriba un moment en què deixa de ser-ho. Pot ser una actualització del pla de control que afecta els tres entorns alhora; pot ser l'auditor preguntant per què el clúster que executa rutas-norte-dev té accés a la xarxa on viuen les dades personals de producció; pot ser que l'empresa obri operacions en una altra regió i la latència des de Portugal a eu-west-1 comenci a notar-se en la conversió. A Rutas Norte va ser el primer: una actualització d'EKS que va sortir malament a pre va deixar també pro inaccessible durant dinou minuts.

Aquesta lliçó tracta de què canvia quan la plataforma deixa de cabre en un clúster: per què s'hi arriba, quines topologies existeixen, com es treballa cada dia sense aplicar al clúster equivocat, com Argo CD governa una flota, com es connecten clústers entre si, i el problema que no té solució fàcil quan cal recuperar-se d'un desastre, que és la dada.

Advertiment de compliment normatiu. La distribució de clústers entre regions afecta directament la residència de les dades personals dels clients de Rutas Norte. Replicar postgres-reserves a una altra regió, emmagatzemar còpies de seguretat fora de la regió principal, o permetre que un clúster d'una regió consulti dades allotjades en una altra, són decisions amb implicacions legals que han de ser revisades i aprovades pel responsable de compliment normatiu abans d'implantar-se. Els exemples d'aquesta lliçó són il·lustratius.

1. Per què una empresa acaba amb diversos clústers
2. Topologies habituals i quina triar
3. El treball diari amb diversos contextos
4. Desplegament multi-clúster amb Argo CD
5. Configuració i polítiques comunes: el clúster com a producte
6. Connectivitat entre clústers
7. Recuperació davant de desastres
8. El pla de Rutas Norte
9. El cost, la complexitat i quan no fer-ho

No és una decisió que es prengui un matí. S'hi arriba per acumulació de raons, i convé reconèixer-les per saber quina t'hi està empenyent.

Els namespaces separen càrregues, però no separen el pla de control. Comparteixen servidor d'API, etcd, planificador, CNI, controlador d'Ingress i complements. Tot el que sigui "de clúster" és compartit: CRDs, ClusterRole, webhooks d'admissió, versions d'operadors.

A la pràctica, això significa que un desenvolupador que desplega un CRD mal format a dev, o un operador que consumeix memòria sense control, pot degradar producció. A Rutas Norte va ser un webhook de validació mal configurat a dev el que, en no respondre, va bloquejar la creació de pods a tot el clúster durant vuit minuts, producció inclosa.

Amb un clúster, la pregunta "què passa si el clúster falla?" té una resposta única i molt dolenta: tot cau. El pla de control gestionat d'EKS és molt fiable, però no és l'únic punt de fallada: una NetworkPolicy massa àmplia, un esgotament d'IP de la VPC, una versió de CNI defectuosa o un error humà amb kubectl delete afecten tot el que hi ha a dins.

Rutas Norte opera principalment al nord peninsular, però està estudiant expandir-se al sud de França. Una petició des de Tolosa a eu-west-1 (Irlanda) suma uns 35-45 ms d'anada i tornada només per la xarxa. Sobre una compra de bitllet amb sis crides encadenades, això són gairebé 300 ms de latència afegida que l'usuari percep.

Aquest és el motiu que no admet discussió tècnica: si la normativa aplicable, un contracte amb un client corporatiu o una decisió del responsable de compliment exigeix que les dades personals de determinats clients no surtin d'un territori, cal infraestructura en aquell territori. No hi ha configuració de namespace que resolgui això.

Kubernetes publica una versió menor cada quatre mesos aproximadament, i el suport de cadascuna dura al voltant de catorze. Actualitzar és obligatori, i provar l'actualització al mateix clúster que produeix és impossible per definició. Amb diversos clústers es pot portar dev a la versió nova, deixar que trenqui el que hagi de trencar, i actualitzar producció setmanes després amb la lliçó apresa.

Relacionat, però diferent: fins i tot les actualitzacions que surten bé tenen finestres de risc. Els nodes es reemplacen, els complements es reinicien, el CNI s'actualitza. Amb un sol clúster, cada actualització és un esdeveniment de producció. Amb dos, és un esdeveniment de producció una vegada cada dues actualitzacions, perquè la primera s'ha assajat.

La deriva mereix èmfasi: el problema de tenir diversos clústers no és tenir-los, és mantenir-los iguals. Un pedaç aplicat a mà en un i no en un altre genera una diferència que ningú no recorda fins que causa un incident mesos després. Tot el de l'apartat 5 existeix per combatre això.

Comença per un. Un sol clúster amb namespaces ben separats, quotes, polítiques de xarxa i RBAC resol el 80 % dels casos i costa una fracció.

El primer desdoblament ha de ser producció davant de la resta. És el que aporta més per unitat de complexitat: aïlla el pla de control del que és crític, permet assajar actualitzacions i satisfà qualsevol auditoria raonable.

El segon, si arriba, ve imposat per la geografia o la normativa, no per preferències d'arquitectura.

El clúster de gestió, a partir del tercer. Amb dos clústers, Argo CD pot viure al de producció gestionant-los tots dos. Amb quatre, cal un lloc neutral.

Aquí és on es produeixen els accidents. Un kubectl delete deploy executat creient ser a dev quan s'és a pro és un incident real i freqüent.

Són dues utilitats petites que estalvien molt de temps. Instal·lar-les és el primer que fa qualsevol que treballi amb més d'un clúster.

Cinc capes, de la més tova a la més dura. Les tres primeres són avisos; les dues últimes són barreres reals.

Capa 1: el prompt mostra el context. És imprescindible. Sense això, tota la resta és opcional.

Fons vermell quan ets a producció. Sembla trivial i és la mesura que més accidents evita.

Capa 2: context per sessió, no global. El problema d'use-context és que canvia l'estat de totes les terminals obertes. Una solució millor és aïllar el kubeconfig per terminal:

Així, la terminal de producció és la de producció i prou: no hi ha manera que un use-context d'una altra finestra la canviï.

Capa 3: confirmació explícita per a verbs destructius.

Capa 4: contextos de només lectura per defecte. Aquesta és la primera barrera real, perquè no depèn de la disciplina de ningú. L'usuari joan-pro del kubeconfig assumeix el rol rutasnorte-pro-lectura, mapejat a un ClusterRole de només lectura:

Escriure a producció exigeix assumir explícitament un altre rol, amb una sessió temporal i un motiu registrat. És una fricció deliberada de trenta segons que converteix cada escriptura en un acte conscient.

Capa 5: no escriure mai a mà a producció. L'objectiu últim. Amb GitOps (10-05), l'únic que aplica canvis a pro és Argo CD. Les persones llegeixen, diagnostiquen i proposen canvis a Git. L'escriptura manual queda reservada per a incidents, amb el procediment d'assumpció de rol i el seu registre d'auditoria.

Argo CD gestiona clústers remots des d'una única instal·lació. Cada clúster es registra com a destí i les Application apunten al que correspongui.

Les etiquetes són la part important: són el que permet escriure "desplega això a tots els clústers de producció" sense enumerar-los.

argocd cluster add crea una ServiceAccount al clúster destí amb els permisos necessaris i en desa les credencials com un Secret al clúster d'Argo CD. Aquest Secret és una credencial d'alt valor: qui el llegeixi pot desplegar a producció. Ha d'estar protegit per RBAC estricte i, preferiblement, xifrat en repòs amb una clau gestionada externament.

Un ApplicationSet genera Application automàticament a partir d'una plantilla i un generador. El generador de clústers en crea una per cada clúster que compleixi un selector.

Això desplega els complements comuns (Kyverno, cert-manager, ingress-nginx, node-exporter) a tots els clústers etiquetats, amb les diferències per entorn resoltes per Kustomize.

Per a les aplicacions de negoci, el generador de matriu combina clústers amb aplicacions:

Amb dos clústers de producció i sis components, això genera dotze Application sense escriure dotze fitxers. Afegir una regió és registrar un clúster amb l'etiqueta correcta; afegir un component és crear un directori.

L'estructura del repositori suporta dues dimensions: entorn i clúster.

Regla important: el que és igual entre clústers viu a base; el que difereix, i només això, a l'overlay. Cada línia d'un overlay és una diferència que algú haurà d'entendre d'aquí a sis mesos. Si un overlay creix molt, gairebé sempre significa que la base està mal factoritzada.

Amb diversos clústers, la pregunta deixa de ser "com desplego la meva aplicació?" i passa a ser "com garanteixo que els N clústers compleixen les mateixes regles?".

La idea de clúster com a producte consisteix que l'equip de plataforma no lliura "accés a un clúster", sinó un producte amb contracte: un clúster acabat de crear ja ve amb observabilitat, polítiques de seguretat, RBAC, quotes, controlador d'Ingress, gestió de certificats i còpies configurades. Ningú no ha de muntar res, i per tant ningú no ho munta diferent.

Encara que tot es desplegui per GitOps, la deriva apareix: versions de complements instal·lats per Terraform, pedaços d'emergència, diferències en la versió del mateix Kubernetes. Convé un informe periòdic.

I la comprovació que importa de debò, feta des d'Argo CD:

Dos clústers són dues xarxes de pods diferents. Un pod d'eu-west-3 no pot resoldre api-reserves.rutas-norte-pro.svc.cluster.local del clúster d'eu-west-1, ni arribar a les seves IP. Hi ha tres nivells de solució, amb complexitat molt diferent.

El més simple i el que resol la majoria dels casos. El trànsit d'usuaris es dirigeix a la regió adequada mitjançant DNS, i cada regió és autosuficient.

• Política de latència: cada usuari va a la regió més ràpida per a ell.
• Política de commutació: si la comprovació de salut d'una regió falla, el DNS deixa de resoldre-la.
• Límit important: el DNS té TTL. Amb TTL de 60 segons, la commutació triga entre un i diversos minuts, perquè hi ha resolutors que ignoren els TTL curts. No hi ha commutació instantània per DNS.

Quan un servei d'un clúster necessita cridar-ne un altre d'un altre clúster (per exemple, la rèplica de PostgreSQL seguint el primari), cal connectivitat de xarxa real: aparellament de VPC o passarel·la de trànsit, rangs CIDR que no se solapin, i regles de tallafoc explícites.

El requisit dels rangs mereix atenció: si els dos clústers fan servir 10.244.0.0/16 per a pods, l'encaminament entre ells és impossible. Cal planificar l'adreçament abans de crear el segon clúster, i és un error que es paga amb una reconstrucció.

Istio, Linkerd o Cilium Cluster Mesh permeten que un Service d'un clúster sigui assolible des d'un altre de manera transparent, amb mTLS, repartiment de càrrega entre regions, commutació per localitat i observabilitat unificada.

Què resolen de debò:

• Descobriment transparent: api-reserves.rutas-norte-pro.svc funciona des de qualsevol clúster de la malla.
• Commutació per localitat: es prefereix la instància local i es desborda a la remota només si la local no està sana.
• mTLS entre clústers sense tocar l'aplicació.
• Una sola vista de la topologia del trànsit.

Què costen:

• Un sidecar per pod (o eBPF, segons la implementació), amb el seu consum de CPU i memòria.
• Un pla de control més per operar i actualitzar.
• Una capa sencera de nous modes de fallada, amb una corba d'aprenentatge considerable.
• Depuració notablement més difícil: el trànsit ja no va on sembla.

El criteri honest: una malla multi-clúster es justifica quan hi ha molts serveis cridant-se entre regions. Si la comunicació entre clústers es redueix a la replicació de la base de dades i a un parell de crides, l'aparellament de VPC i uns Services de tipus ExternalName resolen el mateix per una fracció del cost.

Rutas Norte no fa servir malla de servei. Amb dos clústers, sis components i una única conversa entre regions (la replicació de PostgreSQL), no està justificada. Es revisarà si apareix una tercera regió.

Aquí és on el multi-clúster deixa de ser una qüestió d'arquitectura i passa a ser una qüestió de supervivència del negoci.

L'argument a favor de l'actiu-actiu no és el temps de recuperació, és que el camí de recuperació s'exerceix cada dia. Un secundari passiu que mai no ha servit trànsit real és una hipòtesi, igual que la còpia que mai no es va restaurar d'11-02.

L'argument en contra és doble: costa el doble, i sobretot obliga a resoldre les escriptures concurrents en dues regions, que és un problema de disseny d'aplicació, no d'infraestructura.

Els mateixos conceptes d'11-02, ara a escala de regió:

Els manifests es repliquen amb git push. L'aplicació arrenca en qualsevol lloc en minuts. La dada és una altra cosa.

Replicació asíncrona de PostgreSQL entre regions. És el que fa Rutas Norte: una rèplica a eu-west-3 que segueix el primari d'eu-west-1 per replicació en flux. El retard típic entre Irlanda i París és de 25-40 ms de xarxa, cosa que a la pràctica significa un retard de replicació de menys d'un segon amb càrrega normal, i d'uns segons durant el pont de maig.

La conseqüència: si la regió principal desapareix de cop, es perden les transaccions confirmades que encara no havien arribat a la rèplica. Amb RPO de 15 minuts hi ha marge de sobres, però convé dir-ho amb claredat: actiu-passiu amb replicació asíncrona no és RPO zero. Pot haver-hi reserves confirmades al client que no existeixin després de la commutació, i el negoci ha de saber què fer-ne.

Replicació síncrona donaria RPO zero, però cada confirmació de transacció esperaria l'anada i tornada a l'altra regió: 35 ms afegits a cada escriptura. Al pont de maig, això és inassumible.

I el problema encara pitjor: la tornada. Quan la regió principal es recupera, la seva base de dades té un estat divergent del de la que ha estat servint. No es pot simplement tornar: cal reconstruir l'antiga principal com a rèplica de la nova i després commutar ordenadament. Aquest procediment ha d'estar escrit abans de necessitar-lo.

La separació va resoldre el problema que la va motivar: les actualitzacions d'EKS s'assagen a nopro, i un webhook mal configurat per desenvolupament ja no pot afectar la venda de bitllets.

Després de l'anàlisi de risc, la direcció va aprovar una regió secundària a eu-west-3 (París) en mode actiu-passiu, amb aquestes decisions:

El punt d'Argo CD mereix atenció. És un error clàssic: posar l'eina que desplega dins del clúster que pot desaparèixer. Rutas Norte ho resol amb una segona instància a eu-west-3 apuntant al mateix repositori, amb syncPolicy.automated desactivada en condicions normals; s'activa com a part del procediment de commutació.

Un procediment escrit i mai executat és una redacció, no un pla. Rutas Norte fa un simulacre anual complet a l'octubre, fora de temporada alta:

Resultats del simulacre d'octubre de 2025, el primer: RTO real de 71 minuts davant de l'objectiu de 30. Les troballes van ser reveladores i cap no s'hauria descobert sense executar-lo:

• El certificat TLS d'eu-west-3 havia caducat: cert-manager no podia completar el repte ACME perquè el DNS no apuntava a aquella regió. Es va corregir fent servir el repte DNS-01 en lloc d'HTTP-01.
• Els ExternalSecrets d'eu-west-3 apuntaven a un magatzem que no estava replicat a aquella regió.
• Ningú no recordava on estava escrit el procediment de commutació del DNS.
• La rèplica de PostgreSQL feia onze dies que no replicava per una regla de tallafoc afegida en un canvi no relacionat. Ningú no ho sabia perquè no hi havia alerta sobre el retard de replicació entre regions.

Aquesta última troballa, tota sola, va justificar el simulacre sencer: en un desastre real s'haurien perdut onze dies de reserves.

És una inversió seriosa. La pregunta que la justifica no és tècnica: quant costa a Rutas Norte una hora caiguda durant el pont de maig? Si són 40.000 € de vendes perdudes més el dany reputacional, la inversió es paga evitant un sol incident regional. Si el negoci pot absorbir mig dia caigut sense conseqüències greus, no.

• Quan un sol clúster encara funciona. Si els namespaces, quotes i polítiques de xarxa cobreixen les teves necessitats d'aïllament, afegir clústers només afegeix deriva.
• Quan no hi ha GitOps. Amb desplegaments manuals, N clústers signifiquen N oportunitats de divergir. GitOps és requisit previ, no complement.
• Quan no hi ha observabilitat centralitzada. Diagnosticar un incident saltant entre panells de tres clústers és inviable. Els logs i les mètriques de tota la flota s'han de veure en un sol lloc.
• Quan l'equip no dona l'abast amb un. Multiplicar la infraestructura no multiplica la capacitat de l'equip, la divideix.
• Quan la raó és "per si de cas". Sense un escenari concret per resoldre, la complexitat es paga sense rebre res.
• Quan la dada no es pot replicar. Si l'aplicació no tolera coherència eventual i no hi ha pressupost per redissenyar-la, un segon clúster dona una falsa sensació de seguretat.

Abans de plantejar-se el segon clúster, convé tenir resolt l'anterior, perquè gairebé tot millora la fiabilitat més per menys diners:

1. Còpies provades i restauració cronometrada (11-02).
2. GitOps amb tot a Git (10-05).
3. Observabilitat i alertes amb runbooks (07-04, 11-06).
4. Alta disponibilitat dins del clúster: multizona, PDB, topologySpread (09-05).
5. Desplegaments segurs amb canari (11-04).
6. I llavors sí, el segon clúster.

Un equip que salta al pas 6 sense els cinc anteriors acaba amb dos clústers fràgils en lloc d'un.

• Crear el segon clúster amb el mateix rang CIDR que el primer. Impedeix l'encaminament entre ells i obliga a reconstruir. Planifica l'adreçament de tota la flota abans de crear el segon.
• Posar Argo CD només dins del clúster de producció. Quan aquest clúster desapareix, desapareix la capacitat de desplegar en qualsevol lloc. Instància secundària o clúster de gestió a part.
• Suposar que el DNS commuta a l'instant. Els TTL curts no sempre es respecten; compta amb un a tres minuts com a mínim.
• Un secundari a zero rèpliques. D'un camí fred no se sap si funciona. Capacitat mínima permanent i trànsit real, encara que sigui poc.
• No alertar sobre el retard de replicació entre regions. És exactament la fallada que Rutas Norte va descobrir al simulacre: onze dies sense replicar i ningú no ho sabia.
• Duplicar l'overlay sencer en afegir una regió. Només el que difereix va a l'overlay; si creix molt, la base està mal factoritzada.
• Instal·lar una malla de servei multi-clúster per defecte. És una de les peces més complexes de l'ecosistema. Només es justifica amb molta comunicació entre regions.
• Consell: posa el context al prompt avui mateix, amb fons vermell per a producció. És la mesura de més retorn per minut invertit de tota la lliçó.
• Consell: fes que els contextos de producció siguin de només lectura per defecte. Escriure ha d'exigir un acte deliberat i registrat.
• Consell: escriu el procediment de commutació i el de tornada. La tornada és més difícil que l'anada i gairebé ningú no la documenta.

Una empresa té un clúster amb dev, pre i pro en namespaces separats, GitOps amb Argo CD, còpies provades mensualment i observabilitat centralitzada. Ha patit dos incidents en sis mesos: un per un operador instal·lat per desenvolupament que va consumir tota la memòria d'un node compartit, i un altre per una actualització de la versió del clúster que va deixar pro degradat durant 25 minuts. L'equip de plataforma són dues persones. Recomana una topologia, justifica-la i digues explícitament què NO recomanes i per què.

Rutas Norte afegeix el clúster rutasnorte-pro-w3 amb les etiquetes entorn=pro, region=eu-west-3 i rol=secundari. Escriu un ApplicationSet que desplegui api-reserves a tots els clústers amb entorn=pro, fent servir l'overlay overlays/pro-{{region}}, i que als clústers amb rol=secundari arrenqui amb menys rèpliques. Indica a més què s'ha de complir al repositori perquè funcioni.

Al simulacre anual, un equip obté: pas 3 (promoció de PostgreSQL) 4 min, pas 4 (Argo CD i escalat) 22 min, pas 5 (verificació) 6 min, pas 6 (DNS) 14 min. RTO total 46 min davant d'un objectiu de 30. Identifica els dos passos problemàtics, proposa una causa probable per a cadascun i una acció correctora concreta.

Solució 1. Recomanació: topologia per entorn, dos clústers — un per a pro i un altre per a dev+pre. Justificació: els dos incidents patits són exactament els que aquesta topologia resol; el primer és contenció de recursos i del pla de control entre entorns, el segon és la impossibilitat d'assajar l'actualització abans d'aplicar-la a producció. A més, els requisits previs estan coberts: hi ha GitOps, còpies provades i observabilitat centralitzada, així que la deriva és manejable. El cost incremental per a dues persones és assumible perquè la major part de l'operació ja està automatitzada.

El que no es recomana: (a) un clúster per unitat de negoci, perquè amb dues persones de plataforma la proliferació és inassumible i no hi ha cap problema que ho motivi; (b) una segona regió, perquè cap dels incidents no va ser regional i el cost (infraestructura més replicació de la dada) no està justificat per l'evidència disponible; (c) un clúster de gestió dedicat, innecessari amb només dos clústers, on Argo CD pot viure al de producció gestionant-los tots dos.

Solució 2.

Requisits al repositori: (a) han d'existir els directoris overlays/pro-eu-west-1 i overlays/pro-eu-west-3; (b) han d'existir els components capacitat-reduida i capacitat-completa; (c) tots els clústers destí han d'estar registrats a Argo CD amb les etiquetes entorn, region i rol; (d) l'AppProject rutas-norte ha de tenir tots dos servidors a la seva llista de destins permesos, o Argo CD rebutjarà les Application generades. Nota addicional: com que l'HPA governa les rèpliques, el component hauria d'ajustar minReplicas/maxReplicas de l'HPA, no el camp replicas del Deployment.

Solució 3. Passos problemàtics: el 4 (22 min sobre uns 5 d'esperats) i el 6 (14 min sobre 2).

Pas 4: causa probable, la regió secundària no tenia capacitat de nodes disponible i es va haver d'esperar que l'autoescalador aprovisionés nodes nous, incloent-hi la descàrrega d'imatges que no estaven en memòria cau en aquells nodes. Acció correctora: mantenir capacitat mínima permanent i preescalfar les imatges (per exemple, amb un DaemonSet que les descarregui, o reservant nodes amb les imatges ja presents). Alternativa complementària: sobreaprovisionar amb pods de baixa prioritat que Karpenter desallotgi en escalar (09-03).

Pas 6: catorze minuts per a un canvi de DNS indica que no estava automatitzat; probablement algú va editar registres a mà en una consola web sota pressió, o es van haver de buscar les credencials. Acció correctora: guionitzar el canvi amb el fitxer de canvi ja escrit i versionat al repositori, executable amb una sola comanda, i provar-lo fora del simulacre. Comprovar a més que el TTL dels registres és de 60 segons i no el valor per defecte, que sol ser molt més gran.

Hem vist per què una empresa acaba amb diversos clústers —aïllament del pla de control, radi d'impacte, latència per regions, residència de la dada, versions diferents i el simple fet que un clúster també s'actualitza— i què costa això realment. Vam recórrer les topologies habituals amb la recomanació de començar per un i desdoblar primer producció davant de la resta; les cinc capes de defensa per no aplicar mai al clúster equivocat, de les quals la més rendible és posar el context al prompt i la més efectiva és que producció sigui de només lectura per defecte; el govern de la flota amb el generador de clústers d'ApplicationSet combinat amb les superposicions de Kustomize; la idea de clúster com a producte per combatre la deriva; els tres nivells de connectivitat entre clústers i el criteri honest sobre quan una malla de servei es justifica; i la recuperació davant de desastres, on el difícil mai no són els manifests sinó la dada, amb la seva replicació asíncrona, el seu RPO no nul i el procediment de tornada que gairebé ningú no escriu.

El pla de Rutas Norte, amb dos clústers avui i una regió secundària aprovada, il·lustra l'essencial: la decisió no es pren per elegància arquitectònica, sinó comparant el cost de la redundància amb el cost d'una hora caiguda al pont de maig. I el simulacre d'octubre, amb el seu RTO real de 71 minuts i els seus onze dies de replicació trencada que ningú no havia detectat, deixa la lliçó més important: un procediment no executat no és un pla.

Ja tenim la plataforma desplegada, amb estat, amb canalització, amb desplegaments segurs i amb una flota governada. Falta el que cap tutorial no explica i el que ocupa realment el dia a dia: mantenir-la viva. A l'última lliçó del mòdul, Operació en Producció: Incidències, Runbooks i Costos, veurem com es gestiona una incidència, com s'escriu un runbook útil, com el pressupost d'error decideix què fa l'equip el mes que ve, com es planifica la capacitat del pont de maig i per què la factura de Kubernetes es dispara i què fer-hi.