El Site Reliability Engineer (SRE) es el perfil que se encarga de que un sistema siga funcionando cuando todo lo demás falla. Mide la confiabilidad con SLI y SLO, automatiza la operación y decide cuánto riesgo puede asumir un equipo antes de frenar los deploys. Con la IA moviéndose de los demos a producción, se volvió uno de los roles de infraestructura más buscados del mercado.

Durante años, las empresas trataron la estabilidad como un problema que se resolvía sumando gente de guardia. Esa lógica se rompió cuando los productos empezaron a depender de modelos de IA que consumen GPU, disparan costos impredecibles y fallan de formas nuevas: latencias que se disparan, respuestas degradadas, colas de inferencia saturadas. Ahí aparece el SRE, un perfil que viene de la ingeniería de software pero que aplica esa mentalidad a la operación.

Qué hace exactamente un Site Reliability Engineer

La definición original la acuñó Google: un SRE es lo que pasa cuando le pedís a un desarrollador de software que diseñe la operación de un sistema. En lugar de resolver incidentes a mano, escribe código para que no vuelvan a ocurrir.

En el día a día, un SRE trabaja sobre cinco frentes:

• Definir objetivos de confiabilidad. Traduce "el sistema tiene que andar bien" a números concretos: SLI (qué se mide), SLO (qué nivel se compromete) y error budget (cuánta falla es aceptable antes de frenar lanzamientos).

• Observabilidad. Instrumenta métricas, logs y trazas distribuidas para que cualquier persona del equipo pueda entender qué está pasando sin adivinar.

• Automatización del trabajo repetitivo. Todo lo que se hace más de dos veces por mes se convierte en script, pipeline o runbook automatizado.

• Gestión de incidentes y postmortems. Coordina la respuesta cuando algo se cae y después documenta la causa raíz sin buscar culpables.

• Capacity planning y costos. Proyecta cuánta infraestructura hace falta y cuánto va a costar, algo crítico cuando el gasto en cómputo de IA puede duplicarse en un mes.

La diferencia real entre SRE y DevOps

La confusión es constante y tiene una explicación simple: los dos roles tocan las mismas herramientas. La diferencia está en el foco.

DevOps responde "cómo llevamos esto a producción más rápido". SRE responde "cuánta velocidad podemos sostener sin romper la promesa que le hicimos al usuario". Si venís del mundo de la operación y querés entender la base común de ambos perfiles, el recorrido de DevOps con IA: qué hace un DevOps Engineer, cuánto gana y cómo formarse es un buen punto de partida antes de especializarte.

Por qué la adopción de IA disparó la demanda de SRE

Cuando una empresa pasa de un piloto de IA a un producto real, aparecen problemas que la infraestructura tradicional no contemplaba:

• Costo variable y difícil de predecir. Cada llamada a un modelo tiene precio. Un pico de uso o un prompt mal diseñado pueden multiplicar la factura sin que nadie lo note hasta fin de mes.

• Fallas silenciosas. Un modelo no devuelve un error 500: devuelve una respuesta peor. Detectar degradación de calidad requiere métricas que no existían en el stack clásico.

• Dependencia de terceros. Si el proveedor del modelo tiene una caída, el producto se cae con él. Hace falta diseñar fallbacks y circuitos de degradación elegante.

• Latencia como feature. En una app conversacional, tres segundos de espera son una mala experiencia. La performance dejó de ser un detalle técnico.

Ese conjunto de problemas es exactamente el terreno del SRE. Según el Future of Jobs Report del World Economic Forum, los roles vinculados a IA, big data y seguridad de sistemas encabezan las proyecciones de crecimiento de empleo tecnológico de la década, y la confiabilidad de la infraestructura es la capa que sostiene a todos ellos.

Cuánto gana un SRE en Argentina

Los rangos varían mucho según el tipo de empleador. Estas son las bandas que se observan hoy en el mercado local:

• Semi senior (2 a 4 años): posiciones en empresas locales y fintech regionales, con foco en on-call, observabilidad y automatización de despliegues.

• Senior (5+ años): el grueso de la demanda. Se espera que definas SLO, lideres postmortems y diseñes la estrategia de resiliencia.

• Staff / Principal: roles escasos, generalmente en empresas con equipos de plataforma consolidados.

El factor que más mueve la aguja no es la seniority sino la moneda: buena parte de las vacantes de SRE en Argentina son para empresas de Estados Unidos o Europa que contratan en dólares. Los datos agregados de Glassdoor muestran una brecha significativa entre las bandas locales y las internacionales para el mismo nivel de experiencia, algo que también se refleja en roles vecinos como el de Cloud Architect.

Qué mira un empleador al evaluar un perfil SRE

• Experiencia real operando sistemas en producción, no solo levantando entornos.

• Dominio de al menos una nube (AWS, Azure o Google Cloud) y de Kubernetes.

• Infraestructura como código: Terraform, Pulumi o equivalente.

• Capacidad de programar de verdad: Python o Go, no solo bash.

• Historias concretas de incidentes: qué pasó, cómo lo diagnosticaste, qué cambiaste después.

Cómo formarte para ser Site Reliability Engineer

No existe una carrera universitaria de SRE. El camino habitual arranca en desarrollo backend, infraestructura o soporte técnico avanzado, y se construye por capas:

1. Base de programación. Sin capacidad de escribir software mantenible, el rol se vuelve operación manual con otro nombre.

2. Linux, redes y sistemas distribuidos. Entender qué pasa debajo de la abstracción de la nube.

3. Cloud y contenedores. Una nube en profundidad es mejor que tres en superficie. Si estás decidiendo por dónde empezar, la comparación entre AWS, Azure y Google Cloud ayuda a elegir sin dar vueltas.

4. Observabilidad y confiabilidad. Prometheus, Grafana, OpenTelemetry y la práctica de definir SLO.

5. Automatización con IA. Cada vez más equipos usan agentes para triage de alertas, generación de runbooks y análisis de logs.

Cursos recomendados de Coderhouse

Si querés construir ese recorrido de forma ordenada, hay tres puntos de entrada según el punto de partida:

• Curso de DevOps & Cloud (nivel avanzado). Es el más directo hacia el rol: cubre contenedores, CI/CD, infraestructura como código y operación en la nube, la base técnica que cualquier SRE necesita dominar.

• Carrera de Desarrollo Backend (nivel inicial). Si todavía no programás con soltura, este es el paso previo. Un SRE sin base de software termina haciendo operación manual.

• Curso de AI Automation (nivel inicial). Suma la capa de automatización con IA que hoy diferencia a los perfiles de infraestructura: agentes que analizan alertas, resumen incidentes y ejecutan respuestas repetitivas.

Si tu objetivo es entrar al rol en los próximos meses, empezá por el curso de DevOps & Cloud y sumá automatización con IA en paralelo: esa combinación es la que hoy diferencia un CV en la pila de candidatos.

Preguntas frecuentes

¿Necesito ser programador para ser SRE?

Sí, y es el filtro que más candidatos deja afuera. No hace falta que hayas trabajado como desarrollador de producto, pero tenés que poder escribir código mantenible en Python o Go, versionarlo y testearlo. La automatización es el corazón del rol.

¿Un SRE hace guardias?

Casi siempre sí, en esquemas rotativos. La diferencia con un rol de soporte es que el SRE tiene el mandato explícito de reducir la carga de guardia: si un equipo se pasa la noche apagando incendios, eso se considera una falla del sistema, no una tarea normal.

¿Cuánto tiempo lleva pasar de desarrollador backend a SRE?

Entre nueve y dieciocho meses de trabajo enfocado es un rango realista si ya programás. El camino más rápido suele ser interno: pedir participar en la rotación de guardias de tu equipo actual, tomar el ownership de la observabilidad de un servicio y construir experiencia real de producción.

¿Qué diferencia hay entre SRE y Platform Engineer?

El SRE optimiza la confiabilidad de los servicios en producción; el Platform Engineer construye la plataforma interna que usan los equipos de desarrollo para llegar a producción. En empresas chicas suele ser la misma persona; en empresas grandes son dos equipos con objetivos distintos.

¿Sirve certificarse en alguna nube?

Ayuda a pasar filtros de reclutamiento, sobre todo en consultoras y en procesos internacionales, pero no reemplaza la experiencia operando sistemas reales. Una certificación acompañada de proyectos concretos y postmortems documentados pesa mucho más que la certificación sola.