Un despliegue rompe la métrica de latencia a las tres de la madrugada. El equipo de desarrollo ya se ha ido a dormir, la alerta salta sola y alguien tiene que decidir, sin nadie a quien preguntar, si el error entra dentro del margen aceptable o si toca revertir. Ese alguien es, casi siempre, un SRE. No es una etiqueta de moda: es el puesto que existe precisamente para ese momento.
El problema real no es que falte gente que sepa Kubernetes. Es que la mayoría de los equipos confunden "tener DevOps" con "tener a alguien que responda cuando todo se cae", y eso es exactamente el hueco que cubre un Site Reliability Engineer. Esta guía explica qué hace de verdad, qué lo distingue de un ingeniero DevOps genérico y qué mirar antes de incorporar uno a tu equipo.
TL;DR. Un Site Reliability Engineer (SRE) aplica ingeniería de software a la fiabilidad de un sistema en producción: automatiza operaciones, gestiona incidentes y decide cuánto riesgo puede asumir un despliegue según un presupuesto de errores acordado. No es sinónimo de DevOps engineer, aunque el mercado español los agrupe en la misma banda salarial. La diferencia real está en el día a día: guardias, SLO y autoridad para frenar un lanzamiento si el sistema no lo aguanta.
¿De dónde viene el rol de SRE (y qué resuelve)?
Site Reliability Engineering nació dentro de Google a mediados de los 2000, cuando el equipo de infraestructura se dio cuenta de que pedirle a un administrador de sistemas tradicional que sostuviera servicios de escala planetaria no funcionaba: hacía falta alguien con criterio de ingeniería de software aplicado a la operación, no solo a la escritura de código. La regla que quedó de esa época sigue vigente: un SRE reparte su tiempo entre resolver incidentes y automatizar para que ese incidente no vuelva a repetirse.
Eso resuelve un problema muy concreto. Sin un dueño explícito de la fiabilidad, cada incidente se convierte en una discusión ad hoc entre desarrollo y operaciones sobre de quién es la culpa. Con un SRE, existe un acuerdo previo (el presupuesto de errores) que decide cuándo se frena el ritmo de despliegues y cuándo se acelera, sin necesidad de reabrir esa discusión cada vez que algo se rompe.
¿En qué se diferencia un SRE de un ingeniero DevOps?
DevOps es una práctica de equipo: la cultura y el proceso que unen desarrollo y operaciones para entregar cambios más rápido. SRE es un puesto concreto dentro de esa práctica, con un mandato más estrecho y más medible: sostener la fiabilidad del sistema en producción con datos, no con guardia intuitiva. Puedes tener DevOps sin tener un SRE dedicado. Lo raro es lo contrario: un SRE que no opere dentro de una cultura razonablemente DevOps.
La frontera se nota en el criterio de éxito. Un ingeniero DevOps se mide, en gran parte, por la velocidad de entrega: cuántos despliegues salen al día sin romper nada. Un SRE se mide por si el sistema sigue en pie después de esos despliegues, con datos de disponibilidad y latencia que respaldan la respuesta. Ver el detalle completo de dónde empieza y termina cada rol en qué es DevOps ayuda a no confundir la práctica con la silla.
¿Qué métricas maneja un SRE: SLI, SLO, SLA y error budget?
Cuatro siglas ordenan el trabajo diario de un SRE, y sin ellas la conversación sobre fiabilidad se queda en sensaciones. Un SLI (Service Level Indicator) es la medición concreta: latencia, tasa de error, tiempo de actividad. Un SLO (Service Level Objective) es el objetivo interno que el equipo se fija sobre ese indicador, por ejemplo un 99,9% de peticiones respondidas en menos de 300 milisegundos. Un SLA (Service Level Agreement) es el compromiso contractual con el cliente, casi siempre menos exigente que el SLO interno, porque deja margen antes de incumplir lo prometido de verdad.
| Métrica | Qué mide | Quién la usa |
|---|---|---|
| SLI | Dato real observado (latencia, errores, disponibilidad) | El equipo de SRE, en tiempo real |
| SLO | Objetivo interno sobre ese dato | Ingeniería y producto, para priorizar trabajo |
| SLA | Compromiso contractual con el cliente | Legal y ventas, casi siempre más laxo que el SLO |
| Error budget | Margen de fallo permitido antes de incumplir el SLO | Todo el equipo, para decidir si se despliega o se frena |
El presupuesto de errores es la pieza que de verdad cambia el comportamiento del equipo. Si el sistema va sobrado de margen, el equipo de desarrollo puede lanzar features nuevas sin pedir permiso. Si el presupuesto se agota, los lanzamientos se congelan hasta recuperar el margen, y esa regla la marca el dato, no una discusión de pasillo entre el responsable de producto y el de infraestructura.
¿Cuáles son las responsabilidades diarias de un SRE?
La mitad operativa incluye guardias rotativas, respuesta a incidentes y post-mortems sin buscar culpables, solo causas raíz. La otra mitad es escribir código: scripts que automatizan lo que ayer se hacía a mano, paneles de monitorización que anticipan el problema antes de que despierte a alguien a las tres de la madrugada, y herramientas internas que reducen el "toil", el trabajo operativo repetitivo que no deja ningún aprendizaje detrás.
- Guardia e incidentes. Detectar, mitigar y documentar caídas, con un post-mortem que se lee después, no que se archiva.
- Automatización. Convertir cualquier tarea manual recurrente en un script o un pipeline, para que nadie vuelva a repetirla a mano.
- Capacidad y coste. Prever cuánto cómputo hará falta el trimestre que viene, antes de que el pico de tráfico obligue a improvisar.
- Observabilidad. Instrumentar el sistema con métricas, logs y trazas hasta que un fallo se pueda diagnosticar sin adivinar.
Ningún día se parece del todo al anterior, pero la proporción entre las dos mitades sí se sostiene: si un SRE pasa más del 50% de su tiempo apagando fuegos, algo en el diseño del sistema está fallando, no solo la suerte.
¿Cómo evaluar a un candidato SRE antes de contratarlo?
La entrevista técnica estándar de "explícame qué es un SLO" filtra poco: cualquiera con dos artículos leídos responde bien esa pregunta. Lo que separa a un SRE con experiencia real de uno que solo conoce la teoría es cómo describe un incidente que gestionó de verdad: qué señal lo alertó primero, qué decisión tomó bajo presión y qué automatización construyó después para que no volviera a pasar. Si la respuesta se queda en "seguimos el runbook", falta la mitad del criterio que hace falta.
Un checklist corto que sí funciona: pedir un caso concreto de gestión de presupuesto de errores (no la definición, el caso), revisar si tiene experiencia operando el stack que ya usas (Kubernetes, Terraform, Prometheus, el cloud que corresponda) y verificar si alguna vez ha tenido que decirle que no a un lanzamiento por motivos de fiabilidad, no de calendario. Esa última pregunta filtra más que cualquier certificación.
¿Cuándo conviene un SRE senior in-house frente a un blended team?
Un SRE senior a tiempo completo tiene sentido cuando la plataforma ya es lo bastante grande como para necesitar dedicación exclusiva a la fiabilidad: varios servicios en producción, guardias reales y un roadmap de infraestructura que no cabe en el tiempo libre de un desarrollador. El problema aparece cuando la organización todavía no está en ese punto, pero necesita el criterio de un SRE para diseñar bien desde el principio: ahí un perfil a tiempo completo se infrautiliza, y contratarlo mal sale caro dos veces.
Ahí es donde funciona un blended team: talento certificado en skills IA e infraestructura que se integra con el equipo interno el tiempo que dura el diseño de la plataforma de observabilidad o la migración a un modelo de guardias real, sin quedarse como coste fijo cuando la fase intensiva termina. El criterio técnico entra desde fuera; la propiedad del sistema se queda dentro. Si necesitas dimensionar ese equipo completo, formar un equipo de GitOps y CI/CD para enterprise desarrolla cómo encaja el SRE junto al resto de roles de la plataforma.
Preguntas frecuentes sobre el rol de SRE
- ¿Necesito contratar un SRE si ya tengo un equipo DevOps?
Depende de si alguien ya posee explícitamente la fiabilidad del sistema con métricas y presupuesto de errores. Si esa responsabilidad está repartida de forma difusa entre varios desarrolladores, un SRE dedicado suele reducir el tiempo de resolución de incidentes más que sumar otro perfil DevOps genérico.
- ¿Cuánto gana un SRE en España?
El SRE comparte banda salarial con el ingeniero DevOps senior en la mayoría de fuentes de mercado españolas. El desglose completo por nivel, con las fuentes primarias, está recogido en la guía de salario de ingeniero DevOps en España.
- ¿Qué certificaciones valen para un SRE?
Ninguna certificación sustituye a un incidente real gestionado, pero la CKA (Certified Kubernetes Administrator) y las certificaciones de arquitectura de AWS, Azure o Google Cloud acreditan la base técnica que el puesto exige. Se valoran como filtro inicial, no como criterio final de contratación.
- ¿La IA está sustituyendo al rol de SRE?
No, lo está reforzando. Los sistemas de IA ayudan a triar alertas y a sugerir causas raíz más rápido, pero la decisión de frenar un despliegue o asumir el riesgo sigue siendo de un humano con criterio de negocio, no del modelo que detecta la anomalía.
- ¿Qué diferencia a un SRE de un Platform Engineer?
El SRE se centra en la fiabilidad del sistema en producción; el Platform Engineer construye la plataforma interna sobre la que el resto de equipos despliega. En muchas organizaciones conviven y comparten herramientas, pero el primero responde por el incidente y el segundo por la infraestructura que lo hace posible.
Un SRE no es un título que se añade a una oferta de empleo para sonar moderno. Es la persona que asume, con datos y no con intuición, la pregunta que nadie más quiere responder a las tres de la madrugada: ¿asumimos el riesgo o frenamos? Si tu plataforma ya hace esa pregunta y todavía no tiene quién la responda con criterio, ese es el hueco que hay que cubrir antes que ningún otro.
Shakers funciona como infraestructura de contratación de talento certificado en skills IA e infraestructura: incorpora perfiles SRE verificados por proyecto real, sin quedarte con coste fijo cuando la fase intensiva de diseño termina. Si ya sabes qué perfil necesitas, puedes revisar el directorio de expertos en Site Reliability Engineering o el de ingenieros de sistemas certificados por Shakers.