Son las 2 AM y tu teléfono suena. No es un feature roto: es latencia en el percentil 99, que viene subiendo desde hace tres horas y nadie lo vio hasta que un cliente grande escribió a soporte. Abres el dashboard, correlacionas tres servicios, encuentras que un deploy de hace dos días saturó una conexión a base de datos que solo se nota bajo carga real. Lo arreglas en cuarenta minutos. A la mañana siguiente no escribes un postmortem para culpar a nadie: escribes uno para que ese tipo de falla se vuelva estructuralmente menos probable.
Eso es un día de trabajo normal para un site reliability engineer. Y cada vez hay más devs senior en LATAM que, al ver ese día completo, dicen "quiero eso" en lugar de "qué pesadilla".
Site reliability engineer no es un rebranding de DevOps
Esta es la confusión más común y la que hay que sacar del medio más rápido. DevOps es una cultura y un conjunto de prácticas: acercar desarrollo y operaciones, automatizar el pipeline, romper silos. No es un puesto con una definición operativa estricta, y por eso terminó significando cosas distintas en cada empresa que lo usa.
Site reliability engineering, en cambio, nació en Google como una disciplina con métricas concretas y reglas de decisión explícitas. Un site reliability engineer no "ayuda a que dev y ops se lleven mejor". Gestiona la confiabilidad de un sistema como si fuera una feature con presupuesto propio, con números que determinan cuándo se frena el trabajo de producto y cuándo no.
La diferencia no es cosmética. Un ingeniero de DevOps puede pasar el día escribiendo Terraform y armando pipelines de CI/CD sin tocar nunca un error budget. Un SRE con el mismo stack en las manos toma decisiones distintas porque su trabajo se mide de manera distinta. Puedes tener el título de "DevOps engineer" y hacer trabajo de SRE, y viceversa. El título importa menos que la lógica de decisión que hay detrás.
El error budget es lo que cambia cómo piensas el trabajo
Acá está el concepto que de verdad separa a un site reliability engineer de un backend dev tradicional, y es más simple (y más incómodo) de lo que suena.
Se define un SLO (service level objective): por ejemplo, 99.9% de disponibilidad mensual. Eso deja un margen de falla permitido, el error budget: en este caso, un 0.1% del tiempo puedes estar caído sin romper la promesa. Ese presupuesto no es un accidente contable, es una herramienta de decisión.
Si el error budget está intacto, el equipo de producto puede lanzar features agresivamente, tomar riesgos, iterar rápido. Si el error budget se agotó, la conversación cambia: se frenan los nuevos lanzamientos y el foco se centra en la estabilidad, sin necesidad de una discusión política sobre “quién tiene razón”. El número decide.
Esto es genuinamente bueno porque saca la ideología de la sala. No hay una guerra eterna entre "queremos velocidad" y "queremos estabilidad": hay un dato que indica cómo está el sistema ahora. Donde falla es cuando una empresa adopta el vocabulario (dice “tenemos SLOs”) sin adoptar la disciplina real de frenar los lanzamientos cuando se agota el presupuesto. Ahí el error budget es una frase en un slide, no una herramienta.
Las guardias de un site reliability engineer no son las de cualquier equipo
Todo equipo de backend con producción en vivo tiene algún tipo de guardia. Lo que cambia con un site reliability engineer es el volumen y la naturaleza de lo que lo despierta.
En un equipo de producto bien armado, la guardia debería ser mayormente silenciosa: alertas raras, bien calibradas, que corresponden a problemas reales. En la práctica, muchos equipos terminan con alertas ruidosas, guardias que interrumpen el sueño por cosas que se autorresuelven, y “vamos a arreglarlo la próxima sprint”, que nunca llega. Un site reliability engineer que hace bien su trabajo ataca justamente eso: cada alerta que suena y no requiere acción humana es una alerta mal configurada, y se trata como una deuda técnica real, no como ruido de fondo aceptable.
La parte que hay que decir sin vueltas: si tu organización no invierte en reducir el ruido de las alertas, ser SRE ahí es guardia de noche con nombre elegante. El rol no te protege de una cultura de incidentes disfuncional. Al contrario, te pone en el centro de ella. Antes de aceptar un puesto de site reliability engineer, pregunta específicamente cuántas veces suena la guardia por semana y qué porcentaje de esas alertas terminó en una acción real. Si nadie tiene ese número, es una señal.
Las métricas de éxito son otras, y eso cambia el día a día
Un backend dev senior suele medirse (formal o informalmente) por features entregadas, calidad de código, velocidad de desarrollo. Un site reliability engineer se mide por cosas que, cuando el trabajo está bien hecho, se notan por su ausencia: tiempo medio de detección, tiempo medio de resolución, número de incidentes recurrentes, tendencia del error budget a lo largo del tiempo.
Otra métrica que cambia el terreno: toil, o trabajo operativo manual y repetitivo que no escala. Un SRE serio mide cuánto de su tiempo es toil y trabaja activamente para reducirlo mediante la automatización. Si en tu rol la mayor parte del tiempo consiste en reiniciar servicios a mano y responder tickets repetidos sin automatizar nunca la causa, no estás haciendo site reliability engineering. Estás haciendo soporte técnico con acceso a producción.
Dónde el rol es un buen salto de carrera y dónde no
Acá la opinión, sin maquillaje.
Es un excelente fit si te gusta pensar en sistemas completos más que en features aisladas, si te motiva la elegancia de resolver una clase de problema en lugar de un ticket puntual, y si tienes tolerancia real (no aspiracional) a la presión de un incidente en curso. También es un buen camino si quieres diversificar de "sé escribir features" a "sé mantener sistemas complejos vivos", que es una habilidad que se paga bien y escasea más de lo que parece en el mercado senior.
No es un buen fit si buscas el rol para escapar de la ansiedad por las fechas límite de los productos. Vas a cambiar las deadlines de sprint por incidentes que no eligen su horario, y para mucha gente eso es objetivamente peor, no mejor. Tampoco es un buen fit si tu interés real es la automatización y la infraestructura pero no te importa la disponibilidad del sistema en sí: ese perfil está mejor servido por un rol de platform engineering, que comparte herramientas con SRE pero no comparte el mismo compromiso con SLOs y guardias.
Hay una versión más suave de ese error que es fácil pasar por alto: asumir el rol de SRE en una empresa que se toma en serio el SRE en el discurso, pero que todavía está construyendo la práctica real. Eso no es automáticamente una mala señal: alguien tiene que construir esa práctica desde cero, y hacerlo es un tipo de trabajo interesante en sí mismo. El error es aceptar ese puesto esperando encontrar la versión madura del rol desde el primer día, y quemarse cuando los primeros seis meses se dedican sobre todo a construir herramientas y convencer al resto de la organización, en vez del trabajo de sistemas profundo que buscabas.
Y hay una trampa específica del mercado actual: muchas empresas publican vacantes de "site reliability engineer" que en la práctica son "sysadmin con Kubernetes y sin presupuesto de error budget real". Antes de aceptar, pide ver (o al menos que te describan) el dashboard de SLOs actual del equipo. Si no existe, no estás entrando a un rol de SRE. Estás entrando a un rol de operaciones con un título más atractivo en LinkedIn.
El site reliability engineering real es una disciplina con reglas, no una vibra. Si la empresa tiene esas reglas y las respeta, es de los roles técnicos más interesantes que existen hoy para un senior que ya se aburrió de escribir features. Si no las tiene, es guardia sin límites con un mejor nombre. La diferencia entre esas dos cosas no radica en el título del puesto. Está en si alguien, en algún lugar de la organización, puede mostrarte un número.
