Desplegar sense downtime: per què la teva app no ​​hauria de caure cada vegada que actualitzes

És divendres a les 17.30. Algú de l'equip diu "apujaré el fix ràpid abans del cap de setmana". Es desplega. L'app cau. El telèfon comença a sonar.

Aquesta escena és més comuna del que hauria de fer. I no passa perquè l?equip sigui dolent. Passa perquè molts productes en producció continuen desplegant amb el mètode més bàsic: aturar, substituir, arrencar. En el temps que triga aquest procés, els usuaris veuen errors, l'app deixa de respondre o desapareix directament.

Això és downtime. I desplegar sense downtime hauria de ser l'estàndard, no pas l'excepció. Perquè encara que la caiguda duri trenta segons, per als teus usuaris és una experiència trencada. Pel teu negoci, són transaccions perdudes i un equip que comença a tenir por de desplegar.

Què és el downtime i per què importa més del que sembla

Downtime és qualsevol període en què la teva aplicació no està disponible o no funciona correctament per als usuaris. Pot ser una caiguda total (l'app no ​​respon) o parcial (funciona però amb errors, lentitud o funcionalitats trencades).

Segons dades de Gartner , el cost mitjà del downtime per a una empresa és d'uns 5.600 dòlars per minut. Aquesta xifra varia enormement segons el sector i la mida, però el missatge és clar: cada minut compta.

Però el cost no és només econòmic directe. Hi ha un cost menys visible i més corrosiu.

Pèrdua de confiança. Un usuari que veu un error 503 o una pàgina en blanc no sap si és un desplegament, un atac o una fallada greu. Només sap que el teu producte no funciona. Si passa una vegada, ho tolera. Si passa cada setmana, cerca alternatives.

Por a desplegar. Quan el desplegar és arriscat, l'equip desplega menys. Les releases s'acumulen, cada desplegament és més gran i més perillós, i el cicle es retroalimenta. És la definició d'un cercle viciós.

Finestres de manteniment. Alguns equips resolen el problema programant desplegaments en horaris de baix trànsit: matinades, caps de setmana. Funciona a curt termini, però destrueix la qualitat de vida de l'equip i limita la capacitat de reaccionar ràpidament davant de problemes.

Les estratègies que eliminen (o minimitzen) el downtime

No hi ha una única manera de desplegar sense downtime. Hi ha diverses estratègies, cadascuna amb els seus avantatges i requisits. L'elecció depèn de la teva infraestructura, equip i nivell de risc que pots assumir.

Rolling deployment

És lestratègia més senzilla. En lloc de parar tota l'aplicació, actualitzes les instàncies una per una. Mentre s'actualitza una instància, les altres continuen servint trànsit. Quan la primera acaba, passes a la següent.

El resultat: en tot moment hi ha instàncies funcionant. L'usuari no nota res.

Quan encaixa. Quan la vostra aplicació corre sobre múltiples instàncies (contenidors, servidors, pods de Kubernetes) i les versions nova i antiga poden conviure breument. És l'estàndard a la majoria d'orquestradors moderns. Kubernetes ho fa per defecte.

Quan no encaixa. Si la vostra aplicació té estat en memòria que no es comparteix entre instàncies, o si la nova versió inclou canvis a la base de dades incompatibles amb la versió anterior. En aquests casos, la convivència de versions pot generar errades.

Blue-green deployment

Mantens dos entorns idèntics: blue (la versió actual) i green (la nova versió). Desplegues la nova versió en green, la proves, i quan tot està llest, canvies el trànsit de blue a green. Si alguna cosa falla, tornes a blue en segons.

Quan encaixa. Quan necessiteu certesa total abans d'exposar els usuaris. És ideal per a aplicacions crítiques on un error en producció té un cost alt: ecommerce, fintech, salut.

Quan no encaixa. Necessites el doble d'infraestructura (dos entorns complets corrents alhora). Per a aplicacions amb molts serveis interdependents, mantenir dos entorns sincronitzats pot ser complex i car.

Canary deployment

Desplegues la nova versió, però només l'exposes a un petit percentatge d'usuaris: un 5%, un 10%. Monitoritzes les mètriques (errors, latència, comportament). Si tot va bé, augmentes el percentatge gradualment. Si alguna cosa falla, l'impacte només afecta una fracció dels usuaris.

Quan encaixa. Quan voleu validar canvis amb trànsit real abans d'exposar-los a tots. És l'estratègia preferida d'empreses com ara Netflix, Google i Spotify per a canvis que afecten l'experiència de l'usuari.

Quan no encaixa. Requereix un sistema de routing que permeti dirigir trànsit per percentatge. També necessites bona observabilitat: si no pots mesurar l'impacte del canary en temps real, no serveix de gaire.

Feature flags

Tècnicament, no és una estratègia de desplegament, sinó d'activació. Desplegues el codi nou en producció, però desactivat. Quan vols, actives la funcionalitat per a un grup d'usuaris, un percentatge o tots. Si falla, la desactives sense redesplegar.

Quan encaixa. Quan vols separar el desplegament (acte tècnic) de la release (acte de producte). Això permet desplegar amb freqüència i activar funcionalitats de manera controlada. Eines com LaunchDarkly o Unleash ho fan accessible.

Quan no encaixa. Si no es gestionen bé, els feature flags s'acumulen al codi i generen complexitat. Cada flag és una bifurcació lògica que cal mantenir. Sense disciplina per netejar-los, es converteixen en deute tècnic.

La peça que falta: les migracions de base de dades

Pots tenir una estratègia de desplegament impecable, però si la teva migració de base de dades trenca la compatibilitat amb la versió anterior, tindràs downtime.

Aquest és el punt que més equips subestimen. Desplegar codi és relativament senzill de fer sense talls. Migrar dades en calent és una altra història.

La regla general: les migracions han de ser compatibles cap enrere. Això vol dir que la versió antiga de l'aplicació ha de poder funcionar amb la base de dades ja migrada. Si una migració reanomena una columna, durant el desplegament la versió antiga cercarà la columna amb el nom vell i fallarà.

La solució és desplegar en fases. Primer, una migració que afegeix la nova columna sense eliminar l'antiga. Segon, un desplegament que utilitza la columna nova. Tercer, una migració de neteja que elimina la columna vella. És més feina, però elimina el risc.

Equips que treballen amb Django ho gestionen bé amb les migracions natives del framework, sempre que se segueixi aquesta disciplina de fases. En altres stacks, eines com Flyway o Liquibase faciliten el mateix enfocament.

Què necessita el teu equip per desplegar sense por

Lestratègia de desplegament és la part visible. Però darrere hi ha requisits que, si no hi són, cap estratègia funciona.

Pipeline de CI/CD automatitzat. Si desplegar requereix executar ordres a mà, connectar-se a servidors per SSH o seguir un document de 20 passos, el risc derror humà és alt. Un pipeline automatitzat garanteix que cada desplegament segueix els mateixos passos, amb els mateixos tests, sempre.

Tests que s'executen abans de cada desplegament. No calen milers de tests. Calen els tests correctes: els que validen que les funcionalitats crítiques de la teva aplicació funcionen. Si el teu pipeline no té una suite de tests que bloquegi el desplegament quan falla alguna cosa, estàs desplegant a cegues.

Observabilitat en producció. Necessites saber què passa després de desplegar. Mètriques de latència, taxes derror, ús de recursos. Eines com Datadog, Grafana o New Relic us donen visibilitat sobre l'impacte real de cada desplegament. Sense observabilitat, un canary deployment no té sentit.

Capacitat de rollback ràpid. Desplegar sense downtime no vol dir que res no pugui fallar. Significa que, quan falla, pots tornar enrere en segons, no pas en hores. Si el teu rollback triga més que el propi desplegament, la teva xarxa de seguretat no funciona.

La pregunta que de veritat importa

La pregunta no és "quina estratègia de desplegament ús?". La pregunta és: amb quina freqüència pot desplegar el teu equip sense que ningú no es posi nerviós?

Si la resposta és "un cop al mes, amb molt de compte", tens un problema d'infraestructura i de confiança. Si la resposta és "diverses vegades al dia, sense pensar-ho dues vegades", tens un equip que ha invertit en les eines i pràctiques correctes.

Segons l'informe DORA State of DevOps , els equips d'elit despleguen sota demanda —de vegades desenes de vegades al dia— amb una taxa d'error inferior al 5%. No és màgia. És automatització, observabilitat i estratègies de desplegament que eliminen el risc.

Desplegar no hauria de ser un esdeveniment. Hauria de ser una rutina. I perquè sigui una rutina, la teva app no ​​es pot caure cada vegada que ho fas.