DevOps Mínim Viable: El que Tota Startup Necessita Abans d'Anar a Producció

No necessites Kubernetes. Probablement no necessites microserveis. Definitivament no necessites un equip de SRE dedicat a aquestes alçades. Però sí que necessites una base de DevOps. Sense ella, cada desplegament és una ruleta russa i cada incidència en producció es converteix en un incendi que apagar a les 3 de la matinada.

He vist startups amb producte sòlid i tracció real que van perdre setmanes per no tenir un pipeline de CI/CD decent. I n'he vist d'altres que van gastar mesos muntant infraestructura d'empresa gran quan tenien 3 enginyers i 0 clients de pagament. Tots dos extrems són errors. El que necessites és el DevOps Mínim Viable.

El checklist del DevOps Mínim Viable

Aquests són els 8 elements que tota startup necessita abans de posar un producte a les mans d'usuaris reals. No és negociable. Si et falta algun, estàs acumulant deute operatiu que et reventarà a la cara en el pitjor moment possible.

1. Control de versions amb branching strategy

Això sembla obvi, però la quantitat de startups que treballen directament sobre main sense estratègia de branching és sorprenent.

Tens dues opcions raonables:

• Trunk-based development. Branches curtes (hores, no dies), merge freqüent a main, feature flags per a codi no acabat. Ideal per a equips petits que despleguen diverses vegades al dia.
• Git Flow simplificat. Branches de feature, una branch de develop, releases des de main. Més estructura, útil quan necessites staging environments clars.

Per a la majoria de startups en fase primerenca, trunk-based amb feature flags és l'opció correcta. Menys overhead, menys conflictes de merge, cicles més ràpids.

2. Pipeline de CI: lint, test, build a cada PR

Cada pull request ha de passar per un pipeline automatitzat abans que ningú la revisi. Mínim:

• Linting. ESLint, Pylint, el que correspongui al teu stack. Això no és estètica — és prevenció de bugs.
• Tests automatitzats. Unit tests com a mínim. Integration tests si en tens. El pipeline falla si algun test falla. Sense excepcions.
• Build. Si la teva aplicació compila, compila a CI. Un PR que trenca el build no es mergeja. Punt.

Això et dona una xarxa de seguretat bàsica. No perfecta, però infinitament millor que "funciona a la meva màquina."

3. Pipeline de CD: desplegament automatitzat a staging i producció

Si estàs fent desplegaments manuals — SSH al servidor, git pull, npm run build, resar — estàs vivint perillosament. Un pipeline de CD bàsic fa això:

• Merge a develop = desplegament automàtic a staging.
• Merge a main (o tag de release) = desplegament automàtic a producció.
• Rollback accessible. Un botó o una comanda per tornar a la versió anterior en menys de 5 minuts.

El desplegament ha de ser un event avorrit. Si cada vegada que desplegueu a producció tot l'equip conté la respiració, tens un problema de procés, no de producte.

4. Monitorització bàsica: uptime, errors, temps de resposta

No necessites dashboards amb 47 mètriques. Necessites saber tres coses en tot moment:

• La teva aplicació està online? Monitorització d'uptime. Si cau, te n'assabentes en minuts, no quan un usuari et tuiteja.
• Hi ha errors? Taxa d'errors 5xx, excepcions no capturades. Eines com Sentry són perfectes per a això.
• És ràpida? Temps de resposta dels teus endpoints crítics. Si la teva API passa de 200ms a 2 segons, vols saber-ho abans que els teus usuaris ho notin.

Les opcions: Datadog si tens pressupost, New Relic amb el seu tier gratuït, o fins i tot CloudWatch si ets a AWS. L'important no és l'eina — és que la monitorització existeixi i que les alertes arribin on algú les vegi.

5. Logging centralitzat i cercable

console.log en producció no és logging. Els logs dispersos en 3 servidors diferents no són útils quan tens una incidència a les 11 de la nit.

Necessites logs centralitzats en un lloc on puguis buscar. Les opcions:

• ELK Stack (Elasticsearch, Logstash, Kibana). Potent, però requereix manteniment si l'hosteges tu.
• CloudWatch Logs si ets a AWS. Fàcil de configurar, cercable, integrat.
• Papertrail o Logtail. Simples, barats, suficients per a startups en fase primerenca.

La regla d'or: si un usuari et reporta un error, hauries de poder trobar el log corresponent en menys de 5 minuts.

6. Backup i recovery: backups de base de dades amb restore provat

Tenir backups no compta si mai has provat restaurar-los. Això és el mínim:

• Backups automàtics diaris de la teva base de dades. Si fas servir RDS o Cloud SQL, això ve de sèrie.
• Retenció mínima de 7 dies. Idealment 30.
• Restore provat. Almenys un cop al trimestre, restaura un backup en un entorn de prova i verifica que les dades hi són. Si mai has provat el teu restore, no tens backups — tens una il·lusió de seguretat.

7. Paritat d'entorns: staging reflecteix producció

El teu entorn de staging ha de ser el més semblant possible a producció. Mateixa versió de base de dades, mateixa configuració de servidor, mateixes variables d'entorn (amb valors diferents, òbviament).

Si alguna cosa funciona a staging però falla a producció, el teu staging no serveix. Els problemes més comuns:

• Versions diferents de dependències. Staging amb Node 18, producció amb Node 16. Fes servir Docker o almenys .nvmrc per fixar versions.
• Base de dades diferent. Staging amb SQLite, producció amb PostgreSQL. No. Fes servir la mateixa base de dades als dos entorns.
• Dades de prova irreals. El teu staging té 10 registres. La teva producció en té 100.000. Els problemes de rendiment no apareixen amb 10 registres.

8. Gestió de secrets: zero credencials hardcodejades

Si hi ha una API key, contrasenya de base de dades, o token d'accés al teu codi font, tens un problema de seguretat que és qüestió de temps que exploti.

El mínim:

• Variables d'entorn per a tots els secrets. Mai al codi, mai al repositori.
• .env a .gitignore. Sempre. Sense excepcions.
• Rotació de secrets. Si un secret es filtra, hauries de poder rotar-lo en minuts, no en hores.

Eines com AWS Secrets Manager, HashiCorp Vault, o fins i tot el gestor de secrets de GitHub Actions n'hi ha prou per començar.

El que NO necessites (encara)

Tan important com el que necessites és el que no necessites. Aquestes són les trampes d'over-engineering més comunes:

• Kubernetes. Tret que tinguis un equip de més de 10 enginyers i necessitats reals d'orquestració de contenidors, Kubernetes és complexitat que no t'aporta valor. Un simple ECS, Railway, o Fly.io és més que suficient.
• Service mesh. Istio, Linkerd... solucions a problemes que no tens amb 3 microserveis (que probablement haurien de ser un monòlit).
• Dashboards de mètriques custom. Grafana amb 15 panells no et fa més ràpid. Les alertes bàsiques sí.
• Multi-region failover. Si la teva startup té 500 usuaris, no necessites redundància geogràfica. Necessites un bon uptime en una regió.

La regla: si no pots explicar en una frase per què necessites una eina o pràctica, probablement no la necessites.

Quan pujar de nivell

El DevOps Mínim Viable no és la destinació — és el punt de partida. Hauries de començar a invertir en infraestructura més robusta quan:

• Tens clients de pagament. Ara hi ha SLAs implícits. El downtime costa diners reals.
• El teu equip supera els 5 enginyers. Més gent = més necessitat d'automatització, millors entorns de desenvolupament, pipelines més sofisticats.
• Tens requisits regulatoris. Si gestiones dades de salut, financeres o personals amb requeriments de compliment, la teva infraestructura ho ha de reflectir.

Eines per pressupost

Pressupost zero (free tier): GitHub Actions per a CI/CD, Vercel o Railway per a hosting, Sentry free per a errors, UptimeRobot per a monitorització d'uptime. Això et cobreix sorprenentment bé fins als teus primers milers d'usuaris.

Pressupost mitjà (200-500 EUR/mes): AWS amb Terraform per a infraestructura com a codi, GitHub Actions o CircleCI per a CI/CD, Datadog o New Relic per a monitorització, ELK managed o CloudWatch per a logs.

Pressupost enterprise (1.000+ EUR/mes): Serveis managed d'AWS o GCP, ECS o EKS per a contenidors, Datadog full suite, PagerDuty per a gestió d'incidències, Terraform Cloud per a gestió d'estat.

El perfil que necessites

Muntar tot això no requereix un equip de DevOps. Requereix un enginyer sènior que hagi fet això abans. Algú que sàpiga la diferència entre el necessari i l'aspiracional, que pugui configurar un pipeline de CI/CD en un dia — no en un sprint — i que entengui que la infraestructura ha de servir al producte, no al revés.

A Conectia, tenim enginyers sènior de DevOps i infraestructura que han muntat exactament aquest tipus de fonamentació per a startups. Sense over-engineering, sense solucions enterprise per a problemes de startup. L'stack correcte per a la teva fase actual, configurat per escalar quan ho necessitis.

Cada enginyer passa pel nostre procés de vetting tècnic liderat per CTOs. Avaluem experiència real en producció, no certificacions. I estan disponibles en 72 hores.

El DevOps Mínim Viable no és glamurós. No escriuràs un post a LinkedIn presumint del teu pipeline de CI. Però és la diferència entre una startup que pot iterar amb confiança i una que té por de fer deploy un divendres.

---

Necessites un enginyer DevOps sènior que munti les bases sense sobre-enginyeria? Parla amb un CTO — infraestructura correcta per a la teva fase, llesta en dies.