Cuándo contratar un DevOps o SRE freelance (y cuándo no)

Muchos equipos pequeños de desarrollo llegan al mismo punto: la aplicación funciona, hay clientes usándola, y los despliegues, los servidores y las copias se han ido montando sobre la marcha. Nadie tiene tiempo de ordenarlo y contratar a alguien a jornada completa para eso parece excesivo. Ahí es donde encaja un DevOps o SRE freelance. Pero no siempre: hay casos en los que no compensa, y conviene saberlo antes de contratar.

¿Qué hace un DevOps o SRE en un equipo pequeño?

En una empresa grande son puestos distintos: DevOps se centra en cómo se construye y se despliega el software, y SRE (Site Reliability Engineering) en que el servicio en producción sea fiable y medible. En un equipo de cinco o diez personas, la misma persona suele cubrir las dos cosas:

• Despliegues automáticos: que subir una versión sea un proceso repetible (CI/CD) y no una sesión de SSH con los dedos cruzados.
• Infraestructura como código: servidores, redes y servicios descritos en archivos versionados (Terraform, Ansible, Docker Compose), no configurados a mano.
• Contenedores: empaquetar la aplicación con Docker para que funcione igual en el portátil, en pruebas y en producción.
• Monitorización y alertas: saber que algo va mal antes de que os lo diga un cliente.
• Copias y recuperación: que exista un plan para volver a levantar el servicio y que se haya probado.

Señales de que lo necesitáis

Si os reconocéis en dos o tres de estas situaciones, la infraestructura ya está costando más de lo que parece:

• Desplegar da miedo y se hace de noche o en viernes «por si acaso».
• Hay un servidor que nadie se atreve a reiniciar ni a actualizar.
• Solo una persona sabe cómo está montado producción, y no está documentado.
• Las caídas se descubren por los clientes, no por una alerta.
• Los desarrolladores dedican horas a pelearse con servidores en lugar de con el producto.
• No sabéis si las copias de la base de datos se pueden restaurar, porque nunca se ha probado.

Cuándo no compensa

Un freelance no es la respuesta a todo, y es mejor decirlo claro:

• Si necesitáis respuesta humana 24/7 todos los días del año. La vigilancia automática puede funcionar a cualquier hora, pero una sola persona no puede garantizar que alguien conteste a las tres de la madrugada cada noche. Para eso hace falta un equipo con turnos o una guardia contratada y por escrito. En mi caso, la vigilancia automática es continua y la respuesta humana es el siguiente día hábil, en horario laboral, también en SRE como servicio.
• Si la carga es de jornada completa y permanente. Si hay trabajo de infraestructura para cuarenta horas semanales durante años, probablemente os conviene contratar a alguien en plantilla. Un freelance puede ayudaros a dejarlo ordenado y a definir el puesto.
• Si el problema no es de infraestructura. Una aplicación lenta por consultas mal hechas o por una arquitectura que no escala no se arregla con más servidores. Conviene diagnosticarlo antes.

Cómo plantear el encargo

La forma más sana de trabajar con un freelance es por objetivos concretos y con entregables que se queden en vuestra empresa:

1. Diagnóstico inicial. Inventario de lo que hay: servidores, servicios, accesos, copias, dominios, certificados. Sale una lista de riesgos ordenada por prioridad.
2. Primeras mejoras de impacto. Normalmente copias verificadas, monitorización básica y un despliegue automatizado. Son las que más tranquilidad dan con menos esfuerzo.
3. Pasar a código lo que está a mano. Infraestructura descrita en un repositorio vuestro, con su README, para que cualquier técnico pueda entenderla.
4. Cuota mensual o bolsa de horas. Una vez ordenado, el trabajo baja mucho: actualizaciones, revisión de alertas, mejoras por tickets y un informe cada mes.

Qué exigir para no depender de una persona

El mayor riesgo de externalizar infraestructura es que el conocimiento se quede en la cabeza del externo. Pedid siempre:

• Que todo esté en vuestros repositorios y cuentas, no en los del freelance. Las credenciales, en un gestor de contraseñas de la empresa.
• Documentación de cómo desplegar, restaurar y escalar, escrita para alguien que no estuvo allí.
• Herramientas estándar (Docker, Terraform, Ansible, GitHub Actions o GitLab CI) en lugar de scripts caseros que solo entiende quien los escribió.
• Acceso revocable con cuentas propias del técnico, nunca la cuenta de administrador compartida.

Con eso, si mañana cambiáis de técnico o contratáis a alguien en plantilla, el traspaso es cuestión de días.

He estado en los dos lados: como CTO de startups, decidiendo qué infraestructura montar con un equipo pequeño, y auditando la de otras empresas desde fuera. De los dos saco la misma conclusión: lo que está en código y documentado se traspasa sin depender de nadie.

En la página de SRE como servicio explico cómo trabajo con una cuota mensual, y en ejemplos podéis ver un informe mensual y un extracto de auditoría con datos ficticios. Si lo que os preocupa son las copias, empezad por la guía sobre cómo comprobar que vuestras copias sirven, y si vuestra aplicación vive en un servidor que nadie mantiene, la de qué debe incluir el mantenimiento de un servidor. ¿Queréis contarme cómo está montado lo vuestro? Reservad una llamada gratuita de 20 minutos.

Preguntas frecuentes

¿Es lo mismo DevOps que administrador de sistemas?

Se solapan mucho. El administrador de sistemas clásico mantiene servidores y servicios; el enfoque DevOps añade automatización, infraestructura como código y despliegues continuos. En un equipo pequeño, la frontera es borrosa y lo importante es que el trabajo quede automatizado y documentado.

¿Puede un freelance trabajar con mi proveedor cloud actual?

Sí. El trabajo es el mismo en AWS, Azure, Google Cloud, Hetzner, OVH o servidores propios. Lo que sí conviene revisar es que las cuentas estén a nombre de la empresa y no de una persona.

¿Hace falta Kubernetes?

Para la mayoría de equipos pequeños, no. Unos pocos servidores con Docker Compose, despliegue automático y buena monitorización cubren muchas aplicaciones con mucha menos complejidad. Kubernetes tiene sentido cuando hay muchos servicios, mucho tráfico variable o un equipo que ya lo conoce.

¿Cuánto tiempo lleva ordenar una infraestructura?

Depende de cuántos servicios haya y de cómo estén. Por eso el primer paso es el diagnóstico: con el inventario delante se puede estimar cada fase en lugar de dar una cifra a ciegas.

Referencias

• Google: Site Reliability Engineering, capítulo «Embracing Risk», sobre objetivos de disponibilidad y presupuesto de errores (en inglés).
• Google: Site Reliability Engineering, capítulo «Eliminating Toil», sobre el trabajo manual y repetitivo que conviene automatizar (en inglés).