Quan contractar un DevOps o SRE freelance (i quan no)
Senyals que el vostre equip necessita un DevOps o SRE freelance, quines tasques externalitzar, quan no compensa i com evitar dependre d'una persona.
Per Víctor Piles TemporalSRE i tècnic de sistemesPublicat el Actualitzat el 7 min de lectura
Molts equips xicotets de desenvolupament arriben al mateix punt: l’aplicació funciona, hi ha clients que la fan servir, i els desplegaments, els servidors i les còpies s’han anat muntant sobre la marxa. Ningú té temps d’endreçar-ho i contractar algú a jornada completa per a això sembla excessiu. Aquí és on encaixa un DevOps o SRE freelance. Però no sempre: hi ha casos en què no compensa, i convé saber-ho abans de contractar.
En resum: un DevOps o SRE freelance té sentit quan la infraestructura frena l’equip (desplegaments manuals, caigudes sense explicació, un servidor que només entén una persona) però no dona feina per a un lloc fix. No compensa si necessiteu resposta humana immediata a qualsevol hora sense contractar guàrdia, o si el problema real és de producte, no d’infraestructura. L’encàrrec ha de deixar-ho tot documentat i en codi perquè no depengau de ningú.
Què fa un DevOps o SRE en un equip xicotet?
En una empresa gran són llocs diferents: DevOps se centra en com es construeix i es desplega el programari, i SRE (Site Reliability Engineering), en el fet que el servei en producció siga fiable i mesurable. En un equip de cinc o deu persones, la mateixa persona sol cobrir les dues coses:
- Desplegaments automàtics: que pujar una versió siga un procés repetible (CI/CD) i no una sessió d’SSH amb els dits creuats.
- Infraestructura com a codi: servidors, xarxes i serveis descrits en fitxers versionats (Terraform, Ansible, Docker Compose), no configurats a mà.
- Contenidors: empaquetar l’aplicació amb Docker perquè funcione igual al portàtil, en proves i en producció.
- Monitoratge i alertes: saber que alguna cosa va malament abans que us ho diga un client.
- Còpies i recuperació: que hi haja un pla per tornar a aixecar el servei i que s’haja provat.
Senyals que ho necessiteu
Si us reconeixeu en dues o tres d’aquestes situacions, la infraestructura ja costa més del que sembla:
- Desplegar fa por i es fa de nit o en divendres «per si de cas».
- Hi ha un servidor que ningú s’atreveix a reiniciar ni a actualitzar.
- Només una persona sap com està muntada la producció, i no està documentat.
- Les caigudes les descobreixen els clients, no una alerta.
- Els desenvolupadors dediquen hores a barallar-se amb servidors en lloc de fer-ho amb el producte.
- No sabeu si les còpies de la base de dades es poden restaurar, perquè no s’ha provat mai.
Quan no compensa
Un freelance no és la resposta a tot, i és millor dir-ho clar:
- Si necessiteu resposta humana a qualsevol hora tots els dies de l’any. La vigilància automàtica pot funcionar a qualsevol hora, però una sola persona no pot garantir que algú conteste a les tres de la matinada cada nit. Per a això cal un equip amb torns o una guàrdia contractada i per escrit. En el meu cas, la vigilància automàtica és contínua i la resposta humana és el següent dia feiner, en horari laboral, també en l’SRE com a servei.
- Si la càrrega és de jornada completa i permanent. Si hi ha feina d’infraestructura per a quaranta hores setmanals durant anys, probablement us convé contractar algú en plantilla. Un freelance us pot ajudar a deixar-ho endreçat i a definir el lloc.
- Si el problema no és d’infraestructura. Una aplicació lenta per consultes mal fetes o per una arquitectura que no escala no s’arregla amb més servidors. Convé diagnosticar-ho abans.
| Situació | Opció que sol encaixar |
|---|---|
| Infraestructura desendreçada, equip xicotet, sense necessitat de guàrdia nocturna | SRE com a servei, un projecte tancat o una bossa d’hores |
| Feina d’infraestructura constant a jornada completa | Persona en plantilla (un freelance pot preparar el terreny) |
| Servei crític amb resposta humana immediata a qualsevol hora | Equip amb torns de guàrdia, o guàrdia contractada a part |
| Només necessiteu que algú mantinga un o dos servidors | SRE com a servei, pla Estàndard |
Com plantejar l’encàrrec
La manera més sana de treballar amb un freelance és per objectius concrets i amb lliurables que es queden a la vostra empresa:
- Diagnòstic inicial. Inventari del que hi ha: servidors, serveis, accessos, còpies, dominis, certificats. N’ix una llista de riscos ordenada per prioritat.
- Primeres millores d’impacte. Normalment còpies verificades, monitoratge bàsic i un desplegament automatitzat. Són les que donen més tranquil·litat amb menys esforç.
- Passar a codi el que està fet a mà. Infraestructura descrita en un repositori vostre, amb el seu README, perquè qualsevol tècnic la puga entendre.
- Quota mensual o bossa d’hores. Un cop endreçat, la feina baixa molt: actualitzacions, revisió d’alertes, millores per tiquets i un informe cada mes.
Què exigir per no dependre d’una persona
El risc més gran d’externalitzar la infraestructura és que el coneixement es quede al cap de l’extern. Demaneu sempre:
- Que tot siga als vostres repositoris i comptes, no als de la persona externa. Les credencials, en un gestor de contrasenyes de l’empresa.
- Documentació de com desplegar, restaurar i escalar, escrita per a algú que no hi era.
- Eines estàndard (Docker, Terraform, Ansible, GitHub Actions o GitLab CI) en lloc de scripts casolans que només entén qui els va escriure.
- Accés revocable amb comptes propis del tècnic, mai el compte d’administrador compartit.
Amb això, si demà canvieu de tècnic o contracteu algú en plantilla, el traspàs és qüestió de dies.
He estat als dos costats: com a CTO de startups, decidint quina infraestructura muntar amb un equip xicotet, i auditant la d’altres empreses des de fora. De tots dos en trec la mateixa conclusió: el que està en codi i documentat es traspassa sense dependre de ningú.
A la pàgina d’SRE com a servei explique com treballe amb una quota mensual, i a exemples podeu veure un informe mensual i un extracte d’auditoria amb dades fictícies. Si el que us preocupa són les còpies, comenceu per la guia sobre com comprovar que les vostres còpies serveixen, i si la vostra aplicació viu en un servidor que ningú manté, per la de què ha d’incloure el manteniment d’un servidor. Voleu explicar-me com teniu muntat el vostre sistema? Reserveu una trucada gratuïta de 20 minuts.
Preguntes freqüents
DevOps és el mateix que administrador de sistemes?
Se solapen molt. L’administrador de sistemes clàssic manté servidors i serveis; l’enfocament DevOps hi afegeix automatització, infraestructura com a codi i desplegaments continus. En un equip xicotet, la frontera és difusa i el que importa és que la feina quede automatitzada i documentada.
Pot un freelance treballar amb el meu proveïdor cloud actual?
Sí. La feina és la mateixa a AWS, Azure, Google Cloud, Hetzner, OVH o en servidors propis. El que sí que convé revisar és que els comptes estiguen a nom de l’empresa i no d’una persona.
Cal Kubernetes?
Per a la majoria d’equips xicotets, no. Uns quants servidors amb Docker Compose, desplegament automàtic i un bon monitoratge cobreixen moltes aplicacions amb molta menys complexitat. Kubernetes té sentit quan hi ha molts serveis, molt de trànsit variable o un equip que ja el coneix.
Quant de temps cal per endreçar una infraestructura?
Depén de quants serveis hi haja i de com estiguen. Per això el primer pas és el diagnòstic: amb l’inventari al davant es pot estimar cada fase en lloc de donar una xifra a cegues.
Referències
- Google: Site Reliability Engineering, capítol «Embracing Risk», sobre objectius de disponibilitat i pressupost d’errors (en anglés).
- Google: Site Reliability Engineering, capítol «Eliminating Toil», sobre la feina manual i repetitiva que convé automatitzar (en anglés).
