Cuando un equipo empieza a tener problemas con infraestructura, una de las primeras conclusiones suele ser bastante lógica:
«Necesitamos otro DevOps».
Hay más despliegues. Más infraestructura. Más alertas. Más incidencias. Más peticiones del equipo de desarrollo.
Y la persona que lleva Cloud, DevOps o Platform ya no llega a todo.
Contratar puede ser exactamente la decisión correcta.
Pero no siempre.
A veces no falta una persona. A veces la infraestructura está generando más trabajo del que debería. Añadir capacidad a un sistema que produce demasiado trabajo puede aliviar la presión sin resolver su causa.
La distinción importa: contratar es correcto cuando la necesidad es estructural, pero no deberíamos contratar personas permanentemente alrededor de problemas que pueden eliminarse.
La pregunta no es solo cuánta gente tienes
Imaginemos un equipo de producto con aproximadamente veinte desarrolladores y una persona que concentra gran parte del trabajo de Cloud, DevOps y Platform.
En su lista aparecen AWS o Azure, Terraform, Kubernetes, CI/CD, observabilidad, secretos, backups, incidencias, accesos y soporte al equipo. Mirada desde fuera, la respuesta parece evidente: falta otra persona.
Antes conviene preguntar algo más útil:
¿En qué está empleando realmente su tiempo?
No es lo mismo dedicarlo a nuevas capacidades, decisiones de arquitectura y ownership permanente que perderlo repitiendo despliegues, atendiendo alertas sin contexto o desbloqueando tareas que deberían ser autónomas.
Situación A: falta capacidad real
La infraestructura está razonablemente automatizada. Los caminos habituales son reproducibles. Los equipos pueden desplegar, los incidentes dejan aprendizaje y la operación no descansa en memoria individual.
Al mismo tiempo, la empresa incorpora productos, equipos, regiones o requisitos. Aparecen responsabilidades nuevas que seguirán existiendo: seguridad de plataforma, fiabilidad, experiencia de desarrollo, gobierno cloud o una función interna de Platform Engineering.
Aquí probablemente sí tiene sentido contratar. El crecimiento ha creado trabajo permanente y ownership continuo. Una nueva incorporación no está compensando un sistema roto: está asumiendo una responsabilidad duradera.
Situación B: existe demasiado trabajo evitable
Los despliegues tienen pasos manuales. Terraform da miedo tocarlo. Las alertas interrumpen sin indicar qué hacer. Crear un entorno tarda días. Las mismas tareas reaparecen cada semana y las incidencias terminan siempre en la misma persona. Los runbooks no existen o no pueden ejecutarse sin contexto oral.
Contratar puede aumentar capacidad, pero no elimina ese trabajo. Incluso puede repartirlo y hacer que parezca más sostenible durante un tiempo.
Una revisión acotada de CI/CD e infraestructura ayuda a separar backlog permanente de deuda operacional antes de decidir qué perfil necesita el equipo.
1. Los despliegues necesitan vigilancia
Que exista un pipeline no significa que el proceso sea fiable. Un CI/CD puede estar técnicamente implantado y seguir dependiendo de conocimiento tácito, permisos especiales o intervención manual.
Conviene observar el camino completo hasta producción:
- ¿Desplegar requiere que alguien esté pendiente?
- ¿Existen pasos manuales fuera del pipeline?
- ¿Un rollback es sencillo, probado y predecible?
- ¿Los desarrolladores pueden desplegar con autonomía dentro de límites claros?
- ¿Los pipelines fallan con frecuencia por causas ajenas al código?
- ¿Hay una persona que debe intervenir constantemente?
Un pipeline frágil transforma cada release en trabajo operacional. También retrasa cambios pequeños, concentra permisos y anima al equipo a desplegar lotes más grandes, justo lo contrario de lo que suele reducir riesgo.
La mejora no siempre exige rehacer toda la plataforma. Puede empezar por artefactos inmutables, validaciones útiles, gestión coherente de configuración, rollback verificable y un camino de entrega que el equipo entienda. Ese es el propósito de una práctica sana de automatización y DevOps, no acumular YAML.
Si cada despliegue necesita supervisión, probablemente existe un problema que merece resolverse antes de asumir que falta headcount.
2. Demasiadas cosas dependen de una sola persona
El bus factor expresa de forma sencilla cuántas personas pueden dejar de estar disponibles antes de que una parte del trabajo quede bloqueada.
La pregunta práctica es incómoda, pero clara:
¿Qué ocurre si mañana la persona que mejor conoce la infraestructura no está disponible?
Puede que solo ella sepa recuperar un sistema, localizar credenciales, interpretar el networking de Kubernetes, modificar determinados módulos de Terraform, responder a una incidencia o explicar por qué la arquitectura es así.
El problema no es que exista especialización. Un equipo senior siempre tendrá personas con más profundidad en ciertas áreas. El riesgo aparece cuando el conocimiento operacional y los permisos para actuar están concentrados sin un camino alternativo.
Reducir esa dependencia requiere:
- documentación vinculada al sistema real;
- runbooks ejecutables y probados;
- automatización de operaciones frecuentes;
- estándares para los caminos habituales;
- procedimientos de acceso y recuperación;
- ownership principal y de respaldo;
- transferencia práctica, no solo sesiones grabadas.
El objetivo tampoco es que todo el mundo sepa todo. Es que una ausencia no detenga producción y que el equipo pueda actuar con evidencia. Este patrón se puede revisar con más detalle al analizar el bus factor de DevOps.
3. Hay demasiadas tareas manuales repetitivas
SRE utiliza el término toil para describir trabajo manual, repetitivo, operacional y susceptible de automatización que consume tiempo sin aportar proporcionalmente nuevo valor.
No todo trabajo operacional es toil. Investigar un fallo nuevo o diseñar una estrategia de recuperación puede generar aprendizaje. Crear el mismo usuario por quinta vez, copiar una configuración entre entornos o renovar certificados mediante una secuencia manual difícilmente lo hace.
El toil suele esconderse en tareas pequeñas:
- crear y retirar usuarios;
- provisionar entornos;
- modificar DNS;
- renovar certificados;
- aplicar cambios de configuración;
- ejecutar deployments;
- comprobar backups;
- rotar secretos;
- repetir cambios casi idénticos entre cuentas.
Por separado, ninguna parece justificar un proyecto. Juntas fragmentan el día, interrumpen trabajo de mayor valor y convierten a la persona de infraestructura en una cola de tickets humana.
La automatización tampoco consiste en convertir cualquier excepción en una plataforma. Primero hay que medir frecuencia, riesgo, tiempo y variabilidad. Después se automatizan los caminos estables con controles proporcionados. La infraestructura como código con Terraform puede ayudar, pero un repositorio difícil de revisar solo cambia la forma de la deuda técnica.
Un equipo puede estar saturado porque su sistema operativo interno genera demasiado trabajo. Antes de sumar capacidad, conviene decidir qué parte de ese trabajo debería dejar de existir.
4. Las alertas existen, pero no ayudan
Tener Prometheus, Grafana, logs centralizados o una plataforma APM no equivale a tener observabilidad.
Las herramientas recogen señales. La práctica debe convertirlas en respuestas:
- ¿Las alertas son accionables?
- ¿Hay tantas que el equipo las ignora?
- ¿Se sabe qué cambió antes de una incidencia?
- ¿Puede identificarse rápido qué servicio está degradado?
- ¿Se distingue una anomalía técnica de un impacto real en usuario?
- ¿Cada aviso tiene severidad, owner y una acción esperada?
Cuando las alertas no filtran ni aportan contexto, producen más trabajo. La persona de guardia reconstruye manualmente la historia, salta entre dashboards y pregunta qué se desplegó. Añadir otro ingeniero reparte la investigación, pero no mejora la señal.
Una práctica de SRE y observabilidad debería conectar síntomas, cambios, dependencias y objetivos de fiabilidad. No hace falta convertir este problema en un proyecto infinito de herramientas.
Una buena observabilidad no significa más dashboards. Significa poder responder antes a las preguntas importantes.
5. Kubernetes necesita permanentemente atención especializada
Kubernetes puede ser una decisión razonable. También introduce una superficie operacional amplia: upgrades, seguridad, networking, almacenamiento, ingress, observabilidad, recursos, autoscaling, GitOps, políticas, backups y disaster recovery.
El problema no es que el clúster necesite conocimiento especializado. El problema aparece cuando cualquier cambio, diagnóstico o actualización termina siempre en el mismo ingeniero senior.
En ese caso conviene revisar tres cosas:
- si Kubernetes sigue siendo la abstracción adecuada para el producto;
- qué complejidad puede delegarse en servicios gestionados o caminos estandarizados;
- qué operaciones deben convertirse en procedimientos repetibles para el equipo.
A veces hará falta más capacidad permanente para operar una plataforma que ya es central. Otras veces hace falta estabilizarla, reducir excepciones, definir límites y transferir la operación. Un trabajo específico de consultoría y soporte Kubernetes puede tener principio y fin sin cuestionar la tecnología completa.
Si cualquier cambio depende del mismo especialista, quizá no necesitas simplemente otra persona. Quizá necesitas reducir la complejidad operacional que esa persona absorbe.
6. La factura cloud aumenta pero nadie puede explicar claramente por qué
Que el coste de Cloud crezca no implica que exista un problema. Más usuarios, tráfico, datos, disponibilidad o regiones pueden justificarlo.
El riesgo es no poder responder:
¿Qué está provocando el incremento?
La respuesta exige mirar más allá del total mensual: rightsizing, recursos huérfanos, almacenamiento, tráfico, snapshots, bases de datos, cargas de Kubernetes, compromisos, decisiones de arquitectura, tagging y ownership.
Sin atribución, el equipo recibe una factura y abre una investigación. Con ownership y contexto, puede distinguir crecimiento productivo, capacidad preventiva, desperdicio y decisiones deliberadas.
FinOps no consiste únicamente en reducir gasto. Consiste en entender el coste y relacionarlo con el valor que genera.
Una práctica de FinOps útil crea un ciclo de decisión entre ingeniería, producto y negocio. No persigue el menor gasto posible ni recorta resiliencia para cumplir una cifra aislada.
Si explicar cada variación requiere días de investigación manual, parte de la presión del equipo no viene del crecimiento. Viene de una arquitectura financiera y técnica sin suficiente visibilidad.
7. Los mismos incidentes aparecen una y otra vez
El patrón es conocido: ocurre un incidente, se aplica un fix, producción vuelve y el equipo retoma lo urgente. Semanas después aparece el mismo fallo con otra forma.
Nadie ignora deliberadamente la causa raíz. Simplemente no queda tiempo. El siguiente despliegue, alerta o petición consume la ventana en la que podrían haberse introducido hardening, automatización, mejores señales o una prueba de recuperación.
Romper el ciclo requiere reservar capacidad para:
- análisis de causa raíz proporcionado al impacto;
- acciones correctivas con owner y fecha;
- automatización de comprobaciones y recuperación;
- mejoras de observabilidad;
- documentación de decisiones y procedimientos;
- diseño de resiliencia donde el riesgo lo justifique.
El equipo necesita tiempo para mejorar el sistema, pero el propio sistema consume todo su tiempo.
Este es uno de los indicadores más fuertes de deuda operacional. Contratar puede abrir espacio para corregirla, pero solo si ese es un objetivo explícito. Si la nueva persona entra directamente en la misma rotación reactiva, el ciclo continúa con una cola algo mayor.
Entonces, ¿cuándo deberías contratar?
Contratar tiene sentido cuando la necesidad es estructural y permanente.
Por ejemplo, cuando existe crecimiento sostenido de productos y equipos; hay volumen suficiente para ownership continuo; se crea una función interna de Platform Engineering o SRE; aumentan requisitos regulatorios o de disponibilidad; o las responsabilidades seguirán existiendo después de resolver los cuellos de botella actuales.
En esos casos importa definir el puesto por los resultados y responsabilidades que tendrá, no por la lista de herramientas que conoce. ¿Será owner de la plataforma? ¿Construirá caminos internos para desarrollo? ¿Liderará fiabilidad? ¿Asumirá operación continuada? ¿Qué decisiones podrá tomar?
La consultoría DevOps y una contratación interna no son alternativas universales. Pueden ser fases distintas: primero entender y estabilizar; después incorporar ownership permanente con un contexto más limpio.
El objetivo no debería ser evitar contrataciones. Debería ser contratar cuando realmente existe una necesidad permanente.
¿Y cuándo puede tener más sentido un proyecto externo?
Hay problemas importantes que no justifican por sí solos un puesto permanente:
- arreglar CI/CD;
- estabilizar Kubernetes;
- ejecutar una migración;
- revisar costes cloud;
- eliminar una dependencia crítica;
- automatizar infraestructura;
- preparar una plataforma para una auditoría;
- mejorar observabilidad.
En estos casos puede tener sentido incorporar capacidad senior durante un periodo limitado con cuatro responsabilidades claras: resolver, documentar, transferir y salir.
El alcance debe incluir criterios de aceptación, acceso a los repositorios y cuentas pertinentes, decisiones registradas y una transferencia que el equipo pueda comprobar. Si el proveedor se convierte en la nueva persona imprescindible, el proyecto no ha resuelto la dependencia: la ha movido.
No estás cubriendo una silla. Estás resolviendo un problema.
Eso no hace pequeño el problema. Una migración o una estabilización de Kubernetes puede ser crítica para el negocio. Solo significa que su intensidad y especialización no tienen por qué mantenerse indefinidamente.
10 preguntas antes de abrir otra vacante DevOps
Esta conversación mejora cuando se apoya en preguntas concretas:
- ¿Qué está consumiendo realmente el tiempo del equipo?
- ¿Cuánto de ese trabajo es repetitivo?
- ¿Qué tareas pueden automatizarse?
- ¿Qué depende actualmente de una sola persona?
- ¿Qué proyectos están bloqueados por infraestructura?
- ¿Los despliegues son realmente autónomos?
- ¿Las incidencias se repiten?
- ¿La observabilidad permite diagnosticar rápidamente?
- ¿Existe suficiente trabajo permanente para justificar otro FTE?
- Si resolviéramos los principales cuellos de botella, ¿seguiríamos necesitando otra persona?
No hace falta responderlas con precisión falsa. Basta con revisar tickets, interrupciones, incidencias, tiempos de espera y trabajo planificado durante varias semanas. La evidencia suele mostrar si el equipo necesita más capacidad o si necesita que la infraestructura genere menos trabajo.
Son afirmaciones distintas:
- «Necesitamos más capacidad».
- «Necesitamos que nuestra infraestructura genere menos trabajo».
Pueden ser ciertas a la vez. Lo importante es no tratarlas como si fueran la misma decisión.
No todo problema de infraestructura necesita otra contratación
A veces sí necesitas ampliar el equipo. Si existe ownership permanente y un backlog duradero, posponer la contratación solo trasladará presión a las personas actuales.
Pero otras veces necesitas capacidad senior durante unas semanas para eliminar un cuello de botella, estabilizar una plataforma, automatizar, resolver deuda operacional, documentar y transferir conocimiento.
Después, el equipo continúa con una infraestructura que exige menos intervención y una idea más clara del trabajo que permanece.
Esa distinción puede evitar contratar alrededor de problemas que en realidad deberían desaparecer.
