Qué hace un Site Reliability Engineer. Google inventó el rol en 2003. Ben Traynor, ingeniero de software de la compañía, se hizo cargo de lo que antes llamaban operaciones y lo transformó aplicando principios de ingeniería de software a los problemas de disponibilidad y fiabilidad de los sistemas.
Hoy el Site Reliability Engineer es uno de los perfiles mejor pagados del sector tech en España. Glassdoor recoge una media de 53.000 euros brutos anuales con 86 sueldos reportados hasta noviembre del año anterior, con un percentil 75 en 72.000 euros y un percentil 90 en 90.800 euros. Las ofertas de LinkedIn para el perfil crecieron un 35% en el último año.
Y sin embargo, sigue siendo uno de los perfiles menos entendidos fuera de los equipos que trabajan con él. Esta guía lo explica con precisión.
Qué es un Site Reliability Engineer y de dónde viene el rol
Un Site Reliability Engineer, conocido por sus siglas SRE, es un ingeniero especializado en garantizar que los sistemas informáticos de una empresa estén siempre disponibles, sean fiables y puedan escalar cuando la demanda crece.
No es un administrador de sistemas que apaga fuegos. Es un ingeniero que diseña sistemas para que los fuegos no ocurran, y cuando ocurren, para que el impacto sea mínimo y controlado.
Google lo define con una frase que resume muy bien el espíritu del rol: SRE es lo que ocurre cuando un ingeniero de software se encarga de lo que antes llamábamos operaciones. La diferencia entre un SRE y un operador de sistemas tradicional es la misma que entre construir una casa y mantenerla: el SRE construye los sistemas que garantizan que la casa no se caiga.
Para entender con detalle en qué se diferencia de un DevOps Engineer y cuándo tiene sentido cada perfil en una organización, el artículo sobre SRE vs DevOps analiza las similitudes y diferencias con criterios concretos.
Los conceptos fundamentales que definen el trabajo de un SRE
El trabajo de un Site Reliability Engineer tiene un vocabulario propio que no existe en otros perfiles tech. Entender estos conceptos es la diferencia entre hablar de SRE y entender realmente qué hace.
SLA, SLO y SLI
Son los tres niveles de acuerdo y medición sobre la fiabilidad de un sistema. El SLA (Service Level Agreement) es el contrato con el cliente o usuario que define qué nivel de servicio se garantiza. El SLO (Service Level Objective) es el objetivo interno que el equipo SRE se marca para garantizar ese SLA.
El SLI (Service Level Indicator) es la métrica concreta que mide si se está cumpliendo el SLO: disponibilidad, latencia, tasa de error. Un ejemplo: el SLA promete un 99,9% de disponibilidad.
El SLO interno se fija en 99,95% para tener margen. El SLI es la medición real de disponibilidad que se registra cada segundo en los sistemas de monitorización.
Error budget
El error budget es el margen de error tolerable antes de violar el SLO. Si el SLO es 99,9% de disponibilidad, el error budget es el 0,1% restante: aproximadamente 8,7 horas de caída permitida al año.
Cuando el error budget se agota, el equipo tiene que tomar una decisión: pausar los despliegues de nuevas funcionalidades y priorizar la fiabilidad. Es un mecanismo que alinea los incentivos de desarrollo y operaciones de forma objetiva, sin necesitar conversaciones difíciles sobre quién tiene la culpa de qué.
Toil
Toil es el trabajo manual, repetitivo y que no escala. Responder siempre a la misma alerta de la misma forma. Reiniciar el mismo servicio cada lunes por la mañana. Aprovisionar servidores uno a uno con los mismos pasos.
El SRE tiene como objetivo explícito reducir el toil por debajo del 50% de su tiempo de trabajo. Lo que no se puede eliminar hoy, se automatiza. Lo que se automatiza hoy, no consume tiempo mañana.
Blameless post-mortem
Cuando un sistema falla en producción, el SRE lidera el post-mortem: el análisis de qué ocurrió, por qué ocurrió y cómo evitar que vuelva a ocurrir. La palabra clave es blameless: sin culpables.
No se busca a la persona que cometió el error. Se busca el fallo del sistema que permitió que ese error tuviera impacto. Es una práctica que mejora la cultura técnica de las organizaciones tanto como la fiabilidad de sus sistemas.
Qué hace un Site Reliability Engineer en su trabajo diario
El día a día de un SRE varía más que el de otros perfiles tech porque combina trabajo proactivo, reactivo y estratégico en proporciones que cambian según el estado del sistema y el momento del ciclo de vida del producto.
Lo que más sorprende a quienes acceden al perfil por primera vez es que la mayor parte del tiempo no se pasa apagando fuegos. Se pasa construyendo los sistemas que evitan que los fuegos ocurran.
Estas son las responsabilidades que aparecen en prácticamente todos los equipos SRE:
- Definir y monitorizar SLOs. Establecer los objetivos de fiabilidad del sistema, medir los SLIs en tiempo real y gestionar el error budget en colaboración con los equipos de producto.
- Gestión de incidencias. Responder a alertas en producción, diagnosticar el problema, coordinarse con el equipo de desarrollo para resolverlo y documentar el post-mortem sin culpables.
- Automatización del toil. Identificar las tareas repetitivas que consumen tiempo del equipo y eliminarlas mediante scripts, herramientas o cambios en la arquitectura del sistema.
- Gestión de capacidad y rendimiento. Anticipar el crecimiento de la carga, planificar el escalado de la infraestructura y garantizar que el sistema no colapse cuando el tráfico se dispara.
- Observabilidad. Construir y mantener los sistemas de monitorización, alertas, logs y trazas que permiten entender el estado del sistema en tiempo real. Sin observabilidad no hay fiabilidad.
- Chaos Engineering. Inyectar fallos de forma controlada en el sistema para verificar que los mecanismos de resiliencia funcionan antes de que un fallo real los ponga a prueba.
- Revisión de arquitecturas. Colaborar con los equipos de desarrollo en el diseño de nuevas funcionalidades para garantizar que no comprometan la fiabilidad ni la escalabilidad del sistema.
- Infraestructura como código. Provisionar y gestionar los entornos de producción con Terraform o Ansible para que sean reproducibles, auditables y consistentes.
Habilidades que necesita un Site Reliability Engineer
Habilidades técnicas
- Linux y sistemas. Base imprescindible. Administración de servidores, gestión de procesos, redes, permisos y depuración de problemas en el sistema operativo.
- Python, Bash y Go. Python y Bash para scripting y automatización de tareas operativas. Go es cada vez más relevante porque es el lenguaje con el que están escritas muchas herramientas del ecosistema SRE: Kubernetes, Prometheus y Terraform, entre otras.
- Kubernetes y Docker. Orquestación de contenedores en producción. Gestión de clústeres, troubleshooting de pods, estrategias de despliegue y gestión de recursos.
- Observabilidad: Prometheus, Grafana y ELK. Métricas con Prometheus, visualización con Grafana, centralización y análisis de logs con el stack ELK. Son las herramientas sobre las que se construye el conocimiento del estado del sistema.
- Infraestructura como código. Terraform para provisionar infraestructura cloud. Ansible para gestión de configuración. La infraestructura que no está en código no es auditable ni reproducible.
- Cloud: AWS, GCP o Azure. Dominar al menos un proveedor cloud en profundidad. Las certificaciones cloud y la certificación CKA de Kubernetes tienen impacto directo y verificable en el salario.
- CI/CD. Integración con los pipelines de despliegue continuo para garantizar que los cambios no degraden la fiabilidad del sistema. Jenkins, GitHub Actions y GitLab CI son los más habituales.
- Ingeniería del caos. Herramientas como Chaos Monkey, Gremlin o LitmusChaos para inyectar fallos de forma controlada y verificar la resiliencia del sistema antes de que un incidente real lo haga.
- Inglés técnico. El SRE book de Google, la documentación de Kubernetes, Prometheus y la mayoría de recursos de calidad sobre SRE están en inglés. Es la infraestructura del aprendizaje continuo en este campo.
Habilidades blandas
El SRE trabaja en la intersección de varios equipos: desarrollo, producto, seguridad y dirección técnica. La capacidad de comunicar el estado del sistema con claridad, de gestionar la presión durante un incidente grave y de escribir post-mortems que mejoran la cultura sin señalar culpables son habilidades que el perfil necesita tanto como el conocimiento técnico.
Y la mentalidad de mejora continua no es opcional. Un SRE que acepta el toil como inevitable deja de ser SRE para convertirse en un operador de sistemas muy bien pagado.
Roadmap para convertirse en Site Reliability Engineer
El SRE es uno de los perfiles con la trayectoria de entrada más clara del sector tech, aunque también uno de los que más base previa requieren. No se llega a SRE desde cero: se llega desde DevOps, desde
administración de sistemas o desde desarrollo de software.
| Punto de partida | Qué tienes | Qué necesitas añadir | Tiempo estimado |
|---|---|---|---|
| DevOps Engineer | CI/CD, Kubernetes, Terraform, cloud | SLOs, error budget, observabilidad avanzada, post-mortems, on-call | 6-12 meses |
| SysAdmin / Infraestructura | Linux, redes, servidores | Scripting en Python/Go, Kubernetes, Terraform, CI/CD, conceptos SRE | 12-18 meses |
| Desarrollador backend | Código, Git, APIs | Linux avanzado, Kubernetes, Terraform, observabilidad, cloud, conceptos SRE | 12-18 meses |
La certificación más relevante del ecosistema SRE es la CKA (Certified Kubernetes Administrator). Junto con las certificaciones cloud de AWS (AWS Certified DevOps Engineer) o Google (Google Professional DevOps Engineer), tienen impacto directo y verificable en el salario. Las empresas que buscan SREs las valoran más que casi cualquier otro certificado.
El SRE book de Google, disponible gratuitamente en línea, es la referencia teórica fundamental del perfil. Cualquier profesional que quiera acceder al rol debería haberlo leído. Para una guía práctica sobre cómo formarse en este perfil, el artículo sobre cómo ser ingeniero SRE detalla el recorrido paso a paso.
Herramientas del stack SRE
| Categoría | Herramienta | Para qué se usa |
|---|---|---|
| Métricas | Prometheus | Recolección y almacenamiento de métricas del sistema |
| Visualización | Grafana | Dashboards de métricas y alertas visuales |
| Logs | ELK Stack / Loki | Centralización, búsqueda y análisis de logs |
| Trazas | Jaeger / Zipkin / OpenTelemetry | Trazabilidad distribuida de peticiones entre servicios |
| Orquestación | Kubernetes | Gestión de contenedores en producción a escala |
| IaC | Terraform / Pulumi | Infraestructura como código en cloud |
| Chaos Engineering | Chaos Monkey / LitmusChaos | Inyección de fallos controlados para probar resiliencia |
| Gestión de incidencias | PagerDuty / OpsGenie | Alertas, on-call y gestión de incidentes |
| Scripting | Python / Bash / Go | Automatización de tareas operativas y reducción del toil |
| Cloud | AWS / GCP / Azure | Infraestructura donde corre el sistema en producción |
Cuánto gana un Site Reliability Engineer en España
El SRE es el perfil mejor pagado del ecosistema DevOps/Cloud en España. La escasez de especialistas que combinen conocimiento de sistemas, desarrollo de software y los conceptos propios de SRE hace que las empresas paguen más por este perfil que por casi cualquier otro en infraestructura.
Glassdoor recoge una media de 53.000 euros brutos anuales con 86 sueldos hasta noviembre de 2025. El percentil 25 está en 39.000 euros, el 75 en 72.000 euros y el 90 en 90.800 euros. Tecnoempleo recoge ofertas de Affirm para SRE senior en el rango de 80.000 a 110.000 euros.
| Nivel | Experiencia | Bruto / año | Neto / mes (aprox.) |
|---|---|---|---|
| Junior SRE | 0-2 años en SRE | 38.000 – 50.000 € | ~2.400 – 2.950 €/mes |
| Mid-level SRE | 2-5 años | 50.000 – 70.000 € | ~2.950 – 3.950 €/mes |
| Senior SRE | 5-10 años | 70.000 – 95.000 € | ~3.950 – 5.200 €/mes |
| Staff / Principal SRE | 10+ años | 90.000 – 120.000 € | ~5.000 – 6.300 €/mes |
Fuentes: Glassdoor (86 sueldos, noviembre 2025) · Tecnoempleo · Freelancermap · Indeed España.
Las empresas que más pagan por SRE en España son compañías tech con productos propios de alto tráfico: fintech, plataformas de e-commerce, empresas de movilidad y grandes corporaciones con infraestructura cloud crítica. El trabajo remoto es la norma y abre acceso a empresas internacionales con salarios significativamente superiores a la media local.
SRE vs DevOps: en qué se parecen y en qué no
La confusión entre los dos perfiles es frecuente incluso dentro de los propios equipos de ingeniería. La diferencia no está en las herramientas, que comparten en gran medida, sino en el enfoque y en la responsabilidad.
[su_columns]Foco en la velocidad y la automatización del ciclo de desarrollo. Construye los pipelines CI/CD, gestiona la infraestructura y elimina los silos entre desarrollo y operaciones. Más orientado al proceso y a la entrega continua.
Foco en la fiabilidad y la disponibilidad. Define SLOs, gestiona el error budget, responde a incidencias en producción y lidera los post-mortems. Más orientado a la medición de la fiabilidad y a la reducción del toil.
En la práctica, muchas empresas medianas tienen un único equipo que hace las dos cosas. Las grandes empresas tech suelen separar los roles porque el volumen de trabajo justifica la especialización. Para la comparativa completa, el artículo sobre SRE vs DevOps analiza los dos perfiles en profundidad.
Cómo empezar: el camino hacia el primer empleo como SRE
El acceso al perfil SRE requiere base técnica previa. No es un perfil de entrada al sector tech: es un perfil de especialización dentro de él. La mayoría de los SREs vienen de DevOps, de administración de sistemas o de desarrollo backend, y dan el salto cuando dominan Kubernetes, Terraform y tienen experiencia real con sistemas en producción.
Lo que marca la diferencia entre un DevOps que trabaja en fiabilidad y un SRE de verdad es el conocimiento de los conceptos propios del rol: SLOs, error budget, toil y post-mortems.
Son los que evalúan en las entrevistas técnicas de las empresas más exigentes. Si tienes base en DevOps y quieres dar ese salto, el artículo sobre cómo convertirse en DevOps Engineer es el punto de partida correcto antes de especializarte en SRE.
Rubén trabajaba como ingeniero de aplicaciones en Barcelona cuando empezó a ver términos como Kubernetes, Terraform y metodología Agile en cada oferta de trabajo que le llamaba la atención. Hizo algunos cursos gratuitos para entender de qué iba y se dio cuenta de que era exactamente lo que quería hacer.
A los pocos meses de terminar el Bootcamp DevOps de KeepCoding, empezó como SRE en Red Hat. Hoy trabaja en producción con Kubernetes y Jenkins en un entorno donde la fiabilidad no es opcional. Su caso demuestra que el sector tech es suficientemente amplio como para que nunca sea tarde para cambiar de disciplina y encontrar dónde encajas mejor.
Para acceder al perfil SRE con la base técnica necesaria, el DevOps y Cloud Computing Full Stack Bootcamp de KeepCoding cubre el recorrido completo en 6 meses.
La referencia teórica fundamental del perfil SRE es el SRE Book de Google, disponible de forma gratuita en línea. Es la lectura que cualquier profesional que quiera acceder al perfil debería haber hecho antes de la primera entrevista.
Conclusión
El Site Reliability Engineer es el perfil que garantiza que los sistemas funcionan cuando la gente los necesita. No apaga fuegos: construye los sistemas que los evitan, y cuando ocurren, los analiza para que no vuelvan a pasar.
Es uno de los perfiles mejor pagados del sector tech en España, con una demanda que no para de crecer y una escasez de especialistas que hace que las empresas compitan por ellos.
El camino de acceso requiere base técnica previa y conocimiento de los conceptos propios del rol. Con esa base, y con la disposición para aprender de los sistemas que fallan en lugar de buscar culpables, el perfil es tan exigente como gratificante.
