DevOps mínim viable: el que tota startup necessita abans de posar res en producció
No necessites Kubernetes. Probablement tampoc no necessites microserveis. I segur que no necessites un equip d'SRE dedicat en aquesta fase. Però sí que necessites uns fonaments de DevOps. Sense això, cada desplegament és jugar a la ruleta russa i cada incidència en producció acaba sent un foc per apagar a les tres de la matinada.
He vist startups amb un producte sòlid i tracció real perdre setmanes per no tenir un pipeline de CI/CD decent. I n'he vist d'altres que es van passar mesos muntant infraestructura de gran empresa quan tenien 3 enginyers i 0 clients de pagament. Tots dos extrems són un error. El que necessites és el DevOps mínim viable.
La checklist del DevOps mínim viable
Aquests són els 8 elements que tota startup necessita abans de posar un producte a mans d'usuaris reals. Això no es negocia. Si te'n falta cap, estàs acumulant deute operatiu que t'esclatarà a la cara en el pitjor moment possible.
1. Control de versions amb una estratègia de branching
Sembla obvi, però la quantitat de startups que treballen directament sobre main sense cap estratègia de branching és esgarrifosa.
Tens dues opcions raonables:
- Trunk-based development. Branques de vida curta (hores, no dies), merges freqüents a main, feature flags per al codi a mig fer. Ideal per a equips petits que despleguen diverses vegades al dia.
- Git Flow simplificat. Branques de feature, una branca de develop, releases des de main. Més estructura, útil quan necessites entorns de staging ben definits.
Per a la majoria de startups en fase inicial, trunk-based amb feature flags és l'opció encertada. Menys overhead, menys conflictes de merge, cicles més ràpids.
2. Pipeline de CI: lint, test i build a cada PR
Cada pull request ha de passar per un pipeline automatitzat abans que ningú el revisi. Com a mínim:
- Linting. ESLint, Pylint, el que toqui segons el teu stack. No és una qüestió d'estètica — és prevenció de bugs.
- Tests automatitzats. Tests unitaris com a mínim. Tests d'integració si en tens. El pipeline falla si falla qualsevol test. Sense excepcions.
- Build. Si la teva aplicació compila, compila-la a la CI. Un PR que trenca el build no es mergeja. Punt.
Això et dona una xarxa de seguretat bàsica. No és perfecta, però és infinitament millor que el «a la meva màquina funciona».
3. Pipeline de CD: desplegament automatitzat a staging i producció
Si fas els desplegaments a mà — SSH al servidor, git pull, npm run build i a resar — vius 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 a l'abast. Un botó o una ordre per tornar a la versió anterior en menys de 5 minuts.
Desplegar ha de ser avorrit. Si cada cop que es puja a producció tot l'equip aguanta 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:
- L'aplicació està en línia? Monitorització d'uptime. Si cau, te n'assabentes en qüestió de minuts, no quan un usuari ho piula.
- Hi ha errors? Taxa d'errors 5xx, excepcions no capturades. Eines com Sentry van perfectes per a això.
- Va ràpida? Temps de resposta dels teus endpoints crítics. Si la teva API passa de 200 ms a 2 segons, ho vols saber abans que els usuaris.
Les opcions: Datadog si tens pressupost, New Relic amb el tier gratuït, o fins i tot CloudWatch si ets a AWS. L'eina és secundària: l'important és que la monitorització existeixi i que les alertes arribin a algú que se les miri.
5. Logging centralitzat i cercable
console.log en producció no és logging. I els logs escampats per 3 servidors diferents no serveixen de res quan tens una incidència a les 11 de la nit.
Necessites els logs centralitzats en un lloc on els puguis cercar. Les opcions:
- ELK Stack (Elasticsearch, Logstash, Kibana). Potent, però demana manteniment si te l'allotges tu mateix.
- CloudWatch Logs si ets a AWS. Fàcil de configurar, cercable, integrat.
- Papertrail o Logtail. Senzills, barats i més que suficients per a una startup en fase inicial.
La regla d'or: si un usuari t'avisa d'un bug, 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 no has provat mai de restaurar-los. El mínim:
- Backups automàtics diaris de la base de dades. Si fas servir RDS o Cloud SQL, això ja ve de sèrie.
- Retenció mínima de 7 dies. Idealment, 30.
- Restore provat. Com a mínim un cop per trimestre, restaura un backup en un entorn de proves i comprova que les dades hi són. Si no has provat mai el restore, no tens backups — tens una il·lusió de seguretat.
7. Paritat d'entorns: staging com a mirall de producció
L'entorn de staging ha de ser tan semblant a producció com sigui possible. La mateixa versió de base de dades, la mateixa configuració de servidor, les mateixes variables d'entorn (amb valors diferents, és clar).
Si una cosa funciona a staging però falla a producció, el teu staging no serveix de res. Els problemes més habituals:
- Versions de dependències diferents. Staging amb Node 18, producció amb Node 16. Fes servir Docker o, com a mínim, un
.nvmrcper fixar versions. - Bases de dades diferents. Staging amb SQLite, producció amb PostgreSQL. No. La mateixa base de dades als dos entorns.
- Dades de prova poc realistes. El teu staging té 10 registres; la teva producció, 100.000. Els problemes de rendiment no apareixen amb 10 registres.
8. Gestió de secrets: zero credencials al codi
Si al teu codi font hi ha una API key, una contrasenya de base de dades o un token d'accés, tens un problema de seguretat que només és qüestió de temps que exploti.
El mínim:
- Variables d'entorn per a tots els secrets. Mai al codi, mai al repositori.
.enval.gitignore. Sempre. Sense excepcions.- Rotació de secrets. Si un secret es filtra, l'has de poder rotar en minuts, no en hores.
Amb eines com AWS Secrets Manager, HashiCorp Vault o fins i tot el gestor de secrets de GitHub Actions en tens prou per començar.
El que NO necessites (encara)
Tan important com saber què necessites és saber què no. Aquestes són les trampes de sobreenginyeria més habituals:
- Kubernetes. Si no tens un equip de més de 10 enginyers i necessitats reals d'orquestració de contenidors, Kubernetes és complexitat que no aporta valor. Amb un ECS senzill, Railway o Fly.io en tens de sobres.
- Service mesh. Istio, Linkerd... solucions a problemes que no tens amb 3 microserveis (que, de fet, probablement haurien de ser un monòlit).
- Dashboards de mètriques a mida. Un Grafana amb 15 panells no et fa anar més ràpid. Les alertes bàsiques, sí.
- Failover multiregió. Si la teva startup té 500 usuaris, no necessites redundància geogràfica. Necessites un uptime sòlid en una sola regió.
La regla: si no pots explicar en una frase per què necessites una eina o una pràctica, probablement no la necessites.
Quan toca pujar de nivell
El DevOps mínim viable no és el punt d'arribada — és el punt de partida. Toca començar a invertir en infraestructura més robusta quan:
- Tens clients de pagament. Ara hi ha SLA implícits. Cada caiguda costa diners de veritat.
- L'equip passa dels 5 enginyers. Més gent vol dir més automatització, millors entorns de desenvolupament, pipelines més sofisticats.
- Tens requisits regulatoris. Si gestiones dades de salut, financeres o personals amb obligacions de compliment normatiu, la infraestructura ho ha de reflectir.
Eines segons el pressupost
Pressupost zero (free tier): GitHub Actions per a CI/CD, Vercel o Railway per al hosting, Sentry gratuït per als errors, UptimeRobot per a la monitorització d'uptime. Et cobreix sorprenentment bé fins als primers milers d'usuaris.
Pressupost mitjà (200-500 EUR/mes): AWS amb Terraform per a la infraestructura com a codi, GitHub Actions o CircleCI per a CI/CD, Datadog o New Relic per a la monitorització, ELK gestionat o CloudWatch per als logs.
Pressupost enterprise (1.000+ EUR/mes): Serveis gestionats d'AWS o GCP, ECS o EKS per als contenidors, la suite completa de Datadog, PagerDuty per a la gestió d'incidències, Terraform Cloud per a la gestió de l'estat.
El perfil que necessites
Muntar tot això no demana un equip de DevOps. Demana un enginyer sènior que ja ho hagi fet abans. Algú que distingeixi 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 d'estar al servei del producte, i no al revés.
A Conectia tenim enginyers sènior de DevOps i infraestructura que han posat exactament aquesta mena de fonaments en startups — sense sobreenginyeria, sense solucions enterprise per a problemes de startup. Tots han passat el nostre vetting tècnic liderat per CTOs, on avaluem experiència real en producció, no certificacions. I responem en menys de 72 hores.
El DevOps mínim viable no és gens glamurós. No escriuràs cap post a LinkedIn fardant 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 desplegar un divendres.
Necessites un enginyer DevOps sènior que posi els fonaments sense sobreenginyeria? Parla amb un CTO — la infraestructura adequada per a la teva fase, a punt en qüestió de dies.
