SRE: mercado

Vacante

un empleo abierto que superó el filtro de calidad y menciona al menos dos tecnologías

Candidato observado

un candidato cuyo stack contiene esta tecnología; es un agregado: ni un solo registro sale del perímetro

Candidato emparejable

aún no contabilizado

Ventana

empleos abiertos en el momento en que se generó el snapshot

Junior SRE es raro (entrada típica: DevOps Middle / Backend Middle + interés por la fiabilidad). El salto de Junior a Middle: tras resolver el primer incidente en producción + configurar el primer SLO de un servicio. De Middle a Senior: responsabilidad sobre SLO de varios servicios + dominio de las guardias (responsabilidad sobre las métricas Mean Time to Detect / Recovery) + programación de automatización a nivel Backend Middle/Senior. De Senior a Staff / Principal: estrategia de fiabilidad de toda la organización + liderazgo de la cultura de ingeniería de producción + mentoría técnica. Trayectoria: DevOps Middle (2-3 años) → SRE Junior / Middle (1-2 años) → Senior → luego Staff / Principal SRE, Engineering Manager (SRE), paso a Backend Distributed Systems Senior o especialización en Chaos Engineering o Performance Engineering.

La distinción original de Google (libro Site Reliability Engineering): DevOps es una cultura / filosofía («romper los silos entre Dev y Ops»). SRE es una implementación concreta de la filosofía DevOps mediante prácticas específicas: SLI / SLO / presupuestos de error + reducción del trabajo repetitivo + automatización primero + 50% del tiempo en ingeniería frente a trabajo operativo + post-mortems sin culpables. SRE = «lo que pasa cuando le pides a un ingeniero de software que diseñe un equipo de operaciones». Realidad práctica 2026: un 70% de solapamiento a nivel de stack (ambos usan K8s + Terraform + Prometheus + Grafana). Diferencias observables en empresas de producto: 1) Profundidad de programación: el SRE escribe más herramientas propias en Go / Python (lógica de autoescalado, automatización de despliegues, algoritmos de planificación de capacidad). El DevOps Engineer configura más a menudo herramientas existentes. 2) Disciplina de SLI / SLO: el SRE es responsable de la arquitectura de SLO (Pyrra / OpenSLO / Sloth), de aplicar la política de presupuesto de error y de alertas ajustadas a la tasa de consumo del SLO. DevOps a menudo configura la monitorización sin SLO formales. 3) Dominio de las guardias: el SRE está en una rotación de guardias regular (24×7 para servicios críticos), más fuerte en la dirección de incidentes + la facilitación de post-mortems. El DevOps Engineer suele hacer guardias solo para su propio producto. 4) Regla del 50% de ingeniería: política de Google: un SRE no debe dedicar más del 50% del tiempo a trabajo operativo; el resto es automatización de ingeniería. El DevOps Engineer no tiene esa salvaguarda. 5) Teoría de sistemas distribuidos: las entrevistas de SRE suelen incluir el teorema CAP / algoritmos de consenso / modelos de consistencia / análisis de modos de fallo. Las entrevistas de DevOps son más de herramientas prácticas. En las startups esta diferenciación suele estar difuminada (una persona = DevOps y SRE a la vez).

SLI (Service Level Indicator): una métrica medible de la salud del servicio (disponibilidad / latencia / tasa de errores / throughput). SLO (Service Level Objective): un valor objetivo para un SLI (p. ej., 99.9% de disponibilidad en 30 días). SLA (Service Level Agreement): un compromiso contractual con los clientes (normalmente más laxo que el SLO, p. ej., 99.5% si el SLO es 99.9%, para mantener un margen de seguridad). Presupuesto de error = 100% − SLO. Si el SLO es 99.9% en 30 días → presupuesto de error = 0.1% = 43 minutos de caída al mes. Cuando el presupuesto de error se consume rápido → congelar los despliegues de nuevas funcionalidades y centrar al equipo en trabajo de fiabilidad. Cuando el presupuesto de error está sano → lanzar funcionalidades de forma agresiva. Puesta en marcha práctica del framework (12 pasos): 1) Identificar los recorridos críticos de usuario (CUJ) de cara al cliente. 2) Elegir SLIs para cada CUJ (normalmente disponibilidad + latencia para lo síncrono, throughput + frescura para lo asíncrono). 3) Elegir el objetivo inicial de SLO (regla: ligeramente por debajo del rendimiento actual). 4) Configurar la medición de SLIs (Prometheus + Grafana o un servicio gestionado). 5) Configurar alertas por tasa de consumo (multiventana: consumo rápido 1h a 14.4× la tasa, consumo lento 6h a 6× la tasa: fórmula de Google). 6) Configurar SLO como código (Pyrra / OpenSLO / Sloth) para el control de versiones. 7) Documentar la política de presupuesto de error (qué pasa cuando se agota: ¿congelación de funcionalidades? ¿revisión de incidentes?). 8) Revisión trimestral de SLO (ajuste del objetivo según el rendimiento real + el impacto en el cliente). 9) Seguimiento del trabajo repetitivo + hoja de ruta para reducirlo (objetivo: <50% del tiempo en trabajo repetitivo). 10) Cultura de post-mortems: sin culpables, centrada en acciones concretas. 11) Integración de ingeniería del caos (Gremlin / Chaos Mesh: probar el SLO bajo fallos de antemano). 12) Dashboard de confianza para clientes (página de estado pública: Statuspage / Atlassian / Better Uptime).

Linux / sistemas en profundidad: procesos, namespaces, cgroups, redes (TCP/IP, DNS, balanceo de carga), depuración de rendimiento (strace / perf / eBPF). Stack de observabilidad: Prometheus + Grafana (PromQL en profundidad), trazado distribuido (Tempo / Jaeger / OpenTelemetry), logs (Loki / ELK), APM gestionado (Datadog / Grafana Cloud / Honeycomb): el SRE «ve» el sistema a través de las métricas. Práctica de SLO: SLI / SLO / presupuesto de error (ver la pregunta aparte), alertas por tasa de consumo, SLO como código. Respuesta a incidentes + guardias: PagerDuty / Opsgenie, runbooks, post-mortems sin culpables, evaluación de la gravedad. Kubernetes: operación en producción (nivel CKA): cargas de trabajo, redes, resolución de problemas. IaC + automatización: Terraform / OpenTofu, Ansible; la habilidad clave del SRE es reducir el trabajo repetitivo (trabajo manual que se repite) mediante automatización, objetivo: <50% del tiempo en ese trabajo. CI/CD: despliegues seguros: canary, blue-green, entrega progresiva, rollback. Programación: Python y / o Go a nivel de escribir herramientas de automatización mantenibles, no «scripts». Sistemas distribuidos: modos de fallo, retry / timeout / circuit breaker, idempotencia, consistencia: la base para la planificación de capacidad y el DR. Chaos engineering: Gremlin / Chaos Mesh: comprobar la fiabilidad antes del incidente. Lo principal: el SRE trata la fiabilidad como un producto: la mide (SLO), automatiza la rutina y elimina de forma sistemática las causas de los incidentes en lugar de apagarlos a mano. El inglés es obligatorio: la literatura de SRE (el libro de SRE de Google) y la comunidad son anglófonas.

Sí, el 41% de los empleos de SRE son full-remote o híbridos. El trabajo de SRE — cloud + dashboards de monitoreo. Outsourcers — casi siempre remotos. Las empresas de producto rusas — híbrido o remoto tras el periodo de prueba. Los bancos rusos — híbrido/oficina por el compliance de seguridad. Las empresas tecnológicas internacionales — full-remote estándar. Salvedad específica del SRE: la rotación de on-call — requiere internet fiable + respaldo de energía + un espacio tranquilo para la respuesta a emergencias nocturnas. Algunas empresas exigen una auditoría del home-office antes de una oferta de SRE remoto. Zona horaria — los roles de SRE normalmente requieren solapamiento con la zona horaria principal del equipo (las empresas de EE. UU. suelen querer 4+ horas de solapamiento con PT/ET). Hubs de relocación: Polonia / Alemania / Canadá / Serbia / Georgia. Inglés para el remoto internacional de SRE — obligatorio (incident command en Zoom en inglés bajo estrés).

Production Engineer (PE): el término de Facebook / Meta para SRE. La misma disciplina, responsabilidades casi idénticas: enfoque en fiabilidad + automatización + guardias + planificación de capacidad + sistemas distribuidos. La diferencia es históricamente filosófica: el SRE de Google es «un ingeniero de software que resulta que hace operaciones»; el PE de Facebook, «un ingeniero integrado en un equipo de producto para la fiabilidad». En la práctica de 2026, se solapan casi por completo. Otros títulos equivalentes: Reliability Engineer (LinkedIn), Infrastructure Engineer (a menudo se solapa con SRE), Production Operations Engineer (término legacy). Cómo leer las ofertas de empleo 2026: busca señales en la descripción del puesto: si menciona «SLI/SLO», «presupuestos de error», «reducción del trabajo repetitivo», «50% del tiempo en ingeniería», «post-mortems sin culpables», «rotación de guardias», es un rol de estilo SRE, sea cual sea el título. Si menciona «configuración de CI/CD», «migración a la nube», «infraestructura como código» pero SIN mencionar SLO, es DevOps general.

Hoja de ruta: 1) Base sólida de DevOps: dominio de Linux + Docker + Kubernetes (CKA) + una plataforma cloud a fondo + IaC (Terraform). Sin esta base no tiene sentido ir a SRE. 2) Programación a nivel Backend Middle: Go (el estándar en SRE: Kubernetes / Prometheus / la mayoría de las herramientas de SRE están en Go) o Python a fondo (análisis de datos + scripting). Libros: "The Go Programming Language" de Donovan / Kernighan, "Fluent Python" de Ramalho. 3) El libro "Site Reliability Engineering" de Google (PDF gratuito): lectura obligada, léelo dos veces. 4) "The Site Reliability Workbook" de Google: el complemento práctico (casos + ejercicios). 5) Dominio de SLI / SLO: configura SLO como código (Sloth / Pyrra / OpenSLO) para un servicio real, configura alertas por burn rate (multiventana: rápida 1 h 14.4×, lenta 6 h 6×). 6) Teoría de sistemas distribuidos: teorema CAP, modelos de consistencia (linealizabilidad / secuencial / causal / eventual), consenso (nociones de Paxos / Raft), análisis de modos de fallo. Libros: "Designing Data-Intensive Applications" de Martin Kleppmann (lectura obligada en 2026), "Database Internals" de Petrov. 7) Chaos engineering: Chaos Mesh / Gremlin / LitmusChaos. Monta experimentos de caos en tu propio clúster de K8s. Libro: "Chaos Engineering" de Nora Jones / Casey Rosenthal. 8) Dominio de las pruebas de carga: k6 (moderno, basado en JS, en auge), Gatling (DSL en Scala) o Locust (Python). Monta pruebas de carga integradas en CI. 9) Observabilidad a fondo: Prometheus avanzado (dominio de PromQL + recording rules + federación), Grafana avanzado (plantillas + alertas), Loki + Tempo + OpenTelemetry. Caso de uso: trazado distribuido entre microservicios. 10) Formación en respuesta a incidentes: nociones de incident command, marco de post-mortems sin culpables, comunicación durante los incidentes. Recursos: "Incident Response & Computer Forensics" de Luttgens / Pepe / Mandia, la formación de gestión de incidentes de Google. 11) Proyecto personal: despliega una app distribuida en K8s con configuración completa de SLO + experimentos de caos + simulación de guardias. Documéntalo como un sistema listo para producción. Cursos rusos: Slurm SRE, Otus "SRE", Karpov.Courses SRE Track. Internacional (EN): "Database Reliability Engineering" de Campbell / Majors, charlas de USENIX SREcon (gratis en YouTube), Google Cloud SRE Certification Path. De DevOps Middle + interés a SRE Junior: 4-10 meses (hay que reforzar la programación + la teoría de sistemas distribuidos).

701 active open SRE positions — premium segment of the DevOps direction. Geography: the US, India, the UK. The real market is broader thanks to a huge international remote segment. Time to close a Senior SRE role — 6-12 weeks (longer than general DevOps due to rare-skill requirements: programming + distributed systems + on-call mastery combination).

Un Senior SRE es responsable del ciclo completo de ingeniería de fiabilidad + liderazgo técnico. Programación a nivel backend Middle+: dominio de Go (estándar para la automatización SRE) o Python a fondo, al nivel de «puedo escribir lógica de autoescalado / algoritmos de planificación de capacidad / operators de K8s personalizados de calidad de producción». Dominio profundo de Kubernetes: a escala de producción (nodos), Operators (Kubebuilder / Operator SDK), CRDs personalizados, patrones multi-tenant. Teoría de sistemas distribuidos: comprensión profunda del teorema CAP, modelos de consistencia (linealizable / secuencial / causal / eventual), algoritmos de consenso (Paxos / Raft), taxonomía de modos de fallo, patrones de manejo de particiones de red. Dominio de la observabilidad: Prometheus avanzado (dominio de PromQL + recording rules + federación + remote_write), Grafana avanzado (plantillas + transformaciones + alertas), dominio de la integración de Loki + Tempo + OpenTelemetry, trazas distribuidas entre microservicios. Dominio de la arquitectura de SLI / SLO: SLO-as-code (Pyrra / OpenSLO / Sloth), diseño de la política de presupuesto de errores + automatización de su cumplimiento, ajuste de alertas de burn rate multiventana (evitar la fatiga de alertas). Dominio del mando de incidentes: dirigir la respuesta a incidentes bajo presión, facilitar post-mortems sin culpables, análisis de factores contribuyentes (no de la causa raíz: enfoque moderno), priorización de acciones. Dominio del chaos engineering: Chaos Mesh / Gremlin / LitmusChaos: diseñar experimentos de caos, facilitar GameDays. Dominio de la planificación de capacidad: metodología de pruebas de carga (k6 / Gatling / Locust), modelos de previsión de recursos, análisis de margen, manejo de picos de carga. Ingeniería de rendimiento: optimización guiada por profiling (perf / bpftrace / flamegraphs), diagnóstico de fugas de memoria, ajuste del GC, análisis del rendimiento de red. Service mesh a fondo: Istio / Linkerd / Cilium: gestión del tráfico, políticas de reintento, circuit breakers, inyección de fallos. Diseño de sistemas para la fiabilidad: diseñar en pizarra alta disponibilidad multirregión y multi-AZ, planificación de RPO / RTO, estrategias de DR, arquitectura basada en celdas para limitar el radio de impacto. Soft: redacción de ADRs, comunicación de incidentes (actualizaciones de la página de estado + llamadas con stakeholders en crisis), disciplina en la rotación de guardias, colaboración entre equipos (Backend / DevOps / Plataforma / Seguridad), mentoría a SRE Middle. Inglés para Senior+ IMPRESCINDIBLE: SRE es un rol muy transversal + la comunidad es angloparlante (USENIX SREcon, papers).